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

[burek]

[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/92b6ee70f5ea45d08527f81cb93105f9ee71d84e>
[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.ebuild#L426
[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-satellite-to-ride-spacexs-second-reused-rocket/
[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-msvc14-dll-windows-native 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