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

Tue Feb 21 03:05:02 EET 2017

[00:07:29 CET] <RiCON> atomnuker: unrelated to the crash, some warnings in opusenc.c: https://i.fsbn.eu/vay0.txt
[00:08:39 CET] <RiCON> no crash with that patch
[00:08:48 CET] <kierank> should be %"PRIi64"
[00:10:28 CET] <atomnuker> your gcc miscompiles opus_pvq.c and is weird for giving very useless warnings
[00:10:44 CET] <RiCON> ( ¯
[00:12:08 CET] <atomnuker> I bet if you used a gcc compiled from a different source it'll work
[00:57:13 CET] <iive> how about compiling the opus_pvq.c with -O0 just for test?
[00:58:18 CET] <iive> aka, make the whole ffmpeg, touch the .c file, make it again so the command line is visible, 
[00:58:41 CET] <iive> use that line to compile the file manually with -O0
[00:59:23 CET] <atomnuker> --optflags='-O0 -g' to the configure options should do that
[00:59:36 CET] <iive> you'd have to recompile the whole ffmpeg
[00:59:57 CET] <iive> also, the manual line would help you if you want to get the broken assembly
[01:00:41 CET] <iive> -S 
[01:01:45 CET] <iive> also, some parts of ffmpeg doesn't compile with -O0,
[01:02:12 CET] <iive> not enough registers in assembly code and you also need to enable dead code elemination.
[01:08:44 CET] <RiCON> iive: i used -ggdb --disable-optimizations, doesn't that remove the -O?
[01:08:58 CET] <iive> it uses -O1
[01:14:42 CET] <iive> atomnuker: what exactly is the problem here?
[01:15:12 CET] <atomnuker> the pvq search algorithm in opus_pvq.c gets miscompiled
[01:15:42 CET] <atomnuker> because the standalone program for fuzzing passes yet it fails in opus_pvq.c
[01:15:43 CET] <iive> what does it do wrong?
[01:16:00 CET] <atomnuker> it seems to put uninitialized data in the output
[01:17:07 CET] <iive> is the code using floats?
[01:17:13 CET] <atomnuker> yes
[01:17:30 CET] <iive> does the problem happen on 32 and 64 bit?
[01:17:50 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:258763ad0e1e: avcodec/h264_cabac: runtime error: signed integer overflow: 2147483647 + 14 cannot be represented in type 'int'
[01:17:51 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:59e5b05ef6f2: avcodec/h264_ps: Fix runtime error: signed integer overflow: -1094995528 * 2 cannot be represented in type 'int'
[01:17:52 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:c11d3634b07b: avcodec/srtdec: Fix signed integer overflow: 1811992524 * 384 cannot be represented in type 'int'
[01:17:53 CET] <cone-039> ffmpeg 03Michael Niedermayer 07master:b7d9b4a1f1fc: avcodec/ituh263dec: Check cbpy in ff_h263_decode_mb()
[01:18:05 CET] <atomnuker> RiCON said he'd try both, no idea what he used until now
[01:19:38 CET] <iive> atomnuker: can you implement the test program as part of ffmpeg? aka make it use the already compiled functions?
[01:20:40 CET] <atomnuker> wouldn't change much, the test itself will be compiled separately and DCE will optimize out everything else
[01:23:45 CET] <iive> my wild guess is that it is something with sse. on 64 bit it used for float point and probably some of the math library functions uses a sse register or something.
[01:27:37 CET] <iive> RiCON: you could try "--optflags='-mno-sse -mno-mmx -mno-avx'"
[01:28:51 CET] <RiCON> atomnuker: segfaulted with nevcairiel's mingw too
[01:40:35 CET] <RiCON> iive: actually compilation failed with those https://i.fsbn.eu/k14m.txt
[01:49:44 CET] <iive> hum... i thought that disable optimizations also disable asm ...
[01:50:36 CET] <RiCON> oh, i thought that worked instead of --disable-optimizations, my bad
[01:52:01 CET] <iive> there is also --disable-asm/mmx/sse/inline-asm/
[02:04:20 CET] <iive> RiCON: btw, it might be good idea to disable some portions of ffmpeg that are not needed for your testing. e.g. video codecs, filters, etc.
[02:28:39 CET] <debianuser> wm4, nevcairiel: Ah, thank you! Input is probably set to NONBLOCK by default (https://github.com/FFmpeg/FFmpeg/blob/master/ffmpeg_opt.c#L992) and since his RPi has weird sleep times it could explain those xruns and high cpu usage. We'll try to test/time av_sleep() next time (xtina was chatting via web-irc, I haven't seen him since)
[02:39:19 CET] <iive> gtg
[02:46:27 CET] <RiCON> atomnuker: final backtrace of the day: https://i.fsbn.eu/tC4q.txt
[03:52:02 CET] <cone-039> ffmpeg 03Pavel Koshevoy 07master:947fdad92de8: avfilter/af_atempo: fix drift calculation, ticket #6157
[08:24:54 CET] <wm4> #define Picture QuickdrawPicture
[08:24:54 CET] <wm4> #include <VideoToolbox/VideoToolbox.h>
[08:24:54 CET] <wm4> #undef Picture
[08:25:02 CET] <wm4> we have this in videotoolbox.h
[08:25:05 CET] <wm4> but why
[09:23:00 CET] <ubitux> wm4: pretty sure it's useless
[09:31:35 CET] <wm4> maybe it was copy-pasted from vda.h
[14:56:47 CET] <wm4> michaelni: can we get the edit list fix in already
[16:54:41 CET] <durandal_1707> wm4: he is working on it?
[16:56:19 CET] <wm4> dunno
[17:16:18 CET] <cone-123> ffmpeg 03Michael Niedermayer 07master:01d196a67dc5: avcodec/pictordec: Do not read more than nb_planes
[17:16:19 CET] <cone-123> ffmpeg 03Michael Niedermayer 07master:15ccaa344c4f: avcodec/mpegaudiodec: Eliminate many undefined operations
[17:16:20 CET] <cone-123> ffmpeg 03Sasi Inguva 07master:7e538c947547: lavf/mov.c: Correct keyframe search in edit list to return the very first keyframe/frame with matching timestamp. Fixes ticket#5904
[17:48:18 CET] <michaelni> atana, hi, do you have time to continue working on peakpoints2 ?
[17:49:02 CET] <atana> michaelni, yes I am working on the array of struct thing
[17:49:22 CET] <michaelni> ok, if you have any questions ask ...
[17:50:11 CET] <atana> what size should I initialize the array initially? 
[17:50:18 CET] <atana> *with
[17:59:54 CET] <J_Darnley> What's the usual size of a memory page these days?  4K?  Go with that.
[18:05:42 CET] <michaelni> atana, anything (like 4k) would work but 0/NULL may be slightly simpler and depending on the av_fast_realloc() to initially allocate it
[19:32:51 CET] <jya> BBB: a question about ffvp9.
[19:33:06 CET] <BBB> jya: hi
[19:33:13 CET] <jya> hi there...
[19:33:42 CET] <jya> We're currently using different decoder depending if we're using it for playback, or webrtc
[19:33:51 CET] <BBB> makes sense
[19:33:59 CET] <jya> I'm aiming to change that and use the same pool of decoders
[19:34:00 CET] <BBB> (given we dont do error resilience/etc.)
[19:34:07 CET] <BBB> hm .. ok
[19:34:30 CET] <jya> (we still have a libvpx decoder, but good that you raise that point)
[19:34:39 CET] <BBB> so your question is probably how much effort is it to & or how would I/you & ?
[19:34:46 CET] <jya> not quite :)
[19:34:55 CET] <jya> it's purely about low latency at this stage
[19:34:56 CET] <BBB> keep going ;)
[19:34:59 CET] <BBB> yes
[19:35:18 CET] <jya> so the common opinion is that to get low latency, you simply reduce the number of threads in use.
[19:35:29 CET] <BBB> well ...
[19:35:34 CET] <BBB> its about frame vs. tile threading
[19:35:45 CET] <jya> but even with ffvp9 configured to use 8 threads, I still get a 1:1 ratio (between number of input and output)
[19:35:52 CET] <BBB> ffvp9 uses frame threading only ATM, you can force some decoders (e.g. ffvp8) to use tile threading
[19:36:09 CET] <BBB> for low latency, you want to implement and force the decoder to use tile threading
[19:36:18 CET] <BBB> I think a GSoC student is currently working on that as qualification task
[19:36:52 CET] <jya> so ffvp9 isn't suitable for low-latency at present if I follow what you're saying
[19:36:56 CET] <BBB> basically AVCodecContext::thread_type
[19:36:59 CET] <BBB> yes
[19:37:03 CET] <BBB> its trivial to implement
[19:37:21 CET] <jya> oh! can I get it by tomorrow then ? :D
[19:37:30 CET] <BBB> but I never did it since nobody cared about it (you only need it for low-latency applications like webrtc, and thats quite some work so Id rather do it all at once when someone easks for it)
[19:37:40 CET] <BBB> who was the gsoc student again
[19:37:58 CET] <jya> i can ask if that would speed things up !
[19:38:46 CET] <jya> but I'm still puzzled with this frame threading vs tile threading. I see no latency (as I call it) with ffvp9, every compressed I input, immediately give me one back
[19:38:56 CET] <jya> there's no need to do multiple input before one comes out
[19:40:31 CET] <BBB> maybe youre not using frame threading then ;)
[19:40:34 CET] <nevcairiel> you should always see a latency of number-of-threads frames when you use frame threading
[19:41:12 CET] <jya> BBB: the AVCodecContext is setup as.. checking
[19:41:44 CET] <jya> mCodecContext->thread_type = FF_THREAD_SLICE | FF_THREAD_FRAME;
[19:42:19 CET] <jya> with mCodecContext->thread_count = 4
[19:42:49 CET] <kierank> jya: in slice/tile thread mode that work is distributed over n CPUs
[19:42:57 CET] <kierank> instead of being serial
[19:42:57 CET] <jya> so something is broken I guess, I should input 4 frames to get one out
[19:43:02 CET] <BBB> no
[19:43:10 CET] <BBB> you should get the first out after inputing the fifth
[19:43:14 CET] <BBB> second out when inputing the sixth
[19:43:15 CET] <BBB> etc.
[19:43:29 CET] <BBB> so you get a latency of 4 frames, after that you should get 1:1 input/output
[19:44:11 CET] <jya> yes, I get that
[19:44:16 CET] <jya> but that's not what I'm seeing..
[19:44:19 CET] <BBB> and I cant for the life of me figure out which gsoc student was working on slice threading
[19:44:29 CET] <BBB> hm & ok& well & if youre not seeing that
[19:44:32 CET] <BBB> thats sort of troubling
[19:44:40 CET] <BBB> that might be worth spending an afternoon on
[19:44:42 CET] <jya> indeed...
[19:44:53 CET] <BBB> maybe libavcodec is compiled w/o threading?
[19:44:57 CET] <jya> i do see ffmpeg creating the threads
[19:45:12 CET] <BBB> ok, thats good
[19:45:15 CET] <BBB> but so theyre never used
[19:45:31 CET] <BBB> when do you set the mCodecContext options? before/after calling what functions?
[19:45:42 CET] <BBB> (it should be before calling avcodec_open2())
[19:46:30 CET] <nevcairiel> if the decoder is opened with frame threading active, even if something would force it to decode serially you would still have the delay, it cant exactly turn it off again
[19:46:53 CET] <jya> AVCodecContext is constructed before avcodec_open2 is opened
[19:47:08 CET] <jya> this is the configuration used on mac (which I'm using right now)
[19:47:09 CET] <jya> https://dxr.mozilla.org/mozilla-central/source/media/ffvpx/config_darwin64.h
[19:47:31 CET] <jya> if we're not using multi-threading that's a worry, though we still get much better performance than libvpx :)
[19:48:33 CET] <BBB> so the timestamp of the frame being returned in the call to avcodec_decode_video2() is the same as the input timestamp?
[19:48:46 CET] <jya> for those tests videos yes
[19:49:05 CET] <BBB> very obscure
[19:49:08 CET] <jya> with H264 it's obivously different, most of our test media has b-frame to make things worse
[19:49:52 CET] <BBB> right
[19:50:11 CET] <jya> I'll investigate further...
[19:50:15 CET] <BBB> tnx
[19:50:27 CET] <BBB> so back to webrtc
[19:50:54 CET] <jya> but otherwise, assuming there's error resilience, i'd simlpy have to set the number of thread to 1
[19:51:03 CET] <jya> that was the original question I wanted to ask :)
[19:51:04 CET] <BBB> my recommendation would be to add the following features: 1) handling missing references, 2) slice threading, 3) potentially implementing error resilience for partially decoded frames
[19:51:36 CET] <BBB> and then 4 (although maybe not in libavcodec?) some communication between decoder and server to signal lost packets adn resending reference frames etc.
[19:53:03 CET] <jya> that would be part of the webrtc stack
[19:53:10 CET] <jya> which I have no control of.
[19:53:25 CET] <nevcairiel> jya: you are not setting the AV_CODEC_FLAG_LOW_DELAY flag, are you?
[19:53:29 CET] <nevcairiel> that disables frame threading
[19:54:00 CET] <jya> no
[19:54:23 CET] <nevcairiel> or _TRUNCATED?  or flags2 FLAG2_CHUNKS? :)
[19:55:18 CET] <jya> we initialise as such:
[19:55:22 CET] <jya> common part:
[19:55:22 CET] <jya> https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegDataDecoder.cpp#61
[19:56:02 CET] <jya> video part: https://dxr.mozilla.org/mozilla-central/source/dom/media/platforms/ffmpeg/FFmpegVideoDecoder.cpp#131
[20:14:18 CET] <BBB> ooooooo
[20:14:21 CET] <BBB> I just crashed llvm
[20:14:24 CET] <BBB> with legit code
[20:14:31 CET] <BBB> I dont think Ive ever been able to do that before
[20:28:16 CET] <atana> michaelni, I have updated the repo. match info is stored in the array and array is sorted based on time diff
[20:32:04 CET] <atana> Now for 'single pass over the array and find songid that occurs most often in a continuous span' how is this continuous span defined?
[20:33:05 CET] <michaelni> atana, initial mi_size is 0 and mi/mi_size need to be maintained across ppointsStats() calls
[20:34:27 CET] <atana> mi/mi_size? do you mean sizeof(mi)/mi_size ?
[20:36:21 CET] <michaelni> mi_size = sizeof(*mi); should be =0
[20:38:50 CET] <atana> mi/mi_size need to be maintained across ppointsStats() calls, I didn't get it
[20:40:09 CET] <michaelni> the array collects data over th whole file, so loosing the array at the end of each ppointsStats() call wont work
[20:40:45 CET] <atana> so having all data of matches in memory for a song?
[20:41:09 CET] <michaelni> mi/mi_size should be in PeakPointsContext
[20:47:26 CET] <michaelni> atana, also in av_fast_realloc(mi, &mi_size, 1000); the 1000 should be the new size of the array, that is sizeof(MatchInfo)*(k+1)
[21:01:13 CET] <atana> michaelni, updated repop
[21:01:17 CET] <atana> *repo
[21:16:19 CET] <michaelni> atana, av_fast_realloc() should be before writing data into the array
[21:20:43 CET] <atana> updated
[21:29:49 CET] <michaelni> atana, cmpfunc() should in case a->matchtime == b->matchtime use the songid to sort
[21:33:17 CET] <atana> done
[21:47:11 CET] <durandal_1707> isnt MQA drm?
[21:47:53 CET] <michaelni> atana, ok, so next is the 2nd step of the algorithm, after qsort, in a single pass find the longest consecutive run of identical structs, the songid of that should be the detected song
[21:50:26 CET] <atana> michaelni,  say the seq is 22222233333333333333333222221122222222221112222222222 then by longest consecutive run 3 should be chosen even though consecutive runs of 2's appears more time?
[21:52:25 CET] <michaelni> atana, yes but all is sorted so this example shouldnt be possible
[21:52:48 CET] <atana> yes
[22:55:52 CET] <cone-123> ffmpeg 03Timo Rothenpieler 07master:f747e1533ab0: avcodec/nvenc: allow forcing keyframes by default
[00:00:00 CET] --- Tue Feb 21 2017