Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

May 2017

1 participants
62 discussions

ffmpeg-devel.log.20170505
by burek 06 May '17

06 May '17

[00:00:01 CEST] <ubitux> jamrial: it looks like shared is not populated somehow [00:00:11 CEST] <nevcairiel> i suppose there is always some crazy commands to run, but deleting things is simple :D [00:02:00 CEST] <jamrial> ubitux: just checked and the .pc files look the same pre and post merge for me... [00:02:04 CEST] <jamrial> save for the prefix thing [00:02:18 CEST] <jamrial> and i mean both with and without --enable-shared [00:02:52 CEST] <ubitux> mmh [00:02:57 CEST] <ubitux> maybe i derped somewhere then [00:03:06 CEST] <ubitux> alright [00:03:13 CEST] <jamrial> let me try on linux [00:03:20 CEST] <jamrial> i only tried mingw [00:03:20 CEST] <ubitux> mmh yeah no right now it works [00:03:26 CEST] <jamrial> ah [00:03:29 CEST] <ubitux> i guess it's about some state again [00:04:11 CEST] <ubitux> anyway [00:04:13 CEST] <ubitux> LGTM [00:04:16 CEST] <ubitux> thanks [00:04:44 CEST] <jamrial> no prob [00:05:26 CEST] <ubitux> 'night [00:06:14 CEST] <jamrial> night! [00:08:38 CEST] <alevinsn> I just deleted contents of tests/ref and restored that [00:08:46 CEST] <alevinsn> and that seems to be sufficient [00:08:49 CEST] <alevinsn> for now [00:28:55 CEST] <cone-249> ffmpeg 03wm4 07master:974ee16d6a71: ffmpeg: check for unconnected outputs [00:28:56 CEST] <cone-249> ffmpeg 03wm4 07master:c0f17a905f35: cuvid: support AVCodecContext.hw_device_ctx API [01:06:01 CEST] <cone-249> ffmpeg 03Diego Biurrun 07master:edb434873238: build: Store library version numbers in .version files [01:06:02 CEST] <cone-249> ffmpeg 03Diego Biurrun 07master:92db5083077a: build: Generate pkg-config files from Make and not from configure [01:06:03 CEST] <cone-249> ffmpeg 03James Almer 07master:6fdd35a3126f: Merge commit '92db5083077a8b0f8e1050507671b456fd155125' [01:06:33 CEST] <nevcairiel> there goes the subdir building support eh [01:06:34 CEST] <nevcairiel> :D [01:07:34 CEST] <wm4> support for what? [01:08:02 CEST] <nevcairiel> we talked about that just yesterday, that you can call "make" from within a library directory, ie. from within the libavcodec dir [01:09:00 CEST] <wm4> that worked? [01:09:05 CEST] <nevcairiel> apparently [01:09:11 CEST] <wm4> fascinating [01:09:19 CEST] <nevcairiel> not any longer [01:09:34 CEST] <nevcairiel> i foresee nicolas complaining soon [01:25:43 CEST] <jamrial> it sure as hell didn't work in out of tree builds [01:27:44 CEST] <wm4> why nicolas [01:41:48 CEST] <nevcairiel> he commented on using it in the ML thread that was linked last night [01:43:04 CEST] <wm4> ah [02:27:54 CEST] <cone-249> ffmpeg 03Diego Biurrun 07master:0b77a5933635: Use correct printf conversion specifiers for POSIX integer types [02:27:55 CEST] <cone-249> ffmpeg 03James Almer 07master:191b2d4fc96f: Merge commit '0b77a5933635293508e7289e7cf191ed166cf070' [02:35:01 CEST] <cone-249> ffmpeg 03Martin Storsjö 07master:131644677970: http: Check for negative chunk sizes [02:35:02 CEST] <cone-249> ffmpeg 03James Almer 07master:f31f610f337d: Merge commit '131644677970a3c4a0096270ea2a5b5d437c2e63' [02:37:02 CEST] <philipl> shit don't compile? [02:37:46 CEST] <philipl> "Use correct printf conversion specifiers for POSIX integer types" [02:37:51 CEST] <philipl> where correct != compilable. [02:39:01 CEST] <cone-249> ffmpeg 03John Stebbins 07master:0982152c3fb0: matroskadec: fix SRT subtitle duration [02:39:02 CEST] <cone-249> ffmpeg 03James Almer 07master:43b136ce80ea: Merge commit '0982152c3fb05365597978c5d7cfeeb7ced01723' [02:39:24 CEST] <philipl> jamrial: there's a comma that got dropped in that merge. [02:40:08 CEST] <jamrial> philipl: will fix, sorry [02:40:28 CEST] <philipl> vorbisdec.c [02:46:11 CEST] <cone-249> ffmpeg 03Diego Biurrun 07master:53618054b64c: parser: Add missing #include for printing ISO C99 conversion specifiers [02:46:12 CEST] <cone-249> ffmpeg 03James Almer 07master:fb496921e86b: Merge commit '53618054b64ce4dab459d23a7efebe9d5afc4855' [02:46:13 CEST] <cone-249> ffmpeg 03James Almer 07master:8acd73e3482c: avcodec/vorbisdec: add missing comma [02:46:57 CEST] <philipl> jamrial: cheers [03:08:16 CEST] <cone-249> ffmpeg 03Diego Biurrun 07master:8a34f3659371: build: Add version numbers to "Requires" entries in pkg-config files [03:08:17 CEST] <cone-249> ffmpeg 03James Almer 07master:ea49308402d9: Merge commit '8a34f3659371680ca523aecfd9098c28f0f809eb' [04:26:21 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:ce7098b8f2b5: avcodec/dvdsubdec: Fix runtime error: left shift of 242 by 24 places cannot be represented in type 'int' [04:26:22 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:a0e5f7f36355: avcodec/cavsdec: Fix undefined behavior from integer overflow [04:26:38 CEST] <alevinsn> Not sure if anyone is here, but, in case someone is.... [04:26:51 CEST] <alevinsn> I submitted a patch on March 26th: https://patchwork.ffmpeg.org/patch/3103/ [04:27:06 CEST] <alevinsn> it hasn't been pushed, but I indicated that I ran make fate [04:27:28 CEST] <alevinsn> this is true, but I didn't use fate-suite, and now that I understand how to run fate properly [04:27:36 CEST] <alevinsn> there are a few FATE tests that fail [04:27:40 CEST] <alevinsn> with this patch [04:27:48 CEST] <alevinsn> so, it doesn't actually pass FATE [04:28:07 CEST] <alevinsn> all the tests that fail with this patch are mpeg4-als-conformance tests [04:28:30 CEST] <alevinsn> specifics 02, 03, 04, and 05 [04:28:34 CEST] <alevinsn> 00 and 01 pass [04:28:58 CEST] <alevinsn> I get the following output when I run the command [04:28:59 CEST] <alevinsn> [out_0_0 @ 00000170CF688F80] 100 buffers queued in out_0_0, something may be wrong. [04:29:00 CEST] <alevinsn> Too many packets buffered for output stream 0:0. [04:29:00 CEST] <alevinsn> Conversion failed! [04:29:19 CEST] <alevinsn> Any ideas to help me pinpoint the cause? [04:29:58 CEST] <alevinsn> the patch modifies ffmpeg.c [04:29:59 CEST] <wm4> what command? [04:30:20 CEST] <alevinsn> ffmpeg -nostdin -nostats -cpuflags all -hwaccel none -threads 1 -thread_type frame+slice -i fate-suite//lossless-audio/als_00_2ch48k16b.mp4 -f crc - [04:30:26 CEST] <alevinsn> that's one that fails [04:30:31 CEST] <alevinsn> but the following works; [04:30:32 CEST] <alevinsn> : [04:30:51 CEST] <alevinsn> ffmpeg -nostdin -nostats -cpuflags all -hwaccel none -threads 1 -thread_type frame+slice -i fate-suite//lossless-audio/als_00_2ch48k16b.mp4 -f crc - [04:31:22 CEST] <alevinsn> I changed the order for when check_init_output_file() is called to fix the bug in my patch [04:31:32 CEST] <alevinsn> but apparently that breaks things for this test [04:32:46 CEST] <wm4> what's the difference between those? [04:34:03 CEST] <alevinsn> between the .mp4 files? [04:34:13 CEST] <alevinsn> oops [04:34:30 CEST] <alevinsn> should be als_02 [04:34:33 CEST] <alevinsn> for the one it fails with [04:37:50 CEST] <wm4> the error "obviously" means that something isn't consuming a specific filter output, but still pushing in input data [04:38:07 CEST] <wm4> (or the output is produced as side effect by other input/output) [04:39:17 CEST] <wm4> for example if you read output A, but not output B, and there is a filter that outputs both to output A and output B for each filtered frame, then the libavfilter will just queue up frames on output B [04:41:02 CEST] <alevinsn> I wonder if in this case [04:41:30 CEST] <alevinsn> it doesn't get to check_init_output_file() (where I moved it to) for some reason [04:42:39 CEST] <alevinsn> one "fix" would be to only change the behavior for video and not audio [04:43:07 CEST] <alevinsn> but that's kludgy, and perhaps there are there other cases not covered by fate-suite that would apply to video [04:53:17 CEST] <wm4> I don't quite understand the problem [04:53:40 CEST] <wm4> (from your patch) [04:53:41 CEST] <wm4> why does the audio/video order matter? [04:54:12 CEST] <alevinsn> the interlaced setting [04:54:14 CEST] <alevinsn> isn't set [04:54:18 CEST] <alevinsn> until it calls do_video_out [04:54:36 CEST] <alevinsn> but, if check_init_output_file() is called before that point [04:54:43 CEST] <alevinsn> and it thinks all of the output streams are setup [04:54:55 CEST] <alevinsn> the interlaced video setting won't be known at that time [04:55:02 CEST] <alevinsn> and it doesn't think it is dealing with interlaced video [04:55:05 CEST] <wm4> shouldn't it always have a frame for each output when initing the filter? [04:55:16 CEST] <wm4> (or the encoder/muxer/etc.) [04:55:36 CEST] <alevinsn> it has to do with the call to avformat_write_header() [04:55:40 CEST] <alevinsn> in check_init_output_file() [04:55:54 CEST] <alevinsn> if it thinks all the output streams are initialized, it will call that [04:56:01 CEST] <alevinsn> but, ost->initialized is set to 1 [04:56:08 CEST] <alevinsn> before calling do_video_out() [04:56:58 CEST] <alevinsn> in do_video_out(), you'll see some code [04:57:16 CEST] <alevinsn> for setting mux_par->field_order [04:57:29 CEST] <alevinsn> which defaults to AV_FIELD_PROGRESSIVE [04:57:38 CEST] <alevinsn> so, if the sequencing is such that [04:57:46 CEST] <alevinsn> it handles the video output stream last [04:58:01 CEST] <alevinsn> (which will always be the case if there is only one output stream and it is a video output stream) [04:58:19 CEST] <alevinsn> it will call avformat_write_header() before it does the first call to do_video_out() [04:58:45 CEST] <alevinsn> there may be other things that it gets from calling do_video_out() first in my patch [04:58:51 CEST] <alevinsn> that fix other issues besides interlaced video [04:59:34 CEST] <alevinsn> and possibly also for do_audio_out() [05:01:41 CEST] <wm4> but check_init_output_file contains a loop that checks if each output stream is initialized [05:02:19 CEST] <wm4> so shouldn't it call avformat_write_header() once for every stream at least 1 packet was encoded?= [05:02:23 CEST] <wm4> and all muxer params set [05:03:09 CEST] <alevinsn> it calls check_init_output_file() for each stream [05:03:10 CEST] <alevinsn> but [05:03:17 CEST] <alevinsn> it only calls avformat_write_header() once [05:03:26 CEST] <alevinsn> after it thinks all the output streams are initialized [05:03:54 CEST] <alevinsn> it will only call check_init_output_file() once per stream [05:05:06 CEST] <wm4> so where's the problem? [05:05:14 CEST] <wm4> it can't call avformat_write_header() again [05:05:57 CEST] <alevinsn> right, but if it calls avformat_write_header() before it has had a chance to go through do_video_out() at least once [05:06:04 CEST] <alevinsn> it will write that the video is progressive into the header [05:06:11 CEST] <alevinsn> and operate on it that way [05:06:54 CEST] <alevinsn> I posted an example of what goes wrong to the ML [05:07:04 CEST] <alevinsn> To demonstrate the impact of this patch, here's some output of before and after for an .h264 file with interlaced 1080i59.94 video content: [05:07:04 CEST] <alevinsn> Command-line: ffmpeg -i test8_1080i.h264 -c:v mpeg2video test8_1080i_mp2.ts [05:07:06 CEST] <wm4> how can it produce an output packet without going through do_video_out()? [05:07:25 CEST] <alevinsn> Before patch: [05:07:26 CEST] <alevinsn> -------------------------------------- [05:07:26 CEST] <alevinsn> Input #0, h264, from 'test8_1080i.h264': [05:07:26 CEST] <alevinsn> Duration: N/A, bitrate: N/A [05:07:26 CEST] <alevinsn> Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc [05:07:27 CEST] <alevinsn> Stream mapping: [05:07:29 CEST] <alevinsn> Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native)) [05:07:31 CEST] <alevinsn> Press [q] to stop, [?] for help [05:07:33 CEST] <alevinsn> Output #0, mpegts, to 'test8_1080i_mp2_2.ts': [05:07:35 CEST] <alevinsn> Metadata: [05:07:36 CEST] <wm4> don't paste that here [05:07:37 CEST] <alevinsn> encoder : Lavf57.72.100 [05:07:39 CEST] <alevinsn> Stream #0:0: Video: mpeg2video (Main), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc [05:07:42 CEST] <alevinsn> Metadata: [05:07:42 CEST] <wm4> ... [05:07:44 CEST] <alevinsn> encoder : Lavc57.92.100 mpeg2video [05:07:46 CEST] <alevinsn> Side data: [05:07:48 CEST] <alevinsn> cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1 [05:07:50 CEST] <alevinsn> -------------------------------------- [05:07:52 CEST] <alevinsn> After patch: [05:07:56 CEST] <alevinsn> -------------------------------------- [05:07:58 CEST] <alevinsn> Input #0, h264, from 'test8_1080i.h264': [05:08:00 CEST] <alevinsn> Duration: N/A, bitrate: N/A [05:08:02 CEST] <alevinsn> Stream #0:0: Video: h264 (High), yuv420p(top first), 1920x1080 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc [05:08:05 CEST] <alevinsn> Stream mapping: [05:08:07 CEST] <alevinsn> Stream #0:0 -> #0:0 (h264 (native) -> mpeg2video (native)) [05:08:09 CEST] <alevinsn> Press [q] to stop, [?] for help [05:08:11 CEST] <alevinsn> Output #0, mpegts, to 'test8_1080i_mp2_2.ts': [05:08:13 CEST] <alevinsn> Metadata: [05:08:15 CEST] <alevinsn> encoder : Lavf57.72.100 [05:08:17 CEST] <alevinsn> Stream #0:0: Video: mpeg2video (Main), yuv420p(top coded first (swapped)), 1920x1080 [SAR 1:1 DAR 16:9], q=2-31, 200 kb/s, 29.97 fps, 90k tbn, 29.97 tbc [05:08:20 CEST] <alevinsn> Metadata: [05:08:22 CEST] <alevinsn> encoder : Lavc57.92.100 mpeg2video [05:08:26 CEST] <alevinsn> Side data: [05:08:28 CEST] <alevinsn> cpb: bitrate max/min/avg: 0/0/200000 buffer size: 0 vbv_delay: -1 [05:08:30 CEST] <alevinsn> -------------------------------------- [05:08:32 CEST] <alevinsn> too late, sorry [05:08:34 CEST] <alevinsn> but [05:08:36 CEST] <alevinsn> the issue has to do with the header that is written to the output file [05:08:50 CEST] <alevinsn> the header is written too early in the current implementation [05:09:01 CEST] <alevinsn> before it has had a chance to discover that the input is using interlaced video [05:09:02 CEST] <michaelni> jamrial, "../configure --cc='ccache gcc' --progs-suffix=abc --build-suffix=def && make -j12" fails to build [05:09:10 CEST] <michaelni> make: *** No rule to make target `libavfilter/libavfilter.pc', needed by `all-yes'. Stop. [05:09:14 CEST] <alevinsn> and that happens in do_video_out() [05:09:27 CEST] <michaelni> i dont have time ATM to bisect but it worked previously [05:09:39 CEST] <alevinsn> which doesn't get called the first time until after it calls check_init_output_file() [05:09:48 CEST] <jamrial> michaelni: is that a build folder inside the source tree folder? [05:09:53 CEST] <alevinsn> it has a frame by the time it calls check_init_output_file() the first time [05:09:54 CEST] <alevinsn> but [05:10:09 CEST] <alevinsn> it does use do_video_out() on this frame until after calling check_init_output_file() [05:10:11 CEST] <alevinsn> if that makes sense [05:10:31 CEST] <michaelni> jamrial, yes plain mkdir + cd whatever [05:10:51 CEST] <wm4> alevinsn: so, yes or no: the current implementation writes the header only once an output packet has been encoded for every stream? [05:11:14 CEST] <alevinsn> no, it writes it beforehand [05:11:24 CEST] <alevinsn> well [05:11:45 CEST] <alevinsn> I don't think that's quite right [05:11:57 CEST] <alevinsn> I don't think it starts to write output packets until it writes the header [05:12:06 CEST] <alevinsn> until all the output streams are initialized [05:12:11 CEST] <alevinsn> but, I'm not certain of that [05:12:31 CEST] <alevinsn> I can't imagine that it would write output packets until all output streams are initialized [05:13:29 CEST] <alevinsn> I don't think I answered your question though [05:13:34 CEST] <alevinsn> but, the answer is no [05:13:51 CEST] <alevinsn> it writes it beforehand [05:14:32 CEST] <alevinsn> this is only an issue for the last output stream that gets initialized though [05:15:33 CEST] <wm4> waiting until all streams have a packet before muxing is probably a good idea [05:15:55 CEST] <alevinsn> which is what I attempted to do [05:16:03 CEST] <wm4> AFAIK libavformat doesn't support leaving streams "blank" anyway (or making them start later) [05:16:28 CEST] <alevinsn> I don't think muxing starts to soon [05:16:36 CEST] <alevinsn> just the call to avformat_write_header() [05:16:42 CEST] <alevinsn> too soon [05:16:59 CEST] <jamrial> michaelni: can you test this fix? https://pastebin.com/raw/0DQbBWBF [05:18:09 CEST] <alevinsn> wm4: The reason why I thought it would be safe to do it this way [05:18:25 CEST] <alevinsn> is it effectively was already doing things in that order in some cases [05:18:46 CEST] <jamrial> michaelni: try doing a disclean and reconfigure to make sure, but since it's a Makefile change i assume it should work even in that build folder's current state [05:18:47 CEST] <alevinsn> if the mp4 file has AAC for audio and H.264 for video [05:19:02 CEST] <alevinsn> it initializes the video output stream before it does the audio output stream [05:19:14 CEST] <alevinsn> so, the sequence is: [05:20:16 CEST] <alevinsn> 1. init_output_stream() called for video [05:20:36 CEST] <alevinsn> 2. init_output_stream() for video calls cehck_init_output_file(), which sees that the audio stream hasn't been initialized and returns [05:20:50 CEST] <alevinsn> 3. do_video_out() called (sets up interlaced) [05:21:12 CEST] <alevinsn> 4. init_output_stream() called for audio, which calls check_init_output_file(), sees all streams initialized and proceeds with header [05:21:22 CEST] <alevinsn> but, if I use opus instead of AAC [05:21:29 CEST] <alevinsn> opus gets started up faster than video [05:21:43 CEST] <alevinsn> and the issue occurs, because it handles the audio output stream before the video output stream [05:22:22 CEST] <alevinsn> but, the point is, in case 1 above, there is already a precedent set for calling do_video_out() before the final call to check_init_output_file() [05:22:41 CEST] <alevinsn> and as such, I would think it would be safe to move the call to check_init_output_file() later [05:22:46 CEST] <alevinsn> in all cases [05:23:20 CEST] <alevinsn> but apparently not for the mpeg4-als-conformance fate tests [05:37:48 CEST] <wm4> alevinsn: how does your patch actually achieve this? [05:50:50 CEST] <cone-249> ffmpeg 03James Almer 07master:a5fdda79eee0: library.mak: fix build rules that depend on pgk-config files [05:51:42 CEST] <jamrial> michaelni: pushed since it fixed it for me [06:00:18 CEST] <alevinsn> wm4: sorry, was putting the kids to bed [06:00:53 CEST] <wm4> I mean I see your patch, but it all seems a bit implicit, probably behaves on coincidental behavior, and is likely to break soon again [06:01:02 CEST] <wm4> s/behaves/relies [06:01:34 CEST] <alevinsn> wm4: what do you mean? I made sure that, at least with reap_filters() [06:01:50 CEST] <alevinsn> the call to check_init_output_output() happens a bit later [06:01:57 CEST] <alevinsn> output_file() [06:02:37 CEST] <alevinsn> previously, it worked in some cases because of timing [06:02:47 CEST] <alevinsn> as with AAC/H.264 vs Opus/H.264 case [06:03:17 CEST] <alevinsn> with my change, check_init_output_file() is guaranteed to be called after each stream has gone through do_<video/audio>_out at least once [06:03:58 CEST] <alevinsn> so, the result should be consistent regardless of the codecs used [06:30:11 CEST] <alevinsn> wm4: I fixed the issue by moving the call to check_init_output_file() within the while loop after calling do_video_out() or do_audio_out() [06:30:29 CEST] <alevinsn> in the cases that it was failing [06:30:55 CEST] <alevinsn> apparently it was able to read a lot of frames quickly [06:31:13 CEST] <alevinsn> and it doesn't return from the while loop as quickly as with other cases [06:34:04 CEST] <alevinsn> and, because the muxer isn't setup yet [06:34:10 CEST] <alevinsn> the output packets need to be cached [06:34:15 CEST] <alevinsn> and when enough build up, it fails [06:34:40 CEST] <wm4> no, the error message is from libavfilter, which has nothing to do with packets [06:34:47 CEST] <wm4> or at least that's what I remember [06:34:56 CEST] <alevinsn> ok, maybe packet isn't the right word [06:35:37 CEST] <alevinsn> ffmpeg is calling them packets [06:35:41 CEST] <alevinsn> ala output_packet() [06:35:48 CEST] <alevinsn> an AVPacket * [06:36:27 CEST] <wm4> <alevinsn> [out_0_0 @ 00000170CF688F80] 100 buffers queued in out_0_0, something may be wrong. [06:36:28 CEST] <alevinsn> which calls write_packet() [06:36:37 CEST] <wm4> that's libavfilter, no packets or AVPackets [06:36:47 CEST] <alevinsn> write_packet() sees that if (!of->header_written) { [06:36:47 CEST] <alevinsn> AVPacket tmp_pkt = {0}; [06:36:47 CEST] <alevinsn> /* the muxer is not initialized yet, buffer the packet */ [06:37:03 CEST] <alevinsn> I'm pretty sure that's what is going on [06:37:10 CEST] <alevinsn> it is buffering the packets [06:37:19 CEST] <alevinsn> it hits some threshold and craps out [06:38:08 CEST] <alevinsn> The "Too many packets buffered for output stream 0:0." error [06:38:12 CEST] <alevinsn> which I mentioned earlier [06:38:14 CEST] <alevinsn> comes from this code [06:38:20 CEST] <alevinsn> from write_packet() in ffmpeg.c [06:38:43 CEST] <alevinsn> so, that's what is happening [06:39:15 CEST] <wm4> oh so we already have such a mechanism, that confuses me even more why your change is needed [06:39:28 CEST] <wm4> sorry maybe my effective sleep deprivation is to blame that I don't get it [06:39:42 CEST] <alevinsn> it all comes down to when it writes the header [06:40:01 CEST] <alevinsn> if it writes it too early, before sending at least one frame through do_video_out [06:40:09 CEST] <alevinsn> which is what it was doing prior to my patch [06:40:15 CEST] <alevinsn> then it thinks it is progressive [06:40:52 CEST] <wm4> so again [06:41:07 CEST] <wm4> it waits until it has a packet before it calls write_header, right? [06:41:16 CEST] <wm4> and to have a packet it needs to encode a packet [06:41:26 CEST] <alevinsn> not in the current code base [06:41:31 CEST] <wm4> and to encode something, a frame has to go through do_video_out [06:41:45 CEST] <wm4> then why do we have such a packet queue [06:42:29 CEST] <alevinsn> ffmpeg.c certainly could use some work [06:42:32 CEST] <alevinsn> perhaps a lot of it [06:43:50 CEST] <wm4> indeed [06:44:07 CEST] <alevinsn> there is no guarantee that an encoded frame will be produced from an input frame [06:44:10 CEST] <wm4> every time I have to fix something in it I hate my life [06:44:30 CEST] <alevinsn> the important thing here is that it goes through do_video_out(), which causes it to interpret the input frame [06:44:38 CEST] <alevinsn> and notice interlaced vs. progressive [06:44:52 CEST] <alevinsn> and populate that information [06:45:08 CEST] <wm4> I understand that [06:45:13 CEST] <alevinsn> after that point, all the information is available to properly populate the header [06:45:16 CEST] <wm4> and in theory it should do that already [06:45:29 CEST] <alevinsn> it should have been doing that already--yes, we agree on that :-) [06:45:43 CEST] <wm4> also it's not allowed to change the codepar after the headers have been written [06:45:56 CEST] <alevinsn> I think I'll need to add an interlaced video fate test [06:46:05 CEST] <wm4> and what I don't understand is why it's doing that with your patch [06:46:25 CEST] <alevinsn> its not changing codecpar with my patch as far as I know [06:46:56 CEST] <alevinsn> or maybe I don't understand what you think my patch is doing that ought to be already being done [06:47:22 CEST] <wm4> I mean without your patch it seems to change codecpar after writing headers (in the cases where it doesn't work) [06:47:42 CEST] <alevinsn> I don't think it changes anything without my patch [06:47:51 CEST] <alevinsn> it thinks it is progressive and sticks with that [06:48:10 CEST] <alevinsn> hmm, let me check [06:48:40 CEST] <alevinsn> it changes mux_par->field_order [06:48:48 CEST] <alevinsn> after calling avformat_write_headers() [06:49:24 CEST] <alevinsn> which is an AVCodecParameters object [06:49:43 CEST] <alevinsn> so, yes, it is changing ost->st->codecpar afterwards [06:49:54 CEST] <alevinsn> after calling avformat_write_header(), which seems wrong [06:50:07 CEST] <alevinsn> but, perhaps it doesn't matter after that point [06:50:48 CEST] <alevinsn> or, maybe it uses this information when it writes the individual frames, but because the header has already been written [06:51:01 CEST] <alevinsn> anything using the output will think it is progressive [06:51:15 CEST] <wm4> could it be that the code setting the interlace flags is simply in the wrong place? [06:51:41 CEST] <alevinsn> I thought so initially [06:51:48 CEST] <alevinsn> and it probably ought to be somewhere else [06:51:51 CEST] <wm4> actually I'm convinced of it right now [06:52:10 CEST] <wm4> this code is called during normal transcoding (outside of init), which should never touch codecpar (probably) [06:52:28 CEST] <alevinsn> the way it is written though, it needs a frame to determine if it is interlaced or not [06:52:40 CEST] <alevinsn> but realistically, all of the interlaced/progressive information should be in the header [06:52:47 CEST] <alevinsn> and it should never need a frame to extract this information [06:53:03 CEST] <alevinsn> but changing ffmpeg.c to do that was a bit of a stretch for me at the time [06:53:05 CEST] <alevinsn> and still is [06:53:17 CEST] <alevinsn> as you said, it can be painful to work in ffmpeg.c.... [06:55:07 CEST] <alevinsn> in fact, every time it goes through do_video_out(), it could in theory change mux_par->field_order, if there are mixed progressive/interlaced frames [06:55:16 CEST] <alevinsn> although, I can't imagine that ever occurs in practice [06:56:36 CEST] <alevinsn> the for loop in do_video_out() isn't formatted properly I also just noticed.... [07:06:21 CEST] <wm4> also the block around FF_API_LAVF_FMT_RAWPICTURE can be removed [07:10:20 CEST] <alevinsn> my change broke a bunch of other fate tests. looking into it.... [07:15:32 CEST] <alevinsn> looks like I need to do the call to check_init_output_file() in both places to get it to work (but only do it once per stream obviously) [07:43:12 CEST] <alevinsn> yay, fate passes completely, woot woot [08:47:07 CEST] <alevinsn> wm4: if you are so inclined, since you've already taken a look at the earlier version of the ffmpeg.c patch [08:47:22 CEST] <alevinsn> it would be great if you could review the new patch that I just submitted to the ML :-) [08:48:43 CEST] <rcombs> michaelni: any more failures in your files with the new version of my patch? [10:05:18 CEST] <cone-274> ffmpeg 03Janne Grunau 07master:35d1f726eb9f: fate: Add --ignore-tests configure option for omitting specific FATE tests [10:05:18 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:f5218b27c4f8: Merge commit '35d1f726eb9fdd376ab900587fb02122b72f2b9a' [10:09:35 CEST] <cone-274> ffmpeg 03Carl Eugen Hoyos 07master:ae68bb779ca7: lavu/timecode: Increase AV_TIMECODE_STR_SIZE. [10:21:44 CEST] <ubitux> i have an issue with an http server and ffmpeg [10:22:38 CEST] <ubitux> requesting ranges "N-" instead of "N-M" makes it not close the fd immediately at the end of the range but it reopens the file [10:23:18 CEST] <ubitux> so it exhausts fd pretty quickly and ffmpeg gets a 5xx [10:23:59 CEST] <ubitux> can we do something about it? i feel like whatever the http requests, the avio is going to read more anyway [10:24:05 CEST] <wm4> the server has the bug? [10:24:10 CEST] <ubitux> not sure [10:24:20 CEST] <ubitux> i'd say yes [10:24:35 CEST] <ubitux> but the ffmpeg behaviour looks aggressive [10:24:38 CEST] <wm4> I mean, the server leaks the FDs, and the server is not ffmpeg? [10:25:22 CEST] <ubitux> it's like FFmpeg saying "I'm going to read everything starting offset X", <read 4096>, "just kidding i'm done" [10:25:36 CEST] <ubitux> wm4: it's not exactly that [10:25:51 CEST] <ubitux> because if you sleep like, 0.05 the server garbage collect these [10:26:04 CEST] <ubitux> and we don't get any 500 [10:26:07 CEST] <wm4> not sure if I understand [10:26:37 CEST] <ubitux> if you sleep 0.05 in between the range requests, the server has time to garbage collect (hypothesis) and close the opened fd [10:26:52 CEST] <ubitux> but if we do it too fast, it's somehow expecting that we may read more [10:27:02 CEST] <ubitux> i'm not sure if it's correct to expect such thing [10:28:06 CEST] <wm4> I think I'm missing context [10:28:51 CEST] <ubitux> yeah i'm sorry, i'll try to explain better when i figured out things more precisely [10:32:48 CEST] <cone-274> ffmpeg 03Martin Storsjö 07master:5c83b4d550ea: fate: Unset the sig variable if ignoring a test failure [10:32:48 CEST] <cone-274> ffmpeg 03Martin Storsjö 07master:eef860dd9253: fate: Tweak printing of ignored tests [10:32:49 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:ed1fe7b2feeb: Merge commit '5c83b4d550ea42653fece092987bab56ccc32ead' [10:32:50 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:8a8f77e49b1a: Merge commit 'eef860dd92538764f4ab7872812914ff10384268' [10:33:36 CEST] <cone-274> ffmpeg 03Diego Biurrun 07master:ee164727dd64: configure: Fix typo in incdir variable written to config.sh [10:33:37 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:3757f8f2f6de: Merge commit 'ee164727dd64c199b87118917e674b17c25e0da3' [10:35:22 CEST] <cone-274> ffmpeg 03Sean McGovern 07master:d31f46e1999f: cmdutils: update copyright year to 2017 [10:35:23 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:21f17bbfd452: Merge commit 'd31f46e1999fab31be46f0cbce0546a5aa49fe48' [10:36:09 CEST] <cone-274> ffmpeg 03Martin Storsjö 07master:c536e5e86981: arm: vp9mc: Fix vertical alignment of operands [10:36:10 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:7d79d58a4e11: Merge commit 'c536e5e8698110c139b1c17938998a5547550aa3' [10:37:10 CEST] <cone-274> ffmpeg 03Martin Storsjö 07master:65074791e8f8: aarch64: vp9dsp: Fix vertical alignment in the init file [10:37:11 CEST] <cone-274> ffmpeg 03Martin Storsjö 07master:85ad5ea72ce3: aarch64: vp9mc: Fix a comment to refer to a register with the right name [10:37:12 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:f439764657f7: Merge commit '65074791e8f8397600aacc9801efdd17777eb6e3' [10:37:13 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:31fc675b1cb5: Merge commit '85ad5ea72ce3983947a3b07e4b35c66cb16dfaba' [10:38:01 CEST] <cone-274> ffmpeg 03Mark Thompson 07master:d08e02d929ff: vaapi_h265: Fix build failure with old libva without 10-bit surfaces [10:38:02 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:7b1929f173e9: Merge commit 'd08e02d929ff8be5f56bb1da0e439bf1ae557552' [10:39:27 CEST] <cone-274> ffmpeg 03Jun Zhao 07master:9b1db2d33883: vaapi_h264: Fix POC on IDR frames [10:39:28 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:730f75a099f8: Merge commit '9b1db2d33883c6ff3f8c7b2453146501ba14ca20' [10:45:12 CEST] <cone-274> ffmpeg 03Anton Khirnov 07master:9026ec8aaf5f: matroskadec: make sure not to leave EbmlBin in an inconsistent state [10:45:13 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:e6ee42febbde: Merge commit '9026ec8aaf5fa19cb4fb266c16f608af0d863b2b' [10:47:29 CEST] <cone-274> ffmpeg 03Steve Lhomme 07master:f8a42d4f260d: dxva2: Make ff_dxva2_get_surface() static and drop its name prefix [10:47:30 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:055d6c2ea92e: Merge commit 'f8a42d4f260db3eae4399fa8bd8c8c2c1d38f23a' [10:50:21 CEST] <nevcairiel> ubitux: that kind of request looks perfectly normal [10:52:02 CEST] <ubitux> yes, what i'm wondering if requesting N but reading less and then doing a new request suggest we could still read on the previous range [10:52:05 CEST] <ubitux> or that kind of logic [10:52:19 CEST] <ubitux> (which would justify a "ressources exhaust" on the server) [10:52:58 CEST] <ubitux> but it looks like to me that the ressources is flagged as "to be liberated" for a gc thread [10:53:02 CEST] <ubitux> and it's handling new requests [10:53:32 CEST] <ubitux> while actually a forced gc cleanup should be done in this case [10:54:42 CEST] <nevcairiel> what kind of file are you reading where it reads with so many little requests? [10:54:57 CEST] <nevcairiel> in my experience it'll read from one long-running request if the IO pattern allow it [10:55:10 CEST] <cone-274> ffmpeg 03Steve Lhomme 07master:0ac2d86c4758: dxva2: Factorize DXVA context validity test into a single macro [10:55:11 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:d168fe14e949: Merge commit '0ac2d86c4758e1419934905b6c092910296aa16a' [10:55:33 CEST] <ubitux> nevcairiel: a mov :) [10:55:48 CEST] <ubitux> and it's actually requesting a single data stream [10:55:54 CEST] <ubitux> so basically very sparse data [10:56:23 CEST] <nevcairiel> well then there is likely not a way around that [10:56:46 CEST] <ubitux> well, a workaround is to request range N-M instead of N- [10:57:01 CEST] <ubitux> because when it reaches M, the server actually drops the ressources immediately [10:57:07 CEST] <nevcairiel> but i doubt the http protocol knows how much data a demuxer is going to read [10:57:08 CEST] <ubitux> and it doesn't fd leak [10:57:39 CEST] <ubitux> right& :) [10:57:55 CEST] <nevcairiel> and somehow letting it know sounds hacky at best [10:58:31 CEST] <wbs> well a mov demuxer with integrated http fetcher would be able to do it better, but with the current abstractions inbetween, it'd indeed end up very hacky [10:59:27 CEST] <rcombs> it wouldn't be absurd to provide a way to indicate to the protocol how many bytes you're going to read [10:59:37 CEST] <rcombs> even if it was just a standard AVOption name [10:59:50 CEST] <wbs> in this case, it would be for each seek within the file [11:00:00 CEST] <wbs> "I want to seek to pos X and I'm going to read Y bytes from there" [11:00:06 CEST] <rcombs> set the AVOption before executing the seek? [11:00:47 CEST] <rcombs> hmm, actually putting it in AVOptions would probably be pretty sub-optimal; it'd be best for aviobuf to know about it [11:00:52 CEST] <nevcairiel> thats extremely hacky to workaround some broken http server [11:01:20 CEST] <rcombs> nevcairiel: well we also currently can end up transferring data more than we need to [11:01:41 CEST] <rcombs> since the server will keep writing until the TCP buffer fills up, even though we only needed up to a particular point [11:01:53 CEST] <rcombs> wonder what e.g. web browsers do about this [11:03:25 CEST] <nevcairiel> web browsers arent typically in the business of downloading tiny s lices of files [11:03:37 CEST] <rcombs> ubitux: is this a case where the whole file will get downloaded eventually, but out-of-order, and thanks to the TCP buffer we end up transferring bits repeatedly? [11:04:02 CEST] <rcombs> also making a seek after an N-M request in HTTP is fast, while making a seek after an N- request is slow [11:04:20 CEST] <rcombs> (HTTP/1.1, anyway) [11:05:14 CEST] <ubitux> this is actually happening in an ordered read of small very sparse data in a mov [11:05:33 CEST] <ubitux> (all the streams are flagged as discarded except the target stream, so only this one is read) [11:05:41 CEST] <rcombs> ah [11:06:16 CEST] <ubitux> so yeah, for every chunk, we request a small read, which ends up with http saying "infinite read incoming starting at X" [11:06:41 CEST] <rcombs> mmmm [11:06:45 CEST] <ubitux> and the avio below makes a bunch of large (useless) reads (but still not enough to reach the next chunk most of the time) [11:07:00 CEST] <rcombs> HTTP/2 solves this by just sticking everything on a single socket [11:07:19 CEST] <ubitux> so next time it makes a new range request [11:07:19 CEST] <rcombs> at least, the "lots of sockets" problem [11:07:34 CEST] <rcombs> not the "reads more data than necessary" problem [11:07:39 CEST] <ubitux> but the server didn't close the fd yet because we didn't read til the infinite [11:08:00 CEST] <rcombs> we do close the old socket, right? [11:08:14 CEST] <rcombs> which means sending RSTs, which will close the socket on the server [11:08:42 CEST] <ubitux> i suppose since it will garbage collect it at t + ~0.05, but it will be too late because we already requested 30 more ranges-requests [11:10:30 CEST] <rcombs> well we only have one request "live" at once, and the RSTs for each previous one would be sent before the SYN for the next [11:11:04 CEST] <nevcairiel> yeah that "leak" is definitely odd behavior on the servers part [11:11:14 CEST] <ubitux> i don't think we are doing anything particularly "wrong" yeah [11:11:19 CEST] <rcombs> so the server should see the previous request ECONNRESET-ing before the next one accept()s [11:11:36 CEST] <ubitux> yeah it should force the gc to release stuff before handling more [11:11:51 CEST] <wm4> btw. is this about the mov demuxer being stupid? [11:11:57 CEST] <nevcairiel> no [11:12:14 CEST] <rcombs> one pet peeve of mine is the awkwardness around the HTTP protocol and temporary seeks-to-end [11:12:15 CEST] <wm4> it's probably the only thing that triggers a lot of seeks just by forward-reading a file [11:12:23 CEST] <rcombs> wm4: AVI, maybe? [11:12:32 CEST] <nevcairiel> having discarded streams is likely to trigger seeks [11:12:52 CEST] <ubitux> wm4: the seeks are triggered because the data is sparse, that's normal, it would happen with any demuxer that support discarded streams [11:13:10 CEST] <wm4> ok [11:13:12 CEST] <rcombs> like, if you open an MOV or MKV with its index at the end, then lavf will perform a seek to the end to read it [11:13:28 CEST] <nevcairiel> i actually hacked my mkv demuxer to just read discarded streams anyway on a network source to avoid seeking [11:13:36 CEST] <nevcairiel> never bothered to look at other demuxers [11:13:42 CEST] <ubitux> wm4: it maybe not happened with a non interlaved avi though ;) [11:13:45 CEST] <rcombs> which means AVIO will close the first socket, open a new one, set it up, send a new request, get the data back& [11:13:57 CEST] <rcombs> and then lavf gets its data and seeks back to (around) the beginning [11:14:00 CEST] <wm4> mpv has a byte-level cache which usually avoids such issues except in extreme cases [11:14:06 CEST] <rcombs> which means AVIO will second the first socket, open a new one, set it up, send a new request, get the data back& [11:14:09 CEST] <ubitux> (or non interleaved mov for what it's worth) [11:14:38 CEST] <ubitux> basically, if the stream was dumped in a single blob in the data atom of the mov, it wouldn't cause a problem [11:14:40 CEST] <rcombs> so you end up making 3 requests when you only would've needed 2 if you'd kept the first one open [11:14:59 CEST] <nevcairiel> rcombs: there is plenty of optimizations one could do if you were to tear down abstraction walls, but abstraction is a good thing for your sanity =p [11:15:13 CEST] <ubitux> but would OTOH cause many seeks if we were reading more than one stream (the classic case) [11:15:19 CEST] <wm4> rcombs: interesting point [11:15:42 CEST] <rcombs> nevcairiel: I think it'd be reasonably possible to abstract "I want to read data at N bytes, but also will be coming back to where I am now" [11:15:43 CEST] <wm4> nevcairiel: or indicative that your abstraction sucks [11:16:03 CEST] <wm4> for example, we could have a connection cache [11:16:11 CEST] <ubitux> btw, somehow related, but a ffmpeg build even without pthreads has a non predictible avio behaviour [11:16:12 CEST] <wm4> that leaves old connection idle and closes them after a short timeout [11:16:19 CEST] <wm4> but also would allow picking up an old connection again [11:16:25 CEST] <ubitux> i have no idea why, but basically the number of reads and their amount is completely random between runs [11:16:35 CEST] <nevcairiel> wm4: in that case we would actively be causing ubitux' socket leak problem, so no? :p [11:16:46 CEST] <wm4> dunno what that leak problem is about [11:16:53 CEST] <rcombs> (which avio would handle and tell the protocol to open an extra connection if the protocol supports that, and otherwise just do what it does now) [11:19:28 CEST] <ubitux> nevcairiel: btw, unrelated, next commit to merge noop because ccb94789e2968329947f1c2e00d019f387f9c409? [11:19:59 CEST] <ubitux> alevinsn: you had a fate issue with checkasm recently, didn't you? [11:22:44 CEST] <nevcairiel> ubitux: yeah [11:23:10 CEST] <ubitux> nevcairiel: authorship is weird, i have a hard time tracking the actual commit [11:23:31 CEST] <nevcairiel> which actual commit? [11:23:42 CEST] <ubitux> the equivalent of 2835e9a9fd2b355e7936d1024ff1bf5fe454e428 [11:23:48 CEST] <ubitux> but maybe it's one made specially for libav [11:23:53 CEST] <ubitux> and not a cherry pick [11:24:28 CEST] <nevcairiel> it was included right in the main10 push in ffmpeg from me, so the commit wasnt needed [11:25:15 CEST] <ubitux> yep ok [11:25:17 CEST] <ubitux> thanks [11:25:22 CEST] <cone-274> ffmpeg 03Steve Lhomme 07master:2835e9a9fd2b: hevcdec: add P010 support for D3D11VA [11:25:23 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:938e5f57d208: Merge commit '2835e9a9fd2b355e7936d1024ff1bf5fe454e428' [11:26:09 CEST] <nevcairiel> ah because anton for some reason added 10-bit dxva2 support instead of picking my patches [11:26:13 CEST] <nevcairiel> well thats libav for you [11:26:24 CEST] <cone-274> ffmpeg 03Martin Storsjö 07master:4e62b57ee039: fate: Skip the checkasm test if CONFIG_STATIC is disabled [11:26:25 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:373bfe4fcaff: Merge commit '4e62b57ee03928c12a3119dcaf78ffa1f4d6985f' [11:26:53 CEST] <nevcairiel> we should probably do the same for that other test tool that doesnt work [11:27:02 CEST] <nevcairiel> although i dont know yet why it doesnt w ork [11:27:15 CEST] <nevcairiel> should figure that out [11:27:16 CEST] <ubitux> we have other test tool with that problem? [11:27:27 CEST] <nevcairiel> avcodec/test/options [11:27:29 CEST] <nevcairiel> apparently [11:27:40 CEST] <nevcairiel> but i'm not sure why [11:28:45 CEST] <cone-274> ffmpeg 03Anton Khirnov 07master:e199a8099411: Changelog: mention the new avbuild/ directory [11:28:46 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:e0beaff4877a: Merge commit 'e199a8099411d0992c3ed278287a81f1d791199c' [11:29:59 CEST] <cone-274> ffmpeg 03Henrik Gramner 07master:3cba1ad76d36: x86inc: Avoid using eax/rax for storing the stack pointer [11:30:00 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:e584e88c5674: Merge commit '3cba1ad76d362c994fa98fb686e04e20826fb579' [11:31:13 CEST] <cone-274> ffmpeg 03Anton Khirnov 07master:e7de05f98f63: h264dec: drop a redundant check [11:31:14 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:cb0eba71f047: Merge commit 'e7de05f98f630b5b3a5e441c8fa763e6d89b8851' [11:32:37 CEST] <cone-274> ffmpeg 03Anton Khirnov 07master:f1af37b51033: h264dec: make ff_h264_decode_init() static [11:32:38 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:20e72faef694: Merge commit 'f1af37b51033ad90e56a8d7dfcc366f2bd9d2fed' [11:42:43 CEST] <BtbN> "/var/tmp/portage/media-video/ffmpeg-9999/work/ffmpeg-9999/configure: line 466: ffbuild/config.log: No such file or directory" [11:42:45 CEST] <BtbN> weird [11:43:06 CEST] <BtbN> it's not an error though, it successfully builds [11:43:15 CEST] <wm4> is that a clean build? i.e. no old build files [11:43:23 CEST] <BtbN> yes, it's a portage build [11:43:48 CEST] <BtbN> building current git HEAD [11:45:06 CEST] <wm4> I don't think I get this message [11:45:15 CEST] <nevcairiel> sounds odd, it should create the directory before the first log calls [11:45:25 CEST] <nevcairiel> unless gentoo somehow patches configure [11:45:36 CEST] <BtbN> i'm pretty sure it leaves it alone [11:45:45 CEST] <BtbN> gives it quite a monsterous configure line, but that's about it [11:46:25 CEST] <nevcairiel> i've always wondered if its possible to convince gentoo to s kip all the arch options and instead just let ffmpeg build with everything, you know, since it has runtime detection [11:47:21 CEST] <BtbN> by setting the cpudetection useflag. [11:48:00 CEST] <BtbN> Disabling it was deemed to be faster, so it instead optimizes for the configured CPU type by default [11:48:17 CEST] <nevcairiel> that sounds dumb [11:48:18 CEST] <nevcairiel> :D [11:48:28 CEST] <BtbN> Which is fine imo, as Gentoo instructs gcc to build with -march=native by default anyway, so the resulting build is not portable to begin with [11:49:01 CEST] <nevcairiel> i dont think setting cpudetection skips all the arch c onfigure settings [11:49:36 CEST] <BtbN> you'd have to just set them all to enabled [11:49:49 CEST] <nevcairiel> yeah which is stupid [11:49:54 CEST] <nevcairiel> let it figure it out, it can do that! [11:50:22 CEST] <BtbN> There's a lengthy bugreport about that, and people came up with benchmarks, showing that disabling runtime detection is $fast, and it was closed [11:50:40 CEST] <nevcairiel> you can fake any benchmark to make your point [11:51:05 CEST] <jkqxz> alevinsn: nevcairiel: Assuming the stuff on github is more than just a wall-throw (possibly overly hopeful, but still...), the next version of libmfx will have pkg-config support built in. [11:51:10 CEST] <jkqxz> <https://github.com/Intel-Media-SDK/MediaSDK/commit/92b6ee70f5ea45d08527f81c…> [11:52:10 CEST] <wm4> nice [11:52:34 CEST] <BtbN> Does it still randomly get stuck? [11:53:01 CEST] <nevcairiel> BtbN: interesting fact: passind --disable-runtime-cpudetect doesnt even do shit except for some obscure ppc thing and some shit in libpostproc, not exactly the most notable cases [11:54:37 CEST] <BtbN> https://github.com/gentoo/gentoo/blob/master/media-video/ffmpeg/ffmpeg-9999… [11:54:47 CEST] <BtbN> it does use a weird way to invoke configure, maybe that's why it's confused [11:55:19 CEST] <nevcairiel> its just an out of tree build, isnt it [12:13:50 CEST] <wm4> why does nicolas have such a problem with the alignment stuff (and is so stubborn about not fixing it / letting nobody fix it) [12:16:46 CEST] <ubitux> it's because our asm dsp expect aligned data but ff_framequeue_skip_samples() doesn't have such requirement? [12:17:18 CEST] <ubitux> can't we have the dsp wrapper call the safe C version for the unaligned part if any? [12:21:30 CEST] <kierank> The alignment requirements for input where always undefined [12:21:44 CEST] <kierank> Sorry for output buffers [12:22:01 CEST] <nevcairiel> perhaps undocumented, but you get into trouble if its not aligned to your cpus SIMD requirements [12:22:05 CEST] <kierank> Opus uses avx2 and so requires 32-byte alignment but this is undovumented [12:44:32 CEST] <atomnuker> kierank: opus? [12:57:00 CEST] <BtbN> nevcairiel, yeah, nothing special about it [13:10:49 CEST] <cone-274> ffmpeg 03Diego Biurrun 07master:e435beb1ea53: crypto: consistently use size_t as type for length parameters [13:10:50 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:651ee9346105: Merge commit 'e435beb1ea5380a90774dbf51fdc8c941e486551' [13:16:17 CEST] <Tomaz^W> Quick question does the ffmpeg configure / makefiles automatically include certain headers? [13:17:18 CEST] <Tomaz^W> utils.c for example in libswscale, needs FF_ALLOCZ_OR_GOTO, which is in libavutil/internal.h, but I don't see it included anywhere, so just wondering if there are some forced header includes? [13:18:14 CEST] <wm4> no, all include statements are in .h or .c files which are part of the git source [13:18:50 CEST] <nevcairiel> its probably included by one of the other headers [13:18:52 CEST] <Tomaz^W> Then I'm lost on how it can find that macro, since no header it includes, are including the needed libavutil/internal.h [13:19:38 CEST] <Tomaz^W> Gonna dig deeper then [13:20:11 CEST] <nevcairiel> avutil.h includes common.h which includes internal.h [13:23:09 CEST] <wm4> uh what [13:23:12 CEST] <Tomaz^W> Thanks! That made me find my misstake, apparently I had forgotten to set HAVE_AV_CONFIG_H [13:23:18 CEST] <wm4> so a public header includes an internal one? [13:23:31 CEST] <nevcairiel> you should never set that define manually [13:23:32 CEST] <Tomaz^W> only if HAVE_AV_CONFIG_H is set [13:23:34 CEST] <nevcairiel> the build system s ets it [13:23:52 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:fcc4ed1efa1a: lavu/sha512: update length argument following sha+md5 changes [13:24:08 CEST] <Tomaz^W> true [13:24:31 CEST] <Tomaz^W> I was just trying a few things out, and now it works, thanks alot nevcairiel [13:26:06 CEST] <nevcairiel> wm4: the "internal" avutil header isnt even that particular internal anyway, it just requires config.h for compiler detection and whatnot, which isnt public/installed [13:27:28 CEST] <BtbN> nevcairiel, hm, using the gentoo configure line for an out-of-tree build reproduces the warning for me [13:27:40 CEST] <BtbN> not to gradually remove things from it, to find which of the 200 options causes it [13:27:52 CEST] <BtbN> https://bpaste.net/show/7f580eba0d63 [13:28:47 CEST] <cone-274> ffmpeg 03Diego Biurrun 07master:00b6a765430e: hmac: Explicitly convert types at function pointer assignment [13:28:48 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:90fe0800fb84: Merge commit '00b6a765430e5c5cacf0bd1be8b318d631cd4e14' [13:30:34 CEST] <cone-274> ffmpeg 03Alexandra Hájková 07master:d7fe11634c1a: motionpixels: Convert to the new bitstream reader [13:30:35 CEST] <cone-274> ffmpeg 03Alexandra Hájková 07master:9aec009f65f7: dvbsubdec: Convert to the new bitstream reader [13:30:36 CEST] <cone-274> ffmpeg 03Alexandra Hájková 07master:4e2505103146: adx: Convert to the new bitstream reader [13:30:37 CEST] <cone-274> ffmpeg 03Alexandra Hájková 07master:bd6496fa07e3: interplayvideo: Convert to the new bitstream reader [13:30:38 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:18e2a446c52b: Merge commit 'bd6496fa07e32fd09ceb79404f9af43df959bcb2' [13:30:57 CEST] <cone-274> ffmpeg 03Mark Thompson 07master:37fab0661a76: vaapi_encode: Fix GOP sizing [13:30:58 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:5786ee3eee7a: Merge commit '37fab0661a760b2a9d727939d72e629acee1a6ef' [13:31:48 CEST] <cone-274> ffmpeg 03Mark Thompson 07master:a3c3a5eac20a: vaapi_encode: Support forcing IDR frames via AVFrame.pict_type [13:31:49 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:2eb8fcff0f99: Merge commit 'a3c3a5eac20a51d402c332cdf5220fff40a7943f' [13:32:23 CEST] <cone-274> ffmpeg 03Mark Thompson 07master:89725a851272: vaapi_h264: Scale log2_max_pic_order_cnt_lsb with max_b_frames [13:32:24 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:2ea6310f4ae7: Merge commit '89725a8512721fffd190021ded2d3f5b42e20e2a' [13:33:02 CEST] <BtbN> ok, found the minimal configure line to reproduce: ../ffmpeg/configure --disable-outdev=sdl [13:33:13 CEST] <BtbN> Which is probably because sdl does not exist anymore [13:33:27 CEST] <BtbN> so it wants to log that, but the ffbuild directory with the log file was not created yet [13:37:27 CEST] <nevcairiel> shouldnt that go to stderr if a nything, to warn about wrong command line [13:38:01 CEST] <BtbN> Yeah, but it also gets logged. [13:38:36 CEST] <BtbN> The warnings gets stored and printed after all the configure output, so people don't miss it [13:40:03 CEST] <cone-274> ffmpeg 03Michael Niedermayer 07master:ce551a3925a1: avcodec/tiertexseqv: set the fixed dimenasions, do not depend on the demuxer doing so [13:40:04 CEST] <cone-274> ffmpeg 03Michael Niedermayer 07master:1f5b6c7e1ee6: avcodec/pixlet: Fix shift exponent 4294967268 is too large for 32-bit type 'int' [13:40:05 CEST] <cone-274> ffmpeg 03Michael Niedermayer 07master:527f89e05922: avcodec/aacps: Fix undefined behavior [13:41:39 CEST] <cone-274> ffmpeg 03Diego Biurrun 07master:2a2889e130fe: build: Remove stray duplicate conditional variable declaration [13:41:40 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:cea5e7355c58: Merge commit '2a2889e130fee6d3c11e506328388afb317626ed' [13:43:03 CEST] <nevcairiel> where is the line that logs this? [13:43:08 CEST] <nevcairiel> i cant find anything special for sdl [13:43:16 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L3495 [13:46:17 CEST] <nevcairiel> should probably move setup of the logging stuff up then [13:46:24 CEST] <BtbN> yeah [13:46:44 CEST] <nevcairiel> right now it would never show up in the logfile anyway [13:46:52 CEST] <nevcairiel> because its re-written in 3588 [13:47:06 CEST] <nevcairiel> echo "# $0 $FFMPEG_CONFIGURATION" > $logfile [13:47:27 CEST] <BtbN> Yeah, those 3 lines should probably go up a bunch [13:47:53 CEST] <BtbN> the problem is, the logfile location could be changed in the option parsing code, so setting it before that is also not very correct [13:49:01 CEST] <nevcairiel> maybe the option parsing should just not log then =p [13:52:07 CEST] <nevcairiel> that one line is the only one logging [13:52:11 CEST] <nevcairiel> apparently [14:05:02 CEST] <cone-274> ffmpeg 03Diego Biurrun 07master:122de16dd810: Replace cmdutils_common_opts.h by a macro [14:05:03 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:b010843594fe: Merge commit '122de16dd8108a59a55d30543c9f28b5f61b02d1' [14:06:35 CEST] <cone-274> ffmpeg 03Steve Lhomme 07master:f67235a28cef: dxva2: get the slice number directly from the surface in D3D11VA [14:06:36 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:0ab40e4477ea: Merge commit 'f67235a28cef44fcd97ae74ad53bbbc0d7f63d60' [14:07:55 CEST] <durandal_1707> michaelni: do you have time? [14:07:57 CEST] <cone-274> ffmpeg 03Steve Lhomme 07master:ac3c3ee678e5: dxva2: allow an empty array of ID3D11VideoDecoderOutputView [14:07:58 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:86b2c7d422fa: Merge commit 'ac3c3ee678e51b05a2a7c30ce79465db46ba01fa' [14:09:23 CEST] <graphitemaster> two questions: 1) does ffmpeg have some sort of method for opening from memory (e.g I already have a stream in memory, would just like it to use it) and 2) is there a way to control how much of that stream ffmpeg buffers internally (copies into it's own memory or does decoding ahead of time of) [14:10:44 CEST] <wm4> 1) custom AVIO, 2) no [14:10:56 CEST] <cone-274> ffmpeg 03Anton Khirnov 07master:b68e353136db: qsvdec: do not sync PIX_FMT_QSV surfaces [14:10:57 CEST] <wm4> also this is the channel for development _of_ ffmpeg, not _with_ ffmpeg [14:10:57 CEST] <cone-274> ffmpeg 03Clément BSsch 07master:3c085c1ba56d: Merge commit 'b68e353136db6f963212c457281d9716516cdc59' [14:12:26 CEST] <ubitux> who wants to take over the merge? (yes, it means the next one are going to be a pain) [14:12:53 CEST] <ubitux> (400 commits left) [14:13:12 CEST] <ubitux> we'll have to decide about the bitstream api [14:13:36 CEST] <wm4> currently they're all skipped, aren't they [14:13:40 CEST] <ubitux> yes [14:16:04 CEST] <BBB> is that get_bits replacement? [14:16:06 CEST] <nevcairiel> the cropping patches? [14:16:27 CEST] <ubitux> nevcairiel: yep, a bunch of cropping patches touching sensible parts [14:16:39 CEST] <ubitux> not sure it's going to be hard, but it's going to be annoying [14:16:50 CEST] <ubitux> BBB: yes, bitstream api is about get_bits replacement [14:17:14 CEST] <ubitux> BBB: they updated a ton of codecs, we skip every one of them, so now we are slower in various configuration and merges are harder [14:17:30 CEST] <nevcairiel> (also faster in various other configurations) [14:17:37 CEST] <ubitux> right [14:17:54 CEST] <nevcairiel> if you leave that out it sounds so one-sided =p [14:17:58 CEST] <BBB> haha [14:18:03 CEST] <ubitux> of course :) [14:18:18 CEST] <BBB> I believe you can simply be faster overall if you make the cache 64bit on HAVE_FAST_64BIT configurations [14:18:38 CEST] <ubitux> i'd love to see this [14:18:55 CEST] <ubitux> but slower + hard merge is too much [14:19:02 CEST] <ubitux> only one of them is fine with me [14:19:15 CEST] <ubitux> (ofc, better if we can get rid of both) [14:19:16 CEST] <atomnuker> I was working on adding persistent caching to the current get bits which would be activated via an ifdef on supported/useful codecs [14:19:23 CEST] <wm4> help Libav to optimize speed, merge these changes, everyone is happy? [14:19:37 CEST] <atomnuker> wm4: what, like our suggestions about the API [14:19:38 CEST] <ubitux> wm4: that's what i'd like to see, but it seems we're not going that way [14:19:53 CEST] <BBB> atomnuker: what is persistent caching? [14:20:20 CEST] <wm4> atomnuker: not from you anyway? Libav isn't aware of any suggestions/questions/communication from you [14:21:05 CEST] <atomnuker> a year ago I said I disliked the API [14:21:38 CEST] <wm4> did it have anything constructive to it? [14:21:45 CEST] <atomnuker> BBB: what their reader currently does e.g. keep a 64 bit cache in the struct instead of redoing the operation on every read [14:22:06 CEST] <BBB> we have a cache also [14:22:10 CEST] <BBB> right? [14:22:13 CEST] <BBB> its just 32bit [14:22:26 CEST] <atomnuker> redone on every get_bits read [14:22:28 CEST] <michaelni> durandal_1707, if its important otherwise ive a few new issues to look at and some patches to test [14:23:29 CEST] <BBB> really? [14:23:50 CEST] <atomnuker> wm4: yes, I said it had inconsistent naming (by occasionally dropping any suffixes related to reading) which also blocked any future improvements to put_bits, as well as being too long [14:24:52 CEST] <wm4> and that was where, on irc? [14:24:53 CEST] <atomnuker> BBB: yes, though where it really counts we get around it and keep the cache persistent for an entire function [14:25:03 CEST] <atomnuker> wm4: yes, I asked luca [14:25:12 CEST] <BBB> hm, I see [14:25:27 CEST] <BBB> yes that makes no sense [14:25:30 CEST] <atomnuker> (by using the macros directly rather than get_bits or anything) [14:25:56 CEST] <atomnuker> I don't know why not always doing it is slower but iive would probably know [14:26:07 CEST] <atomnuker> *isn't always faster [14:27:00 CEST] <BBB> I would guess that changing the function signature changes inlining behaviour by the compiler which has all sort of downstream effects [14:27:08 CEST] <BBB> (note it doesnt use av_always_inline) [14:27:09 CEST] <iive> i was going to work on get_bits after i finish my current plaything. [14:27:18 CEST] <ubitux> michaelni: i'm sorry about "this text", but CE has been a dick with me all morning and was bringing up again his pkg-config shit so i couldn't let it go [14:27:37 CEST] <ubitux> (see cvslog) [14:27:41 CEST] <BBB> anyway, do what you guys need to, I still agree dropping libav get_bits replacement is silly [14:27:46 CEST] <BBB> and I also agree pkg-config is a fine requirement [14:28:03 CEST] <iive> atomnuker: libav bitstreamer is faster, because it have simplified the addressing [14:28:04 CEST] <BBB> I have to install it manually on my system (mac) and I never made an issue out of it [14:29:00 CEST] <ubitux> (michaelni: refering to this thread http://ffmpeg.org/pipermail/ffmpeg-cvslog/2017-May/106891.html) [14:29:01 CEST] <iive> we can do the same. that is, instead of having an bit_index and calculating the address each time, keep the address in the bs [14:30:54 CEST] <wm4> atomnuker: well I can see that one guy bringing up some broad remarks to some other guy doesn't make the actual author of the patches jump on it (if she was even aware of the criticism), especially if no other attempt at communication happened (especially not bringing it up in Libav patch review) [15:31:54 CEST] <gh0st__> ubitux: Hi! I am new here, and I wondered about what merges you are talking about. You are merging things from libav project into ffmpeg if I am not mistaking? [15:33:59 CEST] <ubitux> gh0st__: yes [15:34:17 CEST] <ubitux> durandal_1707: stupid question: aren't fir filter just "tap" filters? why do you have a fft? [15:35:38 CEST] <durandal_1707> ubitux: convolution in time is slower than in freq domain [15:35:43 CEST] <ubitux> ah wait, it's using the 2nd stream for coeffs [15:35:57 CEST] <ubitux> but in many case you have like, 3-10 coeffs max, no? [15:36:17 CEST] <durandal_1707> ubitux: up to 20 sec for reverb [15:36:33 CEST] <ubitux> i'd imagine sth like -af afir="-1 2 5 2 -1" [15:36:35 CEST] <durandal_1707> aurelization, ambiophonics etc [15:36:39 CEST] <ubitux> or at least a way of doing that [15:37:47 CEST] <BBB> btw if we are going to make performance improvements to our bit reader [15:37:49 CEST] <BBB> thats all great [15:37:54 CEST] <durandal_1707> ubitux: this is for huge impulse response [15:37:57 CEST] <BBB> but can we please not be biologists about it? [15:38:08 CEST] <BBB> i.e. each change should be submitted individually and judged independently [15:38:19 CEST] <BBB> dont delete old import new and say look its better for one file!" [15:38:29 CEST] <BBB> thats not how we do performance improvements here [15:38:32 CEST] <ubitux> durandal_1707: do we have something for small fir? [15:40:38 CEST] <durandal_1707> ubitux: nope, but what use is small fir? [15:41:17 CEST] <durandal_1707> i could add small fir support to this one anyway if one needs 0 latency [15:45:35 CEST] <ubitux> durandal_1707: mainly experiment, audio understanding, precise sample tests, ... [15:47:29 CEST] <ubitux> durandal_1707: btw, if you're bored: http://mziccard.me/2015/06/12/beats-detection-algorithms-2/ [15:47:33 CEST] <ubitux> this one might be cool [15:48:02 CEST] <ubitux> (or something along the lines) [15:48:08 CEST] <durandal_1707> ubitux: look at code and help me find obvious bug [15:50:03 CEST] <ubitux> it looks like you handled it, but double check the (N+1)/2 hack due to bins size [15:50:42 CEST] <ubitux> btw, "clicks" are probably visible with a wav view [15:51:04 CEST] <ubitux> try with simple signals and look for a peak glitch [15:51:42 CEST] <ubitux> look at the nb_samples too [15:52:04 CEST] <ubitux> like, make sure they have a fixed size or something [16:33:47 CEST] <Croolman> Hi everyone, just a quick question. I have gone through the cascade of the function which are called when the av_frame_copy() function is called, but I would like to just doublecheck. If destination frame is bigger than source, can I expect dest frame to be an input with black padding on left and bottom? [16:34:19 CEST] <Croolman> sorry - right side and bottom [17:22:51 CEST] <kierank> One of the vector_fmul functions requires 32-byte alignmenr [17:24:46 CEST] <atomnuker> oh that [17:25:22 CEST] <atomnuker> yeah, I was going to say the ptwo fft is the only simd code in the opus decoder so far [17:26:17 CEST] <atomnuker> shame I couldn't use any float_dsp functions for the encoder, I don't care if they'd give a 2% speed increase [17:28:54 CEST] <atomnuker> I could use a vector fmul in case of more than 480 coeff but I'd have to do a nasty trick and offset the pointer to get something aligned [18:19:15 CEST] <jamrial> nevcairiel: should i push the hevc patches or do you still want to look at them? [18:20:14 CEST] <nevcairiel> oh yeah i forgot to comment on the ML [18:24:37 CEST] <nevcairiel> overall LGTM to me [18:33:37 CEST] <jamrial> so Nicolas introduces a regression, and then pulls this shit? [18:33:47 CEST] <JEEB> yup [18:34:56 CEST] <JEEB> yes, things might not be perfectly defined and the change might not technically be incorrect - but it's still a regression [18:35:47 CEST] <nevcairiel> so getting tired of dealing with that guy, everytime his name pops up its the same deal of stupidity [18:36:24 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:9fac508ca46f: avcodec/wnv1: Fix runtime error: left shift of negative value -1 [18:36:24 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:38152d9368be: avcodec/dss_sp: Fix multiple left shift of negative value -466 [18:36:24 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:f55df6299868: avcodec/g722: Fix multiple runtime error: left shift of negative value -1 [18:55:29 CEST] <kierank> atomnuker: https://spaceflightnow.com/2017/05/05/bulgarias-first-communications-satell… [18:55:32 CEST] <kierank> Good work [18:58:18 CEST] <iive> bulsat com? [19:17:08 CEST] <AaronL> jkqxz: I don't know who maintains the Intel Media SDK github that you mentioned [19:17:17 CEST] <AaronL> but that project may not be suitable for use on Windows [19:21:05 CEST] <AaronL> jamrial: I've been meaning to take a look at your HEVC patches [19:21:09 CEST] <AaronL> but I haven't gotten around to it [19:21:14 CEST] <AaronL> I came up with a plan for how to review them [19:21:17 CEST] <AaronL> though [19:21:42 CEST] <AaronL> If you would like my review, I'll try to get to it today if you are interested in waiting before applying [19:21:48 CEST] <jamrial> why do you even need a plan for that? [19:22:06 CEST] <AaronL> um, plan isn't the right word [19:22:24 CEST] <jamrial> reply to the set if you think it's good, or reply to individual patches if you want to comment on some specific change [19:22:52 CEST] <AaronL> but, the order in which I would review the patches--for something like that, I like to apply them and use tortoisemerge to compare the old and new files [19:26:51 CEST] <AaronL> general question: I read Clément BSsch's (ubitux, I think) blog post about libav at http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html [19:27:36 CEST] <AaronL> talks about, for libav, every small patch requires review [19:27:55 CEST] <AaronL> and apparently different from the policy for ffmpeg--but, as far as I can tell, that's the policy for ffmpeg now as well [19:28:00 CEST] <AaronL> as that correct? [19:28:11 CEST] <AaronL> is that correct I mean [19:28:26 CEST] <AaronL> referring to "color preferences" section of the blog post [19:30:05 CEST] <AaronL> ubitux: you asked: "you had a fate issue with checkasm recently, didn't you?" [19:30:20 CEST] <AaronL> yes, was caused by doing a shared build--problem goes away with a static build [19:30:49 CEST] <AaronL> nevcairiel helped me out with that [19:38:57 CEST] <AaronL> ubitux: I see that one of the merges disabled checkasm for shared builds--that's good, but options.exe also fails to build for the same reason [19:49:36 CEST] <ubitux> AaronL: yes that's an old blog post from 2012 [19:49:50 CEST] <ubitux> we still don't have a forced review [19:50:20 CEST] <ubitux> there are unofficial rules, but basically we want review for api changes [19:50:27 CEST] <ubitux> or non trivial patches [19:50:44 CEST] <AaronL> there are a lot of pretty trivial patches posted to the ML [19:50:50 CEST] <ubitux> or typically patches that touch maintained part by other developers [19:51:00 CEST] <ubitux> yeah sure [19:51:08 CEST] <ubitux> but not mandatory doesn't mean you can't do it [19:51:15 CEST] <ubitux> reviews are good [19:51:39 CEST] <AaronL> I guess my point is, based on what I've been seeing on the ML, and the cvslog ML, most patches are submitted for review [19:51:49 CEST] <AaronL> even by the maintainer, even for trivial changes [19:51:51 CEST] <ubitux> the cases where you don't want review are typically on quick fix on code you maintain, or cosmetics [19:52:11 CEST] <ubitux> and there is actually a relatively large amount of those so it would be a pain to force a review for this [19:52:22 CEST] <AaronL> perhaps not recently I guess [19:52:37 CEST] <ubitux> it's up to the developers [19:53:45 CEST] <ubitux> so anyway [19:54:00 CEST] <AaronL> k [19:54:01 CEST] <ubitux> what's the issue with options? [19:54:20 CEST] <ubitux> like, which symbols are failing? [19:54:25 CEST] <AaronL> this can be seen in one of the shared fate MSVC runs that nevcairiel has setup on fate.ffmpeg.org [19:54:29 CEST] <AaronL> I'll get a link [19:55:31 CEST] <AaronL> search http://fate.ffmpeg.org/log.cgi?time=20170505160414&log=test&slot=x86_32-msv… for __imp [19:55:45 CEST] <AaronL> the problem stems from building binaries for dynamic use on Windows [19:55:52 CEST] <AaronL> and then trying to link to them staticly [19:56:02 CEST] <AaronL> options.exe failed to build for the same reasons that checkasm.exe failed to build [19:56:14 CEST] <AaronL> although, that doesn't affect any of the FATE tests [19:56:37 CEST] <ubitux> ah, that's some array again [19:56:53 CEST] <ubitux> maybe missing or broken av_export [19:56:54 CEST] <AaronL> this is libavcodec/tests/options.exe--nevcairiel indicated that is just built for more code coverage [19:57:03 CEST] <AaronL> and isn't really needed [19:57:38 CEST] <ubitux> so it seems the av_export are present on these symbols [19:58:04 CEST] <AaronL> I think it more has to do with building the .o files such that they can be used for dynamic linking [19:58:12 CEST] <AaronL> it is the exact same failure that happened with checkasm [19:58:22 CEST] <AaronL> until checkasm was disabled for shared builds [19:58:25 CEST] <nevcairiel> it doesnt link against any other symbols from what i can tell [19:58:26 CEST] <ubitux> every failing symbol is one of these table with av_export [19:58:29 CEST] <nevcairiel> no clue why options thing fails [19:58:46 CEST] <nevcairiel> it just includes the .c file, no linking [19:58:56 CEST] <ubitux> seems like a windows thing [19:58:59 CEST] <ubitux> i won't be able to help :p [19:59:20 CEST] <AaronL> it does link [19:59:31 CEST] <AaronL> I'm pretty sure--I took a look at the Makefiles yesterday [20:01:56 CEST] <AaronL> $(TESTPROGS) $(TOOLS): %$(EXESUF): %.o [20:01:56 CEST] <AaronL> $$(LD) $(LDFLAGS) $(LDEXEFLAGS) $$(LD_O) $$(filter %.o,$$^) $$(THISLIB) $(FFEXTRALIBS) $$(ELIBS) [20:02:06 CEST] <AaronL> from ffbuild/library.mak [20:02:13 CEST] <nevcairiel> thats what all tests do, but all others work [20:02:18 CEST] <nevcairiel> so whats special about that one [20:02:44 CEST] <AaronL> probably what options.c uses [20:03:00 CEST] <AaronL> static linker can be smart about what symbols it brings in [20:04:14 CEST] <AaronL> although admittedly, there isn't much to the file [20:15:34 CEST] <AaronL> nevcairiel: its a mystery--I have no idea why it doesn't work for options.exe. [20:15:59 CEST] <AaronL> according to the log message to disable checkasm for shared builds [20:16:09 CEST] <AaronL> "This worked up until recently, only by luck." [20:16:44 CEST] <AaronL> its not "luck", since it happens repeatedly, but it would be nice to know why it works fine for the rest of the libavcodec test exes [20:16:46 CEST] <AaronL> but not options.exe [20:21:09 CEST] <AaronL> ubitux: any chance that nevcairiel and michaelni have convinced you that it is okay to use the libmfx patch as-is that I submitted? :-) [20:21:43 CEST] <AaronL> because I can guarantee it, that if I create a new patch that does what you proposed, it won't be approved [20:22:14 CEST] <ubitux> yeah but please document that it's not a pkg-config fallback, it's an actual support for different lib [20:22:36 CEST] <AaronL> I don't have push rights--maybe I can get those? :-) [20:23:01 CEST] <ubitux> a bit too early to have such access i'd say, but that's not up to me alone [20:23:24 CEST] <AaronL> I've been working on ffmpeg since roughly end of March--maybe that's not enough time [20:23:52 CEST] <jamrial> AaronL: he means send a new patch with the changes in wording and code as required [20:24:25 CEST] <ubitux> AaronL: it's more about the contributions than time [20:24:37 CEST] <ubitux> but again, not up to me alone, more like a project decision [20:25:10 CEST] <AaronL> ubitux: you want comments in the configure itself? I was pretty clear on the existence of the third-party package without pkg-config support in the commit log message [20:25:15 CEST] <AaronL> in configure itself I mean [20:25:50 CEST] <ubitux> it may be better in the script itself, up to you [20:25:59 CEST] <ubitux> i'm just afraid that it will be forgotten [20:26:12 CEST] <AaronL> right, ok, I'll do that and resubmit, thanks [20:26:20 CEST] <ubitux> and someone will say "hey look we have x264 and mfx who have fallback, why not add it to every other?" [20:26:43 CEST] <ubitux> while the first one is stupid, yours has a very different reason for being there [20:32:42 CEST] <jamrial> ubitux: wait until i push my hevc changes before merging the relevant avframe cropping commit [20:32:57 CEST] <jamrial> that way you wont need to apply it to both parsers [20:33:14 CEST] <jamrial> since there will be only one again :p [20:33:24 CEST] <ubitux> i've not motivated myself to deal with the avframe cropping yet :p [20:33:32 CEST] <jamrial> ah ok. just saying :p [20:33:42 CEST] <jamrial> and for that matter, wm4 didn't want the fields to be size_t i think [20:33:49 CEST] <jamrial> but libav refused to change them [20:34:16 CEST] <jamrial> we could make them unsigned/uint32_t, but wm4 said the difference between projects would be annoying [20:34:43 CEST] <jamrial> i mean, why size_t if they even added a sanitize check to make nothing is ever above INT_MAX anyway? [20:34:48 CEST] <ubitux> ah, the crypto thing? [20:35:02 CEST] <ubitux> didn't know there was opposition [20:35:13 CEST] <ubitux> we should really keep up with the commits asap so we don't forget these [20:35:26 CEST] <ubitux> and discussion about mergine or not gets fresh :p [20:35:41 CEST] <ubitux> we reached 2017, so ~4 months left to do, ~400 commits [20:39:28 CEST] <jamrial> no, i mean the cropping stuff [20:39:48 CEST] <jamrial> the new avframe fields are size_t, wm4 was against that but libav didn't change them [20:40:54 CEST] <jamrial> the crypto stuff is also weird i think, but meh [20:44:32 CEST] <ubitux> oh ok, my bad [20:44:41 CEST] <ubitux> i though it was about the crypto len args [21:01:11 CEST] <ubitux> http://www.ipol.im/pub/art/2017/181/ [21:06:26 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:1002932a3b16: avcodec/cdxl: Fix signed integer overflow: 14243456 * 164 cannot be represented in type 'int' [21:06:27 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:0953736b7e97: avcodec/nellymoser: Fix multiple left shift of negative value -8591 [21:06:28 CEST] <cone-036> ffmpeg 03Michael Niedermayer 07master:f52fbf4f3ed0: avcodec/dfa: Fix off by 1 error [21:10:35 CEST] <AaronL> jamrial: I'll review the HEVCContext patch now [22:07:32 CEST] <AaronL> jamrial: just finished--everything looks good [22:08:02 CEST] <jamrial> AaronL: ok, thank you [22:08:59 CEST] <AaronL> jamrial: I know that there wasn't much to that last review, but have my reviews been useful overall? [22:10:38 CEST] <jamrial> yeah, you poined that one assert and the packet unref were not needed in the concatdec patch, which i hadn't noticed [22:11:31 CEST] <AaronL> plus the loop for calling receive, which you changed, even if not necessary [22:12:52 CEST] <AaronL> if you feel so inclined, since you presumably looked at the patch I submitted to address the memory leaks when FF_API_LAVF_AVCTX is defined [22:13:04 CEST] <AaronL> maybe that's one that can be pushed [22:13:41 CEST] <AaronL> it seems that there have been some conversions to new bitstream API in libav (and merges of that into ffmpeg) [22:13:50 CEST] <AaronL> is concatdec something specific to ffmpeg? just curious [22:34:59 CEST] <Compn> alevinsn : yes, concatdec is only in ffmpeg, it appears. https://git.libav.org/?p=libav.git;a=tree;f=libavformat [22:37:01 CEST] <Compn> looking at the project summary, ffmpeg has over 1 million LOC https://www.openhub.net/p/ffmpeg , while libav is at 650k https://www.openhub.net/p/libav [22:53:38 CEST] <cone-036> ffmpeg 03James Almer 07master:c4b08c8a4e54: avcodec/hevcdec: remove HEVCContext usage from hevc_sei [22:53:39 CEST] <cone-036> ffmpeg 03James Almer 07master:a687fb997097: avcodec/hevcdec: move SEI message parsing into a separate header [22:53:40 CEST] <cone-036> ffmpeg 03James Almer 07master:1d53b8e9073c: avcodec/hevcdec: remove HEVCContext usage from ff_hevc_compute_poc() [22:53:41 CEST] <cone-036> ffmpeg 03James Almer 07master:4aaace8b25a9: avcodec/hevcdec: move SliceHeader struct definition to hevc_ps [22:53:42 CEST] <cone-036> ffmpeg 03James Almer 07master:ceb085906623: avcodec/hevc_parser: use ff_h2645_packet_split() to parse NAL units [22:53:43 CEST] <cone-036> ffmpeg 03James Almer 07master:1c088632e98a: avcodec/hevc_parser: remove HEVCContext usage [22:53:44 CEST] <cone-036> ffmpeg 03James Almer 07master:bf1e3be5a3f6: avcodec/hevc_parser: move slice header parsing to its own function [22:53:45 CEST] <cone-036> ffmpeg 03James Almer 07master:6a72578cc21e: avcodec/hevc_parse: decode SEI message NALUs in extradata [22:53:46 CEST] <cone-036> ffmpeg 03James Almer 07master:470ad23a5560: doc/libav_merge: remove line about ADVANCED_PARSER [22:54:12 CEST] <jamrial> git push is taking an unusually high amount of time to complete for me ever since the server move [22:54:48 CEST] <durandal_1707> define amount [22:55:45 CEST] <jamrial> it can take a minute to push even a single commit [22:56:25 CEST] <nevcairiel> i didnt notice that yet [22:58:28 CEST] <jamrial> right now, pushing a few hundred commits to my github repo (to make it up to date with the main repo after weeks of not touching it) is faster than pushing one commit to source.ffmpeg.org [22:59:51 CEST] <jamrial> ubitux: ADVANCED_PARSER ifdeffery is no more :D [23:06:05 CEST] <ubitux> jamrial: \o/ [23:06:07 CEST] <ubitux> thanks! [23:06:21 CEST] <ubitux> jamrial: yeah git is ultra slow since the server move [23:06:39 CEST] <ubitux> at least for pushing [23:06:48 CEST] <jamrial> guess we'll have to poke thresh about it [23:06:53 CEST] <ubitux> maybe it's spawning a docker for each hook [23:06:59 CEST] <jamrial> yeah, git fetch/pull is fine [23:12:00 CEST] <jamrial> nevcairiel: will you push your movenc hvcc patch? [23:14:41 CEST] <nevcairiel> i guess i should [23:20:50 CEST] <alevinsn> nevcairiel: do you have any opinion on the patch that I submitted to copy the .pdb files? Since you build with MSVC, I would think it would be useful for you. [23:24:07 CEST] <alevinsn> Is Marton Balint here on IRC? Or, if not, what handle does he usually go by? [23:24:36 CEST] <ubitux> mmh, "cus" i think, not sure [23:25:18 CEST] <ubitux> maybe that's just his trac name [23:27:41 CEST] <alevinsn> ubitux: going back to your blog [23:27:43 CEST] <alevinsn> "To make things simple, after trying to find a compromise, Michael and the remaining people in the FFmpeg team later decided to restore ffmpeg.org DNS and the Libav folks were "forced" to fork to have it their way. " [23:27:57 CEST] <alevinsn> what does that mean, that they restored ffmpeg.org DNS [23:28:06 CEST] <ubitux> you don't want to dig that shit [23:28:08 CEST] <jamrial> alevinsn: this is five years old. most of the things mentioned there don't even apply anymore [23:28:12 CEST] <alevinsn> and as a result, that forced the libav folks to have to work [23:28:21 CEST] <alevinsn> I know, I'm just curious what that means [23:28:31 CEST] <alevinsn> to have to fork [23:28:34 CEST] <ubitux> alevinsn: you're going to bring all kind of unwanted discussions... we want to forget this stuff actually [23:28:47 CEST] <alevinsn> I mean, what does it mean to restore ffmpeg.org DNS [23:28:56 CEST] <alevinsn> if you don't want to talk about it, that's fine [23:28:57 CEST] <ubitux> point back on the mplayer server [23:29:09 CEST] <ubitux> where there is the previous source code, iirc [23:31:24 CEST] <kierank> jamrial: please don't fall for luca's bullshit with printing random stuff [23:31:56 CEST] <kierank> sent patch to remove that crap for h264 as well [23:32:29 CEST] <jamrial> kierank: eh, i find the x264/x265 enconding parameters stored in that SEI pretty useful [23:32:41 CEST] <ubitux> ah yeah i got the issue kierank is mentioning [23:32:47 CEST] <ubitux> user data is often binary [23:32:49 CEST] <kierank> random encoders put junk in there [23:32:52 CEST] <kierank> and terminal goes crazy [23:32:57 CEST] <kierank> gets trashed [23:32:58 CEST] <kierank> and bells [23:33:02 CEST] <kierank> and other stuff [23:33:23 CEST] <philipl> printf("%s\n", (char *)random()); [23:33:37 CEST] <jamrial> was going to say, any simple way to check it's safe to print instead? [23:33:48 CEST] <kierank> not without examining the whole string [23:33:56 CEST] <jamrial> the bprint API maybe [23:34:00 CEST] <kierank> this is what libav tried to do but as usual never bothered to finish [23:34:11 CEST] <kierank> do you really want to see arbitrary byte lengths written to terminal [23:34:15 CEST] <ubitux> string_is_ascii in 2 places [23:34:35 CEST] <kierank> I can write 100MB sei values [23:34:35 CEST] <ubitux> jamrial: otherwise you can still hexdump it [23:34:40 CEST] <kierank> do you really want that printed to terminal [23:34:50 CEST] <ubitux> maybe hexdump @ debug level [23:35:03 CEST] <ubitux> (though that shit is in avformat instead of avutil) [23:35:12 CEST] <kierank> I agree it's useful but av_log is not the right way [23:36:24 CEST] <jamrial> do we have stream side data for this? [23:44:23 CEST] <jkqxz> Detecting the x264 parameters guid and printing that seems pretty reasonable. Assigning any other interpretation to it is madness. [23:45:11 CEST] <jkqxz> (Well, unless you know the guid is from X thing. If you don't know the guid, don't ever touch it.) [23:46:27 CEST] <kierank> probably ok as long as av_log string is documented as untrusted [23:47:44 CEST] <jkqxz> Yeah, also check printability if you're going to print it. If it goes in side data then whatever, someone else can validate it for whatever they are doing. [23:48:16 CEST] <jamrial> we don't seem to have side data for this [23:48:24 CEST] <jamrial> and i don't feel like writing one [23:48:25 CEST] <jkqxz> (I'm sure some people would like the incredibly useful "reencode with same x264 parameters" feature, by sending them through side data...) [23:48:32 CEST] <kierank> i can still attack by signalling a million byte length [23:48:41 CEST] <kierank> and then av_log logs a million bytes [23:48:51 CEST] <jamrial> does av_log have a limit? [23:49:23 CEST] <nevcairiel> there is a line length limit i think [23:49:49 CEST] <jkqxz> What side data do you want? What would people even use "x264 params" side data for, or were you thinking of something else? [23:50:09 CEST] <nevcairiel> people like seeing the encode params for some reason [23:50:30 CEST] <nevcairiel> (although personally I would prefer if it stored the actual command line instead of every single option, would be much easier to read) [23:50:51 CEST] <jamrial> jkqxz: we could add a "user data/string" side data or whatever, but i'm not going to do it [23:52:17 CEST] <nevcairiel> if we know its a string, isnt that kinda what metadata is for [23:52:36 CEST] <nevcairiel> although that comes back to the topic of mixing actual tags with technical metadata [23:52:41 CEST] <jamrial> yeah, but exporting it as metadata will be propagated to the output [23:54:18 CEST] <kierank> i would be happy with checking the length is sane and then checking its a string [23:54:35 CEST] <kierank> but i don't want it to be done on arbitrary data [23:58:34 CEST] <jamrial> meh, maybe some other time [23:58:40 CEST] <BBB> nevcairiel: the commandline would be harder to interpret since defaults for options can change between versions [23:58:49 CEST] <nevcairiel> BBB: it also stores the version [23:58:53 CEST] <nevcairiel> heck store all the things [23:59:06 CEST] <BBB> right but then you have to combine two things [23:59:07 CEST] <BBB> that sucks [23:59:18 CEST] <BBB> combining CLI + options string would help [00:00:00 CEST] --- Sat May 6 2017

1 0

ffmpeg.log.20170505
by burek 06 May '17

06 May '17

[00:01:13 CEST] <furq> shrug [00:01:23 CEST] <furq> if nobody disagreed on the mailing list then there's no harm in pressing the issue [00:01:43 CEST] <furq> it looks better than encode_audio.c to me, but i've barely touched the api [00:02:27 CEST] <furq> maybe rename it "encode_mux_audio.c" or something so it's more clear what the difference is [00:02:59 CEST] <faLUCE> furq: iive and others, at this point, I ask you to look/test the code and push a request to reconsider it, if you think it's worthwile [00:03:11 CEST] <furq> i would if i was a developer [00:03:16 CEST] <faLUCE> furq: yes, encode_mux_audio.c would be better [00:03:56 CEST] <iive> faLUCE: i won't do it tonight, I'm way too tired. [00:04:02 CEST] <faLUCE> iive: np [00:04:10 CEST] <iive> i'll try not to forget tomorrow ;) [00:04:14 CEST] <faLUCE> iive: do it when/if you want [00:04:34 CEST] <furq> but yeah i'd be more likely to use the api if the examples were better [00:05:08 CEST] <faLUCE> furq: for the examples, the point of view of the user is more important than that of the developer [00:05:14 CEST] <furq> right [00:05:33 CEST] <faLUCE> I'm more an user of the API, than a developer, so I wrote something that is useful for the user [00:06:13 CEST] <furq> well yeah by all accounts being a developer is not very much fun for this precise reason [00:06:24 CEST] <furq> it's probably the same for any large open-source project [00:06:37 CEST] <furq> especially ones with high concentrations of germans [00:06:46 CEST] <faLUCE> but people were very dogmatic, in that channel... for example, they argued that I would have feed the encoder with dummy audio frames (sin tones) instead of reading a file (which is absurd, in my opinion, for an user of the API) [00:07:08 CEST] <faLUCE> [00:06] <furq> especially ones with high concentrations of germans <----- LOOOL [00:08:21 CEST] <faLUCE> furq: you know? I also prepared an example with libevent and libav (you suggested to use libevent for HTTP, and it worked perfectly) [00:31:39 CEST] <alexpigment> furq: regarding our earlier conversation, I went and did some PSNR/SSIM tests on x264 (medium preset) vs nvenc hevc (slow preset) [00:32:12 CEST] <alexpigment> at the same bitrate, libx264 is better quality (not by a huge amount in my 10mbps, but still) [00:33:08 CEST] <alexpigment> BUT NVENC's HEVC is 6.5x faster than x264 on my system. for context, i have a Core i7 3770 and an Nvidia 1060 [00:34:08 CEST] <alexpigment> more importantly, if you can afford a bitrate that's 1.4x of x264, you end up with the same quality (same PSNR/SSIM, at least) at 6.5x the speed [00:34:21 CEST] <alexpigment> so i think that's a strong argument for nvenc [00:34:37 CEST] <alexpigment> especially if for whatever reason HEVC is a required aspect [00:39:32 CEST] <furq> psnr isn't a hugely useful metric with x264 because of psy and stuff [00:40:36 CEST] <furq> but yeah if you need an hevc bitstream for whatever reason then i'd definitely consider it [03:11:21 CEST] <thebombzen_> apparently, using "ffmpeg -h encoder=h264_vaapi" says that the only supported pixel format is vaapi_vld [03:11:38 CEST] <thebombzen_> which is causing me issues because the autoscaler can't do that. explicitly setting -pix_fmt vaapi_vld doesn't help either [03:12:31 CEST] <thebombzen_> how am I actually supposed to use the h264_vaapi encoder [06:03:10 CEST] <thebombzen_> are there any extra things required to get vaapi working on linux? [06:04:32 CEST] <thebombzen_> if I try to run ffmpeg -f lavfi -i testsrc2 -c h264_vaapi -f null -, then it'll complain that the autoscaler can't scale to null [06:04:59 CEST] <thebombzen_> upon running ffmpeg -h encoder=h264_vaapi, it says that it only accepts vaapi_vld as a pixel format [06:06:07 CEST] <thebombzen_> if I try to force -pix_fmt yuv420p, it'll say this: Incompatible pixel format 'yuv420p' for codec 'h264_vaapi', auto-selecting format '(null)' [06:06:18 CEST] <thebombzen_> am I missing something here? [06:08:25 CEST] <furq> don't you need -vf format=nv12,hwupload [06:08:43 CEST] <thebombzen_> hwupload? [06:10:21 CEST] <thebombzen_> hm. tried that, didn't work [06:10:22 CEST] <thebombzen_> http://sprunge.us/SJFE [06:10:51 CEST] <furq> -vaapi_device [06:11:00 CEST] <thebombzen_> is there way to list devices [06:11:08 CEST] <furq> iirc it's always /dev/dri/renderD128 [06:11:12 CEST] <furq> at least for intel [06:11:51 CEST] <furq> you don't need the filters if you're hardware decoding [06:13:52 CEST] <thebombzen_> hardware encoding [06:13:57 CEST] <thebombzen_> and now it's an unknown libva error [06:14:02 CEST] <thebombzen_> http://sprunge.us/ZEUh [06:14:13 CEST] <furq> well yeah you'd normally be hardware decoding as well [06:14:21 CEST] <furq> obviously not if you're using lavfi for testing [06:15:14 CEST] <thebombzen_> do you know how to fix the "unknown libva error" [06:15:19 CEST] <furq> i do not [06:15:29 CEST] <thebombzen_> hm. I did install libva-intel-driver since last reboot [06:15:35 CEST] <thebombzen_> I might have to reboot to refresh some module [06:18:31 CEST] <thebombzen> it did not fix it [07:13:48 CEST] <james999> alexpigment: what's that about, benchmarking hevc vs x264? [11:49:52 CEST] <cryptopsy> how can i get total play time for mplayer? like 8300/15000 , where 15000 is the total play time but 8300 is the current position [11:52:32 CEST] <faLUCE> hello, iive, if you want to bump the thread we talked about yesterday, this is the correct link: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209494.html . Thanks [12:07:36 CEST] <thebombzen> well [12:07:57 CEST] <thebombzen> cryptopsy: perhaps you should ask the mplayer people, not the ffmpeg people [12:08:03 CEST] <thebombzen> or even better, use mpv [14:02:32 CEST] <thunfisch> Hey. I've got a problem with concat, using this ffconcat file & command: https://paste.xinu.at/m-LUyZb/ total duration should be 48:37, but somehow ffmpeg generates a file that's only 43:27 long with half of the last file duration missing. sadly cannot share the files because of copyright issues. any idea what I'm missing? [14:03:27 CEST] <thunfisch> oh, -preset is slow [14:05:51 CEST] <thunfisch> in the process of doing a run with higher loglevel, gonna paste the output in a minute.. [14:09:08 CEST] <thunfisch> https://paste.xinu.at/m-iAE/ [15:21:51 CEST] <thunfisch> what the hell. okay, i added 'file 0.png\nduration 0.001' to the end, now it's giving me 79183 frames, which is 00:52:47.28. something's really broken there. [15:21:51 CEST] <thunfisch> but the previously last slide (14.png) now has the proper end time of 46:37, just the new last slide is way too long. [16:20:34 CEST] <thunfisch> okay, another topic: is it possible to output (to a file preferably) the raw rtsp headers when recording from a rtsp server? I'm specifically interested in the Range and RTP-Info headers. [16:20:43 CEST] <thunfisch> can't find anything in the documentation that would allow that.. [16:50:53 CEST] <Croolman> Hi everyone. Does anyone know, what does the av_frame_copy() do when dst frame is bigger than source? Can I expect dest frame to be an input with black padding on right and bottom side? I have gone through the function, but cant figure out myslelf with confidence.. [16:52:46 CEST] <BtbN> "This function does not allocate anything, dst must be already initialized and allocated with the same parameters as src." [16:52:47 CEST] <thebombzen> Croolman: you probably have to scale it yourself [16:52:53 CEST] <TheWild> hello [16:53:03 CEST] <BtbN> If the frame does not match 100%, you'll most likely crash [16:53:06 CEST] <thebombzen> I don't how it'll fail, but it won't work as expected [16:53:33 CEST] <thebombzen> Croolman: you can use libswscale to scale it, or you could manually pad it with the pad filter in libavfilter [16:53:48 CEST] <TheWild> I have a video file, but it is damaged in a way that it can be still watched from the beginning, but not seeked. Can ffmpeg be used to fix it without doing any conversion? [16:54:04 CEST] <thebombzen> TheWild: what format is it in? [16:54:05 CEST] <furq> maybe [16:54:13 CEST] <furq> ffmpeg -i foo.mp4 -map 0 -c copy bar.mp4 [16:54:24 CEST] <furq> replace mp4 with the extension you want [16:54:40 CEST] <furq> if that doesn't work then you're probably out of luck [16:54:52 CEST] <thebombzen> because furq's command should work [16:55:04 CEST] <thebombzen> but keep in mind that if the input format is something like mpeg-ts (.ts) then it's nto damaged [16:55:13 CEST] <thebombzen> certain containers like .ts just don't support random access seeking [16:55:19 CEST] <furq> what [16:55:35 CEST] <thebombzen> yea, mpegts doesn't support seeking [16:55:38 CEST] <furq> i don't think you're thinking of mpegts [16:55:45 CEST] <thebombzen> hm? [16:56:11 CEST] <thebombzen> mpeg-ts doesn't support random access seeking by design [16:56:13 CEST] <dystopia_> .ts can also be h264 or hevc [16:56:17 CEST] <Croolman> BtbN: I did read the documentation, but do not understand the fraze "same parameters". The function inside checks just if the dest size is smaller than dest, nothing else. I do pass already allocated frame. [16:56:17 CEST] <dystopia_> it's just a container [16:56:22 CEST] <TheWild> here are details: https://kopy.io/AHZGO. Original file extension was lost. [16:56:24 CEST] <dystopia_> and you can seek it fine [16:57:06 CEST] <thebombzen> no, seeking with mpegts doesn't work well [16:57:15 CEST] <thebombzen> you can try but it won't be accurate [16:57:18 CEST] <dystopia_> unless your on about the actual transport stream capture, then you would have to demux the audio and video streams [16:57:21 CEST] <furq> it does work though [16:57:22 CEST] <BtbN> Croolman, well, it means exactly that. It has to have the same propperties, otherwise the results are undefined [16:57:27 CEST] <BtbN> same size, pix fmt, everything [16:57:40 CEST] <thebombzen> you can't reliably seek mpegts, it doesn't work I'm saying [16:57:54 CEST] <thebombzen> you can try but there's no guarantee you'll be able to do anything [16:58:03 CEST] <thebombzen> and there's no guarantee it'll be accurate [16:58:45 CEST] <furq> every player i've ever used can seek ts just fine, even if it's not designed for it [16:58:50 CEST] <thebombzen> mpv doesn't [16:58:53 CEST] <furq> it's not like m2v or something where you actually can't seek [16:58:57 CEST] <Croolman> BtbN: alright, I have the alocated frame for the destination, would not be then just easier to memcpy the memory from one to another line by line? [16:59:13 CEST] <thebombzen> I frequently will try to seek mpegts files in mpv and it doesn't work well [16:59:18 CEST] <thebombzen> whereas if I remux to mp4 it works fine [16:59:23 CEST] <dystopia_> seek fine in media player classic [16:59:26 CEST] <BtbN> that's exactly what the function does, but the parameters have to match for either of those methods [16:59:26 CEST] <furq> i just tried it and it works [16:59:34 CEST] <Croolman> thebombzen: cannot scale it, I need the image inside to be the same, just with black paddings on right and bottom side [16:59:38 CEST] <dystopia_> i often watch the .ts while i wait for ffmpeg to finnish the encode [16:59:38 CEST] <furq> "works well" is subjective, but it does work [16:59:42 CEST] <dystopia_> i can seek fine [16:59:48 CEST] <thebombzen> furq: it doesn't work perfectly [16:59:56 CEST] <furq> probably [16:59:58 CEST] <BtbN> Croolman, the content of a bigger frame will probably be random garbage, and not black [17:00:08 CEST] <BtbN> if it doesn't just plain crash [17:00:10 CEST] <furq> but there are formats that can't be seeked at all [17:00:18 CEST] <furq> it's a pretty big distinction [17:00:33 CEST] <thebombzen> I mean that with mkv and mp4 and nut and etc. you can seek to an exact timecode [17:00:42 CEST] <thebombzen> if you try that with mpegts there's no guarantee it'll work [17:01:03 CEST] <thebombzen> it sometimes can but it's generally not accurate or reliable [17:01:17 CEST] <thebombzen> Croolman: try using the pad filter from libavfilter [17:01:21 CEST] <thebombzen> that does what you need [17:01:56 CEST] <TheWild> I dropped the -map 0 parameter and ffmpeg did the job well. Thank you very much. [17:02:08 CEST] <dystopia_> it should seek to nearest i-frame which should be present throughout the file iirc [17:02:21 CEST] <Croolman> thebombzen: I am wirting a filter to be a part of ffmpeg, cannot really use static functions from inside the library... If I understand it correctly [17:02:35 CEST] <thebombzen> Croolman: what? [17:02:53 CEST] <furq> TheWild: you'll need -map 0 or else it'll drop the extra audio streams [17:03:00 CEST] <Croolman> BtbN, I guess yo ure right, then I am out of options [17:03:07 CEST] <furq> at least use -map 0:v -map 0:a [17:03:11 CEST] <thebombzen> Croolman: what are you actually trying to do? [17:03:16 CEST] <furq> otherwise you'll need to use a container that supports those subtitle streams [17:03:18 CEST] <furq> i.e. mkv [17:03:20 CEST] <BtbN> use an appropiate filter for your job [17:03:49 CEST] <Croolman> thebombzen, I am aware of the pad filter, but I am not using the API of ffmpeg [17:03:58 CEST] <thebombzen> Croolman: yes you are? [17:04:12 CEST] <thebombzen> you are using av_frame_copy [17:04:17 CEST] <thebombzen> how are you not using ffmpeg's API? [17:04:30 CEST] <Croolman> thebombzen, alright, part of it yes [17:04:49 CEST] <thebombzen> you should also link to libavfilter, and use the pad filter [17:05:29 CEST] <thebombzen> it's what you need, and every ffmpeg installation will come with it in addition to libavformat and libavcodec [17:05:53 CEST] <thebombzen> if you're trying to be minimalist, then you can build a verison of libavfilter with nothing but the pad filter (and a few necessary others like buffer) [17:05:53 CEST] <TheWild> the other streams are probably damaged, because when I add -map 0, it doesn't work even with -copy_unknown/-ignore_unknown. [17:06:07 CEST] <thebombzen> TheWild: try muxing to .mkv instead of .mp4 [17:06:09 CEST] <thebombzen> and see what happens [17:07:25 CEST] <furq> TheWild: the source has got streams which probably aren't supported by the output container [17:07:34 CEST] <furq> so yeah, use mkv [17:07:41 CEST] <TheWild> nope, same problems. ffmpeg complains very quickly and ends. [17:07:46 CEST] <furq> what's the error message [17:08:05 CEST] <Croolman> thebombzen: ok, lets say I would use the padding filter, what of its function would I call forom the filter? [17:08:45 CEST] <Croolman> dunno if we are on the same page [17:09:12 CEST] <thebombzen> well you should read the libavfilter documentation [17:09:14 CEST] <thebombzen> and the examples [17:09:35 CEST] <thebombzen> you're trying to increase the size of the video by padding with black. ffmpeg's API has that functionality, namely in the pad filter of libavfilter [17:09:49 CEST] <thebombzen> so you should read the libavfilter documentation and basic examples [17:09:55 CEST] <thebombzen> and then work from there [17:10:02 CEST] <TheWild> https://kopy.io/jK0ed [17:10:10 CEST] <TheWild> ^ furq [17:11:41 CEST] <thebombzen> fyi you're using an old version of ffmpeg [17:12:02 CEST] <thebombzen> more than a year old [17:12:08 CEST] <thebombzen> it's possible this is a bug that's been fixed [17:12:26 CEST] <thebombzen> try grabbing a recent build and try again [17:12:42 CEST] <furq> er [17:12:45 CEST] <furq> yeah that's all fucked [17:12:51 CEST] <furq> you shouldn't be getting decoder errors with -c copy [17:13:01 CEST] <furq> it shouldn't be decoding anything [17:13:20 CEST] <dystopia_> try just map 0:0 and 0:1 [17:13:30 CEST] <furq> 16:03:07 ( furq) at least use -map 0:v -map 0:a [17:14:03 CEST] <furq> 0:0 and 0:1 would be the automatic selections anyway, and it'd drop the other audio stream [17:14:07 CEST] <Croolman> thebombzen, thank you. I was under the imperssion that filtes from inside the libavfilter should not use other filters' functionality from within the libav*. I ll look into it then [17:14:21 CEST] <thebombzen> are you trying to write a filter for libavfilter? [17:15:02 CEST] <thebombzen> what filter are you writing? why do you need to pad the video manually? [17:15:21 CEST] <Croolman> thebombzen, yes [17:15:35 CEST] <Croolman> I am trying to write the wavelet denoise filter [17:16:15 CEST] <thebombzen> why do you need to pad for that [17:16:20 CEST] <thebombzen> also there are two wavelet denoisers already [17:16:28 CEST] <Croolman> I need every frame to be of 2^n width and height, so internally I need to create a copy of input frame, process it an put the ROI on output [17:17:50 CEST] <Croolman> do you mean the - vf_waveform.c? [17:18:01 CEST] <furq> !filter owdenoise [17:18:01 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#owdenoise [17:18:08 CEST] <furq> !filter vaguedenoiser [17:18:09 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#vaguedenoiser [17:19:06 CEST] <Croolman> Ahh, ok. [17:19:36 CEST] <Croolman> It is a school project and I am using different wavelet, also the threshold is computed internally [17:22:49 CEST] <thebombzen> if it's a school project then it might be best not to frame it as a patch to libavfilter [17:22:52 CEST] <thebombzen> but rather its own thing [17:23:10 CEST] <thebombzen> also 2^n x 2^n is really nice in theory but in the real world you have annoying prime factors like 3 and 5 [17:23:27 CEST] <thebombzen> you should figure out a way to deal with those [17:23:50 CEST] <thebombzen> how do you actually do that? Idk, I'm a mathematician, not a software developer. [17:23:52 CEST] <furq> i don't think he said anything about patching [17:24:07 CEST] <thebombzen> [11:14:07] <Croolman> thebombzen, thank you. I was under the imperssion that filtes from inside the libavfilter should not use other filters' functionality from within the libav*. I ll look into it then [17:24:15 CEST] <thebombzen> definitely did [17:24:22 CEST] <Croolman> it is not a patch. Idid not know there are two already, initially was planning to put it into ffmpeg if it wen well. [17:24:33 CEST] <thebombzen> putting it in ffmpeg is a patch [17:24:41 CEST] <furq> "i'm writing a filter" doesn't imply contribution [17:25:04 CEST] <thebombzen> it does when he says that he's trying to avoid referencing libavfilter filters from another filter he's writing within libavfilter [17:25:06 CEST] <furq> and it's not a patch unless he contributes it [17:25:17 CEST] <furq> unless he has some really messed up way of writing code [17:25:52 CEST] <thebombzen> Croolman: either way, given that this functionality already exists, if you're writing it as a school project, I think it's better to write libcroolmanwavelet and link to libavfilter [17:25:53 CEST] <Croolman> It is a code written from ground zero [17:25:55 CEST] <thebombzen> rather than try to integrate it [17:26:22 CEST] <thebombzen> because the point of the project is to use wavelets, right, not to learn how to play with pads [17:26:31 CEST] <Croolman> The integration itself is mandatory [17:26:38 CEST] <thebombzen> ...oh. okay. [17:27:07 CEST] <Croolman> This is the only issue I am facing. The 2^n closest width/height is easz to compute [17:27:07 CEST] <thebombzen> why does your professor want you to put it inside libavfilter? that's an odd assignment [17:27:33 CEST] <thebombzen> yea. 2^n by 2^n is super nice but in the real world you won't get that. I have no idea how to fix that, because I'm a mathematician, not a software developer [17:27:42 CEST] <Croolman> The way he put it seems like he does not know there are some already either [17:27:43 CEST] <thebombzen> I just look at 2^n by 2^n and go "it's done!" [17:27:58 CEST] <thebombzen> there's about eight different denoise filters in libavfilter [17:28:25 CEST] <Croolman> I do know that [17:28:47 CEST] <hamdjan> hi, with the android app soundhound you can find out the title of a playing song. i wonder if it is also possible to say what movie a trailer belongs to. basically i got the movie title and just want to make sure the trailer is really belongs to that movie. would it suffice if you grab several unique colors from different frames of the trailer and compare them with e.g. 50 pictures of the google image result? https://www.google.de/search?q=jack+rea [17:28:47 CEST] <hamdjan> cher&source=lnms&tbm=isch [17:29:38 CEST] <Croolman> thebombzen: The issue here is really how to copy data from smaller frame to bigger frame, thats it. [17:29:47 CEST] <furq> Croolman: you might want to look at how -vf pad does it [17:29:47 CEST] <kepstin> hamdjan: that's a little out of scope for ffmpeg user support. If you figure out how to do that, do let us know about the paper you publish for your PHD ;) [17:29:52 CEST] <furq> https://ffmpeg.org/doxygen/trunk/vf__pad_8c_source.html [17:31:24 CEST] <thebombzen> hamdjan: that sounds like a hard problem [17:31:35 CEST] <Croolman> furq: I did, but it is a lil too complicated to decompose. Also I just dont wanna to copy paste code from another filter. [17:31:50 CEST] <kepstin> hamdjan: basically, "it's not that simple". Existing online screenshot identification tools, like https://whatanime.ga/ for example, rely on massive databases of video data. [17:32:07 CEST] <thebombzen> hamdjan: things like soundhound or shazam compare a clip to a large database. if you're trying to parse the title of a video and a few screenshots you're in for a lot of work [17:32:12 CEST] <hamdjan> kepstin, hehe, i think its possible, but not that easy. trailers are mostly transcodes and multiple different filters are added, so the original colors change, same for the screenshot pictures of google image result list. so i would have to apply multiple filters on both the screenshot and the trailer frames and see how similar they are and if there are reoccuring colors/forms [17:32:43 CEST] <thebombzen> it won't appear in google images necessarily with "search by image" unless that shot or similar shot appears prominently [17:32:48 CEST] <thebombzen> otherwise it'll just find visually similar images [17:33:15 CEST] <hamdjan> yes, it would only see if the visual forms of the e.g. the main actor reappears, or the color of his jacket [17:33:29 CEST] <thebombzen> this doesn't have an easy solution. the problem you're trying to solve is hard [17:33:53 CEST] <thebombzen> you can't just bust in and say "I'm going to solve it with algorithms!" and expect it to work easily [17:34:00 CEST] <hamdjan> right, thanks for clarifying that, won't go for it then. thought i could make a quick solution to this [17:34:18 CEST] <thebombzen> It might be easier to parse the title of the youtube video [17:34:25 CEST] <thebombzen> than to parse the video itself [17:34:31 CEST] <thebombzen> usually the name of the movie is in the title [17:34:46 CEST] <hamdjan> i do that already, but sometimes there are often movies with the same or similar name or trailers with typos in the movie title etc [17:35:27 CEST] <kepstin> keep in mind that google itself probably already knows what movie a trailer is from, because of their giant analysis system to detect copyright owners for videos [17:36:15 CEST] <hamdjan> hm, i took a quick look into google's youtube api, but they don't reveal the trailer movie unfortunately to the public [18:36:02 CEST] <james999> rnndom question, but what % of URLs that people type in these channels are preceded by http:? [18:36:20 CEST] <james999> i.e. how often do people just say "go to ffmpeg.org/doc/examples"? [18:54:33 CEST] <agrathwohl> I am wondering how 2-pass mode works for h264_nvenc and hevc_nvenc. The 'slow' preset is reported to enable '2-pass mode' but does one also need to specify the '-pass 1' and '-pass 2' flag in order to explicitly perform a 2-pass encode? [19:06:43 CEST] <jkqxz> It's internal two-pass, not external. (The hardware encoder is probably run on each frame twice, the first encode being used the inform the parameters to the second. That is all inside the opaque proprietary drivers, though, so you've no idea what it actually does.) [19:07:51 CEST] <DHE> as I understand it this is correct. per-block decisions are made better in 2-pass mode but is otherwise still frame-by-frame [19:08:02 CEST] <kepstin> agrathwohl: jkqxz I've looked this up earlier. The nvenc encoder normally operates a single macroblock at a time - when in the misnamed "2-pass mode", it analyzes an entire frame before encoding that frame [19:08:07 CEST] <DHE> nvenc was mainly targeted at real-time jobs like video conferencing [19:08:45 CEST] <agrathwohl> Thanks this is very useful information for us. [19:08:52 CEST] <furq> that really is misnamed [19:09:04 CEST] <agrathwohl> How come nVidia can't get their terminologies together? Not the first time in recent memory that they've done something like that. [19:09:13 CEST] <agrathwohl> Appreciate all the insights, cheers! [19:09:22 CEST] <DHE> from their perspective it's 2-pass. just on a frame-level rather than a whole video level [19:09:30 CEST] <furq> https://www.youtube.com/watch?v=WTIe867A0CQ [19:09:36 CEST] <furq> this is probably why [19:09:43 CEST] <alexpigment> fwiw, sometimes developers are just out of touch with reality, and yet they name things ;) [19:09:44 CEST] <agrathwohl> So would a more preferrable approach be to decode with the GPU and encode with x264/x265? [19:10:10 CEST] <furq> depends what you're doing [19:10:10 CEST] <agrathwohl> If the target is high-resolution VOD 360 video? :D [19:10:14 CEST] <furq> for archival, certainly [19:10:23 CEST] <DHE> x264 easily produces more consistent and better quality than nvenc, at the obvious cost of performance. again, nvenc is best for real-time work like video conferencing, live game streaming, etc [19:10:26 CEST] <furq> nvenc is good for realtime but not really great for anything else [19:10:48 CEST] <alexpigment> nvenc is good for realtime + not using up CPU [19:11:00 CEST] <furq> well that's normally a constraint for realtime stuff [19:11:13 CEST] <kepstin> if you need to do realtime capture then re-encode for vod, it might make sense to capture with really high bitrate nvenc, then re-encode with x264/x265 to get it smaller. [19:11:17 CEST] <agrathwohl> i've noticed quite a decrease in quality, indeed. Even with objective tests like PSNR x264 performs much better with not a significant decrease in performance;. [19:11:18 CEST] <alexpigment> true, i don't know why i clarified there ;) [19:12:07 CEST] <agrathwohl> I've been considering just pre-processing all our source masters to yuv444p10le so that CUDA cards can decode it, then use CPU to squeeze out all the quality possible. [19:12:30 CEST] <agrathwohl> Seems like this approach is being validated. Thanks so much to all for your help [19:12:31 CEST] <alexpigment> agrathwohl: i actually did a few tests yesterday. the extra bitrate needed to achieve the same PSNR is not horrible. it's like 1.4x in my quick tests [19:12:44 CEST] <agrathwohl> alexpigment what kind of resolutions and frame rates were you dealing with? [19:12:50 CEST] <furq> you should probably clarify that that was nvenc_hevc vs x264 [19:13:13 CEST] <furq> granted i doubt nvenc_hevc is much better than nvenc_h264 [19:13:14 CEST] <agrathwohl> furq actually it was both hevc_nvenc/x265 and h264_nvenc/x264 [19:13:20 CEST] <furq> oh ok [19:13:35 CEST] <furq> s/much better/different/ then [19:14:17 CEST] <alexpigment> true again. it's probably more like 1.5x the bitrate needed to achieve the same PSNR [19:14:39 CEST] <furq> i figured they weren't much different but i didn't know it was that close [19:15:22 CEST] <alexpigment> i'd have to do a few more tests to prove that off-the-cuff statement [19:15:55 CEST] <alexpigment> but it's safe to assume that the quality of x264 is still better than hevc_nvenc but not by a huge amount [19:16:12 CEST] <alexpigment> and that h264_nvenc trails behind the hevc quality by some amount [19:16:15 CEST] <furq> 40% is pretty significant for modern video [19:16:28 CEST] <alexpigment> signficant for certain applications [19:16:32 CEST] <furq> sure [19:17:01 CEST] <kepstin> i wouldn't have been surprised if x264 can beat h265_nvenc, at least in the slower encoding modes [19:17:33 CEST] <alexpigment> sometimes I just need a quick intermediate file, in which case file size is not a big deal at all [19:17:41 CEST] <furq> nvenc still doesn't support bframes in hevc does it [19:17:54 CEST] <alexpigment> i don't think so but i can check real quick [19:18:09 CEST] <furq> wikipedia says pascal doesn't [19:18:37 CEST] <alexpigment> yeah, no b-frames in this video [19:19:59 CEST] <furq> out of interest, how does lossless nvenc compare to lossless h264/ffv1 etc [19:20:06 CEST] <furq> lossless x264, rather [19:20:09 CEST] <alexpigment> you mean in terms of file size? [19:20:14 CEST] <furq> yeah [19:20:18 CEST] <alexpigment> lemme test [19:20:34 CEST] <furq> can you compare against -preset ultrafast and -preset veryslow [19:21:55 CEST] <alexpigment> yeah [19:22:01 CEST] <alexpigment> crf 1 or crf 0? [19:22:12 CEST] <alexpigment> crf 0 does high 444 i think [19:22:45 CEST] <furq> -qp 0 [19:22:49 CEST] <alexpigment> k [19:23:03 CEST] <furq> crf/qp don't affect the pixel format [19:23:42 CEST] <alexpigment> in my experience crf 0 does [19:23:45 CEST] <alexpigment> i'd have to test again [19:23:59 CEST] <alexpigment> but i was pretty sure it forces it to high 444 predictive profile [19:24:09 CEST] <alexpigment> but then it's probably still doing 4:2:0 [19:24:17 CEST] <alexpigment> (i'm just mumbling at this point, ignore me) [19:24:18 CEST] <kepstin> it forces that profile, yes, because that profile is needed for the lossless predictive mode [19:24:46 CEST] <hamdjan> what is the video codec of this video? http://sprunge.us/AhCi [19:24:51 CEST] <kepstin> note that "-crf 0" is only lossless in 8-bit x264, it is not lossless in 10-bit; that's why furq said to use '-qp 0' instead [19:24:59 CEST] <hamdjan> mp42 or avc1? [19:25:24 CEST] <hamdjan> i think avc1 and mp42 is only the container? [19:25:46 CEST] <alexpigment> furq: for my 1.5 minute test video, the losslesshp NVENC profile was 2.34GB [19:26:14 CEST] <alexpigment> libx264 with the ultrafast preset was 2.5GB [19:26:30 CEST] <alexpigment> still waiting on veryslow - will probably be another 5 minutes [19:26:34 CEST] <furq> that's not bad [19:27:05 CEST] <furq> hamdjan: it's h.264 [19:27:14 CEST] <hamdjan> furq, thanks for assuring! [19:27:21 CEST] <furq> Format/Info : Advanced Video Codec [19:27:23 CEST] <hamdjan> furq, so avc1 is a synonym for h264 [19:27:30 CEST] <furq> avc is [19:27:56 CEST] <furq> actually i guess avc1 is as well [19:28:19 CEST] <alexpigment> is avc1 just the fourcc name for avc? [19:28:33 CEST] <alexpigment> (i.e. they needed four characters and just added a '1') [19:28:34 CEST] <alexpigment> ? [19:29:16 CEST] <furq> https://www.fourcc.org/avc1/ [19:29:26 CEST] <furq> h264 is the usual fourcc [19:30:45 CEST] <alexpigment> interesting. not sure why it shows up in MediaInfo over h264 [19:31:05 CEST] <furq> that just reads whatever's in the container [19:31:19 CEST] <alexpigment> then again, fourcc doesn't list H264 [19:31:28 CEST] <alexpigment> the website i mean [19:31:39 CEST] <alexpigment> nm [19:31:40 CEST] <furq> https://www.fourcc.org/h260-through-h269/ [19:31:46 CEST] <alexpigment> it's not searchable because of the way they wrote it [19:31:49 CEST] <furq> yeah [19:32:17 CEST] <alexpigment> maybe it only gets used if cabac is off or something [19:32:25 CEST] <alexpigment> baseline profile, etc [19:32:49 CEST] <furq> according to ms avc1 is "h.264 bitstream without start codes" [19:32:58 CEST] <furq> i'm not sure how reliable that is though [19:34:46 CEST] <alexpigment> i'm not even sure i know what that means - would movflags faststart add those start codes? [19:35:20 CEST] <furq> start codes == annex b [19:35:32 CEST] <furq> faststart is specific to mp4 [19:36:19 CEST] <alexpigment> i see. well i'll just accept that this particular designation is ourside of my area of knowledge ;) [19:36:25 CEST] <alexpigment> *outside [19:36:37 CEST] <furq> i'm sure i've seen mp4s with h264 fourccs, which shouldn't be possible according to ms [19:36:43 CEST] <furq> i wouldn't put money on that though [19:36:56 CEST] <furq> but then i don't think fourccs are really relevant any more [19:37:29 CEST] <alexpigment> yeah, the last time i even paid attention to fourcc names was when I was trying to force an AVI to be either Divx or Xvid [19:37:40 CEST] <furq> yeah i don't think it matters for anything but avi [19:37:48 CEST] <furq> and it's 2017, so there's no good reason to use avi [19:38:05 CEST] <alexpigment> it has its place [19:38:13 CEST] <alexpigment> but i don't usually use it [19:38:14 CEST] <furq> is the place "the past" [19:38:17 CEST] <furq> or is it "the bin" [19:38:47 CEST] <alexpigment> what's that program that everyone uses with avisynth? [19:38:54 CEST] <alexpigment> not avidemux, but the other one [19:39:09 CEST] <alexpigment> it's a very barebones NLE [19:40:24 CEST] <alexpigment> VirtualDub [19:40:28 CEST] <alexpigment> it took me a minute [19:40:45 CEST] <dystopia_> :O [19:40:45 CEST] <alexpigment> anyway, if you use VirtualDub still in 2017, I suppose you would need to work with AVI a lot :) [19:40:52 CEST] <dystopia_> virtualdub is was out of date too [19:41:05 CEST] <dystopia_> doesn't support many modern codecs and stuff [19:41:08 CEST] <alexpigment> exactly [19:41:17 CEST] <alexpigment> which is part of why people use AviSynth with it [19:41:25 CEST] <dystopia_> i use to love it back in the day though [19:41:30 CEST] <furq> it supports any codecs that ffdshow supports, which is most of them [19:41:38 CEST] <furq> but yeah the container support is terrible [19:41:44 CEST] <alexpigment> furq: i figured it was only VFW codecs [19:42:08 CEST] <furq> ffdshow is vfw [19:42:09 CEST] <alexpigment> but then again i haven't used ffdshow in many years. it wrecked my system codecs so much [19:42:28 CEST] <furq> you can use avisynth directly with ffmpeg anyway [19:42:37 CEST] <furq> although i don't see why you would when vapoursynth exists now [19:43:08 CEST] <furq> and you don't have to rely on awful crash-prone-after-8-hours-of-encoding hacks to get multithreading [19:43:11 CEST] <alexpigment> anyway, this is a long convoluted way to say that some people still use VirtualDub [19:43:16 CEST] <furq> they sure do [19:43:31 CEST] <furq> lord have mercy on their souls [19:43:38 CEST] <alexpigment> haha [19:44:23 CEST] <alexpigment> it's a least a more legit program compared to AviDemux. that program only seems to work for a small handful of workflows [19:47:17 CEST] <alexpigment> ok furq, here are the final numbers on that test from earlier [19:47:38 CEST] <alexpigment> NVENC, preset losslesshp: 2.34GB [19:47:47 CEST] <alexpigment> libx264, preset ultrafast: 2.50GB [19:48:02 CEST] <alexpigment> libx264, preset veryslow: 1.62GB [19:48:25 CEST] <alexpigment> but damn if veryslow didn't take over 10 minutes :) [19:53:12 CEST] <furq> that's not bad at all [19:56:21 CEST] <hamdjan> how can i check if my ffmpeg installation can convert h264? [19:56:41 CEST] <hamdjan> ffmpeg codecs shows this: http://sprunge.us/RGhd [19:57:05 CEST] <hamdjan> so listing "DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_crystalhd h264_vdpau ) (encoders: libx264 libx264rgb )" it should also be able to convert h264? [19:57:05 CEST] <c_14> > DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_crystalhd h264_vdpau ) (encoders: libx264 libx264rgb ) [19:57:14 CEST] <c_14> it can decode and encode h264, yes [20:02:17 CEST] <faLUCE> hello, is there any code for a simple audio-video player with libav? [20:02:50 CEST] <faLUCE> something like this (which doesn't work) http://dranger.com/ffmpeg/tutorial05.html [20:03:27 CEST] <faLUCE> I tried that too: https://github.com/wang-bin/QtAV but it seems in a bad state [20:10:48 CEST] <hamdjan> c_14, thanks for assuring! [21:30:47 CEST] <bwe> Hi, how do I add `scale=-1:1080` to -filter_complex correctly? `ffmpeg -i Slide01.png -vf scale=-1:1080 output.png` works, however my more complex don't: https://bpaste.net/show/0569ae5dea03 [21:59:48 CEST] <teratorn> bwe: how does it fail? [22:03:23 CEST] <bwe> Negative values are not acceptable. Failed to configure input pad on Parsed_pad_4 Log: https://bpaste.net/show/1e9cd4c80cd6 [22:05:05 CEST] <bwe> Ah, I need to consider a different order... [22:06:00 CEST] <bwe> `scale` must precede `pad`. Why so? [22:09:23 CEST] <teratorn> bwe: I dunno, sorry [22:10:27 CEST] <teratorn> bwe: oh [22:10:34 CEST] <bwe> teratorn: working log here: https://bpaste.net/show/b3c9df1949b8 [22:11:21 CEST] <teratorn> bwe: does specifying scale=w=-1:h=1080 work? [22:12:41 CEST] <bwe> teratorn: Do you mean adopting the working version (the last paste) to scale=w=-1:h=1080? [22:13:01 CEST] <teratorn> no the version that gave the error about negative values [22:15:09 CEST] <bwe> teratorn: ... -filter_complex '[0:v]setsar=sar=1/1,fps=30,loop=loop=-1:start=0:size=1,trim=duration=5.7,pad=width=1920:height=1080:x=(out_w-in_w)/2:y=(out_h-in_h)/2:color=white,scale=w=-1:h=1080[0]; does not work [22:16:12 CEST] <teratorn> hmmmm [22:16:24 CEST] <teratorn> so it has nothing to do with the value -1 [22:16:42 CEST] <teratorn> perhaps it does not know what the requested pix format is since it is the last filter in the chain [22:16:49 CEST] <bwe> teratorn: No, as this is even recommended: https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg [22:17:03 CEST] <relaxed> bwe: your input image is 1920x1440, but you're trying to pad it to pad=width=1920:height=1080 ? [22:17:19 CEST] <relaxed> how's that going to work? [22:17:20 CEST] <bwe> teratorn: the pad fails because it receives 1440 px yet it expects 1080. [22:17:24 CEST] <bwe> relaxed: It can't. [22:17:54 CEST] <relaxed> scale, then pad [22:17:55 CEST] <bwe> relaxed: So scale ensures that pad is fed with 1080 height. [22:18:22 CEST] <bwe> relaxed: Thanks for that clarification. The problem was not syntax, as I expected. [22:18:51 CEST] <relaxed> you're welcome [22:23:05 CEST] <bwe> relaxed: Where would I have learned that from the docs? Yes, its complex and to believe to get something to work as a newbie in a few hours seems to be rather naïve. [22:25:06 CEST] <relaxed> "Negative values are not acceptable" was a pretty good hint, but it just takes experience to look at ffmpeg's output [22:25:45 CEST] <relaxed> you'll bang your head against the desk less and less as you use it =) [22:27:49 CEST] <relaxed> when you run into an error with filters, simplifying the command as much as possible also helps to see what's wrong [22:29:40 CEST] <bwe> Isn't there some list on the wiki outlining the process to isolate the issue faster / common mistakes...? [22:31:29 CEST] <faLUCE> hello, is there any code for a simple audio-video player with libav? [22:36:53 CEST] <relaxed> faLUCE: the top of ffplay.c says "simple media player based on the FFmpeg libraries" [22:36:54 CEST] <teratorn> faLUCE: ffplay.c ? [22:37:25 CEST] <faLUCE> too long.In addition, it uses threads and I don't understand why [22:38:03 CEST] <teratorn> faLUCE: any real player will be a lot longer [22:38:30 CEST] <teratorn> "audio-video player" and "simple" don't go together [22:38:53 CEST] <faLUCE> I tried this, for video only, http://dranger.com/ffmpeg/tutorial02.c and it's ok. I need something which adds the audio part: http://dranger.com/ffmpeg/tutorial05.html <--- this doesn't work and it uses threads [22:38:57 CEST] <relaxed> People ask for this here quite a bit. Too bad the dranger tutorial is out of date. [22:39:10 CEST] <faLUCE> relaxed: exactly [22:39:35 CEST] <faLUCE> about the dranger tutorial I don't understand why it uses threads [22:40:54 CEST] <faLUCE> I saw that ffplay uses threads too. I don't understand that too [22:41:37 CEST] <relaxed> What would be cool is if someone took the dranger tutorial, added it to ffmpeg/tools/tutorial.c with explanations by the code. Then tutorial.c could be tested with fate [22:42:28 CEST] <faLUCE> relaxed: as said before, I tried to send examples to the mailing list. They have been rejected without any good reason, even if they were well coded and useful. [22:43:31 CEST] <relaxed> it would be a lot of work and they probably want someone to maintain it if it goes in [22:43:42 CEST] <relaxed> do you have a link to the email thread? [22:44:13 CEST] <faLUCE> relaxed: really not. they just had a dogmatic behaviour. anyway, iive told me that he wanted to bump and propose my thread again [22:44:32 CEST] Action: relaxed pets iive [22:44:41 CEST] <faLUCE> relaxed: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209494.html [22:45:20 CEST] <faLUCE> I have a good experience with libav, and I could send many useful things [22:45:48 CEST] <faLUCE> I could re-work on the danger tutorial too, but this behaviour really discouraged me in contributing [22:47:15 CEST] <relaxed> You might have better luck with an RFC email explaining your goal and the best way to go about it. [22:48:22 CEST] <faLUCE> relaxed: really not. My time is up. I don't want to waste more time with that. If some people, here, find my examples useful, then it's up to them to propose them again to the mailing list [22:49:38 CEST] <faLUCE> relaxed: you can see yourself how useful is the example I proposed. But they preferred to keep horrible code like "muxing.c" or "decoding_demuxing.c", or "aac_transcoding" [22:54:33 CEST] <faLUCE> does anyone want to make this simple avplayer with me? :-) [22:54:50 CEST] <faLUCE> I have some ideas... [22:55:30 CEST] <JEEB> I would rather just make a thing on top of libvlc or libmpv [22:55:41 CEST] <JEEB> we don't need more NIH in base player things [22:55:52 CEST] <faLUCE> JEEB: I thought about that, but in this way I can't control the latency [22:55:55 CEST] <durandal_1707> kodi [22:56:30 CEST] <JEEB> faLUCE: never came up with the idea of contributing to those things instead of doing NIH? esp. since they already can use lavf/lavc [22:56:56 CEST] <faLUCE> JEEB: what is NIH? [22:57:08 CEST] <JEEB> Not Invented Here (syndrome) [22:58:28 CEST] <faLUCE> JEEB: I have to make a low latency live http mpegts player. I succeded in making a video only player, and if I make an audio video player it would be really useful for anyone [22:59:25 CEST] <faLUCE> but I need some help [22:59:40 CEST] <JEEB> I still don't see why libvlc (or libmpv) wouldn't be something you could work with [23:00:04 CEST] <JEEB> since you would still be able to call it faLUCE's delicious player, but at least you'd be contributing to something that would get generally used [23:01:01 CEST] <faLUCE> JEEB: I don't have clear ideas about that. But I suspect that wrapping libav (as libmpv or libvlc do) doesn't give me control over the latency. In fact, both vlc and mpv have bad latency for mpegts http streams [23:01:54 CEST] <JEEB> let me guess you didn't even try to minimize that. and even if it wouldn't be perfect what stops you from trying to improve those two [23:02:09 CEST] <faLUCE> JEEB: I'm not interested in making "faluce's player". I would be glad if I can use external libs for the player (I already built my lib) [23:02:23 CEST] <JEEB> only if you definitely see that due to how those two are done you can't architecturally make it good enough [23:02:44 CEST] <JEEB> I recommend you go poke #videolan for example regarding minimizing of latency as I know VLC is often used in UDP environments [23:04:00 CEST] <faLUCE> JEEB: I already know how to minimize the latency with libav (as said before, I did that for the video part, and for the audio part separately) [23:04:16 CEST] <faLUCE> and I did that for muxing audio+video [23:04:18 CEST] <JEEB> I didn't say anything about that [23:04:30 CEST] <JEEB> actually read what I said, please [23:05:06 CEST] <JEEB> I know it's often simpler to hack something up yourself for a POC, but generally these things end up more useful if you don't end up NIH'ing [23:05:18 CEST] <faLUCE> JEEB: let me finish: [23:05:25 CEST] <faLUCE> the main problem in vlc are THREADS [23:05:42 CEST] <faLUCE> I don't like libvlc stuff for this reasons [23:06:32 CEST] <JEEB> you should look into the input modules and such that are in both libvlc and libmpv [23:06:33 CEST] <faLUCE> in addition, vlc has option for minimizing the latency (I know all of them) but they don't give good results [23:06:49 CEST] <JEEB> look into meaning the code [23:07:11 CEST] <JEEB> anyways, at this point it seems like you have made your mind so I'm just going to stop [23:07:21 CEST] <JEEB> have fun doing NIH [23:08:06 CEST] <faLUCE> JEEB: vlc code is a mess and it uses threads without a good reasons. In addition, the options for minimizing the latency don't work well. If I sum all these things, it could be easier to re-write the dranger example... This is what I have to decide [23:09:34 CEST] <faLUCE> now, the first question is: is it necessary to use threads for audio+video playing? is it possible to put them into only one main loop? why does ffplay use them? [23:10:35 CEST] <JEEB> maybe you should have this discussion on #videolan or #mpv , seeing where those threads actually help (I would guess the renderers at least should be in their own threads) [23:11:21 CEST] <faLUCE> JEEB: right. I'll try to ask that in #mpv [23:11:37 CEST] <JEEB> -34 [23:12:06 CEST] <faLUCE> ? [23:32:28 CEST] <zerodefect> Is this channel appropriate to ask dev-oriented questions using libavformat/libavutils, or is it more for cli-based questions? [23:36:55 CEST] <teratorn> zerodefect: both [23:37:23 CEST] <DHE> zerodefect: response times to API questions is longer, but yeah this is the channel. [23:37:34 CEST] <zerodefect> Thanks. [23:38:50 CEST] <zerodefect> Would there be any reasons or limitations that would prevent me from being able to dynamically load libavformat and/or libavutils and call corresponding functions? [23:39:50 CEST] <faLUCE> zerodefect: same as for other libs :-) [23:41:24 CEST] <zerodefect> Ok. I figured as much. I ask because I did have issues linking at compile time where the order of libavformat/libavutils had to be a specific order (Ubuntu 17.04, GCC 6.3) [23:41:39 CEST] <zerodefect> I could never quite get to the bottom of that :/ [23:42:25 CEST] <DHE> yeah, gcc's linker is single-pass by default. though it can be made multi-pass [23:43:27 CEST] <zerodefect> Yeah, I got around it eventually by tweaking the order (can't remember which one came first) [23:43:43 CEST] <DHE> gcc ..... -Wl,--start-group -lavcodec -lavformat .... -Wl,--end-group [23:44:01 CEST] <DHE> will run multiple passes through everything in the group until it gets it all (assuming you didn't miss anything) [23:44:13 CEST] <zerodefect> Ah, good to know. I'll make a note of that :) [23:44:14 CEST] <DHE> I think that syntax is right [23:44:26 CEST] <zerodefect> I can look up the specifics [23:47:23 CEST] <arog> hey [23:48:36 CEST] <arog> I have an app that is recording images to a mp4 file, hte issue is that sometimes people forget to stop the application (which calls av_write_trailer, avcodec_close and avio_close) and eject the hard disk [23:48:54 CEST] <arog> is it possible to keep the file in a "safe" state every so often? [23:48:54 CEST] <zerodefect> I'm using Boost.DLL (v1.62) to dynamically load libavutil. I resolve the symbols for 'av_frame_alloc' - the return address looks right. I call the function pointer and bang...segmentation fault. [23:49:00 CEST] <arog> so it won't be completely unusable [23:49:23 CEST] <arog> maybe every 10-15 seconds it saves? [23:50:33 CEST] <arog> can I just do av_write_trailer then open it again to add more data? [23:59:16 CEST] <draean> Quick question: if I'm trying to pull in a stream source, and mix it into the file "ffmpeg -i input.mp4 -i "http://stream/source.mp3" -map 0:v -map 1:a output.mp4" but I want to be able to handle that audio stream not being there, and play black audio instead while it's missing. what would I need to look at? [00:00:00 CEST] --- Sat May 6 2017

1 0

ffmpeg-devel.log.20170504
by burek 05 May '17

05 May '17

[00:41:58 CEST] <jamrial> nevcairiel: did you have time to check the hevc patches? [01:14:48 CEST] <cone-273> ffmpeg 03James Almer 07master:14e092448f2e: avformat/concatdec: port to the new bitstream filter API [01:42:46 CEST] <alevinsn> nevcairiel: you there? [02:01:26 CEST] <alevinsn> anyone know why tests/checkasm is built such that it links to FF_STATIC_DEP_LIBS? [02:01:31 CEST] <alevinsn> instead of FF_DEP_LIBS? [02:01:44 CEST] <alevinsn> it appears to be the only thing that uses FF_STATIC_DEP_LIBS [02:03:43 CEST] <J_Darnley> Didn't someone guess the right answer before? [02:03:51 CEST] <alevinsn> ? [02:03:55 CEST] <J_Darnley> It needs to call internal functions [02:04:06 CEST] <alevinsn> ok, that makes sense [02:04:17 CEST] <alevinsn> still, that doesn't quite explain why it wants .a files [02:04:18 CEST] <J_Darnley> Perhaps you were offline [02:04:21 CEST] <alevinsn> instead of .lib files [02:04:24 CEST] <alevinsn> yeah, i had to leave [02:04:45 CEST] <alevinsn> I'll check IRC logs [02:06:56 CEST] <alevinsn> yeah, looks like I missed the final stuff from nevcairiel [02:45:45 CEST] <alevinsn> currently fate, when an error occurs, appears to just stop running [02:45:47 CEST] <alevinsn> at least on Linux [02:45:54 CEST] <alevinsn> is there any way to get it to continue to the next test? [02:53:41 CEST] <J_Darnley> It's make so the -k option will do it [02:54:31 CEST] <alevinsn> ah, that makes sense, thanks [05:27:21 CEST] <cone-761> ffmpeg 03James Almer 07master:c53bf8c9b8ad: configure: fix libopus detection [07:12:52 CEST] <wm4> philipl_, jkqxz: anything to say about that cuvid patch? [09:25:54 CEST] <ubitux> what is required to take the reordering out of the h264 decoder? [09:45:12 CEST] <wm4> lots of tears? [09:55:36 CEST] <rcombs> ubitux: funny that you ask, I was just talking to jkqxz about that [09:55:50 CEST] <ubitux> heh :) [09:55:56 CEST] <rcombs> thinking about A53? [09:56:01 CEST] <ubitux> no, vda/vt [09:56:04 CEST] <rcombs> ah [09:56:17 CEST] <ubitux> i really want to have that async vt decoder in ffmpeg [09:56:25 CEST] <rcombs> (I had both of those use-cases in mind) [09:58:47 CEST] <wm4> maybe trying this with hevc first would be easier, but then again I have not the slightest clue [10:46:12 CEST] <nevcairiel> i doubt thats a realistic thing to be doing [11:56:59 CEST] <ubitux> nevcairiel: why? [11:57:31 CEST] <ubitux> it will really help cleaning up that garbage [11:57:33 CEST] <nevcairiel> because you would basically re-build a h264 decoder without slice decoding [13:52:24 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:390c6ee42c49: tools/target_dec_fuzzer: Fix memleak on open failure [14:31:52 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:92f4a4bf29d7: configure: Do not add omit-frame-pointer for ossfuzz [16:24:10 CEST] <ubitux> michaelni: you may want to use -Og when available btw [16:47:08 CEST] <jamrial> ubitux: i looked at the next merge. wtf do we do with raise_major? [16:48:05 CEST] <jamrial> how do we make the new .version files consider it? it's a configure time only variable [16:48:53 CEST] <ubitux> yeah i wanted to drop it [16:49:21 CEST] <ubitux> we can still keep it and pass it as argument [16:49:26 CEST] <ubitux> to check if it should be enabled or not [16:50:06 CEST] <ubitux> like, to the script, you pass the $raise_major_enabled var or whatever actual holder [16:52:39 CEST] <jamrial> libversion.sh is called by make, so configure would need to store raise_major in some way in config.mak or wherever [16:53:07 CEST] <jamrial> kinda hacky [16:57:41 CEST] <BBB> for the stupid (me): what is raise_major? [17:00:31 CEST] <jamrial> a configure option that bumps the libraries' major version by 100 [17:00:51 CEST] <JEEB> ah [17:01:11 CEST] <BBB> I bet its totally not a hack or anything, right? [17:01:30 CEST] <jamrial> 99% chances is a hack :p [17:03:32 CEST] <jamrial> the commit message says it's to allow users to install the just compiled libraries alongside other already installed libraries with the same soname [17:07:08 CEST] <BBB> but why [17:07:20 CEST] <BBB> actually, I retract that question [17:07:25 CEST] <BBB> I dont want to know [17:07:38 CEST] <BBB> Im just going to continue to statically link so I dont have to re-live dll hell ever in my life [17:08:18 CEST] <BBB> WhatCouldPossiblyGoWrong[TM] [17:13:39 CEST] <ubitux> jamrial: don't you have access to that variable in the config.mak? [17:13:55 CEST] <ubitux> i mean, i'm all for dropping the feature though [17:13:55 CEST] <ubitux> michaelni: do we still need that raise major hack? [17:15:49 CEST] <philipl_> wm4: I missed it, but I've found it now. Will look today [17:18:55 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:cabfed6895fc: avcodec/msvideo1: Check buffer size before re-getting the frame [17:20:27 CEST] <philipl> wm4: so the main point here is that the cuvid decoder can directly access the hw_device_ctx if the client (mpv) sets it first. and so we don't need the half-initialized hw_frames_ctx. Makes sense when I look at it. Do you have the mpv side cleanup somewhere? Does it just remove video/decode/cuda.c? [17:22:55 CEST] <michaelni> ubitux, i dont remember exactly what it was used for [17:23:28 CEST] <ubitux> 102b794e09482fec881e7ec903e57914895f9b74 [17:23:39 CEST] <ubitux> > this allows seperate installation of shared libs that should not conflict with whatever is already installed. [17:24:01 CEST] <ubitux> the SYMVER thing doesn't seem present anymore [17:24:17 CEST] <ubitux> so it's only a +100 on major [17:24:54 CEST] <ubitux> note: FF_SYMVER is defined but not used [17:32:27 CEST] <jamrial> ubitux: oh, you're right, it's there [17:37:23 CEST] <alevinsn> nevcairiel: you there? [17:39:16 CEST] <ubitux> damnit why is ffmpeg, even with --disable-pthreads, no predictible wrt the avio requests over http [17:39:33 CEST] <nevcairiel> alevinsn: not for long [17:39:51 CEST] <ubitux> i have a httpd that doesn't seem to like at all ffmpeg requests [17:40:01 CEST] <ubitux> it leads to fd exhaustion on its [17:40:03 CEST] <ubitux> side [17:40:04 CEST] <alevinsn> k, I saw your messages from yesterday regarding checkasm, disabling checkasm isn't enough to get shared builds FATE runs to work [17:40:22 CEST] <alevinsn> it later builds options.c (from libavcodec, for example), but in a way that enables some test code [17:40:24 CEST] <ubitux> are we somehow opening and not closing N connections with ffmpeg for each ranges? [17:40:26 CEST] <nevcairiel> checkmas is the only thing that doesnt work reliably [17:40:29 CEST] <alevinsn> and that fails as well [17:40:39 CEST] <alevinsn> to build [17:40:44 CEST] <alevinsn> complaining about the same missing symbols [17:40:54 CEST] <alevinsn> no problem when I do a static build [17:41:09 CEST] <alevinsn> which is the way the MSVC fate builds are configured to run at fate.ffmpeg.org [17:41:15 CEST] <alevinsn> so, I gave up and went with that [17:41:23 CEST] <alevinsn> is this an issue for shared builds on Linux? [17:41:24 CEST] <nevcairiel> fate has both, shared and static [17:41:41 CEST] <ubitux> i had to hack something for the shared one iirc [17:42:06 CEST] <alevinsn> well, it doesn't appear to work on Windows--as I indicated, disabling checkasm in tests/Makefile isn't sufficient [17:42:12 CEST] <alevinsn> more needs to be done [17:42:27 CEST] <ubitux> fate/configs/enable-shared.cfg:extra_ldflags="-Wl,-rpath=libpostproc:libswresample:libswscale:libavfilter:libavdevice:libavformat:libavcodec:libavutil:libavresample" [17:42:30 CEST] <alevinsn> since it tries to do a static-like build for options.c, and possibly other stuff [17:42:47 CEST] <ubitux> i don't remember why i need this [17:43:25 CEST] <alevinsn> ubitux: I guess that's for Linux, right? [17:43:26 CEST] <alevinsn> gcc [17:43:26 CEST] <nevcairiel> the alternative to that is to install the libraries into a path where the linker finds them [17:43:30 CEST] <ubitux> alevinsn: yes [17:43:35 CEST] <alevinsn> oh [17:43:42 CEST] <alevinsn> so, alter LIB environment variable [17:44:08 CEST] <alevinsn> it wants .a versions of libraries though [17:44:36 CEST] <alevinsn> when a dynamic build is done [17:44:36 CEST] <nevcairiel> i dont see anything special for the options tool, it only uses public stuff as far as I can see and has no special link instructions [17:45:27 CEST] <alevinsn> unfortunately, I don't have the output log anymore [17:45:32 CEST] <alevinsn> but, it should be easily reproduced [17:49:08 CEST] <nevcairiel> its not really all that important either way, as long as the main fate tests all work, those special test tools are mostly just nonsense to increase coverage [17:49:32 CEST] <alevinsn> so, if I use make -k, I can get past those failures? [17:49:49 CEST] <nevcairiel> presumably [17:49:58 CEST] <nevcairiel> the fate stations on fate.ffmpeg.org manage to do it =p [17:50:39 CEST] <alevinsn> it might be nice if those used make V=1 or V=2 fate [17:51:06 CEST] <nevcairiel> way too much spam for no use [17:51:37 CEST] <alevinsn> I had hoped to see that output so that I could compare my compilation lines to the ones done by the "official FATE system" [17:51:41 CEST] <nevcairiel> the configure commands are shown there, nothing else is otherwise hidden anywhere [17:52:00 CEST] <alevinsn> if there were some way to log V=1,V=2 separate;y [17:52:05 CEST] <alevinsn> or at the same time as V=0 [17:52:11 CEST] <alevinsn> that would be awesome [17:52:52 CEST] <nevcairiel> i still dont see why [17:52:59 CEST] <nevcairiel> those dont o ffer any useful info [17:53:25 CEST] <alevinsn> well, for example, I wanted to see if it was trying to find .a files [17:53:34 CEST] <alevinsn> when linking [17:53:41 CEST] <alevinsn> and compare it to my link line, when it was failing [17:54:15 CEST] <nevcairiel> clearly you can see from the log that it also fails making the checkasm test for similar reasons [17:54:22 CEST] <nevcairiel> in the shared config [17:54:48 CEST] <alevinsn> hmm, I didn't notice that there were shared runs on fate.ffmpeg.org [17:54:52 CEST] <alevinsn> but I guess I missed that [17:56:01 CEST] <alevinsn> yeah, I see that [17:56:10 CEST] <alevinsn> but, there are also differences [17:56:24 CEST] <alevinsn> it complained about -lm not working much earlier for my log for some reason [17:56:48 CEST] <nevcairiel> the order is not deterministic since it uses parallel make [17:58:14 CEST] <mdavis> For my own amusement/education, I was thinking of writing Codec2 support into FFmpeg. Should I do it "right" in case anyone's interested? [17:58:14 CEST] <alevinsn> options.exe failed for the same reason I see now [17:58:20 CEST] <alevinsn> in the shared build at [17:58:24 CEST] <alevinsn> http://fate.ffmpeg.org/log.cgi?time=20170503202843&log=test&slot=x86_32-msv… [17:58:32 CEST] <alevinsn> just search for __imp [17:58:35 CEST] <nevcairiel> (ie. make -j3 for most of my fate boxes, since its a resource limited VM) [17:59:35 CEST] <alevinsn> ok, this is all making sense--I should add some information to fate.texi for shared builds [18:00:08 CEST] <nevcairiel> shared setups are way different everywhere, it should just be discouraged for fate testing [18:00:24 CEST] <jamrial> michaelni: regarding repeated calls to av_realloc for cases where the final size of the array is known beforehand, do you think i should revert b438a7868c and 9f102653fd? [18:00:50 CEST] <jamrial> michaelni: have either of those changes affected any of these fuzz cases you're trying to fix? [18:01:27 CEST] <nevcairiel> anyhow time to leave [18:01:38 CEST] <alevinsn> thanks [18:02:18 CEST] <alevinsn> jamrial: for multi-patch patch sets, what's the best way for someone to review [18:02:29 CEST] <alevinsn> such that the previous patch, once reviewed [18:02:33 CEST] <alevinsn> doesn't appear in the diff anymore? [18:02:43 CEST] <alevinsn> besides committing it personally [18:02:51 CEST] <alevinsn> so, I review patch 1 [18:02:58 CEST] <alevinsn> then apply patch 2 (or something like that) [18:03:08 CEST] <alevinsn> and the patch 1 changes don't show up anymore [18:03:16 CEST] <alevinsn> in my review tool, diff tool, etc [18:04:01 CEST] <alevinsn> question for anyone, really [18:16:03 CEST] <nevcairiel> Use a proper git client to read the diffs or just review on the ML if possible [18:32:21 CEST] <michaelni> jamrial, the ossfuzz fuzzer doesnt use ffmpeg.c so nothing in it can affect it [18:32:49 CEST] <jamrial> michaelni: ok [18:32:54 CEST] <michaelni> a testcase that uses ffmpeg.c could be added of course [18:37:56 CEST] <nevcairiel> Wasn't the reason for the slowdown the memory analyzer and not just an inherent slowness [19:48:52 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:a0296fc056f0: avcodec/pngdec: Use ff_set_dimensions() [20:06:42 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:c1c3a14073b3: libavcodec/mpeg4videodec: Convert sprite_offset to 64bit [20:06:44 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:d2657d225c14: avcodec/flicvideo: Check for chunk overread [20:21:29 CEST] <Dresk|Dev> Apologies for asking a usage question in the dev channel, figured hopefully it would not agitate the natives too much, but my question is : with 3.3 regarding Android - does this version provider hardware decoding with the result being a texture, as opposed to an overlay? [20:28:37 CEST] <Compn> with which android hwaccel interface, Dresk|Dev ? [20:28:52 CEST] <Compn> omx? stagefright? something else [20:31:28 CEST] <JEEB> mediacodec is now a thing in lavc [20:32:01 CEST] <JEEB> it either outputs a normal avframe and I think there might be a texture output as well (a "hwaccel"), but I haven't utilized it [20:32:14 CEST] <JEEB> since the mediacodec decoder is "fast enough" for me in general [20:32:54 CEST] <Dresk|Dev> Compn: I'm not certain which interface - I was seeing if ffmpeg "handled" going through MediaCodec API on its own or something [20:33:15 CEST] <Dresk|Dev> Compn: We purely use ffmpeg and don't use any Android code at all in our engine currently [20:34:25 CEST] <Dresk|Dev> JEEB: We're software decoding 4K videos and no SoC right now can do it (we've tried Snappy 821, 830, Exynos 8890, Tegra K1 and Tegra X1) [20:35:03 CEST] <JEEB> well, d'uh [20:35:04 CEST] <JEEB> ARM [20:36:04 CEST] <JEEB> also UHD sounds about where you probably would want direct rendering instead of possible memcpy. not sure how that works with opengl on android [20:38:15 CEST] <Dresk|Dev> Hm, one moment, discussing with my fellow developers about understanding these changes (I'm the dumbest one of the bunch, hehe) [20:40:26 CEST] <Dresk|Dev> JEEB / Compn : I deeply appreciate your help by the way, I could conceive how ffmpeg is not always the most joyous of projects to work on [20:43:36 CEST] <Dresk|Dev> JEEB: Is there anything that needs to be done to get that accelerated codec by default? Right now we just call avcodec_find_decoder with the result of the codec_id in the stream, then copy the codec context and build a decoder context from that - is that behavior going to "get us" the mediacodec so calls to avcodec_decode_video2 (in our case) go through it? [20:44:42 CEST] <Compn> oh wow 4k on android ? [20:46:22 CEST] <JEEB> you would have to make sure you are using the mediacodec -prefixed decoder [20:46:27 CEST] <Dresk|Dev> Compn: Yes sir, that is our goal [20:46:50 CEST] <JEEB> if you log things you should see if the decoder is h264 or mediacodec_h264 for example [20:56:08 CEST] <durandal_1707> atomnuker: trying to get uniform partitioned convolution to work, i get frequency spikes each time of one full IR samples block size [20:57:40 CEST] <durandal_1707> with this filter ffmpeg could do reverb, ambiophonics and much more [21:00:05 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:fc4f88375b8a: avcodec/wavpack: Fix invalid shift and integer overflow [21:00:06 CEST] <cone-249> ffmpeg 03Michael Niedermayer 07master:a78ae465fda9: avcodec/mjpegdec: Fix runtime error: signed integer overflow: -24543 * 2031616 cannot be represented in type 'int' [21:39:20 CEST] <philipl> wm4: You have your ship-it [22:05:59 CEST] <durandal_1707> atomnuker: shit, using 1,0,0,0.....as IR i get perfect output [23:02:09 CEST] <wm4> philipl: yes, the mpv side of the change pretty much drops cuda.c and does not set hw_frames_ctx in the get_format callback [23:06:24 CEST] <philipl> wm4: jolly good. [23:18:52 CEST] <cone-249> ffmpeg 03Carl Eugen Hoyos 07master:3624d45ddbe9: compat/strtod: Add missing const qualifiers. [23:22:27 CEST] <jamrial> ubitux: check https://github.com/jamrial/FFmpeg/commits/mergework whenever you can [23:23:48 CEST] <jamrial> merged two commits at once, plus cherry picked changes from another two that fix regressions introduced by the merged ones [23:24:56 CEST] <jamrial> tried it and both raise major build suffix seem to work (shared build or not), but i'd prefer if you can look at it and test it some [23:27:01 CEST] <ubitux> +DESC = Libav container format library [23:27:04 CEST] <ubitux> this one is wrong ^ [23:27:06 CEST] <ubitux> (lavf) [23:27:54 CEST] <jamrial> oops [23:28:14 CEST] <jamrial> fixed locally :p [23:28:56 CEST] <ubitux> did you check if an out of tree build still work? [23:28:57 CEST] <jamrial> ubitux: had to remove the include config.mak from every library Makefile [23:29:15 CEST] <ubitux> i think one of the main thing we have different is that "src" dir from the build dir [23:29:29 CEST] <ubitux> which may need special care (not sure if it makes a difference here) [23:31:27 CEST] <jamrial> ah, symlink right? didn't, try on linux [23:34:56 CEST] <ubitux> /bin/sh: /home/ux/src/ffmpeg/ffbuild/libversion.sh: Permission denied [23:35:10 CEST] <ubitux> /bin/sh: /home/ux/src/ffmpeg/ffbuild/pkgconfig_generate.sh: Permission denied [23:35:30 CEST] <jamrial> do you know what line? [23:35:59 CEST] <ubitux> it's missing a chmod +x [23:36:09 CEST] <ubitux> on both scripts [23:36:41 CEST] <jamrial> right [23:37:30 CEST] <ubitux> Requires: libavcodec >= , libswresample >= , libavutil >= [23:37:39 CEST] <ubitux> these look broken in the installed .pc [23:38:52 CEST] <jamrial> odd, it creates them fine here [23:39:16 CEST] <ubitux> .version files are empty, is this normal/unrelated? [23:41:21 CEST] <jamrial> they should be filled [23:41:35 CEST] <jamrial> did you add +x to the scripts and tried from a clean state? [23:41:55 CEST] <ubitux> let me retry from a clean state [23:42:01 CEST] <ubitux> that might be the issue [23:42:30 CEST] <jamrial> force pushed a version with the scripts fixed, hopefully [23:43:43 CEST] <ubitux> seems to work yeah [23:46:22 CEST] <ubitux> just trying one last thing and i guess it's good [23:49:04 CEST] <ubitux> jamrial: are you sure the Libs.private is correctly set in shared build? [23:49:12 CEST] <ubitux> (in the .pc file) [23:51:30 CEST] <ubitux> btw, not sure if that's on purpose but libdir and includedir don't seem to rely on ${prefix} anymore [23:51:38 CEST] <ubitux> it's expanded [23:52:19 CEST] <jamrial> probably because it's printed from configure to config.sh, then to pkgconfig_generate.sh [23:52:31 CEST] <jamrial> it shows up with ${prefix} in config-sh [23:52:43 CEST] <jamrial> and afaik libs.private is the same as pre merge [23:53:05 CEST] <ubitux> mmh, strange [23:53:14 CEST] <jamrial> let me check again [23:53:55 CEST] <ubitux> compare with --enable-shared [23:54:28 CEST] <alevinsn> when running FATE on Windows, the diff is failing for me in some cases because of whitespace [23:54:45 CEST] <alevinsn> newline characters apparently in the generated output [23:55:05 CEST] <alevinsn> anyone know if there is a way I should be setting things up to prevent that? [23:55:31 CEST] <BtbN> probably git putting windows line endings into things [23:55:59 CEST] <alevinsn> no, I have that turned off [23:57:03 CEST] <alevinsn> crap, I guess it didn't fix that for some of the files [23:57:22 CEST] <alevinsn> I thought I had addressed that [23:57:55 CEST] <nevcairiel> easiest is just to delete everything but the .git dir and let git restore everything [23:59:45 CEST] <alevinsn> I had read that I could use git checkout-index --force --all [23:59:53 CEST] <alevinsn> to fix that [00:00:00 CEST] <alevinsn> but it doesn't seem to have worked in all cases [00:00:00 CEST] --- Fri May 5 2017

1 0

ffmpeg.log.20170504
by burek 05 May '17

05 May '17

[00:08:52 CEST] <bsat98> i can't figure out if named pipes as input to ffmpeg are or are not supported. a few older threads i saw they weren't, and now I see some success stories but i'm just not able to get it working [00:09:23 CEST] <bsat98> i'm using: ffmpeg -y -i tmp.mp4 -ss "00:00:00.000" -vframes 1 t.png [00:09:34 CEST] <bsat98> and i get an error: `stream1, offset 0x20: partial file` [00:09:44 CEST] <bsat98> of course the command works when not using named pipe [00:20:27 CEST] <llogan> bsat98: how do we duplicate the issue? [00:27:57 CEST] <bsat98> llogan: `mkfifo tmp.mp4 && curl something.mp4 > tmp.mp4` and then in a separate term: `ffmpeg -y -i tmp.mp4 -ss "00:00:00.000" -vframes 1 t.png` [00:45:40 CEST] <bsat98> actually, even if i just use cat and pipe it with -i pipe:0 i get exactly the same error [00:54:47 CEST] <llogan> bsat98: don't use mp4 to pipe. or try relocating the moov atom before piping: ffmpeg -i in.mp4 -movflags +faststart out.mp4 [01:10:09 CEST] <bsat98> llogan: it works thanks so much [01:12:55 CEST] <llogan> bsat98: should have been: ffmpeg -i input.mp4 -c copy -movflags +faststart out.mp4 [01:16:40 CEST] <bsat98> llogan: that would cause it to do less computation by copying the raw av? [01:18:26 CEST] <llogan> it stream copies. avoids re-encoding. [01:20:58 CEST] <bsat98> llogan: i'm scared because the files are already being processed by ffmpeg somewhere else, but without -c copy using the command you gave me it reduces the filesize by half :D [01:22:04 CEST] <furq> that reencodes it using the default settings [01:22:13 CEST] <furq> which aren't particularly great quality [01:22:23 CEST] <bsat98> oh right [01:22:34 CEST] <furq> also iirc ffmpeg rewrites the file twice if you remux with faststart [01:22:39 CEST] <furq> a proper mp4 muxer will only write it once [01:23:02 CEST] <bsat98> furq: are you aware of a better suited tool for this? [01:23:10 CEST] <furq> if you just need to remux then use l-smash [01:24:05 CEST] <furq> if they're short files then it's not really worth switching [01:24:10 CEST] <bsat98> my actual problem is basically [01:24:50 CEST] <bsat98> users upload videos, and i want to generate thumbnails *on demand* and in different resolutions. [01:24:58 CEST] <furq> i need to remux a lot of very large files on a vps with slow io, so i really notice the difference [01:25:15 CEST] <bsat98> so my idea was to pipe the first bit of the file to ffmpeg from a named pipe [01:25:26 CEST] <bsat98> and then generate it like that, rather than move files around the network etc [01:25:28 CEST] <furq> if you're processing the file with ffmpeg to begin with, then just add -movflags +faststart to that command [01:25:36 CEST] <furq> no need to remux at all [01:25:44 CEST] <bsat98> yes i plan to do that [01:25:57 CEST] <bsat98> im just wondering if there's a more lightweight approach [01:26:16 CEST] <bsat98> i have mp4 h264 files only and i just want to read up to the first keyframe from an arbitrary pipe [01:26:16 CEST] <furq> i didn't think piping mp4 would work at all [01:26:40 CEST] <furq> unless it's fragmented [01:27:03 CEST] <bsat98> it wasn't working until i used -movflags +faststart [01:27:21 CEST] <furq> weird [01:27:33 CEST] <bsat98> why wouldn't it work though? [01:27:41 CEST] <bsat98> or i mean why do you assume it wouldn't work [01:27:42 CEST] <furq> mp4 isn't streamable [01:27:58 CEST] <bsat98> are you sure about that? [01:28:06 CEST] <furq> how are you piping it [01:28:19 CEST] <bsat98> named pipe from gsutil [01:28:31 CEST] <furq> i'm not sure if i'd trust that [01:28:46 CEST] <furq> i guess if you're always seeking from the start and the moov atom is at the start then it should work [01:29:18 CEST] <bsat98> that's what is happening [01:29:54 CEST] <furq> you can't pipe mp4 out of ffmpeg because it writes the moov atom in a second pass [01:30:09 CEST] <furq> if you're not using ffmpeg then i don't really know [01:30:20 CEST] <furq> although either way i'd probably just have the files on a network share [01:30:23 CEST] <bsat98> i'm using ffmpeg to transcode everything to mp4 [01:30:27 CEST] <furq> i meant for piping [01:30:39 CEST] <bsat98> oh right [01:31:31 CEST] <bsat98> i wonder if -movflags +faststart is going to "work" for every type i transcode [01:31:34 CEST] <bsat98> i'll have to test :< [01:31:38 CEST] <furq> that's an output format option [01:31:43 CEST] <furq> if you're converting to mp4 then it'll always work [01:31:50 CEST] <bsat98> but is it always going to be the same normalized mp4 format [01:31:59 CEST] <furq> sure [01:32:08 CEST] <bsat98> i assumed there might be some subtle differences depending on the input format [01:32:08 CEST] <furq> unless you're running different commands on different inputs [01:32:14 CEST] <bsat98> i am [01:32:26 CEST] <furq> even then i doubt it [01:32:40 CEST] <bsat98> everything ends up as mp4 with h264 encoding [01:32:46 CEST] <furq> every mp4 has a moov atom, faststart just moves that to the beginning of the file [01:32:51 CEST] <bsat98> but the path to that is different depending on the type of file was input [01:32:54 CEST] <furq> if there's no moov atom the mp4 won't play at all [01:33:01 CEST] <bsat98> okay, that's good [01:33:02 CEST] <bsat98> thanks [01:33:13 CEST] <furq> as everyone whose camera has run out of battery in the middle of a recording will know [01:43:52 CEST] <bsat98> furq: so i notice that chrome is able to stream the original non-moov-atom-fixed versions of my mp4s with the help of varnish, is there something i'm missing? [01:44:38 CEST] <furq> it won't work if you disable range requests in your httpd [01:44:43 CEST] <bsat98> using range requests and 206s [01:44:48 CEST] <furq> right [01:45:04 CEST] <furq> that's a relatively recent thing [01:45:06 CEST] <bsat98> but shouldn't the mp4 need to be fully consumed [01:45:18 CEST] <bsat98> in order to decode it properly [01:45:21 CEST] <furq> no, it just does incrementally larger range requests from the end of the file until it finds the moov atom [01:45:23 CEST] <bsat98> if the moov atom is at the end [01:45:26 CEST] <bsat98> ohh [01:45:32 CEST] <furq> if the moov atom is at the start then that isn't needed [01:45:45 CEST] <bsat98> yeah im just saying it "works" with it being at the end [01:45:48 CEST] <bsat98> which surprised me [01:46:04 CEST] <furq> yeah that's worked for a while now [01:46:10 CEST] <furq> even ffmpeg will do that now [01:46:14 CEST] <furq> but it is a bit of a hack [01:46:51 CEST] <bsat98> so basically chrome is trying to find the moov atom? [01:46:57 CEST] <furq> pretty much [01:47:01 CEST] <bsat98> that's why there's like 3-4 reqs [01:47:03 CEST] <bsat98> makes sense [01:47:09 CEST] <bsat98> chrome so smart [01:47:12 CEST] <furq> that's why piping doesn't normally work with mp4, because you can't seek a pipe [01:47:20 CEST] <bsat98> i see [02:10:30 CEST] <james9999> this is probably a bad idea because of what was discussed earlier about doc [02:11:00 CEST] <james9999> but would it be useful to have a bot like fflogger that could show things with commands? [02:11:07 CEST] <james9999> like !mp4 and it displays something about moov atoms [02:11:17 CEST] <james9999> i know some channels have bots some don't [02:12:20 CEST] <furq> !muxer mp4 [02:12:21 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#mov_002c-mp4_002c-ismv [02:12:23 CEST] <furq> you mean like that [02:16:20 CEST] <james9999> yes exactly [02:16:22 CEST] <james9999> XD [09:35:10 CEST] <JC_Yang> questions about AVIOContext api, should the read_packet callback block if no more data currently available? I've simply checked the source, it seems like return 0 when no data is available result in an EOF conclusion. So read_packet should block when no more data currently available(but new data is coming), is it right? [09:35:39 CEST] <c_14> I think it returns EAGAIN? [09:40:35 CEST] <c_14> though it looks like ffurl_read blocks [09:47:07 CEST] <JC_Yang> the in-header document say nothing about this, so frustrated. [09:56:31 CEST] <JC_Yang> the only callers are all within the aviobuf.c, the the call site indicate it really should not return 0, so the proper treatment should block, IIUC. [10:09:31 CEST] <JC_Yang> anyone please correct me if i'm wrong [10:35:29 CEST] <Nacht> If I run ffprobe to probe a MPEG-TS file using H.264 coding. How do I know which of the code pages in libavcodec it uses ? I see quite a list of H.264 pages. [10:35:32 CEST] <Nacht> Is it h264_parser.c ? [10:36:00 CEST] <Nacht> The reason I'm asking, is that I'm trying to figure out how you're scanning for the NAL units [10:36:29 CEST] <JC_Yang> code page? [10:36:55 CEST] <Nacht> as in: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264_parser.c [10:39:23 CEST] <JC_Yang> if what you like to know/understand is "how does ffmpeg find the h264 NAL from a TS", I think the right place to go is libavformat [10:40:16 CEST] <JC_Yang> it is the demuxer in action [10:47:06 CEST] <Nacht> Cheers, I'll have a look there [10:49:31 CEST] <crow> is there any ffmpeg bisect documentations? for an bug report i should do bisect, i know that rls 3.2.4 works and 3.3 not (coredump) [10:59:24 CEST] <eiro> hello everyone [10:59:45 CEST] <eiro> can a file have multiple video stream ? [11:00:00 CEST] <JC_Yang> that depends [11:00:07 CEST] <JC_Yang> on the file format [11:00:36 CEST] <eiro> outch ... [11:01:00 CEST] <eiro> ok thanks [11:01:12 CEST] <JC_Yang> e.g mkv and mpeg-ts can contain multiple video streams [11:14:00 CEST] <Nacht> Man I really don't get this. I'm looking at the streams of NASA and they just don't make sense. Somehow FFMPEG knows how to handle them though. If I look at the NAL units they send for the first frame for example, I see NAL 9, 7, 8 and then 3 times 6. Which is weird, as you'd expect an IDR frame (5) being the first frame. [11:22:03 CEST] <JC_Yang> you're investigating the file hex? [11:24:23 CEST] <Nacht> Aye. I do see the IDR now. Trying to figure out why I got 3 SEI frames now [11:24:36 CEST] <Nacht> *units [11:26:57 CEST] <JC_Yang> I think MPEG-TS standard should be your reference [11:28:46 CEST] <Nacht> Already got trough the MPEG-TS. I'm trying to split the TS files, although I noticed not all encoders set the RAI when an IDR frame is present. So it's best to just analyse the H264 and look for the IDR there [11:28:56 CEST] <jkqxz> That still isn't the end of the first access unit. You have AUD, SPS, PPS, 3xSEI - there still isn't any frame data yet, presumably the IDR slices follow that. [11:29:41 CEST] <Nacht> Yeah I found the IDR as well, 00 00 01 25 [11:29:48 CEST] <JC_Yang> http://www.itu.int/rec/T-REC-H.222.0 there're free docs(which are marked as suspersed, but actually enough for your study) [11:36:49 CEST] <faLUCE> Hello. With these settings: ultrafast preset, size=640x480, gopsize=5, bitrate= default bitrate, 0 bframes, I have a latency of about 200ms, for the h264 encoder. Can I reduce it more? [11:45:10 CEST] <thebombzen_> faLUCE: not with the ffmpeg CLI [11:45:16 CEST] <thebombzen_> you can use -tune zerolatency though [11:45:24 CEST] <thebombzen_> that can improve it [11:45:51 CEST] <thebombzen_> but sub-200 isn't really possible with ffmpeg's CLI because there's buffers you can't control [11:56:55 CEST] <faLUCE> thebombzen_: yes, I just set zerolatency and FINALLY, I can receive a http-mpegts-h264 0latency stream [11:57:17 CEST] <faLUCE> thebombzen_: I used the API [11:57:18 CEST] <thebombzen_> it won't be zero [11:57:25 CEST] <thebombzen_> but it'll be very low yea [11:57:33 CEST] <thebombzen_> also I recommend superfast if you can [11:57:44 CEST] <thebombzen_> it's a huge step up from ultrafast [11:57:50 CEST] <faLUCE> thebombzen_: is it faster than ultrafast? [11:57:55 CEST] <faLUCE> ok thanks, I'll try it [11:57:57 CEST] <BtbN> the preset has no impact on the latency, as long as your CPU can handle it [11:58:16 CEST] <thebombzen_> BtbN: well, somewhat [11:58:31 CEST] <thebombzen_> if you have -tune zerolatency set, yes [11:58:48 CEST] <BtbN> why would you not have that set if you want zero latency? [11:58:54 CEST] <faLUCE> now I have only the network latency, which is about 0.1 seconds. I obtained it by avoiding avformat_find_stream_info(), and setting the stream's params manually [11:59:21 CEST] <thebombzen_> also superfast it is not faster. it's one step lower than ultrafast, but if you can handle realtime encoding it's good enough [11:59:46 CEST] <thebombzen_> but superfast looks a lot better [12:00:30 CEST] <thebombzen_> ultrafast is terrible visual quality [12:00:37 CEST] <thebombzen_> I'd recommend trying superfast first [12:02:13 CEST] <Nacht> Right, I found my error. It's due to the fact that I have 3 SEI units in this stream that it breaks the code. Due to the 188 bytes limitation on MPEG-TS, the IDR unit got pushed to the next packet. [12:02:31 CEST] <Nacht> Back to the drawingboard [12:28:32 CEST] <thebombzen_> BtbN: by the way, is there any planned support for hevc_nvenc in OBS's simple output mode [12:28:37 CEST] <thebombzen_> currently it only does h264_nvenc [12:37:35 CEST] <heftig1> what controls the input buffer size (the one that -re reads from for pacing)? [12:51:03 CEST] <BtbN> thebombzen_, ask the OBS people. As no streaming service is going to support HEVC, I doubt it. [12:58:14 CEST] <heftig1> how does HEVC compare to AVC at the same encoding speed? [12:58:24 CEST] <heftig1> assuming x264 and x265 [13:01:10 CEST] <heftig1> i think it's worse, and that's why no streaming service is interested in HEVC yet (aside from the effort needed for the whole pipeline to support another codec) [13:01:17 CEST] <BtbN> You will have trouble getting HEVC to encode at the same speed as h264 [13:03:57 CEST] <BtbN> The streaming sites are not interested because some people have trouble to even decode h264 in real time. [13:04:14 CEST] <BtbN> And browsers have no sign of support for HEVC playback support, let alone hardware acceleration. [13:05:31 CEST] <Mandevil> HEVC patents situation is still a mess. [13:13:07 CEST] <tp_> netflix is using HEVC as well [13:14:56 CEST] <Mandevil> They stream in HEVC? [13:15:04 CEST] <tp_> yes [13:15:12 CEST] <Mandevil> How do the clients play the streams? [13:15:16 CEST] <Mandevil> Flash? [13:15:54 CEST] <tp_> through their app, its for 4K content only i think, well and must be for HDR content too [13:16:24 CEST] <Mandevil> So they have to have Windows app, MacOS app...? [13:18:49 CEST] <tp_> i dont think they care much for that, but they have an app for android tv [13:19:06 CEST] <Nacht> Aren't they using VP9 ? [13:19:09 CEST] <Nacht> https://medium.com/netflix-techblog/more-efficient-mobile-encodes-for-netfl… [13:26:01 CEST] <thebombzen_> BtbN: yea but OBS is also used for gameplay recording. [13:26:09 CEST] <thebombzen_> also I asked you cause you pushed the last commit here: https://github.com/jp9000/obs-studio/blob/master/plugins/obs-ffmpeg/obs-ffm… [13:26:15 CEST] <tp_> they are using a lot of codecs, probably VP9 as well [13:27:28 CEST] <thebombzen_> I use hardware encoding to record gameplay and it'd be nice if OBS allowed me to use hevc instead of h264 because then perhaps I won't have 120 Mbps recordings [13:38:33 CEST] <Mandevil> thebombzen_: have you tried Intel QSV? [13:38:43 CEST] <Mandevil> thebombzen_: I hear it encodes HVEC really fast. [13:39:22 CEST] <Mandevil> (you need SkyLake or newer CPU, though)> [13:39:45 CEST] <thebombzen_> I have a 6700k and I didn't know you could do that with OBS [13:40:04 CEST] <Mandevil> How does OBS do its encoding? [13:40:10 CEST] <Mandevil> You can use ffmpeg to do it, right? [13:41:21 CEST] <thebombzen_> if you use ffmpeg's advanced feature you don't get a replay buffer [13:41:45 CEST] <thebombzen_> I could use ffmpeg's advanced for hevc_nvenc as well but then no replay buffer [13:42:06 CEST] <Mandevil> No idea what is replay buffer. [14:08:55 CEST] <faLUCE> <thebombzen_> but sub-200 isn't really possible with ffmpeg's CLI because there's buffers you can't control <--- I did not understand that. What is sub-200 ? [14:13:54 CEST] <DHE> latency in milliseconds I assume [14:15:21 CEST] <faLUCE> why is it not possible, with CLI, if I set zerolatency ? which are the other buffers? [14:19:56 CEST] <faLUCE> In addition: I see that avformat_find_stream_info() adds latency, because it buffers frames in the muxer, while finding these info. Is there a way to discard these frames (--> flush the buffer), after the infos are obtained, so to call av_read_frame only for the next frames? [14:24:50 CEST] <faLUCE> do I have to use custom I/O for that, or is there a function which I can easily call so tu flush the demuxer's buffer? [15:05:25 CEST] <superware> I have an h264 video over UDP (no container format), FFmpeg can decode it without problem but when I try to copy the stream to an mp4 output file with av_interleaved_write_frame, the mp4 is being played at once without any timing, I guess this is since all packets have AV_NOPTS_VALUE for pts and dts. any ideas how to workaround this? [15:09:00 CEST] <DHE> a couple of things to try. force your own framerate with -r on the input stream [15:13:09 CEST] <superware> I'm using the ffmpeg library directly, not through ffmpeg.exe :| [15:16:27 CEST] <JEEB> so what is actually getting written in as timestamps? [15:16:30 CEST] <JEEB> have you checked? [15:16:42 CEST] <JEEB> L-SMASH's boxdumper f.ex. can do it [15:16:47 CEST] <JEEB> `boxdumper --box file` [15:16:56 CEST] <JEEB> (and use less or something else to scroll it) [15:19:25 CEST] <superware> well, if the packet I'm writing using av_interleaved_write_frame has AV_NOPTS_VALUE for pts/dts, and when I play the mp4 (through ffplay, VLC, Windows Media Player) it renders all frames at once (no timing) so I guess pts/dts are actually written as AV_NOPTS_VALUE [15:19:52 CEST] <JEEB> I don't think that's valid [15:19:55 CEST] <superware> unfortunately I don't what's L-SMASH/boxdumper, I'm on Windows [15:20:17 CEST] <JEEB> L-SMASH is a project and boxdumper is an app [15:20:57 CEST] <superware> I guess I need to generate pts/dts? but how? the input time_base is 1/90000... [15:26:37 CEST] <faLUCE> superware: do you use the libav library? [15:26:44 CEST] <superware> yep [15:27:33 CEST] <BtbN> thebombzen_, nvenc hevc is from my experience not much better than nvenc h264. [15:27:55 CEST] <thebombzen_> I've found it's a bit better [15:27:58 CEST] <thebombzen_> one primary advantage is it supports 10bit precision [15:28:13 CEST] <thebombzen_> which is useful for 3d video game recordings [15:28:18 CEST] <BtbN> on pascal, h264 should as well? [15:28:32 CEST] <BtbN> it will probably internally downsample to 8bit though [15:28:43 CEST] <thebombzen_> yea, and that defeats the whole point [15:29:05 CEST] <BtbN> But games usually don't product 10bit output anyway [15:29:28 CEST] <thebombzen_> they don't. I'd upscale it first [15:29:43 CEST] <BtbN> But what's the gain of it then? [15:29:48 CEST] <thebombzen_> compression ratio [15:30:09 CEST] <thebombzen_> same reason I'd want to use hevc in the first place [15:30:34 CEST] <BtbN> it shouldn't be terribly hard to add it to OBS, can be treated mostly the same as h264 [15:30:48 CEST] <BtbN> 10bit might be more of a problem though [15:30:49 CEST] <thebombzen_> I agree, but I don't know c++ or c [15:31:32 CEST] <thebombzen_> otherwise I might try that out myself [15:31:47 CEST] <thebombzen_> although I also don't program for Windows and I only use OBS on win [15:32:12 CEST] <thebombzen_> but yea, upscaling 8->10 and then using dct-based lossy encoding, and then having the decoder go from 10->8. [15:32:19 CEST] <thebombzen_> for some reason it actually improves the compression ratio [15:32:45 CEST] <BtbN> you can just feed nvenc 8bit content, and tell it to encode 10bit i believe, not 100% sure though [15:32:56 CEST] <thebombzen_> I don't think nvenc has an upscaler [15:33:02 CEST] <thebombzen_> I think I have to feed it yuv420p10le [15:33:16 CEST] <BtbN> P010 is the native and preferred format [15:33:46 CEST] <thebombzen_> what even is p010le [15:33:55 CEST] <BtbN> nv12 for 10bit [15:33:57 CEST] <thebombzen_> is that like nv12 but for 10bit? [15:33:59 CEST] <thebombzen_> oh okay ninjad [15:34:26 CEST] <BtbN> if you go for 12 bit, things get more fun. As the pixel format nvenc wants is not supported by ffmpeg [15:34:39 CEST] <BtbN> but a 16bit format with the 4 other bits left empty matches perfectly [15:35:38 CEST] <thebombzen_> it supports yuv444p16le apparently [15:35:55 CEST] <BtbN> yes, but it will do 12bit encoding [15:35:59 CEST] <BtbN> and just ignore the 4 lsb [15:36:13 CEST] <thebombzen_> the real issue here is more that OBS doesn't support a replay buffer outside of simple mode [15:36:22 CEST] <thebombzen_> which is what I want [15:36:31 CEST] <BtbN> It really can't, when it hands of to ffmpeg [15:36:43 CEST] <BtbN> but you should be able to build one yourself [15:36:49 CEST] <thebombzen_> hm? [15:36:53 CEST] <BtbN> just use the segment muxer and tell it to overwrite/delete old segments [15:37:35 CEST] <thebombzen_> ah I didn't think about that. but I'd have to do something funny [15:37:36 CEST] <BtbN> Or am I misunderstanding what the replay buffer does? Basically hold the last X seconds in a buffer, and copies them to disk on the press of a button [15:37:43 CEST] <thebombzen_> it does exactly that [15:37:57 CEST] <BtbN> yeah, segment muxer like that, and some script that copies the segments on a hotkey [15:38:14 CEST] <faLUCE> I tried this: http://dranger.com/ffmpeg/tutorial02.c for demuxing and playing a http h264 mpegts live stream, and I don't have latency at all, If I use ffplay, with -fflags nobuffer, I still have some (small) latency. Why ? [15:38:23 CEST] <thebombzen_> the issue with the segment muxer's "overwrite" option is write after the overwrite you end up with basically no data [15:38:37 CEST] <thebombzen_> so if that's the time you choose to save, you end up sad [15:38:50 CEST] <BtbN> you'd have to implement a delay, so on hotkey press, it waits one segment length before copying [15:38:58 CEST] <thebombzen_> which is one minute [15:39:01 CEST] <BtbN> and ignores the latest segments, as it's incomplete [15:39:11 CEST] <BtbN> why would you use one minute segments? [15:39:18 CEST] <BtbN> Just use something short, like a few seconds [15:39:22 CEST] <thebombzen_> because that's the length of the replay buffer [15:39:32 CEST] <thebombzen_> at least as I like it [15:39:34 CEST] <BtbN> you use way shorter segments [15:39:39 CEST] <BtbN> one segment = one gop [15:39:49 CEST] <BtbN> and keep as many segments as you want in your replay buffer [15:40:01 CEST] <BtbN> the length of all segments you keep is the length of your replay buffer [15:40:19 CEST] <thebombzen_> that doesnt' quite mimic the functionality of the replay buffer [15:40:25 CEST] <BtbN> it does? [15:40:35 CEST] <thebombzen_> because the replay buffer stores the last X seconds and if I hit a hotkey it'll dump it to a .ts file named with the timestamp [15:40:41 CEST] <thebombzen_> and if I just keep playing I can do it again [15:40:45 CEST] <BtbN> yes [15:40:51 CEST] <thebombzen_> whereas the segment muxer doesn't let me do that sort of differentiation [15:40:54 CEST] <BtbN> you do the 4 seconds segments for a minute or two [15:41:10 CEST] <BtbN> and on hotkey, have some script copy the segments except for the latest one, and combine them [15:41:27 CEST] <BtbN> mimics the replay buffer perfectly [15:41:33 CEST] <thebombzen_> oh you're suggesting that I use something like autohotkey to run the script [15:41:54 CEST] <BtbN> if you use mpeg-ts, combining the segments is trivial for any scripting language [15:41:58 CEST] <thebombzen_> yea I use ts anyway [15:42:17 CEST] <thebombzen_> I don't know how to write windows scripts is the issue [15:42:59 CEST] <thebombzen_> I could probalby learn [15:43:06 CEST] <BtbN> download bash.exe, use bash :D [15:43:12 CEST] <thebombzen_> I normally do [15:43:14 CEST] <thebombzen_> it comes with git [15:43:26 CEST] <thebombzen_> but I don't know if that works with autohotkey [15:43:40 CEST] <BtbN> can probably do it entirely in an autohotkey script [15:43:59 CEST] <BtbN> never used that though [15:43:59 CEST] <thebombzen_> GOTO "I don't know how to write windows scripts" [15:44:25 CEST] <thebombzen_> but keep in mind that your suggested solution is to 1. set up the segment muxer to have GOP-sized segments last for 1 minute total and then start overwriting (which I don't know how to do) [15:45:03 CEST] <thebombzen_> 2. Download a third-party piece of software (e.g. AHK) that I can use to create a keybind, because the window manager doesn't support keybinds (unlike on Linux) [15:45:17 CEST] <thebombzen_> 3. with the keybind, run a shell (or other) script that I have to write myself [15:45:40 CEST] <thebombzen_> and all these together can allow me to use hevc instead of h264. It sounds like it's not worth it to me. [15:46:11 CEST] <thebombzen_> it sounds much easier to just allow NVENC's HEVC encoder in simple mode. I would submit a patch for that, but I don't know C/C++ [15:47:06 CEST] <BtbN> maybe just submit a bug to them? If it's simple, they might just add it [15:47:19 CEST] <thebombzen_> true. sounds like a plan [17:32:04 CEST] <Guest72238> hi [17:32:33 CEST] <Guest72238> i tried to compile ffmpeg for windows but i get "C compiler test failed." [17:36:20 CEST] <Guest72238> anyone there?? [17:38:09 CEST] <c_14> Guest72238: check the end of config.log [17:43:09 CEST] <Guest72238> WARNING: Unknown C compiler x86_64-w64-mingw32-gccgcc, unable to select optimal CFLAGS [17:44:45 CEST] <Guest72238> i know what i did wrong [17:45:42 CEST] <Guest72238> it should be -cross-prefix=x86_64-w64-mingw32- and not -cross-prefix=x86_64-w64-mingw32-gcc [17:51:25 CEST] <cryptodechange> dang [17:51:42 CEST] <cryptodechange> I encode something with the same settings but 1080 16:9 instead of cropped 800 [17:51:58 CEST] <cryptodechange> And the bitrate is 10mbit higher than my average encodes before it [17:52:26 CEST] <cryptodechange> Though I was using crf 15/16, as it's higher resolution I should really up it a bit more [17:53:30 CEST] <Guest72238> where do i put the frei0r.h [18:01:05 CEST] <c_14> Guest72238: anywhere in your include path [18:01:56 CEST] <Guest72238> sry but I'm pretty bad with linux [18:02:05 CEST] <Guest72238> where is the include path [18:02:42 CEST] <mdavis> Any of the folders in the PATH environment variable [18:02:49 CEST] <mdavis> echo $PATH [18:03:56 CEST] <mdavis> oh wait nvm [18:03:56 CEST] <BtbN> PATH hat nothing to do with includes [18:04:00 CEST] <BtbN> *s [18:04:19 CEST] <mdavis> yeah, zoned out on that one ;) [18:05:29 CEST] <mdavis> Guest72238: It would probably go somewhere like /usr/include or /usr/local/include [18:07:21 CEST] <mdavis> If you installed frei0r to a non-standard location, you'd have to configure FFmpeg with something like [18:07:44 CEST] <mdavis> --extra-cflags="-I/usr/local/whatever/include" [18:08:37 CEST] <mdavis> I haven't tried working with frei0r before, though, I know it has some quirks [18:09:05 CEST] <Guest72238> well i actually have not installed frei0r [18:09:15 CEST] <Guest72238> i'm going to disable it [19:07:31 CEST] <livingbeef> Would it be possible to have overlay pattern repeated over the whole width and height of the original video? [19:20:47 CEST] <james9999> by the way [19:20:59 CEST] <james9999> any idea how to stream youtube with youtube-dl and ffmpeg on windows? [19:21:09 CEST] <james9999> i would try piping in linux but i'm not sure it works [19:21:47 CEST] <BtbN> you want to stream to youtube? [19:21:53 CEST] <james9999> no from [19:22:02 CEST] <james9999> my xbox auto selects the res to the lowest one [19:22:08 CEST] <james9999> but i can fix that by streaming youtube to it from my pc [19:22:16 CEST] <james9999> but as of now i can only do it for files on my hard drive [19:22:19 CEST] <BtbN> Why not watch youtube on your PC then, when you need it anyway? [19:22:39 CEST] <james9999> cause my pc isn't a big 50 inch screen tv with surround sound and comfy sofas. :D [19:22:53 CEST] <BtbN> But you can connect it to a TV [19:22:55 CEST] <furq> youtube-dl -o - [19:23:10 CEST] <james9999> furq: that pipes to stdout? [19:23:14 CEST] <furq> yes [19:23:22 CEST] <BtbN> connecting your PC to the TV seems like way less of a hassle than that [19:23:24 CEST] <james9999> ok. i'm probably screwed on windows then [19:23:29 CEST] <james9999> even though i have yotuube-dl and ffmpeg for windows [19:23:31 CEST] <furq> piping works on windows [19:23:42 CEST] <james9999> eh [19:23:49 CEST] <james9999> I know io redirect like < or > works [19:24:14 CEST] <james9999> like if I open an MSYS shell? [19:34:02 CEST] <james9999> also in this line of output is bitrate the total bitrate or just the bitrate of the video frame? [19:34:04 CEST] <james9999> frame= 891 fps= 30 q=29.0 size= 1273kB time=00:00:29.23 bitrate= 356.9kbits/ [19:43:17 CEST] <cryptodechange> At crf=15 1920x800 I'm getting ~12mbit/sec, but 1920x1080 i'm getting 20-22mbit [19:43:18 CEST] <cryptodechange> madness [19:44:02 CEST] <cryptodechange> Two different sources of coursew [19:46:30 CEST] <furq> yes, crf 15 is madness [19:47:22 CEST] <cryptodechange> It's normal to scale the crf down for lower resolutions right? [19:47:29 CEST] <furq> if by down you mean up then yes [19:47:40 CEST] <furq> oh nvm you said lower [19:47:46 CEST] <furq> 1080p is not "lower resolutions" [19:48:13 CEST] <cryptodechange> So eg. if I was using crf=15 for 1920x800, crf=14 for 720p, 13 for 480p or whatnot [19:48:37 CEST] <furq> i mean if you're going to use such stupid crf values then you might as well just remux the bluray [19:48:58 CEST] <cryptodechange> Why? I went from 30gb to 12gb [19:49:13 CEST] <furq> didn't you say half of that was audio [19:49:48 CEST] <cryptodechange> One film was 12gb, one was 16gb, I think the larger one was TrueHD [19:51:42 CEST] <cryptodechange> 1920x800 vs. 1920x1080p is 530k more pixels 26% more [19:52:38 CEST] <cryptodechange> I don't think applying that to CRF would make sense (in this case, crf=20) [19:53:29 CEST] <furq> i use 21 for 720p and up [19:59:27 CEST] <cryptodechange> If you were encoding 480p content, would you apply the same crf? [20:04:05 CEST] <BtbN> either you want a certain quality, or you don't [20:06:16 CEST] <furq> i use 20 for sd stuff [20:06:19 CEST] <furq> or 19 for stuff i care about [20:15:51 CEST] <Dresk|Dev> I had a question about 3.3 regarding Android - does this version provider hardware decoding with the result being a texture, as opposed to an overlay? [21:14:49 CEST] <alexpigment> does anyone know if it's possible to add chapters to an MKV when encoding it in FFMPEG, or is MKVMerge necessary for that functionality? [21:17:04 CEST] <durandal_1707> alexpigment: there is support via api [21:17:16 CEST] <alexpigment> so not via the command line? [21:17:32 CEST] <durandal_1707> check if fffmpeg have option for this [21:17:40 CEST] <furq> you can do it with -metadata iirc [21:18:23 CEST] <alexpigment> that's good to know. everytime i search on google i get results for mkvmerge [21:18:34 CEST] <faLUCE> I have to make a simple player for http+mpegts+h264 and AAC. I could start from demuxing_decoding.c, but I wonder if is there any wrapper lib for ffmpeg + sdl [21:18:44 CEST] <furq> alexpigment: https://www.ffmpeg.org/ffmpeg-formats.html#Metadata-1 [21:19:03 CEST] <furq> you might be better off using mkvmerge because -metadata doesn't support any chapter file format that anything else uses [21:19:43 CEST] <furq> actually i might have a script somewhere that converts ogm chapters to ffmetadata [21:20:25 CEST] <alexpigment> ogm chapters are for MKV? [21:20:28 CEST] <faLUCE> what about this? [21:20:29 CEST] <faLUCE> https://github.com/wang-bin/QtAV [21:20:35 CEST] <furq> alexpigment: it's just a common chapter file format [21:21:03 CEST] <alexpigment> gotcha. i'm a bit green on chapters tbh [21:22:41 CEST] <alexpigment> well, i'll do some testing with this metadata option to see how well-supported the resultant files are [21:23:13 CEST] <faLUCE> I need a minimal audio/video player source code... is there any? [21:24:17 CEST] <furq> alexpigment: it shouldn't make any difference to the player [21:24:33 CEST] <furq> you're not actually muxing in a chapter file [21:25:01 CEST] <alexpigment> oh, that's what you meant about metadata not supporting the chapter file formats [21:25:08 CEST] <alexpigment> i'm going to be specifying custom chapter points [21:25:26 CEST] <furq> if you're specifying them by hand then ffmetadata is fine [21:25:44 CEST] <alexpigment> ok cool [21:25:46 CEST] <furq> it's just annoying because no tool that exports chapter files supports that format [21:26:08 CEST] <alexpigment> yeah, not a biggie for me. i'm not ripping movies from discs or anything [21:26:31 CEST] <alexpigment> but given that i am just specifying time stamps and nothing else, is there an even simpler method than metadata? [21:26:47 CEST] <furq> that's the only way i know of to do it with ffmpeg [21:26:50 CEST] <alexpigment> k [21:27:01 CEST] <alexpigment> i was hoping to avoid writing a file out for the metadata, but it's fine [21:40:56 CEST] <alexpigment> that seemed to do the trick. thank you very much [21:41:10 CEST] <alexpigment> (furq, i mean) [22:42:47 CEST] <james999> furq you said h265 isn't mature yet [22:43:00 CEST] <james999> does that basically mean people figure out better ways to optimize it [22:43:06 CEST] <james999> until it's as fast as libx264 is now? [22:43:27 CEST] <james999> IOW the underlying file format stays the same, but the encoding and decoding improve [22:43:37 CEST] <BtbN> h265 is a finalized standard, the format itself won't change [22:44:36 CEST] <furq> 21:43:27 ( james999) IOW the underlying file format stays the same, but the encoding and decoding improve [22:44:39 CEST] <furq> yes [22:44:50 CEST] <furq> this is the case with all codecs [22:45:35 CEST] <furq> the standard is finalised and then people figure out increasingly efficient ways of making something that conforms [22:46:15 CEST] <furq> x264 is probably the most developed encoder of all time [22:46:35 CEST] <furq> so it's no surprise that an encoder with a much less open development model for a much newer standard isn't quite there yet [22:46:40 CEST] <furq> even if the standard has greater potential [22:46:40 CEST] <BtbN> I haven't actually benched x264 on this box [22:47:05 CEST] <james999> maybe that's what confused me [22:47:19 CEST] <james999> the part where you said it has greater potential, just noone has optimized it to that level yet [22:47:35 CEST] <BtbN> you're probably confusing h265 with x265 [22:47:39 CEST] <furq> yeah [22:47:45 CEST] <furq> h265 is the codec, x265 is the encoder [22:47:55 CEST] <furq> the codec is a standard, that doesn't change [22:48:09 CEST] <james999> ok [22:48:22 CEST] <james999> but how do you know it will eventually be faster than current codecs? [22:48:29 CEST] <BtbN> it will never be faster [22:48:32 CEST] <furq> i didn't say it would [22:48:36 CEST] <furq> and yeah it probably won't [22:48:40 CEST] <furq> h265 is much more complex [22:48:40 CEST] <alexpigment> there should be an asterisk by "that doesn't change". it's likely that we'll see a lot of amendments and revisions [22:48:45 CEST] <furq> it'll be faster than it currently is [22:49:01 CEST] <BtbN> x265 is real-time capable now, which is already a huge step up [22:49:09 CEST] <furq> it has greater potential for compression [22:49:11 CEST] <BtbN> at least on 1080p [22:49:15 CEST] <alexpigment> BtbN - on what hardware? [22:49:20 CEST] <BtbN> Ryzen [22:49:24 CEST] <furq> particularly at 1440p, 4k etc [22:49:39 CEST] <alexpigment> 1080p on Ryzen is realtime, which means it won't be realtime on laptop hardware for years [22:50:02 CEST] <BtbN> Don't really see a point in real time encoding h265 though [22:50:03 CEST] <james999> by laptop do you mean desktop? [22:50:05 CEST] <alexpigment> most laptops are still shipping with 2core/4thread CPUs :( [22:50:14 CEST] <furq> ryzen is desktop [22:50:27 CEST] <furq> the server zen cpus will have different branding [22:50:36 CEST] <furq> and they also don't exist yet [22:50:53 CEST] <BtbN> They won't have any issues with hevc in realtime though, with their 32 cores [22:51:15 CEST] <alexpigment> james999: yeah, i meant laptop. i'm contrasting ryzen desktop (8core/16threads) with current laptop hardware (2core/4threads or sometimes 4core/8threads) [22:51:32 CEST] <furq> is realtime x265 a big step up over nvenc [22:51:42 CEST] <furq> i'd have thought you'd have to fuck up the quality quite a lot to get 30fps out of it [22:52:02 CEST] <alexpigment> nvenc is actually pretty nice for H.265 [22:52:33 CEST] <alexpigment> i mean it wins easily (i can't stress this enough) on speed. and x265 isn't optimized enough at this point to really take nvenc to school on quality [22:52:51 CEST] <alexpigment> granted, i've done a lot of benching on speed, and not as much on quality [22:52:59 CEST] <furq> that is all true but i was under the impression that x264 still easily beats nvenc-hevc [22:53:13 CEST] <alexpigment> that may be true, but it's also true for x264 vs x265 [22:53:33 CEST] <furq> probably at realtime, yeah [22:53:40 CEST] <alexpigment> i don't actually know for sure how x264 compares to 1000-series nvenc though on quality [22:53:41 CEST] <furq> but x265 can at least get compression gains [22:54:08 CEST] <furq> i also don't see the point of realtime hevc though [22:54:35 CEST] <alexpigment> well if streaming needs to be done, you'd need to do it realtime [22:54:46 CEST] <alexpigment> (this is theoretical, obviously) [22:55:00 CEST] <alexpigment> and if you want to do broadcasting, you'd need to do it in realtime [22:55:04 CEST] <furq> sure, but why would you want to stream hevc in 2017 [22:55:20 CEST] <alexpigment> because you're bandwidth-limited and you're trying to do 4k? [22:55:49 CEST] <alexpigment> not really saying i believe people should be streaming HEVC in 2017, but without being able to encode in realtime, you'll never be able to stream in realtime [22:55:56 CEST] <furq> that seems unlikely, but i guess it is a reason [22:55:57 CEST] <alexpigment> or broadcast in realtime [22:56:33 CEST] <furq> i guess it's a chicken and egg thing [22:56:38 CEST] <alexpigment> right [22:56:44 CEST] <furq> it has no utility right now, but if it's not possible then nobody's going to build anything that makes it useful [22:56:56 CEST] <alexpigment> that's the point i was trying to make, although you said it more eloquently ;) [22:57:14 CEST] <furq> that's me baby [22:57:22 CEST] <alexpigment> ol' eloquent furq [22:57:24 CEST] <furq> rephrasing your points and taking the praise [22:57:36 CEST] <alexpigment> you're living the life, man [23:21:57 CEST] <faLUCE> I need a minimal audio/video player source code with libav... is there any? [23:27:55 CEST] <BtbN> ffplay? [23:28:05 CEST] <faLUCE> BtbN: the code is too long [23:28:19 CEST] <BtbN> well, it's the most minmal you got [23:28:50 CEST] <faLUCE> BtbN: I found this: http://dranger.com/ffmpeg/tutorial02.c, it is good for video only [23:29:04 CEST] <faLUCE> so I need something like that, but for audio+ video [23:29:15 CEST] <faLUCE> ffplay is too long [23:35:39 CEST] <iive> there must be examples in ffmpeg source... maybe in docs? [23:36:02 CEST] <james999> there's an ffmpeg tutorial? o_0 [23:36:23 CEST] <faLUCE> iive: could not find it [23:36:26 CEST] <BtbN> There are tons of things that call themselves tutorial.. [23:36:33 CEST] <BtbN> Most of them are outdated and/or bad [23:37:21 CEST] <james999> yeah too bad there's not a website that tries to be a sort of hub for high quality guides and tutorials [23:37:33 CEST] <james999> a linux documentation project, if you will. XD [23:37:35 CEST] <iive> faLUCE: ffmpeg-src/doc/examples/ [23:37:43 CEST] <faLUCE> iive: please [23:38:26 CEST] <faLUCE> anyway, I posted updated examples to the mailing list and they have not been accepted, even if they are judged well coded and working [23:39:00 CEST] <faLUCE> there's a really bad aptitude from the libav developers to provide examples. [23:39:08 CEST] <faLUCE> even to accept them [23:39:28 CEST] <iive> faLUCE: link to the mail thread? [23:39:34 CEST] <james999> well faLUCE what can I tell you, sometimes the international illuminati just end up keeping you down [23:39:50 CEST] <alexpigment> haha [23:40:55 CEST] <faLUCE> iive: http://ffmpeg.org/pipermail/ffmpeg-devel/2017-March/209448.html [23:41:15 CEST] <faLUCE> then I stopped contributing [23:42:54 CEST] <iive> faLUCE: just bump the thread, do you want me to do it? [23:43:27 CEST] <BtbN> also, ffmpeg is still not libav. [23:44:13 CEST] <iive> :) [23:44:22 CEST] <faLUCE> iive: what does "bump" mean? (forgive my english) [23:45:16 CEST] <iive> faLUCE: ask about the status of the patch. e.g. michael might want to give time for other developers to nitpick your code, nobody finds anything to comment, patchs got forgotten. [23:46:17 CEST] <iive> ask about the status of the patch, since nobody objected, it have a silent aproval and should be committed. [23:46:25 CEST] <iive> michaelni: ^ [23:46:41 CEST] <faLUCE> iive: to be honest I'm a bit discouraged about that. So I left that stuff in the limbo. some people were very polemic with it, saying that "it doesn't add useful thing" (which is cleraly false: you can judge yourself the code) [23:47:21 CEST] <faLUCE> iive: what I suggest you is to read and try the code, and if you judge it worthwile, then bump it yourself [23:47:37 CEST] <faLUCE> because I've not been listened [23:48:28 CEST] <iive> yeh, recently there have been a bunch of nay sayers... [23:48:43 CEST] <furq> where did people say it didn't add anything useful [23:48:56 CEST] <faLUCE> furq: in the #ffmpeg-devel chat [23:49:00 CEST] <iive> probably irc [23:49:05 CEST] <furq> oh [23:50:16 CEST] <faLUCE> I don't want to appear conceited, but the code seems clear and it explains how to do useful things (you can read the comments) [23:51:13 CEST] <faLUCE> I prepared other snippets as well (for other useful things, like rtp, live grabbing etc.), but after these comments on the irc channel I left all [23:51:20 CEST] <furq> well the question is whether it adds anything over encode_audio.c [23:51:45 CEST] <furq> and also whether it omits anything potentially useful that encode_audio.c does [23:51:49 CEST] <faLUCE> furq: " [23:51:51 CEST] <faLUCE> It can be adapted, with few changes, to a custom raw audio source (i.e: a live one). [23:51:52 CEST] <faLUCE> + * It uses a custom I/O write callback (write_adts_muxed_data()) in order to show to the user [23:51:52 CEST] <furq> because if it doesn't then it should replace it if it's better [23:51:54 CEST] <faLUCE> + * how to access muxed packets written in memory, before they are written to the output file. [23:51:55 CEST] <faLUCE> " [23:52:33 CEST] <faLUCE> the code was intended for showing how to make a COMPLETE pipe from a live source [23:53:18 CEST] <faLUCE> and it's coded in a strictly sequential form, so to have readable "blocks" in this pipe [23:53:42 CEST] <faLUCE> instead of splitting it into unreadable functions which force the user/reader to jump from one line to another [23:54:43 CEST] <faLUCE> in addition, AAC needs to be muxed [23:54:53 CEST] <faLUCE> which is not included in "encode_audio.c" [23:55:41 CEST] <faLUCE> in addition, it explains how to manage the muxed packets with a custom I/O, which is useful if you have to insert the code in your program [23:57:22 CEST] <faLUCE> anyway, after that, I wrote my own library: https://github.com/paolo-pr/laav [23:59:29 CEST] <faLUCE> in addition, they preferreed to leave some terrible examples (like: muxing.c, which is a complete disaster of code: just look at it. Or "demuxing_decoding.c"). Now: I don't want to be polemic, but these things really discourage people about contributing [23:59:44 CEST] <faLUCE> then I left my purposes. [00:00:00 CEST] --- Fri May 5 2017

1 0

ffmpeg-devel.log.20170503
by burek 04 May '17

04 May '17

[00:00:09 CEST] <jamrial> ok, thanks [00:03:03 CEST] <alevinsn> jamrial: btw, I don't think it matters for a 0/9 e-mail [00:03:38 CEST] <alevinsn> but you misspelled "dependencies" in this one and the earlier one :-) [00:04:30 CEST] <nevcairiel> those mails are just for the ML, not like anyone really cares [00:05:34 CEST] <jamrial> meh, that one is not going to be commited anyway :p [01:19:52 CEST] <alevinsn> btw, where is this channel publicly logged? [01:23:48 CEST] <wm4> http://ffmpeg.gusari.org/irclogs/ [01:48:14 CEST] <cone-155> ffmpeg 03James Almer 07master:b3570f03893c: avcodec/decode: also check for FF_CODEC_CAP_SETS_PKT_DTS in audio decoders [01:50:00 CEST] Last message repeated 1 time(s). [03:44:22 CEST] <jamrial> gcc 7.1 compiles ffmpeg just fine and passes fate on x86_64 linux [03:46:20 CEST] <cone-155> ffmpeg 03Carl Eugen Hoyos 07master:a75ef1506a62: lavc/jpeg2000dec: Fix jp2 inner atom size used for overread checks. [03:47:40 CEST] <wm4> jamrial: is 7.1 the first gcc 7 release? [03:50:00 CEST] <jamrial> wm4: yeah [03:50:25 CEST] <wm4> that's amazing then [03:51:00 CEST] <jamrial> starting with gcc 5 the first release is the .1, to help differentiate between development builds and releases [04:39:03 CEST] <rcombs> oh, TIL [04:40:09 CEST] <james9999> in linuxese isn't it odd numbered subversions are unstable and even numbers ones are stable? [04:40:22 CEST] <james9999> so it's the same thing there? [04:41:31 CEST] <jamrial> no [04:42:18 CEST] <wm4> I think nobody does that anymore [04:45:21 CEST] <james9999> according to wikipedia the linux kernel used to do that but doesn't anymore [04:45:26 CEST] <james9999> that's where I heard about it [04:45:50 CEST] <james9999> https://en.wikipedia.org/wiki/Software_versioning#Odd-numbered_versions_for… [04:57:28 CEST] <rcombs> node does something like that [04:58:40 CEST] <rcombs> hmm, is there an easy way to generate a stream with no packets in lavf? (trying to come up with a fate test that doesn't require a new binary sample) [05:06:12 CEST] <rcombs> alternately, what dir would it make sense to put a binary sample for MPEGTS, or general lavf behavior, in? [05:06:38 CEST] <rcombs> most of the dirs are named after either codecs or& where the samples came from, I guess? [05:29:35 CEST] <wm4> jkqxz: that was quite a lot of boilerplate refucktoring in the videotoolbox code... [05:30:02 CEST] <wm4> (regarding [PATCH] videotoolbox: add hwcontext support) [09:50:20 CEST] <ubitux> in an incoming merge, there is the introduction of an "avbuild" directory [09:50:28 CEST] <ubitux> is it ok to use "ffbuild"? [10:00:36 CEST] <durandal_170> wouldnt that causes issues later? [10:07:31 CEST] <ubitux> similar to avconv.c vs ffmpeg.c [10:10:13 CEST] <rcombs> does it matter if it's not user-visible? [10:10:23 CEST] <rcombs> (does it matter if it is?) [10:10:33 CEST] <rcombs> it's not like "av*" isn't used as a namespace in ffmpeg [10:10:50 CEST] <rcombs> probably wouldn't be that much work to change, but it'd be even less work to leave [10:11:46 CEST] <rcombs> (hot take: "ffmpeg" is a better name for a project than "libav", but "avconv" is a better name for a command-line tool) [10:12:02 CEST] <durandal_170> i dont care, [10:19:42 CEST] <atomnuker> ubitux: what's it for? [10:20:32 CEST] <ubitux> isolate random build files [10:22:23 CEST] <atomnuker> makefiles? [10:25:59 CEST] <atomnuker> anyway, I'd prefer ffbuild [10:50:59 CEST] <wm4> also config.log etc [12:13:32 CEST] <jkqxz> config.log moving isn't very nice. Everything else is good; tidies up some files you ~never look at. [12:15:17 CEST] <cone-092> ffmpeg 03Michael Niedermayer 07master:382b4fc9b5f3: avcodec/svq3: Increase offsets to prevent integer overflows [12:15:18 CEST] <cone-092> ffmpeg 03Michael Niedermayer 07master:48b311784417: avcodec/svq3: Reject dx/dy beyond 16bit [12:15:44 CEST] <jkqxz> wm4: Should we move the transfer-by-mapping into common code, then? (If the transfer function doesn't exist but map does, use it.) [12:17:37 CEST] <jkqxz> wm4: Wrt the type-mapping functions, elenril suggested a hwcontext error mapping function. Having type mapping like that could avoid adding the extra public symbols. [12:20:49 CEST] <wm4> jkqxz: sounds good, not sure what you mean by error mapping [12:22:31 CEST] <jkqxz> Something like "int av_hwdevice_error_string(AVBufferRef *device, char *buffer, size_t len, int error_code)". [12:23:39 CEST] <wm4> any relation o my patch? [12:23:42 CEST] <wm4> *to [12:25:43 CEST] <cone-092> ffmpeg 03Anton Khirnov 07master:45286a625c6c: h264dec: make sure to only end a field if it has been started [12:25:44 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:2584656106bf: Merge commit '45286a625c6ced1f5c4c842244cbb4509429abba' [12:25:56 CEST] <jkqxz> I was just thinking of it as inspiration for "enum AVPixelFormat av_hwdevice_image_type_to_pixfmt(not_sure_what_type_t something)" and reverse functions rather than adding the specific av_map_videotoolbox_format_to/from_pixfmt() public functions. [12:26:41 CEST] <jkqxz> Maybe it's a bit too clumsy to actually be useful. [12:27:04 CEST] <cone-092> ffmpeg 03Alexandra Hájková 07master:fa64aea12ee6: unary: Convert to the new bitstream reader [12:27:05 CEST] <cone-092> ffmpeg 03Alexandra Hájková 07master:00c72a1e01a9: mlp: Convert to the new bitstream reader [12:27:06 CEST] <cone-092> ffmpeg 03Alexandra Hájková 07master:fc322d6a7018: tta: Convert to the new bitstream reader [12:27:07 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:9d45454cd09a: Merge commit 'fc322d6a70189da24dbd445c710bb214eb031ce7' [12:27:24 CEST] <cone-092> ffmpeg 03Martin Storsjö 07master:a0c443a3980d: aarch64: vp9itxfm: Use the offset parameter to movrel [12:27:25 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:9f1bca4e6f90: Merge commit 'a0c443a3980dc22eb02b067ac4cb9ffa2f9b04d2' [12:27:59 CEST] <wm4> AVPixelFormat av_map_from_hw_format(AVBufferRef *device, AVPixelFormat format, uint64_t hw_format) maybe [12:28:11 CEST] <wm4> or void *hw_format [12:28:48 CEST] <cone-092> ffmpeg 03Ruta Gadkari 07master:5b26d3b789bd: nvenc: Update check for lookahead [12:28:49 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:bf0fde84d503: Merge commit '5b26d3b789bd19a32dbe1e9c7ccab9498de7ee9b' [12:29:21 CEST] <cone-092> ffmpeg 03Diego Biurrun 07master:f9edc734e0ca: ratecontrol: Drop xvid-rc-related struct members unused after a6901b9c6 [12:29:22 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:c3e08544100c: Merge commit 'f9edc734e0ca3f6ef06c1ad0bd2c19c0c66f1ffa' [15:25:27 CEST] <ubitux> 11096804340ac2cec37ef1bce828105bd0a7dfbe [15:25:28 CEST] <ubitux> why? [15:26:09 CEST] <JEEB> back to 2011 :D [15:29:40 CEST] <ubitux> it's full of random revert [15:30:26 CEST] <BtbN> "this breaks my workflow" [15:31:27 CEST] <nevcairiel> nice of him to elaborate =p [15:33:01 CEST] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-cvslog/2011-June/038509.html [15:33:20 CEST] <ubitux> i suppose it's about supporting running make into the lib subdir [15:33:37 CEST] <ubitux> which isn't supported anymore in ffmpeg, right? [15:34:09 CEST] <BtbN> it never was, but happened to work [15:34:13 CEST] <nevcairiel> does it work now? [15:34:26 CEST] <ubitux> (please tell me no) [15:36:03 CEST] <RiCON> nevcairiel: it works now, there's still the include ../config.mak [15:36:18 CEST] <nevcairiel> well just one line might not be enough to make it work =p [16:55:06 CEST] <cone-092> ffmpeg 03Diego Biurrun 07master:11a9320de547: build: Move build-system-related helper files to a separate subdirectory [16:55:07 CEST] <cone-092> ffmpeg 03Clément BSsch 07master:3f17751eeb7e: Merge commit '11a9320de54759340531177c9f2b1e31e6112cc2' [17:02:50 CEST] <ubitux> huh, we still have --enable-raise-major? [17:03:02 CEST] <ubitux> the shit is this fuck again? [17:27:51 CEST] <cone-092> ffmpeg 03Michael Niedermayer 07master:dec2fa8cc708: tools/target_dec_fuzzer: Use decoder and not codec_id as argument [22:43:30 CEST] <alevinsn> nevcairiel: you there? [23:20:41 CEST] <alevinsn> any way to run just a specific fate test? [23:22:07 CEST] <jkqxz> make fate-name-of-test [23:22:30 CEST] <jkqxz> Some groupings also work, like fate-h264. [23:23:04 CEST] <alevinsn> don't use SAMPLES= in that case? [23:23:31 CEST] <jkqxz> Um, probably? I always put --samples on my configure line, so don't think about it afterwards. [23:24:08 CEST] <alevinsn> ok, that worked [23:24:18 CEST] <wm4> without SAMPLES (and if no sample dir is configured) it will run only tests that don't require samples, AFAIK [23:27:52 CEST] <alevinsn> anyone here have any experience building on Windows with MSVC? [23:28:02 CEST] <alevinsn> I could swear that I got past this point in the past [23:28:10 CEST] <alevinsn> but when I use make fate (with or without SAMPLES) [23:28:16 CEST] <alevinsn> it is failing to build checkasm [23:28:21 CEST] <alevinsn> because of some missing __imp symbols [23:31:52 CEST] <alevinsn> anyone know why make fate rebuilds libavcodec, etc? [23:32:00 CEST] <alevinsn> why doesn't it just use the .dlls that are already built? [23:32:16 CEST] <wm4> maybe you changed the code? [23:32:21 CEST] <alevinsn> nope [23:32:34 CEST] <alevinsn> it generates .a files when I do make fate [23:32:38 CEST] <alevinsn> order was [23:32:50 CEST] <alevinsn> make testclean; make clean; make distclean; (probably overkill) [23:33:04 CEST] <alevinsn> ./configure ...; make V=1; make fate [23:33:09 CEST] <alevinsn> no changes to the code [23:33:34 CEST] <wm4> it does build some test programs over default make [23:33:51 CEST] <alevinsn> it wants a libavdevice.a file for some reason (static build, although I doubt it is truly static) [23:34:09 CEST] <alevinsn> but, you don't think it should be rebuilding the various shared libraries, right? [23:34:10 CEST] <nevcairiel> fate runs with shared libraries just fine, although sometimes needs a bit trickery to actually make it find the .dlls for some test programs [23:34:15 CEST] <nevcairiel> and no it wouldnt do such a rebuild [23:34:46 CEST] <alevinsn> on Windows, I've only ever seen it build libavdevice.a, libavfilter.a, etc [23:34:54 CEST] <alevinsn> after it successfully builds the DLLs [23:35:30 CEST] <J_Darnley> That's the gcc equivalent for the MSVC .lib files [23:35:36 CEST] <alevinsn> right [23:35:42 CEST] <alevinsn> but I'm not using gcc :-) [23:35:57 CEST] <alevinsn> here's an example command-line [23:35:58 CEST] Action: J_Darnley thinks he should be ignored [23:36:14 CEST] <alevinsn> skipping strip -wN ..@* tests/checkasm/x86/checkasm.o [23:36:14 CEST] <alevinsn> rm -f libavdevice/libavdevice.a [23:36:14 CEST] <alevinsn> lib -nologo -out:libavdevice/libavdevice.a libavdevice/alldevices.o libavdevice/avdevice.o libavdevice/decklink_common.o libavdevice/decklink_dec.o libavdevice/decklink_dec_c.o libavdevice/decklink_enc.o libavdevice/decklink_enc_c.o libavdevice/file_open.o libavdevice/lavfi.o libavdevice/utils.o [23:36:14 CEST] <alevinsn> : libavdevice/libavdevice.a [23:37:27 CEST] <alevinsn> one odd bit is that it is using lib instead of mslink [23:37:52 CEST] <alevinsn> and the other odd bit is that it wants .a files [23:38:03 CEST] <nevcairiel> if you build shared for msvc, you should probably also pass disable static just to make sure, msvc cant build both at the same time like gcc can [23:38:27 CEST] <alevinsn> I'm doing that [23:38:37 CEST] <alevinsn> ./configure --toolchain=msvc --enable-yasm --enable-asm --enable-shared --disable-static --enable-decklink --enable-libmfx --disable-nvenc --disable-cuda --disable-cuvid --disable-indev=gdigrab --disable-indev=vfwcap --disable-indev=dshow --extra-cflags=-arch:AVX2 [23:41:07 CEST] <nevcairiel> in any case to use fate from a shared build you need to install the binaries and make sure they are in the path, otherwise it wont be able to load the dlls [23:42:38 CEST] <alevinsn> yeah, I've done that, and it can find ffmpeg [23:42:47 CEST] <alevinsn> etc etc [23:42:54 CEST] <alevinsn> and run it [23:43:08 CEST] <alevinsn> by just invoking ffmpeg--but, still not sure what to do for the build failures [23:43:19 CEST] <alevinsn> have to go through--I'll see what I can figure out later, thanks [23:43:36 CEST] <nevcairiel> well it works just like expected here [23:44:42 CEST] <nevcairiel> configure --toolchain=msvc --enable-shared --prefix=/d/somedir/in/path && make && make install && make fate [23:44:46 CEST] <nevcairiel> no rebuiilds in static [23:46:56 CEST] <nevcairiel> in any case no reason to run fate in a shared build, its more effort either way with the installing and whatnot [23:48:10 CEST] <nevcairiel> oh i see whats going on, checkasm is special since it needs to access avcodec internal stuff to work [23:48:40 CEST] <nevcairiel> but the msvc shared builds objects are probably not quite compatible with that [23:48:46 CEST] <nevcairiel> ie. just run fate in static =p [23:49:04 CEST] <nevcairiel> (or well, skip checkasm anyway) [00:00:00 CEST] --- Thu May 4 2017

1 0

ffmpeg.log.20170503
by burek 04 May '17

04 May '17

[00:37:53 CEST] <kilobyte_> good evening everyone. Does anybody have an idea how to record a game which runs at 50 fps? I tried this, but it doesnt record all the frames, the replay is a VERY LITTLE jerky: ffmpeg -probesize 10M -rtbufsize 1500M -f dshow -i audio="virtual-audio-capturer" -acodec pcm_s16le -f gdigrab -framerate 50 -i desktop -vcodec libx264 -qp 0 -threads 0 -crf 0 -preset ultrafast -tune zerolatency output.mkv [00:38:25 CEST] <furq> don't use gdigrab [00:38:37 CEST] <furq> and also don't use -tune zerolatency if you're recording to a file [00:38:43 CEST] <furq> generally don't use it ever [00:39:21 CEST] <kilobyte_> I also have UScreenCapture, no joy with this either [00:39:23 CEST] <james9999> the ffmpeg doc suggests using gdigrab [00:39:32 CEST] <furq> where does it do that [00:40:16 CEST] <james9999> https://trac.ffmpeg.org/wiki/Capture/Desktop [00:40:33 CEST] <furq> that's the wiki, not the docs [00:40:58 CEST] <furq> it also suggests using dshow and then says "gdigrab also exists" as an afterthought [00:41:10 CEST] <furq> which seems about right because gdigrab is inherently slow [00:41:40 CEST] <furq> but yeah if you're capturing from a game under windows then OBS or something like that will probably do a better job [00:41:45 CEST] <james9999> It also mentions it here without any caution or proviso: https://www.ffmpeg.org/ffmpeg-devices.html [00:41:53 CEST] <BtbN> I wonder how hard a desktop duplication capture source would be [00:42:49 CEST] <furq> well yeah [00:42:58 CEST] <furq> https://www.ffmpeg.org/ffmpeg-codecs.html#libmp3lame-1 [00:43:04 CEST] <furq> that doesn't bother to mention that mp3 is shit [00:43:23 CEST] <furq> if you had warnings for every potential problem then the docs would be twice as dense as they are already [00:43:41 CEST] <james9999> well all I can say is when I was googling for desktop capture it's one of the first things I tried after reading about it in the documentation [00:43:49 CEST] <furq> well yeah it works [00:44:02 CEST] <furq> but if you can get a reliable 50fps capture of a game with it then you're very lucky [00:44:26 CEST] <furq> it's adequate enough for screencasts and stuff where there's very little movement [00:44:58 CEST] <james9999> so advice on getting a game capture at 50fps goes where? the wiki? [00:45:05 CEST] <furq> probably [00:45:30 CEST] <james9999> ok [00:45:33 CEST] <furq> ideally the OBS wiki because that's actually designed for doing this [00:46:18 CEST] <james9999> maybe. but screencasting is the reason I googled for ffmpeg in the first place [00:46:25 CEST] <james9999> so it's not exactly an uncommon use case [00:50:45 CEST] <BtbN> You want OBS for that [00:51:34 CEST] <james9999> BtbN: ironically that was the last program I downloaded. [00:51:57 CEST] <james9999> although with that pkt_size hack I did get streaming to work sort of with ffmpeg [02:57:02 CEST] <james9999> https://trac.ffmpeg.org/wiki/CompilationGuide/MSVC [02:57:02 CEST] <james9999> i'm trying to wrap my head around the idea of a c99-to-c89 converter. o_0 [04:01:18 CEST] <utack> who makes the docs on https://www.ffmpeg.org/ffmpeg-all.html ? [04:01:41 CEST] <utack> it seems like zscale "tin" also accepts smpte2084, just the the output [04:01:46 CEST] <utack> that is not documented [05:03:00 CEST] <c_14> utack: anyone who writes a patch and sends it to the mailing list [05:43:19 CEST] <james999> the last project mailing list I looked at every post was BUG or PATCH [05:43:25 CEST] <james999> is that typical? [05:43:51 CEST] <c_14> what else would be on it? [05:44:04 CEST] <james999> idk. discussion about what features to add or support? [05:44:29 CEST] <c_14> happens rarely, or on irc [05:44:41 CEST] <furq> non-contributors having interminable conversations about the future of the project [05:44:41 CEST] <james999> also several threads were just one person replying to themselves [05:45:03 CEST] <furq> or just bikeshedding in general [05:45:31 CEST] <furq> oh and also people signing their name and having a hilarious and clever quote afterwards [05:45:48 CEST] <furq> extra points if you've set up your mail client to randomly select a quote from a big list you compiled in 1993 [05:46:37 CEST] <furq> and then...footnotes [05:46:38 CEST] <james999> TIL Parkinson's Law of Triviality [05:47:26 CEST] <utack> c_14 allright [05:48:53 CEST] <james999> furq: lol at some point I stopped doing that because it got lame [05:49:01 CEST] <james999> or i just stopped caring, either way [05:49:13 CEST] <furq> it was always lame [05:50:05 CEST] <furq> i hope you mean the quotes and not the footnotes [05:50:06 CEST] <c_14> I'd totally throw a fortune here, but I don't want to install it so just imagine I did. [05:50:15 CEST] <furq> the footnotes transcend lameness [05:50:29 CEST] <furq> when you see a mailing list post with more than 10 footnotes...that's when you know this post is Worth Reading [05:51:04 CEST] <furq> especially when you see it go from [3] to [5] and realise that [4] is inside [3] [05:51:18 CEST] <james999> wow, wikipedia has an entire article discussing mailing list posting etiquette: https://en.wikipedia.org/wiki/Posting_style [05:51:42 CEST] <james999> also yes I mean quotes, Idk how the hell you would justify footnotes in email [05:51:50 CEST] <c_14> The number of people who get annoyed by bad posting style is non-negligible [05:51:53 CEST] <furq> i'm going to link that to some people who have extremely strong feelings about top posting and watch them get furious [05:51:55 CEST] <c_14> james999: I use them for links [05:52:08 CEST] <furq> using them for links is the only acceptable use for footnotes [05:52:24 CEST] <furq> i've seen many posts where the length of the footnotes exceeded the length of the post [05:52:32 CEST] <james999> ah ok. i sort of do that on facebook sometimes, putting the links at the end of a post instead of inline [06:05:50 CEST] <james999> on a completely different subject [06:05:58 CEST] <james999> I'm reading about the ffmpeg drama. pretty intense [08:22:35 CEST] <JC_Yang> do I need to use a lavf muxer to extract raw avc streams from a program stream? Do raw streams require a muxer? [10:02:30 CEST] <kerio> is decoding h264 a deterministic thing [10:02:46 CEST] <kerio> or will different decoders output different things [10:04:01 CEST] <JC_Yang> that depends [10:05:02 CEST] <JC_Yang> the decoders have flexibility to postprocess the decoded video [10:05:19 CEST] <JC_Yang> e.g [10:05:23 CEST] <kerio> yeah i guess [10:05:43 CEST] <kerio> there's multiple different raw videos that map to the same h264 encoding for obvious reasons [10:08:40 CEST] <JC_Yang> IIRC, there're other cases which the standard allow some sort of flexibility, while the decoder should maintain the major semantic of the bistream. [10:11:49 CEST] <jkqxz> The actual decoding of H.264 is completely deterministic - there is exactly one correct output for a given stream. (This is a requirement because you can refer to previous frames without accumulating error.) [10:12:37 CEST] <jkqxz> Decoders are allowed to postprocess the output to show something different to the user, but they must still store the correct output for use as reference. [10:16:38 CEST] <jkqxz> (There are some funny edge cases to that: you don't need to actually generate the correct output for frames which aren't referred to (e.g. you can ignore or replace the deblocking filter) - this is generally only an optimisation used to do less work in the decoder, though.) [10:17:18 CEST] <kerio> oh i see what you mean [10:17:45 CEST] <kerio> for all intents and purposes, the output that other frames refer to *is* the correct output [10:27:25 CEST] <termos> is it normal that right after running avcodec_open2 on my libx264 codec I get a time_base in AVCodecContext that's 0/2? [12:29:09 CEST] <alfal> Hi everyone! Anyone here with ffserver experience? Is it possible to have a single jpeg in the stream and then replace the jpeg at different times? For example a stream that always shows the latest picture taken. I'm very thankful! [12:47:03 CEST] <durandal_170> alfal: no [13:05:55 CEST] <faLUCE> hello. In order to demux a http mpegts stream, I tried "demuxing_decoding.c" example, even if it says that it works on files (and doesn't say anything about http streams). Anyway, It receives the stream and prints that the frames are decoded, but the resulting output file is not readable. What's wrong? Should I allocate two demuxers, instead of only one, or is it enough avformat_open_input(&fmt_ctx, "http://stream_url. [13:05:57 CEST] <faLUCE> ts", NULL, NULL) ? [13:49:16 CEST] <JEEB> faLUCE: I have no idea what you're expecting but as you can see a single open like that should get you the MPEG-TS demuxed [14:03:38 CEST] <ss23> Hi, I'm wanting to create a filter that operates on two input streams (two versions of the same original content) and will only pass frames through to output when the frame(s) selected are an I frame of one input, and a B frame of the other. So, compare frame 0 from both streams, and only pass it through if it's an I frame in video stream 1, and also a B frame in video stream 2 [14:04:21 CEST] <ss23> I'm thinking I could use eq somehow, but it only operates on a single frame at a time, so I can't figure out how to make an eq for each stream but only pass frames through if both eq's worked [14:35:35 CEST] <faLUCE> JEEB: then I should see the raw output file, but the player (ffplay) says it's corrupted... in addition, the demuxed packets doesn't have the size of encoded packets: the sizes are similar, but not the same [14:38:02 CEST] <Nacht> Anyone I can bother with some questions regarding H264 ? [14:38:11 CEST] <faLUCE> Nacht: just ask [14:38:26 CEST] <Nacht> What's the relationship between NALU: SPS and IDR ? [14:39:02 CEST] <hiihiii> hello [14:40:07 CEST] <hiihiii> I have made some gif files but discovered that they had the wrong dimensions (larger) [14:41:06 CEST] <hiihiii> I now want to take those gif files and convert them to the right dimensions but I'm concerned that they'll be "re-encoded" [14:42:02 CEST] <hiihiii> I've made them with palettegen/paletteuse [14:43:54 CEST] <BtbN> you can't resize stuff without re-encoding [14:44:10 CEST] <hiihiii> yes I now that [14:44:46 CEST] <Nacht> 2nd question I also have, how do you identify if a PID is for audio or video ? [14:45:10 CEST] <Nacht> based on the headers [14:45:28 CEST] <hiihiii> I just don't want the colors to degrade a 2nd time. [14:45:43 CEST] <BtbN> then encode from the original material again [14:46:05 CEST] <hiihiii> I wish I had the original inputs [14:46:26 CEST] <hiihiii> they were large in size, so I deleted them [14:47:03 CEST] <hiihiii> I won't be concerned if I had used the generic palette [14:47:58 CEST] <hiihiii> because the colors won't be altered by quantization [14:49:42 CEST] <hiihiii> since I used a custom palette, I believe some loss in color is inevitable [14:50:12 CEST] <BtbN> converting gif to gif should be lossless, if all involved parts are smart enough [14:50:50 CEST] <hiihiii> even if I generate a palette again. it will not be the same as the one generated from source input [14:50:55 CEST] <BtbN> but specially with scaling, which might create new intermediate colors, you can easily see a quality hit [14:51:18 CEST] <hiihiii> well I'm scaling down [14:51:19 CEST] <BtbN> There are only 255 colors already, no need to generate a palete [14:51:49 CEST] <hiihiii> umm I don't know [14:52:12 CEST] <hiihiii> tht would be the case for gif with a generic palette [14:52:36 CEST] <BtbN> hm? [14:52:46 CEST] <BtbN> A gif is paleted colors, 255 arbitrary colors. [14:53:12 CEST] <BtbN> So when converting gif to gif, there is no point in making a new palete, there are no new colors going to show up from anywhere [14:53:55 CEST] <hiihiii> but for a gif made with a custom palette, re-encoding will revert back to using a generic palette [14:54:10 CEST] <BtbN> there is no generic gif palette. [14:54:23 CEST] <BtbN> Every gif has its color palette embedded [14:54:32 CEST] <hiihiii> and that will swap any special colors with the preset ones [14:54:46 CEST] <hiihiii> but ffmpeg has one [14:55:02 CEST] <BtbN> there's no preset ones. It will figure out the best palete from the input [14:55:18 CEST] <hiihiii> http://blog.pkh.me/img/ffgif/default-palette.png [14:55:30 CEST] <hiihiii> I'm afraid you're wrong [14:55:52 CEST] <hiihiii> then what would be the use of palettegen and paletteuse filters ??? [14:56:09 CEST] <BtbN> to investigate a whole video for the best overall palette [14:56:23 CEST] <BtbN> instead of a single frame [14:56:48 CEST] <hiihiii> in other words create a palette of colors to get butter results [14:57:02 CEST] <hiihiii> I've made simple tests [14:57:21 CEST] <BtbN> I'm not sure what you are even trying to argue about. You don't seem to have a choice anyway [14:57:27 CEST] <hiihiii> of the same input and the difference is clear [14:57:52 CEST] <hiihiii> . [14:58:20 CEST] <BtbN> scaling the gif with the same palette should be ok [14:58:42 CEST] <BtbN> And running palettegen on the gif, I'd expect it to give you the original palette again [15:00:22 CEST] <hiihiii> maybe... [15:00:23 CEST] <hiihiii> I came here to ask whether I can or not suppress/tell ffmpeg to not look for any other palette because it's already exists inside the input file [15:01:00 CEST] <hiihiii> i not then my only choice is to use palttegen [15:01:05 CEST] <hiihiii> again [15:02:00 CEST] <BtbN> ffmpeg will decode the gif, and it will just be a normal RGB or YUV stream of frames then [15:02:16 CEST] <BtbN> Which just happens to only have the same 255 colors all over [15:02:46 CEST] <BtbN> the problem I see is that scaling it will most likely result in more/different colors [15:03:03 CEST] <BtbN> so generate the palette without scaling, and use it for the scaled version [15:03:18 CEST] <BtbN> and maybe try around a bit, might also look better if you generate a new one post-scaling [15:04:15 CEST] <hiihiii> okay thx that sounds good [15:08:53 CEST] <BtbN> Or just get the original material again... [15:09:16 CEST] <BtbN> If the original is huge, I'd imagine a gif of it to be even larger [15:12:09 CEST] <hiihiii> the original was a single file [15:12:35 CEST] <hiihiii> I trimmed multiple sections from it to gif [15:12:45 CEST] <hiihiii> anyway [15:13:02 CEST] <hiihiii> I tried doing what was suggested [15:14:42 CEST] <hiihiii> the result looks significantly worse. the palettes generated even have a large chunk of black at the bottom suggesting that there are some unused colors [15:16:37 CEST] <BtbN> some part of the chain is not smart enough for that special case then [15:16:42 CEST] <hiihiii> heck even without resizing the image there's some degradation in color [15:17:15 CEST] <BtbN> Is it using yuv as intermediate? [15:19:07 CEST] <hiihiii> I haven't specifyed the color format so it must be that of the source input or the ffmpeg default for gif [15:19:20 CEST] <hiihiii> the input is yuv420 [15:19:56 CEST] <BtbN> try forcing it to use rgb [17:02:32 CEST] <retroj> does ffmpeg have any sort of volume automation filter, whereby one could define when in an audio stream to raise and lower the volume? [17:06:51 CEST] <DHE> might dynaudnorm be in the ballpark? [18:24:50 CEST] <durandal_170> retroj: loudnorm also [19:09:38 CEST] <retroj> DHE, durandal_170: thank you [19:18:01 CEST] <b0bby__> Whats the best way to compile ffmpeg from their github repository then test it using a pre-written c program. Step by step instruction would help. I've tryed this before by myself but I always get gcc compiler errors when trying to test the libraries. Thanks for any help. [19:19:19 CEST] <DHE> like most linux apps from source, ./configure, make, and optionally make install. run configure --help to see what options are available. if you plan to install, consider using the --prefix option and related parameters [19:20:08 CEST] <james9999> i always get compiler errors when trying to compile things. so i gave up trying to compile things from websites. ^_^ [19:21:18 CEST] <b0bby__> Ok im going to recompile all the stuff from scratch. Does anyone have some test code I could use? [19:27:48 CEST] <DHE> there's a couple of sample apps in doc/examples if you really want to test the C interface [19:27:48 CEST] <DHE> of course, the ffmpeg CLI tool is already a C user of libav [19:28:31 CEST] <b0bby__> what does --prefix do? [19:28:59 CEST] <retroj> b0bby__: installation path. normally prefix is /usr/local or /usr [19:29:29 CEST] <DHE> some users like /opt/$packagename to keep per-applications apart, but then you have issues with $PATH and suck [19:29:30 CEST] <DHE> such [19:30:55 CEST] <b0bby__> ok I created the make file and set the prefix to a separate install directory [19:31:00 CEST] <b0bby__> Compiling now [19:33:51 CEST] <b0bby__> running make install [19:34:41 CEST] <b0bby__> ok now I have a folder that looks like: bin include lib share [19:42:42 CEST] <DHE> so ffmpeg should be in the bin directory, man pages in the share directory, and so on and so forth [19:48:23 CEST] <b0bby__> ok I tried to compile ffmpeg.c and got the errors: https://pastebin.com/Uwu45DtJ [19:59:23 CEST] <b0bby__> Anyone here? [20:09:19 CEST] <b0bby__> hello? [20:14:12 CEST] <tdr> b0bby__, your source is missing header files. libavutil/internal.h should be there when it unpacks but isnt [20:19:08 CEST] <b0bby__> libavutil/internal.h is there: https://gist.github.com/2432ec892159cf00ac0eca14c9a8f2bc [20:19:42 CEST] <tdr> ok line 12 of your paste [20:20:07 CEST] <tdr> its either not there or some env is off during your buikd [20:21:30 CEST] <b0bby__> tdr: what? [20:22:11 CEST] <tdr> b0bby__, just saying it cant find your header, so its either not there or its looking in the wrong place or you're building it weird. how you building it? [20:23:00 CEST] <b0bby__> gcc ffmpeg.c [20:23:13 CEST] <b0bby__> hold on Ill pint the forr folder layout [20:23:26 CEST] <tdr> omg really? [20:23:35 CEST] <tdr> have you ever compiled from source before? [20:24:20 CEST] <tdr> b0bby__, which OS platform are you compiling on? [20:29:02 CEST] <b0bby__> tdr: linux [20:29:14 CEST] <b0bby__> Here is a directory printout https://gist.github.com/5efcd8479df9224aa28ac62be1187014 [20:38:34 CEST] <tdr> b0bby__, you shouldnt be running gcc on it like that directly though. run ./configure --help (to look at switched), then ./configure then make and optionally make install [20:40:49 CEST] <tdr> b0bby__, you may need to download a bunch of packages with headers files (-dev / -devel) for your distro too, it depends what you already have and which switches you want to enable. [20:43:50 CEST] <kilobyte_> hey all, yesterday I asked, let me try again: how to record Windows desktop about 50-60 fps? I tried this: ffmpeg -probesize 10M -f dshow -rtbufsize 1500M -video_size 1920x1080 -rtbufsize 702000k -framerate 50 -i video="screen-capture-recorder":audio="virtual-audio-capturer" -vcodec libx264 -qp 0 -threads 0 -crf 0 -preset ultrafast -acodec pcm_s16le -tune zerolatency output.mkv but it doenst seem recording all the 50 frames, just abou [20:46:32 CEST] <b0bby__> Ok is their an easier way to do video converting or minor editing. ffmpeg is kicking up a fight and unless someone can help me step by step I need another way. [20:46:48 CEST] <tdr> b0bby__, most distros have a binary for it you can download [20:47:19 CEST] <tdr> b0bby__, even lastest versions. its common enough to build "newest version" that there's guides for building it for most distros too. [20:47:23 CEST] <furq> didn't you just say you built it [20:48:14 CEST] <dystopia_> he said "converting" not "compiling" which i guess he means encoding, [20:48:31 CEST] <furq> 18:33:51 ( b0bby__) running make install [20:48:31 CEST] <furq> 18:34:41 ( b0bby__) ok now I have a folder that looks like: bin include lib share [20:48:59 CEST] <tdr> furq, the errors from the pastebin were from from compiling, not an install phase [20:49:04 CEST] <dystopia_> ahh i joined after that, never mind then [20:49:33 CEST] <b0bby__> Tell me what to do and Ill do it. Anything to get this working [20:49:34 CEST] <tdr> b0bby__, which distro of linux are you on? [20:49:38 CEST] <b0bby__> mint [20:49:54 CEST] <tdr> b0bby__, sudo apt-get install ffmpeg [20:49:54 CEST] <furq> b0bby__: what are you actually trying to do [20:49:58 CEST] <furq> you already compiled ffmpeg [20:50:20 CEST] <tdr> furq, when i saw, he was running gcc on ffmpeg.c [20:50:32 CEST] <furq> yeah that's the bit i don't understand [20:50:51 CEST] <tdr> if it compiled before that prob just made a mess [20:51:00 CEST] <b0bby__> I want to develop a C/C++ program that has some video conversion/editing functionality [20:51:21 CEST] <tdr> b0bby__, ok did the apt-get command I gave you pull in ffmpeg? [20:52:18 CEST] <b0bby__> tdr yes [20:52:27 CEST] <furq> b0bby__: can you build the stuff in doc/examples [20:52:51 CEST] <furq> look at the makefile in there [20:53:45 CEST] <b0bby__> what should I link it to [20:54:34 CEST] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/doc/examples/Makefile [20:56:41 CEST] <b0bby__> furq: how can I tell make where my libs are installed [20:57:49 CEST] <b0bby__> furq never mind [21:00:09 CEST] <b0bby__> here are the errors from the compile with make decode_video.c: https://pastebin.com/t7DLTnqg [21:00:46 CEST] <furq> did you do the thing it tells you to do [21:07:06 CEST] <james9999> Perhaps you should add the directory containing `libavdevice.pc' [21:07:06 CEST] <james9999> to the PKG_CONFIG_PATH environment variable [21:08:38 CEST] <b0bby__> I got to go [21:08:53 CEST] <b0bby__> I'll try to comeback later to get this fixed [21:09:09 CEST] <furq> that boy ain't right [21:58:00 CEST] <reuf> hello - best resource to see overal a ilities of ffmpeg? [21:58:07 CEST] <reuf> i mean best book, tutorial [22:00:03 CEST] <james9999> i don't think anything like that exists reuf [22:00:28 CEST] <james9999> of course you're welcome to learn all about how ffmpeg works, then write the tutorial yourself and host it yourself. [22:01:20 CEST] <reuf> james9999, thanks [22:01:51 CEST] <james9999> well i was laying on the sarcasm a bit heavy there but np, glad to provide helpful-if-slightly-snarky answers [22:05:49 CEST] <llogan> reuf: there is a book, but it is not free and not from the FFmpeg developers: http://ffmpeg.tv/ [22:06:11 CEST] <llogan> otherwise see the FFmpeg Wiki http://trac.ffmpeg.org/ [22:06:18 CEST] <llogan> and of course the documentation [22:07:06 CEST] <reuf> llogan, thanks [22:14:26 CEST] <b0bby__> Hey I compiled ffmpeg and I'm trying to compile one of the examples (decode_video.c) with "gcc decode_video.c -L"/home/kitt/Documents/c programs/ffmpeg/ffmpeg build/install/lib" -lswscale -lavutil -lavformat -lavcodec". However I get the error: https://gist.github.com/5352e462633ad9b7410180102d9a8d37. Here is also a directory layout: https://gist.github.com/anonymous/497a407b6c15824fe9ea09a46dbe7d5b [22:14:35 CEST] <b0bby__> How do I fix this? [22:23:19 CEST] <b0bby__> ?? [22:26:52 CEST] <faLUCE> hey, I found this option: AVFormatContext->max_analyze_duration for minimizing the delay when playing a stream... do you know which is the corresponding option for ffplay ? [22:30:08 CEST] <faLUCE> I tried "-analyzeduration 100000" (0.1 seconds), but it did not improve.... (It improved with libav, though) [22:31:35 CEST] <furq> you need to set -probesize as well [22:31:58 CEST] <faLUCE> furq: do you mean that I have to set both? [22:32:14 CEST] <furq> that is normally what "as well" means [22:32:43 CEST] <faLUCE> furq: but I did not set both with libav, and it minimized the delay. Why do I have to set both with ffplay? [22:32:52 CEST] <furq> shrug [22:33:39 CEST] <faLUCE> furq: sorry for my poor english: does "shrug" mean, in this case, "I don't know" ? [22:36:33 CEST] <james9999> faLUCE: either that or the world is about to tumble off of Atlas's shoulders [22:36:37 CEST] <DHE> yes. a shrug is an action done with the shoulders [22:37:00 CEST] <faLUCE> ok, thanks [22:45:25 CEST] <vbgunz> hello fellas, I wrote a script a long time ago and it works great with a single monitor, but having a strange multi monitor setup, it gets crazy to just get coordinates or the name of a single screen. other than :0 for -i, is there a way to put the name of the screen I'm trying to capture? [22:47:50 CEST] <b0bby__> Hey I compiled ffmpeg and I'm trying to compile one of the examples (decode_video.c) with "gcc decode_video.c -L"/home/kitt/Documents/c programs/ffmpeg/ffmpeg build/install/lib" -lswscale -lavutil -lavformat -lavcodec". However I get the error: https://gist.github.com/5352e462633ad9b7410180102d9a8d37. Here is also a directory layout: https://gist.github.com/anonymous/497a407b6c15824fe9ea09a46dbe7d5b [22:47:50 CEST] <b0bby__> How do I fix this? [22:51:43 CEST] <jkqxz> b0bby__: You have the libraries in the wrong order, and you're missing at least m, dl and z. Just use pkg-config. [22:53:25 CEST] <b0bby__> jkqxz: how do I use pkg-config [22:56:18 CEST] <jkqxz> Which libraries are you actually using? libavcodec and libavutil? Put the output of "pkg-config --cflags --libs --static libavutil libavcodec" at the end of your command line. (May also need to set PKG_CONFIG_PATH if you've installed in a funny place.) [22:58:26 CEST] <b0bby__> https://gist.github.com/anonymous/ce3c0fc2a7dbe73c9936ab5ae85748e0 [23:07:38 CEST] <vbgunz> I'm sorry, is there a way to tell ffmpeg to record a particular monitor? I have several in very wild and different orientations and sizes. can I just just say record all of screen 1, 2 or 3? my $DISPLAY is always just :0, there is no 0.1, 0.2. [23:09:01 CEST] <BtbN> it's all one big rectangular screen [23:09:08 CEST] <BtbN> just need to give the right coordinates [23:12:30 CEST] <vbgunz> damn, that makes it crazy. is there a way to see what the coordinates already are? through trial and 20 minutes later I found 0.0+0,420 is what I needed for the main screen. damn if that's true [23:12:47 CEST] <BtbN> xrandr should show them I believe? [23:13:04 CEST] <vbgunz> I tried xrandr --query [23:13:27 CEST] <vbgunz> it shows my monitors but not their positions [23:14:21 CEST] <vbgunz> I mean, I can look deeper, maybe I'll find what I'm looking for in xrandr [23:14:38 CEST] <BtbN> It should print something like 1920x1080+1280+487 for each monitor [23:14:53 CEST] <BtbN> there you have its width/height and x/y offset, that's all you need for ffmpeg [23:15:17 CEST] <vbgunz> I wish, that would solve everything, I'm trying and --verbose is just nuts atm [23:15:34 CEST] <BtbN> xrandr prints that just fine for me, no idea what you are doing with it [23:17:42 CEST] <vbgunz> for me, xrandr prints 1920x1080+0+0 ... for the main horizontal screen. 1080x1920+1920+0 for the second vertical screen. but to get the first monitor right, I can't use just -i :0 ... these huge black bars surround the top, left and right sides of the video. I need to use 0.0+0,420 and it took me 20 minutes to find that out [23:18:17 CEST] <vbgunz> I'm not finding clues to get that correct the first time [23:19:05 CEST] <vbgunz> ffmpeg version 3.1.7, Fedora 25 [23:19:50 CEST] <BtbN> if xrandr does not print the correct layout, something is wrong [23:22:56 CEST] <vbgunz> tell me about it, everything is fine with a single monitor. having more than 1 enabled, it gets tough [23:25:59 CEST] <furq> if you have different vertical resolutions then the smaller ones will be centred relative to the biggest one [23:27:29 CEST] <furq> i'm guessing you have one 1920x1080 and one 1080x1920 [23:27:33 CEST] <vbgunz> 420+1080+420=1920, makes sense [23:28:54 CEST] <vbgunz> I know the tv I'm connected too is in a wild position atm, when it is enabled the overall area gets much larger and will probably making capturing the main monitor hell [23:38:40 CEST] <cryptodechange> What is the difference between deadzone 21,11 (default) and deadzone 6,6 (grain)? [23:39:35 CEST] <furq> nothing [23:40:25 CEST] <furq> the deadzone settings do nothing if trellis is enabled [23:41:18 CEST] <cryptodechange> TIL [23:42:14 CEST] <cryptodechange> I noticed the qcomp is increased too [23:42:16 CEST] <cryptodechange> from 0.6 to 0.8 [23:57:35 CEST] <vbgunz> out of nowhere :0+0,420 stopped working perfectly after spending time figurign it out and it has to be :0 again... monitor setup didn't change at all, still 2 monitors :( [23:59:05 CEST] <vbgunz> the only thing I did try was recording the second monitor and successfully doing so at 1080x1920 ... it's the only thing I did differently between all the recording [00:00:00 CEST] --- Thu May 4 2017

1 0

ffmpeg-devel.log.20170502
by burek 03 May '17

03 May '17

[00:56:37 CEST] <cone-651> ffmpeg 03Michael Niedermayer 07master:56ddb923c63f: tools/target_dec_fuzzer: Use avcodec_register_all() instead of register_all() [01:38:59 CEST] <cone-651> ffmpeg 03James Almer 07master:0a6ca7aa0aa1: avcodec/internal: update FF_CODEC_CAP_SETS_PKT_DTS doxy [01:51:40 CEST] <rcombs> so, what's "scan_all_pmts" actually supposed to do [01:54:53 CEST] <jamrial> rcombs: looks like some mpegts only thing that somehow made it to ffmpeg/ffplay/ffprobe [01:55:44 CEST] <rcombs> it seems to be the thing that makes avformat_find_stream_info take 5 or 7 seconds on live streams (indirectly) [01:55:52 CEST] <rcombs> and I don't understand quite what the purpose is [01:56:28 CEST] <rcombs> like, there's code in mpegts.c that _seems_ to be trying to tell find_stream_info to finish up when it thinks all streams have been found (by clearing AVFMTCTX_NOHEADER) [01:56:39 CEST] <james999> is that why there is 5 sec of delay when using ffmpeg to livestream to my xbox one? [01:56:51 CEST] <rcombs> but the command line tools set scan_all_pmts, which disables that code [01:56:53 CEST] <james999> I use -f mpegts and it's not live at all [01:57:08 CEST] <rcombs> james999: if you mean startup latency, yes [01:57:24 CEST] <rcombs> otherwise& maybe? There are a lot of possible factors there [01:57:32 CEST] <DHE> that sounds like a probing issue and may be indicative of ffmpeg having trouble finding all the codec parameters it wants. [01:58:00 CEST] <james999> can I tweak ffmpeg to get the latency minimal? my command is ffmpeg -re -i file.mp4 -vcodec libx264 -f mpegts udp://blahblah [01:58:37 CEST] <rcombs> find_stream_info continues probing for 5 seconds while AVFMTCTX_NOHEADER is set, even if all codec parameters are found [01:58:46 CEST] <rcombs> because it assumes more streams might show up during that time [01:59:27 CEST] <rcombs> mpegts.c sets AVFMTCTX_NOHEADER at startup, but has code to clear it "when all programs have received a PMT" [01:59:28 CEST] <DHE> that doesn't sound right. with mpegts you know you have everything once you have a PAT, all referenced PMTs, and info on all referenced streams. but that could take a while to measure since you need to wait for all of the above including keyframes in the UDP [01:59:50 CEST] <rcombs> but that code is disabled when the "scan_all_pmts" AVOption is set to 1 [02:00:01 CEST] <rcombs> and ffmpeg_opt.c (and ffprobe, etc) sets that option by default [02:00:10 CEST] <rcombs> I'm trying to understand why [02:00:31 CEST] <DHE> but this is in avformat_find_stream_info that takes 5 seconds, right? [02:01:10 CEST] <rcombs> yeah [02:03:22 CEST] <JEEB> that really sounds like full probing of all the streams [02:03:32 CEST] <JEEB> instead of trusting the PMT [02:06:21 CEST] <DHE> another possibility is huge keyframe intervals? stream probing needs a keyframe right? x264 defaults to -g 250 I think... [02:07:07 CEST] <JEEB> well that's what I mean with full probing. also it's time/data amount based, it won't even wait for an IRAP as far as I have seen [02:07:30 CEST] <JEEB> if you don't get the parameter sets within the alotted probing time it will just throw hands up [02:08:14 CEST] <DHE> ah, udp... [02:08:58 CEST] <DHE> I mean that whimsically... [02:41:35 CEST] <rcombs> looks like it was added by cehoyos in re: http://trac.ffmpeg.org/ticket/3762 [02:42:36 CEST] <rcombs> I think e971eef8 is bonkers [02:42:58 CEST] <rcombs> if we want scan_all_pmts to be on by default we should turn it on by default in mpegts.c [02:46:49 CEST] <rcombs> all documentation on the MPEGTS code seems to assume I know what all of the abbreviations mean [02:46:52 CEST] <rcombs> (I do not) [03:02:22 CEST] <DHE> what do you need to know? [03:05:28 CEST] <james999> Eh that's the first time in any software type channel somebody said that. XD [03:05:43 CEST] <james999> (well that I've seen lol) [03:30:27 CEST] <james999> idk i'm a novice and i never know where to start with source code and doc on projects [03:30:51 CEST] <james999> At least in channels like this you can talk to an actual person for a specific issue sometimes [08:51:08 CEST] <cone-552> ffmpeg 03Carl Eugen Hoyos 07master:20da4135020f: lavf/nutdec: Fix an impossible condition, regression since e0c53c34. [12:56:16 CEST] <robUx4> nevcairiel: do you know if we do any funky stuff with Win32 thread init ? [12:56:52 CEST] <robUx4> when I use more than one thread, I get some crashes in a VLC thread when doing D3D11 calls [12:57:22 CEST] <robUx4> with 1 thread (no pthread_frame involved) don't have any issues with the same VLC thread [12:58:06 CEST] <robUx4> ie that thread has nothing to do with avcodec and D3D11 is not known to libavcodec at all at this stage [12:58:37 CEST] <nevcairiel> never heard of any such things [12:58:54 CEST] <nevcairiel> only thing I know is that its best to avoid mixing native win32 threads and some sorts of pthread wrappers [13:00:26 CEST] <robUx4> libavcodec is using w32pthread.h which uses native win32 stuff [13:00:38 CEST] <nevcairiel> and vlc ? :) [13:00:45 CEST] <robUx4> they both use _beginthreadex() [13:01:02 CEST] <robUx4> vlc doesn't use pthread on windows [13:01:32 CEST] <robUx4> it's a crash in NVIDIA drivers, so not easy to understand why [13:01:49 CEST] <nevcairiel> an entirely unrelated thread crashing doesnt seem to make much sense to me, unless they both do call somewhat related things [13:02:32 CEST] <nevcairiel> (this is a good time to mention that I'm still not rather fond of mt-hwaccel use :p) [13:03:21 CEST] <robUx4> yes, it's rather odd [13:03:22 CEST] <nevcairiel> on that note, what version of avcodec are you using in this case? mt safety improvements have been made only recently [13:04:02 CEST] <robUx4> 57.92.100 [13:04:31 CEST] <robUx4> (I tried libav with the same result) [13:04:58 CEST] <nevcairiel> that should be recent enough [13:05:37 CEST] <robUx4> yes, we force a build using a recent enough version [13:06:38 CEST] <robUx4> basically lavc requests a frame to write to, we create a vout and do some D3D11 stuff [13:06:46 CEST] <robUx4> then boom [13:07:10 CEST] <robUx4> with 1 thread the frame request is in the decoder thread [13:07:23 CEST] <robUx4> with >1 thread the frame request is in a separate thread [13:07:39 CEST] <robUx4> the vout work is always in a separate VLC thread [13:07:47 CEST] <nevcairiel> i assume you enabled the d3d11 mt mode [13:08:02 CEST] <robUx4> at this stage lavc has no knowledge D3D11 will ever be used [13:08:32 CEST] <robUx4> I call ID3D10Multithread_SetMultithreadProtected(), yes [13:08:44 CEST] <nevcairiel> so it crashes before you ever give a frame to lavc? [13:08:48 CEST] <robUx4> yes [13:08:57 CEST] <nevcairiel> odd [13:09:34 CEST] <robUx4> I create my surfaces, I try to create decoder output views, boom [13:10:04 CEST] <robUx4> (usually the output views are created along while decoding but I moved it for testing) [13:12:21 CEST] <nevcairiel> one crazy idea, maybe that particular thread needs to call CoInitializeEx? the lavc threads definitely wouldnt have called that [13:12:56 CEST] <robUx4> I tried that with no effect [13:16:32 CEST] <robUx4> if I move ID3D10Multithread_SetMultithreadProtected sooner in the code it doesn't crash on the decoder output views creation and decoding works [13:16:50 CEST] <robUx4> it crashes on exit though... [13:23:14 CEST] <robUx4> ah no, it was remaining test code, so I guess the thread proctection is best set as soon as one creates the device [13:47:25 CEST] <KGB> [13FFV1] 15michaelni pushed 1 new commit to 06master: 02https://git.io/v94a8 [13:47:25 CEST] <KGB> 13FFV1/06master 14b15129d 15Jérôme Martinez: JPEG2000-RCT formula update... [16:22:22 CEST] <ubitux> jamrial: hey, cool stuff with the hevc parser [16:22:51 CEST] <ubitux> not sure if i can make any relevant review though [16:22:56 CEST] <jamrial> yeah, it was a fun weekend project [16:23:48 CEST] <JEEB> najs [16:23:53 CEST] <JEEB> yea, I read those in the train [16:24:24 CEST] <BtbN> hm, I wonder how hard it is to make ffmpeg a WebRTC peer [16:24:36 CEST] <BtbN> would be quite useful [16:25:01 CEST] <nevcairiel> from experience, those things are all riddled with weird complex shit =p [16:25:19 CEST] <BtbN> yes, the whitepapers I found for it are wtf complex [16:25:31 CEST] <BtbN> Even the official library for it is... weird [16:25:33 CEST] <BtbN> and C++ [16:27:55 CEST] <nevcairiel> jamrial: i assume you added the logctx on all the sei parsing functions just for consistency? most of them dont seem to use it [16:28:27 CEST] <wm4> any reason why they make it "weird complex"? [16:28:30 CEST] <wm4> *made [16:28:40 CEST] <BtbN> Because web 4.0 [16:29:26 CEST] <BtbN> https://webrtc.org/native-code/native-apis/ just look at all the fancy flowcharts... [16:30:48 CEST] <jamrial> nevcairiel: yeah, it was more automatic than intentional, so i'll remove it where it's not needed [16:31:27 CEST] <j-b> webrtc... [16:31:31 CEST] <j-b> that's scary [16:31:32 CEST] <nevcairiel> i dont particularly care, but its unlikely for existing sei functions to get new log calls [16:31:37 CEST] <nevcairiel> so might as well [18:27:58 CEST] <Mista_D> Is there a frame accurate "concat" version? If its in development, would there be anyway to bounty it? [18:29:47 CEST] <wm4> if you mean the concat demuxer, it can't be frame accurate [19:14:15 CEST] <cone-155> ffmpeg 03Thomas Mundt 07master:2da5bf4c2f4c: avfilter/interlace: add complex vertical low-pass filter [19:14:52 CEST] <kierank> 10:31 AM <"j-b> webrtc... [19:14:52 CEST] <kierank> 10:31 AM <"j-b> that's scary [19:14:58 CEST] <kierank> yes and people want to use it for video [19:15:04 CEST] <kierank> that's not just web conversations [19:26:06 CEST] <ubitux> jamrial: why are you dropping md5 include from hevcdec.h? it seems you still use AVMD5 [19:26:26 CEST] <ubitux> i suppose it doesn't break checkheaders because it's a struct pointer but it's more correct to have it, no? [19:27:24 CEST] <ubitux> ah, you move it out in the next commit [19:27:50 CEST] <ubitux> i suppose it's a git split shortcut/mistake [19:37:12 CEST] <jamrial> ubitux: yeah, originally patches 1 and 2 were one, but i decided to split it to make it more readable [20:42:56 CEST] <cone-155> ffmpeg 03Muhammad Faiz 07master:9b4648a2cdeb: avcodec/decode: do not treat discarded frames as eof when draining [20:55:55 CEST] <TD-Linux> BtbN, the easiest current solution is to use Janus in between [20:57:16 CEST] <TD-Linux> wm4, it's complex because a) it has a lot of features and b) it has encryption (the privacy kind, not the DRM kind) [20:58:57 CEST] <BtbN> Using WebRTC to stream to a Browser seems the best solution for low latency right now [20:59:11 CEST] <BtbN> But it's only VP8/Opus from what I can see, so rather limited without server side transcoding [20:59:33 CEST] <TD-Linux> also VP9, H.264 baseline, and g.711 (don't use g.711 though) [20:59:53 CEST] <BtbN> not like any of those are better options. [21:06:17 CEST] <cone-155> ffmpeg 03Muhammad Faiz 07master:c4be288fdbe1: ffmpeg: count packets when queued [21:15:44 CEST] <BBB> jamrial: ping [21:16:56 CEST] <jamrial> BBB: pong [21:17:07 CEST] <BBB> regarding that vp9 patch [21:17:15 CEST] <BBB> the question is probably how pkt_dts is set [21:17:32 CEST] <BBB> as long as its set outside the scope of get_buffer, its probably ok [21:17:50 CEST] <BBB> because the frame returned there is a frame decoded much earlier (a p-skip frame, so we just return the reference with a changed pkt_dts) [21:17:53 CEST] <BBB> (and pts) [21:23:48 CEST] <jamrial> BBB: it's set right after the AVCodec.decode() call in decode.c, and in ff_thread_decode_frame() [21:23:52 CEST] <jamrial> so to be honest, i can't say [21:24:06 CEST] <jamrial> the patch was mostly to raise awareness of the fact the decoder is setting pkt_dts without the FF_CODEC_CAP_SETS_PKT_DTS cap [21:24:30 CEST] <wm4> BBB: when decoding, it sets AVFrame.pkt_dts to the input packet's dts [21:24:38 CEST] <wm4> which probably makes sense in some weird way [21:25:36 CEST] <wm4> input pkt = the one at the decode call, so basically delayed by the decoder's internal delay [21:27:29 CEST] <BBB> I guess if it passes fate with threading etc., its ok [21:27:31 CEST] <BBB> but hard to say [21:28:50 CEST] <wm4> this implies fate has the correct result [22:01:28 CEST] <BBB> wm4: fate is correct (vp9 results were generated from reference decoder) [22:01:36 CEST] <BBB> wm4: s/fate/fate-vp9/ [22:01:51 CEST] <wm4> even the dts values? (I have no idea what dts means for vp9...) [22:02:45 CEST] <BBB> do we even log dts values? [22:03:03 CEST] <BBB> ¯\_(Ä)_/¯ [22:03:05 CEST] <nevcairiel> yes [22:03:12 CEST] <BBB> we do?!? [22:04:09 CEST] <JEEB> :D [22:04:46 CEST] <nevcairiel> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=tests/ref/fate/vp9-00-quanti… [22:04:50 CEST] <nevcairiel> columns even have a headline! [22:04:51 CEST] <nevcairiel> :D [22:05:15 CEST] <cone-155> ffmpeg 03Muhammad Faiz 07release/3.3:58a8e4733ae0: ffmpeg: count packets when queued [22:05:28 CEST] <nevcairiel> i would assume without re-ordering in vp9 that they are basically always equal to pts though [22:12:17 CEST] <BBB> nevcairiel: the question was whether pts/dts are copied from the ref which were returning [22:12:22 CEST] <BBB> (which was decoded earlier) [22:12:30 CEST] <BBB> nevcairiel: the pts is copied afaict [22:12:35 CEST] <BBB> so I had to re-set that [22:12:37 CEST] <BBB> so I set the dts also [22:12:41 CEST] <BBB> but maybe thats wrong [22:12:42 CEST] <BBB> who knows [22:15:58 CEST] <TD-Linux> my initial intuition is that show_existing_frame is still a packet and should have its own dts (not from the ref) [22:16:54 CEST] <BBB> TD-Linux: I think his point is that dts is set independently of frame buffer allocation [22:17:07 CEST] <BBB> TD-Linux: in that case, it doesnt need to be set in the decoding module (in this case ffvp9) [22:17:15 CEST] <TD-Linux> yeah ok [22:17:28 CEST] <BBB> but yes youre right dts should be set to the packet dts not the ref dts [22:17:37 CEST] <nevcairiel> thats what it should do [23:16:00 CEST] <cone-155> ffmpeg 03Michael Niedermayer 07master:79aa2ff19915: avutil/softfloat: use ldexp(), fixes undefined shift [23:32:44 CEST] <alevinsn> jamrial: just to confirm, there are a total of 9 patches associated with "Removing HEVCContext dependencies", right? [23:32:54 CEST] <jamrial> yes [23:32:56 CEST] <alevinsn> and you tacked on 8 and 9 without sending a new patch set? [23:33:06 CEST] <nevcairiel> the numbering got a bit confused [23:33:11 CEST] <jamrial> yeah [23:33:14 CEST] <nevcairiel> some patches have a v2, two are outside of the set [23:33:15 CEST] <nevcairiel> :D [23:33:27 CEST] <jamrial> the two outside the set are superseeded by those v2 :p [23:33:40 CEST] <alevinsn> And all of these have to do with "Remove ADVANCED_PARSER in libavcodec/hevc_parser.c"? [23:33:42 CEST] <jamrial> i'll send a new patchset in a few with the logctx change and the md5.h change ubitux mentioned [23:34:47 CEST] <ubitux> alevinsn: yeah it's about dropping the schyzophrenic mode of the parser when the decoder is present or not [23:35:15 CEST] <ubitux> it makes the parser and the decoder use shared code [23:35:32 CEST] <ubitux> similar to what was done to h264 a while ago [23:35:41 CEST] <ubitux> so you can have a fully functionnal parser without the decoder [23:36:19 CEST] <alevinsn> and this originated as a result of a libav merge? [23:37:16 CEST] <ubitux> yeah mmh iirc that ADVANCED_PARSER was introduced to fix regression(s?) in the parser [23:37:25 CEST] <ubitux> due to simplifications of not using the decoder [23:37:34 CEST] <ubitux> something along these lines, you need to check the history [23:38:18 CEST] <alevinsn> does that mean that, after this change, libav will still have ADVANCED_PARSER while ffmpeg won't? [23:38:35 CEST] <ubitux> no, ADVANCED_PARSER was added in FFmpeg only [23:38:37 CEST] <BtbN> if they don't decide to merge it, yes [23:38:53 CEST] <ubitux> it was a huge hack/workaround [23:39:30 CEST] <alevinsn> on a separate note, I wouldn't mind a little history lesson on ffmpeg and libav since Michael resigned as leader in 2015 [23:39:41 CEST] <alevinsn> I read the e-mail he sent to ffmpeg-devel [23:39:47 CEST] <jamrial> ADVANCED_PARSER was done in ffmpeg to keep the functionality of the parser intact after the libav merge basically reduced its functionality considerably (no sei or slice header parsing) [23:39:52 CEST] <nevcairiel> 2015 to 2017: we worked on code [23:39:52 CEST] <nevcairiel> :D [23:39:57 CEST] <JEEB> yup [23:40:02 CEST] <alevinsn> and he hoped that by resigning, libav and ffmpeg would merge [23:40:02 CEST] <ubitux> alevinsn: we thought it would help rejoining the projects, but nothing changed [23:40:28 CEST] <nevcairiel> there is a couple extremely stubborn people on both sides [23:40:31 CEST] <alevinsn> so, nothing has changed, and no one is technically a leader of ffmpeg since then? [23:40:56 CEST] <ubitux> blurry area [23:41:28 CEST] <jamrial> there have been more collaborations from devs of both projects to both projects, but otherwise things didn't really change much in that area [23:42:12 CEST] <jamrial> and right now ffmpeg has a voting comittee that sometimes works, sometimes doesn't [23:42:14 CEST] <nevcairiel> in other news, gcc 7.1 was released [23:42:19 CEST] <JEEB> yup [23:42:22 CEST] <alevinsn> with the decision made to really move forward with not maintaining some of the libav interfaces [23:42:35 CEST] <alevinsn> does that effectively mean it will become harder and harder to do merges? [23:42:56 CEST] <alevinsn> this is regarding using structs directly [23:42:57 CEST] <nevcairiel> to some degree it might make it easier in some areas, harder in others [23:46:00 CEST] <ubitux> speaking of this, we need to go back to merges again [23:46:14 CEST] <ubitux> we really need to avoid putting ourselves in that situation again [23:46:16 CEST] <nevcairiel> were we blocked somewhere, or just slacking? [23:47:02 CEST] <ubitux> next one is a h264 one fixing something we can't reproduce for a different reason [23:47:30 CEST] <jamrial> just noop it, like the mpeg one before it [23:48:21 CEST] <ubitux> idk.. [23:48:35 CEST] <ubitux> i'm going afk anyway right now [23:48:37 CEST] Action: ubitux & [23:48:43 CEST] <jamrial> ok, later [23:49:28 CEST] <jamrial> our h264 slice code is vastly different, and kierank fuzz tested it a lot, so unless we're sure it fixes something, better to just noop it [23:58:41 CEST] <jamrial> nevcairiel: there, pretty much the same save for the logctx and md5.h changes, plus some cosmetics, makefile changes and patch order [23:59:42 CEST] <nevcairiel> i read most of them today and it seemed fine, going to give them another pass a bit later [00:00:00 CEST] --- Wed May 3 2017

1 0

ffmpeg.log.20170502
by burek 03 May '17

03 May '17

[00:02:09 CEST] <b0bby__> Hey [00:02:19 CEST] <durandal_1707> hey [00:02:25 CEST] <james999> yeah most info on the inet is wrong [00:02:37 CEST] <james999> that's why i wanted to add my commandline syntax for wifi streaming with ffmpeg to the documentation [00:02:47 CEST] <james999> but i'm not sure if that's a patch or what the procedure is [00:25:59 CEST] <b0bby__> does anyone know whats wrong https://pastebin.com/g3duvTF1 [00:26:04 CEST] <b0bby__> ?\ [00:34:18 CEST] <durandal_1707> b0bby__: see working examples in repo [00:34:57 CEST] <b0bby__> link? [00:38:26 CEST] <james999> b0bby__: The error means there is a missing ; before the line it references [00:38:40 CEST] <james999> So you'll have to check each source file line by line to discover the problem [00:38:58 CEST] <BtbN> the source file is in an official ffmpeg header [00:39:03 CEST] <b0bby__> Shouldn't the source file have working code [00:39:21 CEST] <BtbN> unless you messed with them, they are fine [00:39:30 CEST] <b0bby__> I mean the headers should be correct [00:39:52 CEST] <james999> idk where did you get the code from? [00:40:28 CEST] <james999> hmm well only other possibility than what BtbN is that gcc is messed up or something [00:40:42 CEST] <BtbN> Or you just can't build something external in-tree [00:40:57 CEST] <b0bby__> I made it. It just loads the avs [00:41:02 CEST] <b0bby__> its a basic test [00:44:46 CEST] <james999> well I could copy the code you have from the same source and try it on my ubuntu vm [00:45:15 CEST] <james999> but I'm afraid halfway through furq or someone will just say it's the wrong code and the solution is trivial [00:49:16 CEST] <furq> that should work finr [00:49:16 CEST] <furq> e [00:58:49 CEST] <cryptodechange> My encode output is getting q=21.0 q=-1.0 [00:59:06 CEST] <cryptodechange> How do I interpret those numbers? [01:00:57 CEST] <kepstin> cryptodechange: using x264? ignore them, they're practically meaningless [01:02:14 CEST] <kepstin> I think the first number will be "the qp of the current frame", which isn't really a useful measurement of anything since the x264 encoder uses different qp values for different parts of the frame. [01:02:45 CEST] <kepstin> and the second number... ? who knows. [01:03:23 CEST] <kepstin> (I think those numbers might mean something when using some ffmpeg internal encoders, like the mpeg1/2 video encoder) [01:04:15 CEST] <furq> yeah it's meaningless unless you're using cqp [01:04:24 CEST] <furq> and if you are using cqp then it's not a number you need to pay attention to [09:45:15 CEST] <JC_Yang> 3.3 released failed to build with MSVC? so many WSA* family functions are said to redefined? anything wrong? [10:47:01 CEST] <JC_Yang> well, --extra-cflags=-DWIN32_LEAN_AND_MEAN fix it. [10:50:13 CEST] <JEEB> JC_Yang: I think we have MSVC FATE instances [10:50:23 CEST] <JEEB> so that kind of failure should have been found out [10:50:40 CEST] <JEEB> unless it's specific to some configuration [10:50:57 CEST] <JEEB> yea, we have active 2013, 2015 and multiple 2017 configurations [10:51:01 CEST] <JEEB> and they keep building [10:51:07 CEST] <JEEB> http://fate.ffmpeg.org/ [10:51:11 CEST] <JEEB> ctrl+F "microsoft" [10:51:35 CEST] <JEEB> I think we had some release branch FATE machines as well, but this interface doesn't show them (and the last I remember the fatebeta one was down) [10:51:37 CEST] <JC_Yang> I'm using msys2, and haven't run vcvars.bat, I manually set the PATH [10:52:14 CEST] <JEEB> msys2 is pretty much common, but generally people add one of the vcvars things into their msys2 execution environment [10:52:23 CEST] <JEEB> you can check how the FATE instances are configured [10:52:28 CEST] <JEEB> as in, their configure lines [10:53:10 CEST] <crow> c_14 I compiled now ffmpeg 3.2.4 and build VDR plugin softhddevice against this and it does not crash, but with ffmpeg 3.3 it does. vdr-softhdevice plugin compiled with ffmpeg 3.2.4 can play normal Live TV and would not crash on this specified channel, but compiled against ffmpeg 3.3 it crashes on this specified channel [10:53:14 CEST] <JC_Yang> the default msvc configure still use .o and .a *nix style output extensions? it is so here in my local build [10:54:26 CEST] <thebombzen> JC_Yang: afaik MSVC uses .lib instead of .a and .obj instead of .o [10:55:08 CEST] <thebombzen> or rather .lib for static libraries and .o for PE object files, but I don't think static libs are AR archives of objects [10:55:15 CEST] <JC_Yang> so something wrong with my ./configure. [10:55:28 CEST] <JEEB> I wouldn't be surprised if our makefiles use common output file names :P [10:55:39 CEST] <thebombzen> msys/gcc still uses .o and .a though [10:56:39 CEST] <JC_Yang> isn't configure for msvc default the extensions to the windows conventions? [10:57:25 CEST] <JEEB> does it really matter what the extension is? as long as you know you've configured it to be built with cl and linked with link that's all that matters [10:57:35 CEST] <JEEB> and you get your pdb files if you haven't disabled debug symbol creation [11:03:32 CEST] <JC_Yang> just curious, since I doubt whether my configure has something wrong. and one more question, no ffplay build in the default configure for msvc? [11:04:05 CEST] <thebombzen> ffplay requires sdl. do you have that? [11:05:43 CEST] <JEEB> JC_Yang: let me see my magic 8-ball - if your configure log says you are using MSVC then it sounds like your configure line in that sense is OK [11:06:03 CEST] <JEEB> of course my magic 8-ball cannot tell me if your configuration was sane or not otherwise [11:08:17 CEST] <JC_Yang> no, no sdl here. thanks. JEEB, the configure says C compiler cl, and the build complete smoothly, I guess its properly done already [11:20:54 CEST] <crow> I have here an problem application crash/coredump with vdr-softhddevice output plugin while watching Live TV on VDR. vdr-softhddevice plugin compiled agains ffmpeg 3.3 crush log url: https://defuse.ca/b/ivryaMqp pass: media ; vdr-softhddevice plugin compiled agains ffmpeg 3.2.4 no crash just log url: https://defuse.ca/b/Ape5u2QY pass: media [11:51:00 CEST] <JC_Yang> it seems that the default configure really lack -DWIN32_LEAN_AND_MEAN, without it, my local build failed. [11:52:16 CEST] <JC_Yang> 2017 community [11:57:22 CEST] <BtbN> Never had to hack that in there anywhere to build on windows. [11:57:44 CEST] <JEEB> note: he said he isn't running vcars or similar [11:57:49 CEST] <JEEB> so he might be missing default env vars [11:57:50 CEST] <JEEB> etc [11:59:53 CEST] <JC_Yang> have already invoke msys2_shell within VS command prompt, and the msys2 shell do know cl, invoke cl in the shell is ok [12:00:39 CEST] <BtbN> Is this some horribly old MSVC version? [12:00:56 CEST] <JC_Yang> visual studio 2017 is the latest [12:01:14 CEST] <BtbN> Works without adding any kind of define for me. [12:01:36 CEST] <JC_Yang> maybe some requirement not matched on my side? [12:02:16 CEST] <BtbN> From how I understand WIN32_LEAN_AND_MEAN, defining it only _disables_ stuff [12:22:34 CEST] <c_14> crow: ok, with this backtrace it looks like ffmpeg is triggering an assertion (which it shouldn't) and the assertion is causing a malloc corruption. The malloc corruption probably isn't a bug in ffmpeg (but in your libc), but the assertion triggering seems like a probable bug in ffmpeg. open a bug report on trac.ffmpeg.org and paste the stuff from the ivryaMqp paste there [12:23:36 CEST] <c_14> also, can you reproduce the bug on another machine or without using the vdr plugin? (using vdpau acceleration on a static video file or something) [12:32:44 CEST] <crow> c_14 i could try to record this channel with vdr-softhddevice compiled against 3.2.4 and then play to play with ffmpeg directly. thank you about suggestion ill open bug report. and provide as much information as posible. thank you [12:36:24 CEST] <crow> i am using archlinux arm and here is the glibc 2.25 in use. [12:38:35 CEST] <crow> hmm i am not able to register in trac, after spam check i get this error message: No handler matched request to /register_ffmpeg_four [12:41:10 CEST] <crow> it works now duck did not read second antispam question properly :D [12:53:56 CEST] <crow> c_14 https://trac.ffmpeg.org/ticket/6364 [12:57:37 CEST] <crow> to reproduce the bug on another machine i need to be at home, so tonight. [14:06:33 CEST] <termos> my AVCodecContext.time_base is 0/2 on my input decoding context, after creating it with avcodec_alloc_context3 (not using the one from the deprecated stream->codec) [14:06:54 CEST] <termos> is there something I'm not setting properly? just following the doc/examples/transcoding.c [14:11:05 CEST] <termos> hm, I might have a race condition [14:17:00 CEST] <cryptodechange> Fort older movies (<2000s) that have been released as bluray, is it preferred to use grain or film tuning? [14:33:18 CEST] <BtbN> There is never a definite answer to that [14:33:29 CEST] <BtbN> Use what yields the best result for that specific material [14:59:43 CEST] <aruns> Hi, have ffmpeg installed on Mac OS X 10.11.6, wondering what the -c flag is for (have checked man page and doesn't actually say) when you pass it as for e.g. -c:v [15:00:13 CEST] <aruns> Running version 3.2.4 of ffmpeg [15:00:58 CEST] <aruns> I am guessing the -c flag is for codec? [15:01:15 CEST] <aruns> Oh I got it now. [15:01:20 CEST] <aruns> Nvm. [16:16:56 CEST] <ZippyTheChicken> hi.. I am using MCEBuddy and FFMPEG is eating up all my memory is there a reason I can findout why and fix it? I am not sure which distribution he is using but it should be only 1 or 2 years old at the most [16:18:40 CEST] <JEEB> we don't offer support for third party software utilizing FFmpeg. if you can specify that it is an issue in FFmpeg itself rather how that application is using the libraries/cli then it goes to our area [16:19:26 CEST] <JEEB> (as in, we don't offer support for users of third party software, if you're trying to develop a piece of software on the libraries etc it is possible to get help here if someone is around and wants to help) [16:21:37 CEST] <ZippyTheChicken> I see... I was just wondering if I could replace his version of ffmpeg I don't know how i can find that out from his ffmpeg.exe file [16:22:13 CEST] <ZippyTheChicken> do you distribute the source code of FFMPeg for windows? and then Authors modify it? or do you distribute the exe and dlls? [16:22:27 CEST] <JEEB> we distribute the source code and people build it [16:22:33 CEST] <ZippyTheChicken> ah [16:22:39 CEST] <JEEB> the source code is common between architectures and OSs [16:22:52 CEST] <ZippyTheChicken> c++ ? [16:23:02 CEST] <JEEB> C, hand-written assembler and some C++ [16:23:15 CEST] <JEEB> C is generally frowned upon due to the exception system leaking etc [16:23:19 CEST] <JEEB> *C++ [16:23:37 CEST] <JEEB> but some dependencies are C++ libraries which is why the wrappers around them are C++ [16:24:30 CEST] <ZippyTheChicken> I guess it would be impossible for me to know what he is doing then... maybe i will see if I can find some revision notes on his code and see if I can find a way to replace his version [16:24:58 CEST] <ZippyTheChicken> thank you very much .. I know where to start now [16:25:07 CEST] <JEEB> replacing the version can be hard if you're doing an upgrade as well (unless it's the command line version he's using an not the libraries) [16:25:34 CEST] <JEEB> because the API could have changed between versions [16:26:21 CEST] <ZippyTheChicken> this is what he is including in his FFMPEG Folder .... ffmpeg.dvrms.exe ffmpeg.exe ffprobe.exe libx264-56.dll pthreadGC2.dll [16:26:40 CEST] <ZippyTheChicken> yes .. also he could be insane and editing your source... :o) [16:28:59 CEST] <JEEB> wow [16:29:02 CEST] <JEEB> that sounds ancient [16:29:26 CEST] <JEEB> at least by the libx264 version [16:29:28 CEST] <JEEB> (56) [16:29:34 CEST] <JEEB> I think we're at over 140 now [16:29:40 CEST] <JEEB> (that's the API version) [16:29:55 CEST] <JEEB> ZippyTheChicken: anyways, that sounds like it's using the command line app :P [16:30:12 CEST] <JEEB> which is not perfect for an application but at least the interfaces are generally stable as of recent [16:30:19 CEST] <JEEB> but yea, nfi [16:30:31 CEST] <JEEB> (this is why you can't really give support to users of 3rd party apps) [17:05:07 CEST] <JC_Yang> invoked msys2 within visual studio dev command prompt, then run ./configure --toolchain=msvc, configure success, and then make still result in the build failed, so many winsock2 redefinition. any steps wrong? ffmpeg 3.3 here. [17:06:10 CEST] <klaxa> did you run make clean between builds? although ./configure should kinda take care of that but not sure? [17:06:37 CEST] <klaxa> i think i had build fails with old binaries still in place [17:06:42 CEST] <JC_Yang> pure fresh build dir here, empty one [17:08:07 CEST] <klaxa> hmm [17:08:34 CEST] <klaxa> i'm not a windows guy, but having the complete output on pastebin or something would definitely help understand what's going on [17:08:35 CEST] <JC_Yang> I invoked msys2_shell -msys2 -user-full-path, this is the way I get the vcvars envs set in msys2 [17:10:34 CEST] <JC_Yang> I've fixed this problem hours ago with -DWIN32_LEAN_AND_MEAN but I'd like to know what's wrong and why require such a fix [17:27:09 CEST] <SouLShocK> is it possible to resize (upscale) and calculate psnr in one execution? I have a bunch of files which are downsized from source material and I'd like to calculate the psnr value for each file, compared to the source [18:02:12 CEST] <kepstin> SouLShocK: sure, use an ffmpeg command with two inputs, and use -filter_complex to either upscale the small video or downscale the big stream before doing the psnr filter [18:02:44 CEST] <kepstin> (I don't know whether upscaling/downscaling is better - the psnr would probably be highly dependent on the algorithm used if upscaling) [18:06:36 CEST] <cryptodechange> Anyone familiar with mkvmerge? Trying to grab the command paramters from the GUI [19:08:40 CEST] <SouLShocK> kepstin: https://pastebin.com/w3SRUAgs [19:14:49 CEST] <SouLShocK> kepstin: sorry here is the full paste https://pastebin.com/8E9QPJe5 [20:23:56 CEST] <arvut> how long do you reckon it will take to process a dvd (4.0G) of VIDEO_TS through x264 to file on a old core2 (1.8Ghz)? [20:24:24 CEST] <kerio> TIAS [20:24:33 CEST] <kerio> also, process how [20:25:01 CEST] <arvut> kerio: was that for me? [20:25:14 CEST] <kerio> yes [20:25:23 CEST] <arvut> what does TIAS mean? [20:25:28 CEST] <kerio> try it and see [20:25:42 CEST] <arvut> oh right, ffmpeg has commandline in it [20:25:55 CEST] <arvut> how do you go back from the hex to regular interface? [20:27:39 CEST] <arvut> should I move the .iso's I created from the dvd's back home to my i7 4790K and do it on that instead? (in case this takes too many hours) [20:27:54 CEST] <arvut> I can scp the files [20:28:06 CEST] <kerio> what is "the hex" [20:28:15 CEST] <kerio> what are you attempting to do [20:28:49 CEST] <arvut> at the moment lots of hex scrolling down, I can switch between raw hexdump and a more colourful output [20:29:07 CEST] <arvut> and the cpu is on heavy load, so its processing the first dvd [20:29:46 CEST] <kepstin> arvut: the i7 is probably gonna be 8-12x faster than the core2 [20:30:00 CEST] <furq> that seems optimistic [20:30:22 CEST] <arvut> kepstin: nice, I'll do the next one on that, this one has ran for two hours now, load is 3.3 on two cores [20:30:24 CEST] <kepstin> assuming a dual-core core2 quip [20:30:29 CEST] <kepstin> less if you have a quad i guess [20:32:14 CEST] <kerio> you still haven't told us what you plan on doing with the dvd :< [21:42:45 CEST] <olinux> having trouble converting mp3 + still image to mp4 .. can watch locally just fine .. can upload to wistia player and it wistia player plays in chrome fine, but doesn't play well in IE/Firefox/Opera browsers [21:43:59 CEST] <olinux> ffmpeg -framerate 1 -loop 1 -i myfile.png -i myfile.mp3 -c:a copy -c:v libx264 -shortest out.mp4 [21:55:54 CEST] <kepstin> firefox might have issues with mp3 audio? you could try aac instead [21:56:36 CEST] <JEEB> I would actually check what colorspace got used for video [21:56:51 CEST] <JEEB> olinux: post your full command line and the terminal output in a single pastebin or similar. then link here. [21:56:55 CEST] <JEEB> that should tell us :P [21:58:16 CEST] <olinux> kepstin, JEEB, thanks .. trying the aac encode now [22:05:23 CEST] <olinux> kepstin, works! thank you [22:45:30 CEST] <arvut> ok, I have encountered more problems, I transfered the 2nd .iso of a dvd movie (converted from vhs to dvd and then ripped to hdd) [22:45:49 CEST] <arvut> transfered to my own machine from the laptop with the core2, but now i can't read it when its mounted [22:46:19 CEST] <arvut> nobody is owner, nobody is group and date is 2006 (presumably when vhs was created from super8) [22:46:31 CEST] <arvut> permission denied, is the iso damaged? [22:46:57 CEST] <arvut> s/iso/image/ [22:47:41 CEST] <arvut> I had to mount the first image, then copy contents as root to hdd and change ownership of files, before I could access it with ffmpeg [22:48:40 CEST] <kerio> can't you just ffmpeg -i foo.iso [22:56:25 CEST] <arvut> I'll give it a try [22:57:08 CEST] <arvut> invalid data found when processing input [22:57:16 CEST] <arvut> it seems to be messed up, dd exited with errors on this one [22:57:24 CEST] <arvut> I think we have to make a new dvd to rip from [22:58:57 CEST] <arvut> kerio: have a look at this http://imgur.com/a/A0yY2 [22:59:24 CEST] <kerio> i guess it doesn't work :< [22:59:57 CEST] <arvut> I'm gonna compare the sum to the original rip, but it might not actually mount on hostmachine either so I think the dvd I ripped it from is scratched or something [23:00:25 CEST] <arvut> that ??????????? ? ? ? ? stuff is messed up when I try to ls -l /mnt/cdrom [23:00:39 CEST] <arvut> permissions, and blinking dir [23:20:42 CEST] <marcurling> Hello, do I have to compile my own ffmpeg for 10-bit encoding? [23:21:49 CEST] <JEEB> depends on the encoder and what sort of binaries you're using [23:22:34 CEST] <marcurling> I'm on W7 so I'm using Zeranoe's with default (h264) [23:23:27 CEST] <JEEB> marcurling: if it's linked to an 8bit libx264 then yes [23:24:19 CEST] <marcurling> I'm using the shared version so all I got to do is finding the 10-bit.dll ? [23:26:02 CEST] <JEEB> marcurling: uhh, not sure it's that simple. [23:26:49 CEST] <marcurling> ok, will google more. Thanks JEBB [23:39:33 CEST] <Sashmo> ifconfig [23:39:37 CEST] <Sashmo> oops [23:46:06 CEST] <arvut> marcurling: try ffmpeg on gentoo, very fast [00:00:00 CEST] --- Wed May 3 2017

1 0

ffmpeg-devel.log.20170501
by burek 02 May '17

02 May '17

[01:06:10 CEST] <cone-186> ffmpeg 03James Almer 07master:095147ae0650: avformat/matroskadec: export Content Light Level metadata [01:06:10 CEST] <cone-186> ffmpeg 03James Almer 07master:37cc1c1e9137: avformat/matroskaenc: add support for writing Content Light Level elements [04:18:56 CEST] <cone-350> ffmpeg 03James Almer 07master:54a4c9b4e9a1: avcodec/options: factorize avcodec_copy_context() cleanup code [04:18:56 CEST] <cone-350> ffmpeg 03James Almer 07master:cac8de2da5c4: avcodec/options: do a more thorough clean up in avcodec_copy_context() [11:44:54 CEST] <cone-274> ffmpeg 03Martin Vignali 07master:37f4d22075c3: libavcodec/exr : fix piz uncompress on big endian [11:44:54 CEST] <cone-274> ffmpeg 03Martin Vignali 07master:5ad18f279af1: fate/exr : add tests for piz uncompress [11:44:54 CEST] <cone-274> ffmpeg 03Martin Vignali 07master:89812e423de6: fate/exr : add test for negative float value [14:48:02 CEST] <durandal_1707> michaelni: thoughts on bigger fft sizes in our implementation? [14:49:48 CEST] <michaelni> we should support te sizes we need [14:50:10 CEST] <atomnuker> you need bigger than 1048576? [14:50:36 CEST] <atomnuker> that's 21 seconds worth of samples at 48000 [15:18:22 CEST] <durandal_1707> atomnuker: max is 131072 and i need bigger because nb taps are fft size / 4 [15:19:45 CEST] <durandal_1707> so supporting up to 7 seconds is enough for common impulse responses [17:43:13 CEST] <durandal_1707> michaelni, atomnuker: could i use already available fft sizes for huge number of taps? [18:13:08 CEST] <durandal_1707> apparently this is called partitioned fft [18:13:46 CEST] <cone-881> ffmpeg 03Micah Galizia 07master:28b24670741e: libavformat/http: Ignore expired cookies [18:13:46 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:63b8d4146d78: avcodec/bmp: Use ff_set_dimensions() [18:13:46 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:b706ddbae3f4: doc/developer: Add terse documentation of assumed C implementation defined behavior [20:03:02 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:2f00300b779e: avcodec/vp3: Check remaining bits in unpack_dct_coeffs() [20:03:03 CEST] <cone-881> ffmpeg 03Michael Niedermayer 07master:b29feec9829c: avcodec/indeo2: Check remaining bits in ir2_decode_plane() [23:00:07 CEST] <nevcairiel> jamrial: i'll look over the hevc patches tomorrow [23:00:26 CEST] <durandal_1707> michaelni: know how partitioned convolution works? [23:04:49 CEST] <michaelni> id guess thats FFT based convolution with blocks smaller than the whole signal [23:13:07 CEST] <durandal_1707> yes [23:45:44 CEST] <cone-651> ffmpeg 03Carl Eugen Hoyos 07master:a88b0b0ba7b4: lavc/mips/hevc_idct_msa: Add missing const qualifier. [23:46:59 CEST] <cone-651> ffmpeg 03Carl Eugen Hoyos 07master:f4c133c70874: lavc/mips/iirfilter_mips: Include config.h. [00:00:00 CEST] --- Tue May 2 2017

1 0

ffmpeg.log.20170501
by burek 02 May '17

02 May '17

[00:00:34 CEST] <thebombzen> that sounds weird because the data stream is in the container originally, so it should still be there [00:00:51 CEST] <thebombzen> are you sure the input file is actually an mp4? or is it an mov? [00:01:11 CEST] <alphabitcity> i believe it's an mp4, but let me double check [00:01:33 CEST] <alphabitcity> .nut worked [00:01:52 CEST] <thebombzen> I thought it would yea. but what format is the input? ffmpeg wont' tell you but "file" should be able to [00:02:03 CEST] <alphabitcity> "1.mp4: ISO Media" [00:02:32 CEST] <thebombzen> is there anything after that [00:02:44 CEST] <thebombzen> anyway try remuxing to MOV and see what happens [00:02:51 CEST] <thebombzen> MOV supports a lot more than mp4 [00:03:06 CEST] <alphabitcity> there's nothing after that [00:05:11 CEST] <alphabitcity> the original cmd changed to .mov worked too [00:05:31 CEST] <thebombzen> so .mov worked and .mp4 didn't? [00:05:41 CEST] <alphabitcity> so it seems. i will try again [00:05:41 CEST] <thebombzen> it sounds like your original file was an mov and not an mp4 [00:09:19 CEST] <alphabitcity> .mp4 and .mov both had trouble: https://pastebin.com/KZsChmPL [00:10:31 CEST] <thebombzen> that looks like it's not trouble. and don't use -c:s copy [00:10:34 CEST] <thebombzen> you don't have subtitles [00:11:04 CEST] <thebombzen> what makes you say it had trouble? it copied it and it worked, right? [00:12:35 CEST] <alphabitcity> (sorry for the slow responses. double checking everything) [00:14:21 CEST] <alphabitcity> ok, aside from a warning, looks like .mov works .. the ouput included "other streams:420kB", which I assume refers to the data track [00:15:27 CEST] <alphabitcity> i wonder if i can just rename output.mov to output.mp4 .. the container of 1.mp4 is "ISO Media" and the container of out.mov is "ISO Media, Apple QuickTime movie" [00:17:54 CEST] <alphabitcity> seems to work. thank you very much @thebombzen [00:24:33 CEST] <thebombzen> alphabitcity: do not [00:24:46 CEST] <thebombzen> renaming the file doesn't actually make it an mp4. it's still an mov [00:25:10 CEST] <alphabitcity> maybe the input was a .mov to begin with? [00:36:12 CEST] <thebombzen> that is what I suggested [00:36:28 CEST] <thebombzen> [18:05:41] <thebombzen> it sounds like your original file was an mov and not an mp4 [01:23:10 CEST] <faLUCE> so, basically, I don't understand how to demux a http mpegts stream with libav: do I have to manage http with avio or with avformat? [01:24:30 CEST] <JEEB> there's a http avformat protocol, AVIO is needed when you need custom IO layer [01:24:44 CEST] <JEEB> so if the lavf http thing is good enough, you can use that [01:24:56 CEST] <JEEB> if you have issues with the lavf http thing, you can use AVIO to handle the IO yourself [01:28:30 CEST] <faLUCE> JEEB: then, do I have to allocate two output formats separately? (one for http and one for mpegts) ? [01:29:50 CEST] <JEEB> pretty sure if you set a muxer's output URI to "http://blah.ts" that is 1) HTTP and 2) MPEG-TS, and the latter you can set manually so the URI can be like "http://blaaaah" [01:31:13 CEST] <faLUCE> JEEB: I see. I thought I could use only one AVFormatContext for both [01:31:30 CEST] <JEEB> I don't get what you're saying [01:33:02 CEST] <faLUCE> JEEB: you are saying that I have to allocate two AVFormatContexts.With the first one I unpack the HTTP packets, with the second one I demux the unpacked HTTP packets (mpegts) [01:33:26 CEST] <faLUCE> I thought I could do that with only one AVFormatContext [01:35:02 CEST] <faLUCE> JEEB: with rtmp-flv I remember that I can use only one AVFormatContext [01:35:18 CEST] <BtbN> rtmp is flv over tcp [01:35:37 CEST] <faLUCE> BtbN: I see [01:37:01 CEST] <faLUCE> when demuxing, do I have to call av_write_frame() ? (as I do for muxing) [01:37:36 CEST] <faLUCE> sorry, nm [01:37:45 CEST] <faLUCE> just saw the demuxing page in the API doc [04:08:26 CEST] <damdai> <+jludka> so you need to check what ffmpeg reports for that file. if it's wrong too, then the problem is there, and you need to report the bug to ffmpeg. mpc-hc uses lav filters, and lav filters uses ffmpeg. if ffmpeg is wrong, everything down the line will be wrong too, and it needs to be fixed in ffmpeg [04:08:29 CEST] <damdai> is this statement true? [04:15:46 CEST] <damdai> <+jludka> so you need to check what ffmpeg reports for that file. if it's wrong too, then the problem is there, and you need to report the bug to ffmpeg. mpc-hc uses lav filters, and lav filters uses ffmpeg. if ffmpeg is wrong, everything down the line will be wrong too, and it needs to be fixed in ffmpeg [04:15:47 CEST] <damdai> is this statement true? [05:18:46 CEST] <james999> yes...? [07:35:08 CEST] <nevermind1> gu [11:27:00 CEST] <hendry> my 4K recording from my GoPro5 seems to spat out several files. Is it possible to join them to make one large video with ffmpeg with https://trac.ffmpeg.org/wiki/Concatenate ? [12:38:19 CEST] <meth> Do you know how to encode using an AMD GPU? [15:05:17 CEST] <meth> OpenCL: Unable to query installed platforms [15:05:22 CEST] <meth> are you all dead? [15:12:13 CEST] <DelphiWorld> hey [15:12:22 CEST] <DelphiWorld> why am i getting Failed to query surface attributes with ffmpeg & libva? [15:19:06 CEST] <crow> I am using VDR application to watch Live TV (softhddevice plugin is as output device needed) which use ffmpeg. but here it crush on an channel switch. is this right place to provide backtrace as it seems (for me as just ordinary user) to be ffmpeg related or should i join other channels? [15:19:53 CEST] <DelphiWorld> if its ffmpeg related, see if the vdr use the latest ffmpeg lib. if yes, provide backtrace to both of ffmpeg & vdr [15:24:56 CEST] <alias_> Hi. I am working on a little java cli program which uses ffmpeg to convert audiobooks (audible .aax files) into mp3 files. It reads the time marks of the chapters from the aax file and creates one mp3 file per chapter. [15:25:10 CEST] <alias_> onversion is rather fast on an audiobook with few, large chapters (e.g. 10h and chapters of 1h length), about 20x conversion speed iirc. If the audiobooks contains many short chapters (e.g. 10h, chapters of 5min length), the conversion speed is only around 3-5x. [15:25:19 CEST] <alias_> Is there a way to speed this up? I am developing and testing on an i5 and a 64 bit linux with a recent kernel. The files bitrates are 130kbit/s. Would converting into a single mp3 file and splitting the result by chapters speed thing up? Thanks in advance! [15:30:46 CEST] <crow> DelphiWorld i am not sure if there is enough log in backtrace but i dont see how could i provide more: https://defuse.ca/b/r8YBzfjU softhddevice plugins use ffmpeg 3.x (only installed on my system). [16:57:29 CEST] <crow> did someone checked above back trace? is it usufull or does it need more information? [17:09:11 CEST] <c_14> crow: looks internal to the program itself, message them [17:09:32 CEST] <c_14> none of those threads are anywhere near libav* territory [17:14:38 CEST] <crow> ok thank you ill contact then vdr-softhddevice plugin developer. [18:06:17 CEST] <brian_> aha [18:06:49 CEST] <brian_> folks: I am pretty new in Windows env and not sure how to do this in Windows ? "./configure --enable-nvenc --enable-cuda --enable-nonfree" [18:12:45 CEST] <ariporad_> Hi all, I was hoping to get some help with using ffmpeg to add chapter markers to a MP3 file. (The file doesn't already have chapters.) AFAICT, the way I would go about this is to put the chapters in a ffmetadata file, but I'm having some trouble figuring out how to add chapter images or links using this method. If anyone had any pointers for this, that would be amazing! [18:18:07 CEST] <brian_> folks help this newbie : I am pretty new in Windows env and not sure how to do this in Windows ? "./configure --enable-nvenc --enable-cuda --enable-nonfree"? [18:19:34 CEST] <c_14> https://trac.ffmpeg.org/wiki/CompilationGuide/MinGW [18:21:49 CEST] <brian_> thanks c_14 [18:45:17 CEST] <cryptodechange> cropdetect rounds down my media to the nearest 16th, how can I do it so it's to the exact pixel? [18:46:54 CEST] <c_14> =round=1 [18:47:17 CEST] <cryptodechange> -vf "cropdetect=24:16:0" [18:47:29 CEST] <c_14> change 16 to 1 [18:48:16 CEST] <cryptodechange> Thanks! no change... cancelled my encode for no reason :'( [18:48:33 CEST] <furq> it's often better to do it by eye anyway [18:48:54 CEST] <c_14> yuv420p probably needs 2 instead of 1 [18:48:57 CEST] <cryptodechange> print screen, measure by pixels? [18:48:57 CEST] <c_14> because even dimensions [18:49:31 CEST] <furq> there are tools that do it [18:50:02 CEST] <cryptodechange> Is cropdetect not an adequate tool? [18:50:06 CEST] <furq> if you have clean black bars then cropdetect will do fine [18:50:13 CEST] <cryptodechange> I [18:50:16 CEST] <cryptodechange> Oh I see* [18:50:30 CEST] <cryptodechange> Typically, blu ray sources would have clean? [18:50:36 CEST] <furq> i should hope so [18:51:25 CEST] <furq> it's useless for things like head switching noise, but you'd hope bluray releases wouldn't have that [18:51:31 CEST] <cryptodechange> Doing cropdetect=1:1 gives me weird dimensions# [18:51:54 CEST] <furq> don't change the first value [18:55:03 CEST] <furq> fwiw if i was using cropdetect i'd probably encode a single frame to check it's close enough [18:55:18 CEST] <furq> -i foo -vf crop=... -frames:v 1 test.png [18:55:41 CEST] <furq> or -i foo -vf crop=... -f y4m - | mpv - [18:56:50 CEST] <cryptodechange> How can I encode a specific frame e.g. midway the movie [18:57:17 CEST] <furq> -ss 01:23:45 [18:58:33 CEST] <cryptodechange> hm [18:58:41 CEST] <cryptodechange> Doing it by eye I get 1920:804 [18:59:01 CEST] <cryptodechange> Doing it by -vf "cropdetect=24:1:0" I get 1920:800 [19:48:39 CEST] <cryptodechange> Encoding a bluray with everything but the video copied, 12000kbit/s [19:49:01 CEST] <cryptodechange> encoding just the video with everything cut out, ~5500kbit/sec [19:49:26 CEST] <cryptodechange> I'm confused, 6500kbit was the audio? [19:50:16 CEST] <sfan5> multiple audio tracks? [19:51:28 CEST] <c_14> blurays tend to use very high bitrates [19:51:28 CEST] <furq> yeah that's not unusual for dts [19:51:40 CEST] <c_14> oh, I read that incorrectly [19:51:42 CEST] <c_14> nvmd me [19:51:45 CEST] <furq> dtsma is up to 25mbit [19:52:53 CEST] <cryptodechange> aha [19:53:04 CEST] <cryptodechange> yeah, crikey, 5 audio trackls [19:53:11 CEST] <furq> that would also explain it [19:53:23 CEST] <cryptodechange> I figured I'll just encode video, then mux what I want included [19:53:50 CEST] <cryptodechange> Dang though, that's about 7gb down from a 32gb remux [19:54:02 CEST] <furq> five regular dts audio tracks will come to about 6.5mbit [19:54:05 CEST] <cryptodechange> with my 'nuke' settings @ 3.2 fps :P [19:54:14 CEST] <furq> but yeah even one track can easily exceed that on a bluray [19:54:41 CEST] <cryptodechange> 4 DTS and 1 AC3 [19:55:07 CEST] <cryptodechange> -x264-params me=tesa:level=4.1:vbv-maxrate=62500:vbv-bufsize=78125:merange=64:b-adapt=2:ref=5:bframes=16:rc-lookahead=150:trellis=2:subme=10:direct=auto:analyse=all:deblock=-3,-3:psy-rd=1,0.0:aq-strength=0.8 [19:55:17 CEST] <cryptodechange> on top of veryslow preset [19:55:23 CEST] <furq> why are you using the vbv [19:55:33 CEST] <furq> to say nothing of the useless shit like me-tesa [19:55:38 CEST] <furq> s/-/=/ [19:55:49 CEST] <cryptodechange> I stole the value from handbrake [19:56:10 CEST] <furq> and merange=64 [19:56:30 CEST] <furq> which is absolutely mental [19:56:33 CEST] <cryptodechange> Super overkill ikr [19:57:03 CEST] <furq> i mean if you want the feds to think you're running a grow op then it makes sense [19:57:22 CEST] <furq> that's the only possible reason to use settings like that [19:57:27 CEST] <furq> it certainly won't have a tangible effect on the video [19:58:10 CEST] <furq> although it's hard to say whether that's worse than rc-lookahead=150 [19:59:08 CEST] <cryptodechange> I did have ref=16 too [19:59:22 CEST] <furq> that actually makes sense though [19:59:48 CEST] <furq> bframes=16 is "overkill" [19:59:57 CEST] <furq> in that it's 99% wasted effort but occasionally will do something [20:00:09 CEST] <cryptodechange> I primarily use plex [20:00:11 CEST] <furq> those merange and rc-lookahead values are more than double what preset placebo uses [20:00:25 CEST] <cryptodechange> so want to ensure compatibility, I don't mind the encode times hense the rediculous values [20:00:31 CEST] <furq> which is called "placebo" for a reason [20:03:42 CEST] <furq> i've said it before but it's really a waste of time using anything more involved than -preset veryslow -tune animation -level 4.1 [20:03:55 CEST] <cryptodechange> This is for bluray movies [20:04:01 CEST] <cryptodechange> film* [20:04:07 CEST] <furq> both in terms of encoding time and time wasted reading atrocious forums compiling The Perfect Command Line [20:04:12 CEST] <cryptodechange> but I suppose you'd recommend film in lieu [20:04:14 CEST] <furq> -tune film or -tune grain then [20:04:32 CEST] <cryptodechange> temp wise, I'm at 50c [20:04:39 CEST] <furq> 16 bframes makes even less sense for film content [20:04:42 CEST] <cryptodechange> and still managing to use plex without issue [20:04:48 CEST] <cryptodechange> I just run the command and leave it over night [20:04:59 CEST] <cryptodechange> I use ref=5 now [20:05:01 CEST] <furq> every time i've done an encode of regular film content with 8 bframes, the encoding log tells me it's never used more than 5 [20:05:24 CEST] <cryptodechange> What's the different between bframes and ref? [20:05:48 CEST] <furq> bframes is the maximum number of consecutive bidirectional predictive frames [20:05:55 CEST] <cryptodechange> veryslow uses ref=16, doesn't that have compatibility issues? [20:05:56 CEST] <furq> refs is the number of frames in either direction that a b/p frame can use [20:06:08 CEST] <cryptodechange> the source bluray is 4 ref frames [20:06:12 CEST] <furq> and yes it does have compat issues, which is why you specify -level 4.1 [20:06:19 CEST] <cryptodechange> aha [20:06:29 CEST] <furq> that'll clamp the value of refs to whatever the maximum the level can take is [20:06:48 CEST] <cryptodechange> I use level=4.1 in x264-params [20:06:54 CEST] <furq> 16 refs means the decoder has to hold 16 frames in memory, which some hardware decoders can't [20:06:57 CEST] <furq> and er [20:07:03 CEST] <furq> i'm not sure if that does the same thing [20:07:21 CEST] <furq> i forget whether it's libavcodec or libx264 which clamps refs [20:07:40 CEST] <furq> if it's libavcodec then you'd need to use -level in ffmpeg [20:09:18 CEST] <furq> i actually normally use -preset veryslow -bf 5 -merange 16 [20:09:33 CEST] <furq> but 24 is probably better for 1080p [20:11:50 CEST] <cryptodechange> What values would actually cause compatibility issues if set wrong? (like ref) [20:12:04 CEST] <furq> refs is the only one i'm aware of [20:12:22 CEST] <furq> setting -level should clamp everything as long as you don't set it to some value that's impossible at that resolution/framerate [20:12:39 CEST] <c_14> clamping level/profile should ensure compatibility [20:12:54 CEST] <furq> yeah, profile as well [20:13:00 CEST] <furq> but you normally don't need to worry about that these days [20:13:08 CEST] <cryptodechange> I'm the sort of guy who buys 64gb ram for my gaming rig [20:13:09 CEST] <furq> most things will play high(a)4.1 now [20:13:42 CEST] <cryptodechange> so the overkill, put placebo to shame settings fits my character >_> [20:13:55 CEST] <furq> there's very little point tweaking things beyond the presets unless you have some pathological source [20:14:24 CEST] <cryptodechange> I should truncate the vbv all together? [20:14:44 CEST] <furq> i don't think that's needed but i'm not an expert on hardware decoders [20:14:52 CEST] <cryptodechange> Baby steps is needed here [20:14:53 CEST] <furq> if you're not burning this back to a bluray then i suspect it's not needed [20:15:11 CEST] <furq> and you're probably not or else you'd need nal-hrd=cbr and whatnot [20:16:08 CEST] <furq> i mean use me=tesa and bframes=16 if you want, those might actually achieve something [20:16:37 CEST] <furq> but the only effect of merange=64 and rc-lookahead=150 is that one day someone will see that in the encoding settings stanza in mediainfo and think "this guy is fucking mental" [20:17:10 CEST] <c_14> And on that day you can go "Mission Accomplished" [20:17:33 CEST] <cryptodechange> going to start my own scene team name [20:17:37 CEST] <furq> they'll then see that you're using subme=10 when 11 exists, and wonder what happened there [20:17:46 CEST] <furq> (i don't recommend 11, but if you insist on maxing everything out) [20:17:47 CEST] <cryptodechange> iMaBitMeNTaL^_^ [20:18:00 CEST] <cryptodechange> Look out release groups [20:18:31 CEST] <cryptodechange> in all seriousness, if someone comes up to me and tells me I'm crazy for setting x264 settings, I would've worried about being hacked more than anything [20:18:53 CEST] <furq> i mean i'd take that over finding someone's done a 1-pass 2mbit abr encode with -preset ultrafast [20:18:59 CEST] <furq> and yes, of course i've seen that [20:19:09 CEST] <cryptodechange> plex uses -veryfast [20:19:22 CEST] <furq> yeah but plex doesn't then think it'd be good to upload that to the internet [20:19:24 CEST] <cryptodechange> Hence why I want to try and limit the bitrate to itty bitty bittys [20:19:43 CEST] <cryptodechange> Private plex server ofc [20:20:05 CEST] <cryptodechange> When I'm remote transcoding my media on the go [20:20:08 CEST] <furq> of course i have also seen several different ways where someone has tagged an upload as "x264" when it isn't [20:20:28 CEST] <furq> including the pleasant surprise of finding it's actually a dvd remux, and the less pleasant surprise of finding it's 1080 mpeg4 [20:20:29 CEST] <cryptodechange> 32gb transcoded veryfast would be better than 10gb transcoded veryfast, and faster too [20:20:47 CEST] <cryptodechange> not be better** [20:21:28 CEST] <cryptodechange> subme=10 vs. subme=11 [20:21:47 CEST] <cryptodechange> QPRD in all frames vs. no early termination in analysis [20:22:16 CEST] <cryptodechange> Handbrakes says subme=10 is the most powerful option [20:22:24 CEST] <cryptodechange> and slowest, apparently [20:31:21 CEST] <furq> why would you listen to what handbrake has to say [21:39:35 CEST] <kepstin> that's part of the reason to use the presets - they'll be kept up to date when options change in x264... [22:03:16 CEST] <shincode> 1> /usr/bin/:"/c/Program Files (x86)/Microsoft Visual Studio 14.0/VC/bin/" 1> ./config.mak does not exist configuring new platforms 1> cl is unable to create an executable file. 1> If cl is a cross-compiler, use the --enable-cross-compile option. 1> Only do this if you know what cross compiling means. 1> C compiler test failed. 1> [22:03:33 CEST] <shincode> bash ./configure --toolchain=msvc [22:03:38 CEST] <shincode> earlier i had this added [22:03:42 CEST] <shincode> bash ./configure --toolchain=msvc --enable-pic --enable-cross-compile --target-os=win32 --host-os=win32 --arch=x86 \ [22:03:46 CEST] <shincode> its so stupid [22:03:51 CEST] <shincode> the script the tool is foolish [22:03:56 CEST] <shincode> im using a msys i686 [22:04:31 CEST] <shincode> i go which cl in configure and its like what? [22:09:58 CEST] <Punkbit> I'm trying to figure out why ffmpeg does not work for me on my machine [22:10:12 CEST] <Punkbit> installed through homebrew: [22:10:24 CEST] <Punkbit> brew install ffmpeg --with-fdk-aac --with-tools --with-freetype --with-libass --with-libvorbis --with-libvpx --with-x265 [22:10:41 CEST] <Punkbit> mac os siera 10.12.4 [22:11:04 CEST] <Punkbit> trying to convert using command: ffmpeg -i frame%04d.png logo.mp4 [22:11:20 CEST] <Punkbit> for the image sequence frame0000.png ~ frame0140.png [22:11:37 CEST] <Punkbit> The result is a 20kb file mp4 [22:12:58 CEST] <Punkbit> log https://pastebin.com/g34zTT0C [22:13:33 CEST] <Punkbit> Any hints on how to fix this? Thank you! [22:14:00 CEST] <furq> is the output file actually broken [22:14:23 CEST] <Punkbit> 18,798 bytes (20 KB on disk) [22:14:37 CEST] <Punkbit> `The document logo.mp4 could not be opened. ` [22:14:43 CEST] <Punkbit> The document logo.mp4 could not be opened. [22:14:53 CEST] <Punkbit> That's the error message I get, so I think the answer is that the file is broken [22:15:06 CEST] <furq> what gives you that error [22:15:27 CEST] <Punkbit> the output file, logo.mp4 in this case, this is the file I tried to generate from the image sequence [22:15:38 CEST] <furq> i mean what are you trying to open it with [22:15:38 CEST] <Punkbit> frame0000.png ~ frame0140.png [22:15:43 CEST] <Punkbit> Quicktime player [22:16:00 CEST] <furq> you might want to check in a better player [22:16:05 CEST] <furq> that log doesn't indicate anything went wrong [22:16:05 CEST] <Punkbit> it's only 20KB though [22:16:13 CEST] <furq> that's not impossible [22:16:15 CEST] <Punkbit> Ok I'll check with vlc [22:16:27 CEST] <furq> i mean it's unlikely but it depends on the source [22:16:41 CEST] <Punkbit> Ok :) I'll download vlc player [22:16:58 CEST] <furq> and quicktime could be breaking because it's yuv444p [22:17:09 CEST] <furq> so yeah test with vlc or mpv [22:17:28 CEST] <Punkbit> is there any other format I can try instead for converting this to? that is compatible with quicktime? [22:17:38 CEST] <furq> add -pix_fmt yuv420p [22:17:40 CEST] <Punkbit> *installing vlc [22:18:04 CEST] <Punkbit> I'll try [22:21:47 CEST] <Punkbit> furq: you're absolutely right! Thanks so much for your help! [22:32:51 CEST] <crow> c_14 i compiled now ffmpeg 3.2.4 and build VDR plugin softhddevice against this and it does not crash, but with ffmpeg 3.3 it does [23:21:26 CEST] <chicken_anda_cow> hey... I would like to change the maximum analyze duration (cause a webstream seems to send metadata too rarely). I tried -analyzeduration 140000000 but ffmpeg still insists on 7000000 :( y that? [23:21:47 CEST] <arvut> hoi [23:21:58 CEST] <arvut> kinda need help regarding choice of -acodec [23:22:46 CEST] <chicken_anda_cow> (if it matters: ffmpeg version 8.0.0-110-gfe48e16) [23:23:03 CEST] <furq> there is no such version [23:23:26 CEST] <arvut> where can I get a list of installed audiocodecs that ffmpeg can use and which ones work for playing the finished file (from DVD, VIDEO_TS/ to .mp4 container) on a ipad2? [23:23:46 CEST] <furq> arvut: if it's mp4 then your choices are pretty much ac3 and aac [23:23:55 CEST] <furq> the dvd will already have ac3 on it so you might as well just not reencode [23:24:18 CEST] <arvut> its a VHS cassette, converted to dvd with a dvd/vhs player setup, I didn't do this work. I'm doing the digitalizing steps from dvd to file [23:24:31 CEST] <arvut> furq: oh, so I skip the -acodec option? [23:24:34 CEST] <furq> -c:a copy [23:24:35 CEST] <chicken_anda_cow> furq: oh no, i time-travelled again ;_; [23:25:11 CEST] <arvut> furq: so all those long scripts with tons of options you find in various guides are mostly meaningless/obsolete? [23:25:20 CEST] <chicken_anda_cow> -.- it's on a libreelec host (obviously the devs mixed up their version number...) [23:25:27 CEST] <furq> most ffmpeg information on the internet is wrong, yes [23:25:36 CEST] <furq> chicken_anda_cow: that's not even a commit hash in ffmpeg or libav [23:25:45 CEST] <furq> so idk what's going on there [23:26:15 CEST] <chicken_anda_cow> :/ [23:26:27 CEST] <furq> but yeah analyzeduration should go up to INT_MAX [23:26:36 CEST] <furq> and the default is 5M, so idk where 7M is coming from [23:28:06 CEST] <chicken_anda_cow> damn :/ [23:29:58 CEST] <furq> i guess pastebin the full command and output somewhere [23:32:35 CEST] <chicken_anda_cow> well, obviously the libreelec devs fixed the analyzeduration. i'll try to annoy them :) [23:43:13 CEST] <furq> https://github.com/LibreELEC/LibreELEC.tv/tree/master/packages/multimedia/f… [23:43:20 CEST] <furq> i don't see any changes to analyzeduration in here [23:47:54 CEST] <chicken_anda_cow> yes... it turned out that the duration was correctly set for the h264 part of the stream... [23:48:23 CEST] <chicken_anda_cow> But for mpegts it still is 7000000 https://pastebin.com/twMn7v51 [23:48:56 CEST] <furq> oh, hls [23:49:10 CEST] <furq> i saw someone mention a bug where analyzeduration doesn't work properly with the concat demuxer [23:49:20 CEST] <furq> this could well be the same thing [23:49:21 CEST] <chicken_anda_cow> ah [23:49:35 CEST] <furq> although good luck getting a bug report past cehoyos when the version number is 8.0.0 [23:50:44 CEST] <chicken_anda_cow> yeah great... >.< [00:00:00 CEST] --- Tue May 2 2017

1 0