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

[burek]

[00:00:00 CEST] --- Tue Oct 16 2018
[00:21:37 CEST] <cone-499> ffmpeg 03Anssi Hannula 07master:b2adc3169705: MAINTAINERS: remove myself as hls demuxer maintainer
[11:42:56 CEST] <JEEB> durandal_1707: do you see the new framesync affecting split filter? I seem to see a performance blow if I use splitting so that one of the video encoders is having a single thread for example
[11:43:14 CEST] <JEEB> and this seems to have only happened with versions that got the new framesync
[11:46:21 CEST] <durandal_1707> JEEB: full ffmpeg console output missing ;-)
[11:46:38 CEST] <durandal_1707> uncut*
[11:47:00 CEST] <durandal_1707> always forgot full phrase
[16:45:32 CEST] <BtbN> philipl, one issue I just noticed with your patches is that they cause a compile error in a --disable-vulkan build, hwdec_cuda.c unconditionally includes Vulkan headers.
[16:56:31 CEST] <philipl> BtbN: Thanks for the heads up. I haven't tested that.
[16:56:37 CEST] <philipl> Did you get any further on it running?
[16:56:42 CEST] <BtbN> nope
[17:09:28 CEST] <BtbN> Doesn't even start with vulkan/cuda disabled. So I have absolutely no clue what's going on.
[17:11:41 CEST] <philipl> weird
[17:12:04 CEST] <BtbN> I guess mpv on Windows is just not a well tested target to actually use with non-standard configs
[17:51:33 CEST] <JEEB> BtbN: I use it daily
[17:52:08 CEST] <JEEB> although I haven't built it lately myself. but given that lachs0r's builds succeed fine I don't see any problem with building for mingw-w64/windows per se
[18:49:27 CEST] <philipl> BtbN: I feel slightly bad roping you in even more but: https://github.com/mpv-player/mpv/issues/5978
[18:50:26 CEST] <philipl> shinchiro builds have cuda support: https://sourceforge.net/projects/mpv-player-windows/files/
[19:13:16 CEST] <BtbN> Finally managed to get mpv to build
[19:13:24 CEST] <BtbN> had to install HyperV, Ubuntu in there, and mxe in there
[19:14:14 CEST] <JEEB> I just used fedora's standard mingw-w64 toolchain with an updated mingw-w64 CRT+headers
[19:16:06 CEST] <durandal_1707> JEEB: what about that framesync bug you wanted to report?
[19:17:22 CEST] <JEEB> nah, I was just thinking if you have encoders with different amount of input buffering and such, how much framesync can cause blocking in the encoding chain as I think I'm seeing worse performance lately (after the new framesync) with something like yadif+overlay+split
[19:18:17 CEST] <durandal_1707> overlay should use multiple cores by now
[19:19:24 CEST] <JEEB> yes, overlay doesn't seem to be the problem
[19:19:50 CEST] <JEEB> I'm more thinking of the split+encoders with different amount of threads/buffering requirements
[19:22:09 CEST] <durandal_1707> JEEB: do you mean split final result to multiple encoders?
[19:22:33 CEST] <JEEB> yea, f.ex. yadif+overlay+split+ X scale
[19:22:49 CEST] <JEEB> 1080p, 720p, 576p, 480p for example :P
[19:27:12 CEST] <JEEB> it seems to especially pop up when you get one of them with a lesser thread count for the encode, like 1. but yea, I just quickly wanted to ask because I haven't gotten any numbers so far
[19:30:02 CEST] <philipl> BtbN: w00t.
[19:30:27 CEST] <BtbN> I guess some of the dependencies I just ignored are required
[19:30:30 CEST] <BtbN> like, lua, jpeg, ...
[19:30:30 CEST] <j-b> +    int reference_track_dolby;
[19:30:32 CEST] <j-b> lol
[19:31:46 CEST] <durandal_1707> yea, not acceptable
[19:33:36 CEST] <kierank> you can tell it's german company because they always list their directors in communications for some reason
[19:35:04 CEST] <durandal_1707> JEEB: well if you know how to reproduce it that would be perfect, i only know that new framesync will buffer much less, and use less memory if one link is faster than other
[19:35:45 CEST] <JEEB> durandal_1707: yea it repros in certain cases 100% although I'm still figuring the exact variables
[19:36:00 CEST] <JEEB> most likely has to do with various encoders going at different speeds and having a different amount of buffering
[19:36:28 CEST] <JEEB> or at least one of those
[19:36:46 CEST] <JEEB> since where it breaks live transcoding completely is where there's one profile with threads set to 1
[19:36:57 CEST] <JEEB> but yea, I'll try to figure out more data :P
[19:42:30 CEST] <durandal_1707> JEEB: what encoders you use?
[19:43:17 CEST] <JEEB> libx264
[19:48:07 CEST] <durandal_1707> and you set one of them to single thread?
[19:48:58 CEST] <JEEB> that seems to be the common thread. I'll try to set up a similar stream on another box to make it testable
[19:49:17 CEST] <JEEB> because other system with all encoders set to 4 seems to be fairing OK
[19:49:29 CEST] <JEEB> then I have another which has threads set to everything from 1 to 8
[19:49:40 CEST] <JEEB> and that used to work OK with a version ~sept 2017
[19:49:56 CEST] <JEEB> then we have newer versions just boom-boom satelliting with the latter thing :P
[19:51:38 CEST] <JEEB> I think most people just quick lavfi and instead just add more refs to the AVFrames coming from lavfi
[19:51:43 CEST] <JEEB> *quit lavfi
[19:51:50 CEST] <JEEB> instead of using the split filter
[19:58:16 CEST] <durandal_1707> more shit: https://hydrogenaud.io/index.php/topic,116742
[19:59:52 CEST] <JEEB> you can always find shit
[20:00:01 CEST] <JEEB> that's why you need to think positive
[20:00:25 CEST] <JEEB> or add ad-blocking filters that block things that gets you down :P
[20:24:15 CEST] <tmm1> anyone going to demuxed this week?
[20:24:21 CEST] <durandal_1707> me
[20:25:46 CEST] <tmm1> cool. some great talks scheduled, looking forward to it
[20:33:00 CEST] <durandal_1707> tmm1: all talks are great
[20:35:19 CEST] <kierank> tmm1: me, j-b, daemon404, BBB
[20:37:28 CEST] <kierank> Can ipads decode periodic intra refresh?
[20:42:00 CEST] <tmm1> i think so, but not sure
[20:55:47 CEST] <cone-908> ffmpeg 03Aman Gupta 07release/4.0:aec3daa8b4b3: avcodec/cbs_h264: silence errors about end_of_seq nalus
[20:55:47 CEST] <cone-908> ffmpeg 03Aman Gupta 07release/4.0:70d0d83d4d61: avcodec/cbs: fix crash in sei_pic_timestamp
[20:55:47 CEST] <cone-908> ffmpeg 03Aman Gupta 07release/4.0:8791a1e7de35: avcodec/cbs: ensure user_data is padded for GBC parsing
[23:13:18 CEST] <jamrial> tmm1: you need to revert aec3daa8b4b3 from release/4.0
[23:13:25 CEST] <jamrial> that's definitely not a fix
[23:15:04 CEST] <cone-908> ffmpeg 03Mark Thompson 07master:f6912cc3e756: trace_headers: Fix memory leaks on syntax read failures
[23:26:22 CEST] <tmm1> ah, sorry
[23:26:38 CEST] <jkqxz> jamrial:  While technically incorrect, it's pretty harmless.  The only visible case I can see is that end-of-sequence NALs would have disappeared from trace_headers output (where previously they were warned about).
[23:29:04 CEST] <jkqxz> jamrial:  I'm not sure which BSF dependency cases are actually useful now.  The IVF one, yes.  The raw H.26[45]/LATM cases can work without it (since they do all check the stream for the "other" case), so it's not really a dependency though you probably do want to include it for remuxing.
[23:29:47 CEST] <jkqxz> The more general containers have the same reasoning for those codecs (and the same checks), but you may not be interested in those codecs.
[23:29:56 CEST] <jamrial> the latm case used to strictly check for adts, but now it would only fail while trying to parse it as latm
[23:33:26 CEST] <jamrial> does AVOutputFormat.check_bitstream fail and the muxing process aborts if the requested bsfs is not available?
[23:35:44 CEST] <jkqxz> I think so?  Looks like do_packet_auto_bsf() returns failure, so av_write_frame() will too.
[23:42:39 CEST] <jamrial> mmh, then h264/h265/latm should have their respective bsfs as deps to work
[23:46:29 CEST] <jkqxz> Er, so they shouldn't have the deps because they might only be used for one case, and are checked at runtime for the other?
[23:58:28 CEST] <cone-908> ffmpeg 03Mark Thompson 07master:57f312a34db4: doc/bitstream_filters: Add av1_metadata
[00:00:00 CEST] --- Wed Oct 17 2018