[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