[Ffmpeg-devel-irc] ffmpeg-devel.log.20190826

[burek]

[04:59:30 CEST] <cone-193> ffmpeg 03Xuewei Meng 07master:f0c97d613ea7: libavfilter: Add dehaze-filter option in existing derain.
[05:08:28 CEST] <cone-193> ffmpeg 03Steven Liu 07master:4ba82ecc12b7: avformat/hlsenc: fix memleak in hls_write_trailer
[05:08:29 CEST] <cone-193> ffmpeg 03Steven Liu 07master:80d2a7f5c64f: avformat/hlsenc: fix memleak of filename
[05:08:30 CEST] <cone-193> ffmpeg 03Steven Liu 07master:17576fda6546: avformat/hlsenc: remove unused value
[05:10:47 CEST] <cone-193> ffmpeg 03Steven Liu 07master:7c2ff06b6e6a: doc/examples/decode_audio: print message about how to play the output file
[05:10:48 CEST] <cone-193> ffmpeg 03Steven Liu 07master:6d1009cb9d88: doc/examples/decode_video: add input file format information for usage
[07:40:17 CEST] <thardin> morning
[09:11:35 CEST] <cone-879> ffmpeg 03Xuewei Meng 07master:59da9dcd7ef6: avfilter/vf_derain: reindent code after last commit
[12:37:02 CEST] <durandal_1707> how can i encode dupe frames with h264?
[12:37:12 CEST] <JEEB> in what sense?
[12:37:22 CEST] <JEEB> you want the headers that say to duplicate or?
[12:38:01 CEST] <durandal_1707> in sense that 10 fully black frames in a row are encoded
[12:38:51 CEST] <thardin> use a black video source?
[12:39:03 CEST] <thardin> like /dev/zero
[12:43:50 CEST] <thardin> I smell DoS samples
[12:49:50 CEST] <J_Darnley> lavfi color source is another option
[12:58:47 CEST] <durandal_1707> no, i mean in way that they are encoded like skip frames, that qtrle "have"
[12:59:19 CEST] <J_Darnley> I don't know how you force any encoder to do that
[13:00:27 CEST] <durandal_1707> does h264 bitstream have mode to signal skip frames?
[13:01:36 CEST] <durandal_1707> ignoring cases when each 2nd is dupe or something similar for softtelecine crap
[13:07:22 CEST] <durandal_1707> vel0city_netbook: will you add your entry on trac wiki gsoc page?
[13:07:28 CEST] <JEEB> try -x264-params keyint=infinite
[13:08:08 CEST] <JEEB> *keyint=infinite:scenecut=0
[13:08:32 CEST] <JEEB> that should force non-keyframes and then you should see libx264 at least output skips if you feed it identical frames
[13:08:36 CEST] <JEEB> not sure if you can *force* it
[13:08:42 CEST] <JEEB> but that's as close as I could get with it
[13:09:12 CEST] <JEEB> might recommend poking #x264 or #x264dev about it if you really need something like that
[13:09:18 CEST] <JEEB> (And those options don't budge)
[13:14:45 CEST] <durandal_1707> swscale is useless, it does not support bunch of trc
[13:15:20 CEST] <rcombs> is there actual "skip" syntax or is it just "a P-frame with every block referencing the keyframe unchanged"
[13:20:44 CEST] <JEEB> yea it could just be that
[13:21:02 CEST] <JEEB> the AVI thing was on container level I think
[13:21:04 CEST] <JEEB> for mpeg-4 patt 2
[13:21:06 CEST] <JEEB> *part 2
[13:21:18 CEST] <thardin> just try encoding some black video and see what happens
[13:21:22 CEST] <JEEB> yes
[13:21:46 CEST] <JEEB> I kind of recommended that with maknig sure there's no additional I-frames but I'm not sure if he's tried it yet :P
[13:21:56 CEST] <thardin> I looked into very low bitrate coding a few years ago. libx264 inserts a bunch of crap that will make the output larger than necessary
[13:22:21 CEST] <thardin> so you might want to hack it a bit if you want to acheive the tiniest output possible
[13:22:46 CEST] <JEEB> yea, I don't think that's his requirement right now (if you're talking about the additional SEIs and other stuff that's not 100% optimal for size limiting)
[13:23:15 CEST] <thardin> yeah the comment and whatever
[13:57:32 CEST] <vel0city_netbook> durandal_1707: added, I linked to my blog post
[13:58:02 CEST] <vel0city_netbook> Cldfire: hello, haven't read your post yet but fyi the first link you have in it is dead
[14:01:51 CEST] <durandal_1707> i did read it
[14:02:04 CEST] <durandal_1707> perhaps it died
[14:03:18 CEST] <vel0city_netbook> I meant the link he has on the post itself, not on Trac. The one with the text "here" that's supposed to link to an OpenCL filter post
[14:46:30 CEST] <JEEB> wbs: whew. I think I have my first crappy version pushing out crappy fragments, but they at least are continuous and all that jazz \o/
[15:30:45 CEST] <Cldfire> vel0city_netbook thanks for pointing that out, i'll fix it here shortly
[15:30:58 CEST] <Cldfire> not sure why it's broken, it worked fine on my local server
[16:12:09 CEST] <kierank> nevcairiel: good response on CFR issue
[16:15:50 CEST] <thardin> which one?
[16:16:09 CEST] <kierank> Qtrle patch
[16:16:49 CEST] <jamrial> it would be nice as well if you all could also chime in regarding the discard/dispose frame flag suggestion so we can get things moving
[16:17:25 CEST] <thardin> don't have my FFlappy on me at the moment
[16:18:32 CEST] <kierank> Not easy to bottom post on a phone with long threads
[16:22:26 CEST] <thardin> reget_buffer() makes it possible to return the same buffer with different pts, right?
[16:25:36 CEST] <jamrial> the duplicate frames sharing the same buffer is already taken care of
[16:25:55 CEST] <jamrial> this is about signaling frames as being exact duplicate of previous ones so they may be discarded if desired, instead of forcing the decoder to never propagate them in the first place (thus producing unconditinoal cfr -> vfr)
[16:26:11 CEST] <thardin> good point about fade filters and such
[16:27:52 CEST] <jamrial> outputting duplicate frames is not a performance concern in decoders. creating buffer references is cheap
[16:28:05 CEST] <jamrial> the issue is, as michaelni_ stated, what happens with them later in the process (filters, encoders, etc)
[16:29:08 CEST] <jamrial> processing 100 frames instead of 20 will be slower, of course. so having a way to drop the frames at some point should be enough to work around this, and keep decoder behavior complaint
[16:29:29 CEST] <jamrial> s/complaint/compliant
[16:30:30 CEST] <thardin> either way it's not the job of lavc to decide that
[16:32:12 CEST] <jamrial> exactly, it's the lavc user
[16:32:53 CEST] <thardin> what's this about bitrate being higher?
[16:33:10 CEST] <thardin> surely any decent encoder will detect these duplicated frames, unless they're intra-only
[16:39:12 CEST] <thardin> now I've read the entire thread. a "this frame is identical to the last one" flag is something I don't think anyone would be opposed to
[16:39:47 CEST] <thardin> smart encoders, filters and whatnot could inspect it and act appropriately
[16:40:10 CEST] <thardin> a filter that only depends on input pixels could re-output the same frame for example
[16:40:19 CEST] <cehoyos> Please don't use the word "compliant" to argue
[16:40:21 CEST] <thardin> whereas one that also depends on time (like a fade) should not
[17:10:34 CEST] <durandal_1707> current behaviour with fraps, qtrle, scpr is not compliant
[17:11:59 CEST] <durandal_1707> you will not forbid me my right for free speech
[18:19:18 CEST] <jamrial> PoC for disposable frame flag in the ml
[19:56:57 CEST] <tmm1> is there a moderator queue on ffmpeg-devel? seems some of my emails got stuck
[19:57:23 CEST] <durandal_1707> i doubt so
[19:57:42 CEST] <durandal_1707> when you sent patches?
[19:58:12 CEST] <tmm1> no, replies to existing threads
[19:58:54 CEST] <durandal_1707> but when?
[19:59:39 CEST] <tmm1> i sent one message 12 hours ago, <CAK=uwuyGBcB+JuXj95ea03im6S9KwNG3aK+Sw+gLBd6qbGZjCQ at mail.gmail.com>
[20:00:26 CEST] <durandal_1707> ugh, and you are subscribed?
[20:00:59 CEST] <tmm1> i'm subscribed as ffmpeg at tmm1.net but it looks like some messages i sent as aman at tmm1.net and those are the ones that never went through
[20:01:52 CEST] <durandal_1707> then you will need to wait for moderator, if any to approve it
[20:02:27 CEST] <durandal_1707> dunno if moderators are still actively doing this thing
[20:03:29 CEST] <durandal_1707> iirc nobody came around so mails are never approved, i hope i am wrong
[20:09:52 CEST] <kierank> Repeat flags are not the same as dropping frames
[20:10:04 CEST] <kierank> One is in the presentation plane, one is decoding
[20:10:08 CEST] <kierank> Not the same thing
[20:25:47 CEST] <tmm1> i need to maintain a queue of AVFrame in a filter, is there any generic implementation i can re-use?
[20:27:18 CEST] <durandal_1707> in hw filter?
[20:28:35 CEST] <tmm1> works with both sw and hw frames
[20:28:37 CEST] <thardin> kierank: you'd also need delays to implement any "repeat this frame N times" solution where N can't be read off metadata
[20:31:38 CEST] <durandal_1707> tmm1: see libavfilter/bufferqueue.h?
[20:32:11 CEST] <tmm1> perfect, thank you
[20:32:21 CEST] <thardin> jamrial: I'd maybe call the flag something else, but the concept is fine. I could update cinepakenc to honor it, maybe something else (gifenc perhaps)
[20:32:40 CEST] <thardin> gitenc could just accumulate durations
[20:32:44 CEST] <thardin> gifenc*
[20:33:49 CEST] <jamrial> thardin: there's a "disposable" packet flag already, so imo using the same name is a good idea
[20:34:46 CEST] <durandal_1707> what that flag for packets means ?
[20:35:18 CEST] <thardin>  * Flag is used to indicate packets that contain frames that can
[20:35:18 CEST] <thardin>  * be discarded by the decoder.  I.e. Non-reference frames.
[20:35:23 CEST] <thardin> only used for h265
[20:35:48 CEST] <thardin> jamrial: fair enough
[20:36:26 CEST] <thardin> see 00d454ed2ca
[20:37:11 CEST] <jamrial> set by libx265 so far, but can also be done with libx264 easily
[20:37:16 CEST] <thardin> does this mean "leaf" B-frames could also be marked disposable?
[20:37:18 CEST] <jamrial> matroska muxer can also be made to look for it and set a container level flag
[20:37:44 CEST] <thardin> I suspect mxfdec could be made to signal this as well
[20:47:48 CEST] <cone-906> ffmpeg 03Michael Niedermayer 07master:8f49176e845f: avcodec/alac: Check for bps of 0
[20:47:48 CEST] <cone-906> ffmpeg 03Michael Niedermayer 07master:5af613cc484e: tools/target_dec_fuzzer: Do not corrupt the packet size return
[20:47:48 CEST] <cone-906> ffmpeg 03Michael Niedermayer 07master:02a44ed0c802: tools/target_dec_fuzzer: Increase maxpixels threshold for dirac
[22:40:44 CEST] <nevcairiel> I really have a hard time figuring out if this is so hard to understand or if its just stubborness to not want to see how its actually very different
[22:52:29 CEST] <durandal_1707> maskedsharpen
[23:00:30 CEST] <kierank> nevcairiel: people being stubborn ofc
[23:00:47 CEST] <kierank> nevcairiel: speaking of which let me remind you what a DoS is
[23:00:52 CEST] <kierank> ad nauseam
[23:46:28 CEST] <baptiste> kierank, people being stubborn both ways, and I don't think adding to the fire is necessary in this case
[23:50:59 CEST] <kierank> baptiste: I think it's very clear who is being stubborn and who is trying to stop the months of awful hacks going in to placate fuzzers
[23:51:26 CEST] <baptiste> security issues are security issues
[23:51:54 CEST] <baptiste> crashes detected by the fuzzer need to be fixed
[23:52:10 CEST] <baptiste> qtrle is a very different issue
[23:55:15 CEST] <kierank> exactly they are not crashes
[23:55:24 CEST] <baptiste> all I see, people sending patches, people arguing all the time, and people being toxic TBH
[23:55:28 CEST] <kierank> they are hacks to stop theoretical long runtimes
[23:55:35 CEST] <kierank> on theoretical samples
[23:55:52 CEST] <kierank> yes because we will not accept awful hacks to please the fuzzer until the next failing sample
[23:56:08 CEST] <kierank> y
[23:57:11 CEST] <baptiste> I mainly see crash fixes, correct me if I'm wrong, it seems that long runtimes is not the majority of fuzzer detected issues
[23:58:46 CEST] <nevcairiel> recently crash fixes seem not to be in a majority, its UB or "timeouts"
[23:59:07 CEST] <baptiste> did you count ? or do I have to go and count ?
[00:00:00 CEST] --- Tue Aug 27 2019