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

[burek]

[10:50:38 CET] <durandal_1707> michaelni: please take look at patch on devel mailing list that fixes logic error in c75273310cf
[10:57:25 CET] <durandal_1707> https://patchwork.ffmpeg.org/patch/16011/
[11:01:40 CET] <cone-497> ffmpeg 03Paul B Mahol 07master:1c3b70e2e078: avfilter: add median filter
[13:09:24 CET] <cone-497> ffmpeg 03Paul B Mahol 07master:4ce263a7fd1c: avfilter/vf_vfrdet: fix reporting max delta
[13:09:25 CET] <cone-497> ffmpeg 03Paul B Mahol 07master:3420e56d9a4a: avfilter/vf_vfrdet: also report average delta
[13:41:57 CET] <cone-497> ffmpeg 03hydra3333 07master:ba6b20df3f74: avcodec/nvenc: turn feature check failures into warnings
[13:44:21 CET] <xdudi> can anyone help me how use avformat_open_input() with digest authentication to get rtsp protocol? I can't find anything via google
[13:48:21 CET] <JEEB> I see it mentioned with RTSP_MODE_TUNNEL which gets set with rtsp_transport http or https
[13:48:38 CET] <JEEB> rtsp_transport is an AVOption for the rtsp module
[13:59:17 CET] <xdudi> I need something like that: https://github.com/leandromoreira/ffmpeg-libav-tutorial/blob/master/0_hello_world.c but I need connect to camera with rtsp by digest authentication
[13:59:31 CET] <xdudi> what should I change in this example?
[14:14:12 CET] <durandal_1707> anybody is smart enought to answer this question: why ffmpeg -r behaves differently than fps filter when duplicating frames from VFR frames? fps filter uses "dumb" techique by duplicating first frame in cache up until to end of gap, while -r does more smart thing by using first frame from cache only halfway of the gap
[14:24:46 CET] <cone-497> ffmpeg 03James Almer 07master:dad75924290e: avcodec/tiff: check the black level denominator
[15:02:34 CET] <durandal_1707> anybody is smart enough to answer this question: why ffmpeg -r behaves differently than fps filter when duplicating frames from VFR frames? fps filter uses "dumb" techique by duplicating first frame in cache up until to end of gap, while -r does more smart thing by using first frame from cache only halfway of the gap; which way is correct way?
[15:11:11 CET] <thardin> i hear ndi-hx ships with lavf
[15:15:33 CET] <thardin> without shipping code or object file
[15:35:04 CET] <durandal_1707> thardin: again?
[16:17:25 CET] <durandal_1707> michaelni: why ffmpeg -r behaves differently than fps filter when duplicating frames from VFR frames? fps filter uses "dumb" techique by duplicating first frame in cache up until to end of gap, while -r does more smart thing by using first frame from cache only halfway of the gap; which way is correct way?
[16:23:31 CET] <cone-497> ffmpeg 03Andreas Rheinhardt 07master:8b28aa0767d5: avformat/dss: Remove superfluous headers
[16:23:32 CET] <cone-497> ffmpeg 03Michael Niedermayer 07master:1850c3feaa1c: avcodec/g723_1dec: fix invalid shift with negative sid_gain
[16:23:33 CET] <cone-497> ffmpeg 03Michael Niedermayer 07master:069be4aa5ddc: avcodec/libvorbisdec: Fix insufficient input checks leading to out of array reads
[16:23:34 CET] <cone-497> ffmpeg 03Limin Wang 07master:e1c4ce4761fc: avfilter/asrc_anoisesrc: change color variable to int
[16:23:35 CET] <cone-497> ffmpeg 03Michael Niedermayer 07master:f17ea0200178: avcodec/apedec: Only clear the needed buffer space, instead of all
[16:23:36 CET] <cone-497> ffmpeg 03Michael Niedermayer 07master:34e701ff93b6: avcodec/adpcm: Fix invalid shifts in ADPCM DTK
[16:23:37 CET] <cone-497> ffmpeg 03Michael Niedermayer 07master:d3dee676b8a8: avcodec/wmalosslessdec: Fix some integer anomalies
[16:26:58 CET] <michaelni> durandal_1707, they behave differently because they are different implementations with neither attempting to do exactly the same as the other.  The correcter one is the one that recovers the "true" data better and that could depend on how the input was created, which way of frame droping was used for example
[16:42:17 CET] <durandal_1707> michaelni: do you mind if i add option to control this? so it can be like already is, or like -r option or some another rounding.
[17:02:06 CET] <michaelni> durandal_1707, sounds like a good idea, yes, iam in favor
[17:05:00 CET] <thardin> question: is there still talk about rewriting stuff for the sole purpose of having a weaker license?
[17:05:49 CET] <thardin> durandal_1707: I'm going to look a bit more into it, but word on the street is "yes"
[17:05:59 CET] <durandal_1707> thardin: question: rewriting what stuff?
[17:11:19 CET] <thardin> any stuff. let's say a decoder
[17:12:00 CET] <thardin> let's suppose there is an AGPL decoder for JPEG. someone wants to rewrite it in order to relicense under the MIT license
[17:12:47 CET] <thardin> I am of the opinion that we should reject such patches unless there is a very good reason to include them
[17:14:08 CET] <JEEB> so we don't want more of our users utilize functionality? given that LGPLv2.1plus is our base license?
[17:14:47 CET] <JEEB> note: i probably lack context into what ypu're commenting on
[17:15:24 CET] <JEEB> since my personal pet peeve is libaribb24's licensing and thus i have worked on getting an lgplv2.1plus implementatiom into FFmpeg
[17:15:58 CET] <thardin> that's only a problem for certain users
[17:16:13 CET] <thardin> specifically, proprietary vendors
[17:19:14 CET] <JEEB> i personally don't have a bone in that game, but for me there generally is a base license of FFmpeg, and for some reason it feels nice when your thing can be enabled by default
[17:21:12 CET] <JEEB> so if I see a patch set thatcan be attempted to upstream for some feature I'd like to have under a 'better' license (closer to baseline license) then i will attempt to see if that can be upstreamed
[17:23:25 CET] <JEEB> but I do agree that if there is a specific reason for something to be under license x, then at least hearing those reasons out is worthwhile
[17:25:26 CET] <thardin> yes, there can often be very good reason. what I'd like to avoid is a situation where someone decides to invest a lot of time rewriting something just to please some vendor
[17:26:35 CET] <thardin> it might also be possible that that person depends on said vendor to continue contributing to other parts of the codebase, so it's not so clear cut always
[17:28:50 CET] <thardin> worth having a discussion around at least, to prevent possible drama
[17:50:14 CET] <nevcairiel> in your example at least, every piece I can liberate from AGPL  is a fight worth fighting, its a horrible license
[18:04:20 CET] <thardin> lol
[18:05:02 CET] <thardin> cloud companies hate it, therefore it is excellent for license trolling
[18:23:18 CET] <durandal_1707> michaelni: have you looked at that .wav file that is completely valid pcm_s16le but is recognized as crappy mp1?
[18:27:23 CET] <michaelni> durandal_1707, not yet
[18:48:37 CET] <thardin> durandal_1707: they say to send enquiries about LGPL sources by email
[19:24:21 CET] <kepstin> durandal_1707: note that the fps filter has some options for controlling its rounding behaviour
[19:30:58 CET] <kepstin> but yeah, it's designed with the assumption that a frame start at its pts and ends at the next frames pts, so it fills in the time that the frame should be appearing for.
[19:35:16 CET] <durandal_1707> kepstin: fps filter pick always first frame when duplicating frames, i added option to control that
[19:38:03 CET] <kepstin> well, as long as you don't change the default behaviour, which imo is most correct especially when increasing framerate.
[19:39:40 CET] <durandal_1707> kepstin: it is not correct when doing vfr -> cfr for same frame rate
[19:39:43 CET] <kepstin> the current method will cause the fps-adjusted video to look identical in a player if the output fps is an integer multiple of the input fps.
[19:40:40 CET] <kepstin> hmm, that should be handled by the rounding of the second frame.
[19:43:24 CET] <durandal_1707> i mean it will use only first frame in gap when filling gap between timestamps
[19:44:53 CET] <kepstin> right, because the pts of a frame is the time when it first appears
[19:45:58 CET] <kepstin> fps filter works by taking the pts of each input frame, converting to the output timebase (with configurable rounding) then filling any gaps with the frame that a player would be displaying during the gap.
[19:47:07 CET] <kepstin> if the behaviour isn't the way you expect when cleaning up "nearly-cfr" vfr video, then playing around with the rounding on the pts conversion should usually fix it.
[19:56:06 CET] <durandal_1707> no, rounding on pts conversion is not solution
[19:57:03 CET] <kepstin> i use it for doing stuff like fixing webcam videos with dropouts - no frame should ever appear before its pts value, because then it'll obviously be out of sync appearing too early.
[19:58:05 CET] <durandal_1707> kepstin: avs/vpy disagrees, also -r
[19:59:08 CET] <kepstin> if you have a particular example of bad behaviour with the fps filter, i'd be interested to see its decision log with -v debug
[19:59:27 CET] <durandal_1707> kepstin: it does not behave like -r
[20:00:10 CET] <kepstin> not behaving with -r doesn't seem like either a good or a bad thing? it's just different...
[20:00:22 CET] <kepstin> i personally don't use -r because its behaviour isn't appropriate for my use case
[20:03:07 CET] <durandal_1707> kepstin: thats why i wrote patch to optionally behave like -r
[20:04:49 CET] <kepstin> i'm mostly curious if the particular problem you're having could be solved by an existing option on the filter.
[20:05:34 CET] <kepstin> not really opposed to adding a new option, it just seems kind of weird since it might make a frame appear before its pts value, causing temporal glitches :/
[20:15:22 CET] <durandal_1707> kepstin: https://www.mediafire.com/file/c9iebz72cwxi97r/ffmpeg_psnr_example2.7z/file  look at 0.mkv file and its gaps after 1st frame
[20:16:38 CET] <kepstin> converting to 24000/1001 fps?
[20:17:50 CET] <durandal_1707> no, to same fps, VFR->CFR
[20:19:02 CET] <kepstin> weird, the first frame in that file has pts=125, but the fps filter is using 0 as the first fps. Last time i worked on the filter, i thought it had it preserve the start offset
[20:19:05 CET] <durandal_1707> -vsync passthrough give 244 frames, while defaukt gives 246 frames, +2 out of nowhere
[20:19:17 CET] <kepstin> the issue is that it's filling in the time between pts=0 and pts of first frame
[20:20:58 CET] <durandal_1707> no, first pts is 0
[20:21:17 CET] <kepstin> oh, missed it
[20:21:53 CET] <durandal_1707> so, i want to mimic -vsync cfr with lavfi fps filter
[20:24:07 CET] <kepstin> hmm. so your input frame pts are 0, 125, 167, 208, 250. So the first frame is displayed for 125ms, then the second and on are displayed each for 41/42ms typical.
[20:24:30 CET] <kepstin> kind of a weird file, but the fps filter is behaving as expect. weird that the file has such a big gap at the start.
[20:25:37 CET] <kepstin> the first frame is being displayed for the duration of three frames at 24000/1001 fps, so that's what the fps filter fixes.
[20:32:57 CET] <kepstin> assuming that mkv file was made from the mp4 file, something really quite odd happened to the timestamps when it was muxed, since the mp4 has exact correct pts starting at 0.
[20:37:02 CET] <mkver> Can this be https://trac.ffmpeg.org/ticket/4536 ?
[20:45:57 CET] <durandal_1707> mkver: nope
[20:46:27 CET] <durandal_1707> kepstin: use ffmpeg -i 0.mkv -vsync cfr/passthrough 0.y4m
[20:46:36 CET] <mkver> Indeed, it's impossible because it has only one stream. I should have downloaded it before commenting.
[20:53:45 CET] <kepstin> durandal_1707: hmm. so from `ffmpeg -i 0.mkv -vsync cfr -vframes 48 -f framecrc -` I see that it makes 2 copies of the first frame and 2 copies of the second frame to fill in the gap
[20:55:11 CET] <durandal_1707> just like 1.mp4
[20:55:53 CET] <kepstin> so from a file with frame 1 at time 0 and frame 2 at time 125 (all ms, rounded to integers), it's made a file with frame 1 at times 0 and 41, and frame 2 at times 84, 125
[21:01:07 CET] <kepstin> how did the dup frames get dropped when that mkv was made? it should have kept the frame at ms 0 and the frame at ms 82 and dropped the duplicates at 41 and 125 if it wanted to preserve correct timing during video playback
[21:01:55 CET] <kepstin> what it instead did was move the start of the second frame to ~41ms after it was supposed to appear :/
[21:03:48 CET] <durandal_1707> kepstin: the frames are type B, looks like decoder may not output them at will
[21:06:55 CET] <kepstin> ... huh. that mkv files has two frames with pts 0, then one at pts 42, then one at pts 125.
[21:07:08 CET] <kepstin> unless i'm reading ffprobe -show_packets wrong
[21:08:55 CET] <kepstin> the fps filter only receives as input one frame with pts 0, then one frame with pts 125.
[21:15:09 CET] <kepstin> i'm really curious how this input file got made with such messed up frame timestamps, if i do something simple like "ffmpeg -i 1.mp4 -c:v libx264 2.mkv" then it preserves all the frames with correct pts values
[21:20:11 CET] <kepstin> anyways, the proposed rounding behaviour option will work around whatever dropped duplicate frames without preserving frame start timestamps on this particular file, but i'm thinking that might be more of a coincidence than anything else, and it might not even work on other files (if e.g. there was a longer run of duplicate frames or whatnot).
[21:57:00 CET] <durandal_1707> kepstin: no, it exactly should work like vsync cfr
[22:00:10 CET] <kepstin> hmm, well, the current behaviour does exactly what the file's timestamps say to do, but sure, an optional thing that makes it behave like -vsync cfr for compatibility with people who rely on that behaviour makes sense.
[00:00:00 CET] --- Wed Oct 30 2019