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

[burek]

[00:03:07 CEST] <nevcairiel> jamrial: that didnt change anything
[00:03:15 CEST] <jamrial> ah well
[00:04:10 CEST] <iive> well, the derective is %error, so it is expected to generate error :D
[00:05:57 CEST] <jamrial> ah, guess then that yasm needs -Werror to be specified, whereas nasm doesn't
[00:51:12 CEST] <mrec__> hi, anyone awake? I have a 50fps h265 video here and ffplay starts to play 25fps for the first few seconds
[00:51:24 CEST] <mrec__> does anyone have an idea where this can be adjusted?
[00:52:13 CEST] <mrec__> https://pastebin.com/BKZHaFKL
[01:15:27 CEST] <BtbN> Don't see anything indicating 25fps there
[01:16:08 CEST] <mrec__> right, but it's not decoding 50 FPS
[01:16:14 CEST] <mrec__> for the first few seconds
[01:16:21 CEST] <BBB> hows your cpu usage?
[01:16:27 CEST] <BBB> (for the first few seconds)
[01:16:40 CEST] <BBB> (or does it use hw decoding?)
[01:16:56 CEST] <BtbN> ffplay can't do that, except via cuvid/qsv
[01:17:00 CEST] <BtbN> but it doesn't on its own
[01:17:03 CEST] <mrec__> oddly it's 27FPS, I added some debug at avcodec_decode_video2, seems like there aren't more frames available
[01:17:20 CEST] <BtbN> It's probably just busy
[01:17:47 CEST] <mrec__> cpu 45%
[01:17:55 CEST] <BBB> Could not find ref with POC -56 isnt fatal from what I recall, right? so it will just use another existing ref?
[01:18:00 CEST] <BBB> (and generate minor artifacts)
[01:18:01 CEST] <mrec__> but once the video is smooth it jumps up to 100+
[01:20:36 CEST] <mrec__> the ffmpeg h265 decoder works quite well, but the video start is not good
[01:24:13 CEST] <mrec__> seems like the same behaviour if I play the h265 video from a file (not streaming)
[01:27:35 CEST] <iive> the laggy start is something i've seen in ffplay, but not specifically to h265
[01:27:52 CEST] <iive> i thought it might be a sync issue or something. Haven't noticed it lately.
[01:28:20 CEST] <nevcairiel> ffplay isnt the most optimized player, you should not really judge it by its performance of anything
[01:29:41 CEST] <mrec__> I compared ffplay with all the other players when it comes to hevc it's the only working one and the performance is better than with other players
[01:30:12 CEST] <mrec__> vlc is doing some optimizations by itself it adds additional cpu load to the whole story
[01:37:50 CEST] <iive> mrec__: try running some cpu graph program, like gkrellm and see if there is big cpu usage at the start.
[01:38:03 CEST] <mrec__> iive: there isn't
[01:38:54 CEST] <iive> then maybe the file is variable framerate and the start is slow.
[01:39:22 CEST] <iive> or another possibility, it has been cut at open gop and the missing frames need a missing reference .
[01:39:25 CEST] <mrec__> it has something to do with the decoding part not with the displaying part
[01:40:14 CEST] <iive> try ffprobe, it might tell you more details.
[01:40:36 CEST] <iive> also, ask in #ffmpeg
[01:41:20 CEST] <mrec__> if I wait for the first keyframe .. the slow video will start from the point where the keyframe is available
[01:42:10 CEST] <mrec__> if I don't wait for the keyframe everything's fine at the point where the keyframe is available
[01:42:26 CEST] <iive> ??
[01:43:15 CEST] <mrec__> https://pastebin.com/Fvg78HeW
[01:44:13 CEST] <mrec__> if I use the disabled section the slow framerate will be there for much longer
[01:58:31 CEST] <mrec__> ok got it... just use sync video ..
[02:04:16 CEST] <mrec__> hmm not really but it shows the problem
[02:04:28 CEST] <mrec__> video is indeed smooth with it
[10:43:11 CEST] <mrec__> BtbN: ok I found my problem yesterday, I'm just delaying the videoframes until it catches up with the audio timestamp
[10:43:38 CEST] <mrec__> the default behaviour is a bit weird... it starts to adapt the video frames to the audio pts
[11:57:01 CEST] <ubitux> so i can confirm that --x86asmexe=yasm fixes tsan
[11:57:10 CEST] <ubitux> will add it to fate until it's solved
[11:57:39 CEST] <ubitux> i don't know why it's messing it up so badly
[11:57:45 CEST] <ubitux> even for non simd code
[11:59:43 CEST] <nevcairiel> its a shame nasm seems to be collecting various issues. yasm worked basically fine for everything, except not being developed anymore and thus lacking support for new instructions
[12:03:08 CEST] <cone-175> ffmpeg 03Paul B Mahol 07master:01e545d04680: avfilter: add limiter filter
[12:10:10 CEST] <iive> we don't have yet avx512 assembly, do we?
[12:10:15 CEST] <nevcairiel> not yet
[12:10:19 CEST] <iive> aka we don't need the extra instructions.
[12:10:47 CEST] <iive> well, report the bugs to nasm, it is actively developed so they will be fixed
[12:13:56 CEST] <iive> what exactly is the issue with the tsan, iirc this is thread sanitizer, how does it interfere with the assembly?
[12:14:30 CEST] <nevcairiel> the question rather is how or why does the assembly interfere with tsan
[12:14:56 CEST] <ubitux> i'd guess that it interferes with the stack reconstruction
[12:15:20 CEST] <ubitux> maybe it's adding garbage on the stack confusing the lib
[12:15:56 CEST] <ubitux> but OTOH it's not related to SIMD, so it's pretty confusing
[12:16:01 CEST] <iive> then in might be x86inc macro doing something diffrent on nasm,
[12:16:29 CEST] <ubitux> ah, the debug flags are different!
[12:16:46 CEST] <ubitux> "-g -F dwarf" vs "-g dwarf2"
[12:16:54 CEST] <nevcairiel> flag syntax is just different between the two
[12:17:02 CEST] <nevcairiel> both basically mean "create dwarf debug symbols"
[12:17:56 CEST] <nevcairiel> but perhaps the debug info is broken
[12:18:12 CEST] <iive> dwarf version matters
[12:18:59 CEST] <nevcairiel> nasm only has "dwarf" or "stabs", it doesnt list a dwarf version
[12:19:39 CEST] <nevcairiel> you can query nasm about its debug formats by using "nasm -f elf -y" (replace elf as appropriate, if necessary)
[12:20:00 CEST] <iive> just did that :D
[12:35:38 CEST] <durandal_1707> who will apply dolbye?
[13:31:25 CEST] <iive> elvis, who else?
[14:59:24 CEST] <kierank> field h264 decoding is a nightmare
[17:22:21 CEST] <ubitux> BBB: symbols are back
[17:22:56 CEST] <ubitux> (re: tsan)
[17:23:39 CEST] <ubitux> and if you need them locally: --x86asmexe=yasm
[18:00:30 CEST] <BBB> ubitux: ty!
[18:00:37 CEST] <BBB> ubitux: wait, are you saying nasm destroys debug symbols?
[18:01:30 CEST] <BBB> I cannot possibly imagine how that would go, but uh, wow, good regression tracing there
[18:02:10 CEST] <jamrial> same happens with msvc it seems
[18:04:22 CEST] <ubitux> BBB: yeah :p
[18:14:14 CEST] <cone-175> ffmpeg 03hexpointer 07master:3fa8f263abf9: libswresample: check input to swr_convert_frame for NULL
[18:51:00 CEST] <JEEB> nice perf improvement with the bit stream reader
[19:30:05 CEST] <kierank> michaelni or BBB: do you know how this code works with threads: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264dec.c#L614
[19:30:21 CEST] <kierank> I want to reset sei per field pair not per field
[19:31:29 CEST] <BBB> kierank: no idea, sorry
[19:32:25 CEST] <BBB> atomnuker: we can enable it by default if we have evidence it actually speeds up; Im pretty sure it slows down cases where we use the low-level bitstream reader API directly
[19:32:39 CEST] <BBB> atomnuker: as a general rule, evidence always beats feelings
[19:46:39 CEST] <kierank> funman: won't work because there can only be one type of side data per frame
[19:59:18 CEST] <kierank> oh lordy the bug is even worse, the side data just leaks
[20:23:01 CEST] <kierank> definitely some paff threading bugs
[20:27:22 CEST] <kierank> durandal_1707: do you know about frame threads
[20:27:29 CEST] <kierank> and how it works in h264
[20:28:47 CEST] <durandal_1707> i only fixed pts issues in parser
[20:35:02 CEST] <BBB> kierank: I know generally how frame threading works
[20:35:22 CEST] <kierank> I get weird behaviour with paff if my number of threads is mod 2
[20:35:25 CEST] <BBB> kierank: if you have a bug where frame-mt in any way produces different output than w/o frame-mt (including poc or whatever), feel free to poke me and I can check
[20:35:37 CEST] <BBB> add it to trac ;)
[20:36:00 CEST] <kierank> i need to find a public sample but yes I will do that if I can
[20:41:42 CEST] <ubitux> so no one has a benchmark script for testing the bitstream patch?
[20:42:27 CEST] <BBB> not me
[20:44:15 CEST] <ubitux> actually, we just need samples
[20:44:22 CEST] <ubitux> the benchmark is straightforward
[20:44:28 CEST] <atomnuker> ubitux: I'll test it tonight on me old trusty rpi 1
[20:44:32 CEST] <ubitux> do we have a compilation of sample we acn use for benchmarks?
[20:44:53 CEST] <ubitux> atomnuker: i have various arm32 and 64 around, so we can compile results
[20:45:47 CEST] <atomnuker> I have an rpi3 gathering dust but I'll be damned if that thing can even compile ffmpeg without breaking
[20:46:17 CEST] <jamrial> ubitux: maybe concat demuxer using one of the utvideo fate samples?
[20:46:40 CEST] <jamrial> or create a long one
[20:46:47 CEST] <atomnuker> last time I tried to install archlinux on it the images were broken
[20:47:04 CEST] <ubitux> you can crosscompile it easily, crosstool-ng has preset for the rpi*
[20:47:45 CEST] <ubitux> jamrial: would be nice to have a bunch of samples so we can test a wide range of codecs
[20:48:30 CEST] <kierank> BBB: so general frame thread questions, does decode_frame dispatch threads or is it called by a "higher layer" in a new thread?
[20:49:30 CEST] <BBB> you mean AVCodec.decode_frame()?
[20:49:49 CEST] <BBB> a higher layer (pthread_frame.c) calls AVCodec.decode_frame() in separate threads
[20:53:21 CEST] <kierank> ok 
[20:53:39 CEST] <kierank> and I guess there's a some kind of context syncing mechanism
[20:58:45 CEST] <BBB> kierank: yes
[20:58:52 CEST] <BBB> kierank: AVCodec.update_thread_context()
[20:59:35 CEST] <kierank> BBB: my problem is i have a sample with side data on paff field 1 but currently this data is lost on output
[20:59:47 CEST] <kierank> i have patched the problem but it only works with threads non mod 2
[20:59:55 CEST] <kierank> so i am going to try and understand h264dec and fix it
[21:00:09 CEST] <kierank> durandal_1707: cfhd will benefit from new bitstream reader btw
[21:01:15 CEST] <jamrial> kierank: wm4 had to deal with something like that with hevc recently i think
[21:05:39 CEST] <BBB> kierank: like I said, need sample, incredibly hard to make generic statements without sample
[21:10:43 CEST] <kierank> BBB: yeah, i'll have to ask on monday if i can share it
[21:10:51 CEST] <BBB> ty
[21:12:37 CEST] <kierank> is there a way to get thread id with ffmpeg's threading api?
[21:14:03 CEST] <BBB> pthread_self()?
[21:17:00 CEST] <kierank> ah I tried to use pthread_getthreadid_np
[21:20:23 CEST] <jamrial> pthread_self() is not supported by the w32/os2 wrappers, though
[21:29:46 CEST] <kierank> BBB: do you know if paff fields are decoded per thread, or merged?
[21:30:14 CEST] <BBB> whatever the container does (if no parser involved), or the parser does in terms of avpacket splitting (if a parser is involved)
[21:30:23 CEST] <BBB> I would expect the parser to do 1 frame (2 fields) per packet
[21:30:28 CEST] <kierank> hmmmm
[21:30:28 CEST] <BBB> but both can happen
[21:30:33 CEST] <BBB> what container?
[21:30:36 CEST] <kierank> my code sends fields
[21:30:38 CEST] <kierank> but i dunno what ffmpeg does
[21:30:52 CEST] <BBB> parser is in lavformat
[21:30:52 CEST] <kierank> guess I have to see what the parser does
[21:30:56 CEST] <BBB> so if you use only avcodec, its fields
[21:31:04 CEST] <kierank> to debug I'm testing in ffmpeg.c
[21:51:59 CEST] <ubitux> atomnuker: so you let down the pthread name thread? :p
[21:52:12 CEST] <atomnuker> no, not yet
[21:52:22 CEST] <atomnuker> just haven't had time to fx it
[21:52:30 CEST] <atomnuker> not that there's anything to fi
[21:52:35 CEST] <atomnuker> *fix
[23:31:09 CEST] <leif> I'm trying to build ffmpeg with openh264 support. I keep getting the error: "ERROR: openh264 not found using pkg-config"
[23:31:32 CEST] <leif> I have added the openh264 directory to my PKG_CONFIG_PATH.
[23:31:57 CEST] <leif> for example: "$ pkg-config --libs openh264
[23:31:58 CEST] <leif> -L/usr/local/lib -lopenh264y
[23:32:27 CEST] <leif> I've also tried building it with: ./configure --enable-shared --disable-sdl2 --disable-indev=jack --libdir='@loader_path' --enable-libopenh264 --pkgconfigdir=/Users/leif/src/openh264
[23:32:50 CEST] <leif> Does anyone have any suggestions how I can tell ffmpeg's configure script where to find the openh264 pkg-config pc file?
[23:34:36 CEST] <BtbN> check the config log
[23:38:08 CEST] <leif> BtbN: Oh interesting. pkg-config --exists --print-errors openh264 returns nothing, even though pkg-config --libs openh264 does.
[23:38:34 CEST] <BtbN> returning nothing seems like a success to me?
[23:39:39 CEST] <leif> Ah, good point.
[23:41:06 CEST] <leif> BtbN: Here is the full log: https://gist.github.com/LeifAndersen/7b59aa17c96956038aaa685c38dd7ebc
[23:42:43 CEST] <BtbN> fatal error: 'wels/codec_api.h' file not found
[23:42:52 CEST] <BtbN> it's missing its includes, not the pkg-config module.
[23:44:58 CEST] <leif> I see. It 'should' be in: codec/api/svc/codec_api.h, perhaps if I add it to the include dirs...
[23:45:05 CEST] <leif> (I thought pkg-config took care of that.)
[23:46:33 CEST] <cone-598> ffmpeg 03Michael Niedermayer 07master:2061de8a3f73: avcodec/sbrdsp_fixed: Fix integer overflow in sbr_hf_apply_noise()
[23:46:33 CEST] <cone-598> ffmpeg 03Michael Niedermayer 07master:fe9242204d33: avcodec/ylc: Fix vlc of 31 bits
[23:46:50 CEST] <leif> OHOHOH, okay.
[23:47:02 CEST] <leif> THe pkg-config file for openh264 is wrong.
[23:47:11 CEST] <leif> That makes sense...
[23:47:27 CEST] <leif> Thank you
[00:00:00 CEST] --- Sun Jul  9 2017