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

Sat May 27 03:05:03 EEST 2017

[00:19:00 CEST] <daon> I'm using video playing software called "mpv (ver0.25.0)" in conjunction with "ffmpeg(ver3.3.1)".
[00:19:14 CEST] <daon> When I play video with sami subtitle(extension: smi), it doesn't process "" tag in subtitle.
[00:19:28 CEST] <daon> "" in lower character works fine, but upper character doesn't work.
[00:19:54 CEST] <daon> Another Korean guy had made a issue at github.com(https://github.com/mpv-player/mpv/issues/3017) because of the same reason like me.
[00:20:14 CEST] <daon> wm4(I can see the same id in user list of this ffmpeg channel) said it's matter of ffmpeg.
[00:20:34 CEST] <daon> Is this matter of ffmpeg? If it is, I don't see why ffmpeg differenciate "" and "". Most Koreans use sami style subtitle format, so many people would go through this problem like me.
[00:23:20 CEST] <jamrial> daon: he asked for a sample you never provided
[00:23:44 CEST] <jamrial> also, if you think this may be a bug in ffmpeg, please open a ticket in http://trac.ffmpeg.org/
[00:25:30 CEST] <daon> Issue was a year ago. I couldn't decide which one do I have to report.
[00:33:33 CEST] <J_Darnley> If you're not going to file a bug on FFmpeg's trac, or on mpv's github, then at least give us here a file that fails.
[00:35:14 CEST] <jamrial> no, things shared here get lost and forgotten. the bug tracker exists for a reason
[00:37:40 CEST] <J_Darnley> True but it is one tiny step beyong not sharing anything.
[00:37:52 CEST] <J_Darnley> *beyond
[00:47:35 CEST] <daon> here's sample smi file content => https://gist.github.com/anonymous/2be738766de9513de65c8844fdc5a2e5
[01:29:04 CEST] <thardin> aw yiss, quad core fuzzing
[04:46:22 CEST] <daon> found how to fix "" problem. After modifying "libavcodec/htmlsubtitles.c" and recompiling ffmpeg&mpv, it works fine.
[04:46:46 CEST] <daon> I'll submit it to ffmpeg.org.
[04:48:32 CEST] <cone-866> ffmpeg 03Michael Niedermayer 07master:356194fcb173: avcodec/smc: Check remaining input
[04:48:32 CEST] <cone-866> ffmpeg 03Michael Niedermayer 07master:8e87d146d798: avcodec/aacdec_fixed: Fix runtime error: signed integer overflow: -2147483648 * -1 cannot be represented in type 'int'
[04:48:32 CEST] <cone-866> ffmpeg 03Michael Niedermayer 07master:43c394dcaebe: avcodec/clearvideo: Check buf_size before decoding frame
[11:12:53 CEST] <thardin> hum. is there a reason why ffmpeg would exit(130)? seems to be ctrl+c, but this is an automated test so obviously I'm not pressing it
[11:23:28 CEST] <BtbN> If a process is killed by a signal, the exit code will be 128 + signal number
[11:23:45 CEST] <thardin> yes, I found the relevant documentation
[11:24:08 CEST] <BtbN> so 130 would be signal 2, SIGINT
[11:25:53 CEST] <thardin> I've not quite been able to reproduce it for some reason
[11:28:41 CEST] <thardin> afl was claiming it had found a bunch of "crashes", but they turned out to most likely be AVERROR(EINVAL)
[11:37:29 CEST] <thardin> which somehow resulted in 130
[14:40:39 CEST] <atomnuker> is there something I should know about vgatherdps before using it in some asm?
[14:42:19 CEST] <kierank> atomnuker: it's not simd iirc
[14:42:26 CEST] <kierank> afaik it just does 8 loads
[14:45:32 CEST] <atomnuker> disappointing
[14:50:39 CEST] <kierank> atomnuker: it's planning for the future
[14:50:46 CEST] <kierank> so future cpus might make it true simd
[14:50:58 CEST] <kierank> so might have a benefit even now
[14:52:35 CEST] <J_Darnley> atomnuker: It zeros out the mask register you you need to load it every time.
[15:23:08 CEST] <BBB> michaelni: do you still understand the big picture of the msa thing?
[15:23:17 CEST] <BBB> michaelni: I feel like Im totally losing sight of it
[15:28:34 CEST] <michaelni> BBB, my understanding is mainly based on the patches submited by the mips developers. 
[15:34:20 CEST] <michaelni> BBB, IIUC MIPS can be big and little endian and our implementation of MSA optimizations works only on little endian. I dont know if thats all code or how trivial it is to make it work on bth endiannesses. And i might be totally wrong
[15:34:43 CEST] <BBB> super confusing
[15:34:46 CEST] <BBB> :D
[15:37:19 CEST] <nevcairiel> if msa doesnt work on BE, it should just be turned off in configure though and not get an additional preproc check everywhere
[15:40:27 CEST] <BBB> that was my initial thought also
[15:40:32 CEST] <BBB> and the first patch did that
[15:40:39 CEST] <BBB> so I dont know/undrstand why that was discarded
[15:41:36 CEST] <BBB> shivraj should also use a better email client ;)
[16:19:35 CEST] <cone-009> ffmpeg 03James Almer 07master:000fb61a71c6: avcodec/hevcdec: export cropping information instead of handling it internally
[16:19:36 CEST] <cone-009> ffmpeg 03James Almer 07master:6505e8cfd02b: avcodec/h264dec: be more explicit in handling container cropping
[16:19:37 CEST] <cone-009> ffmpeg 03James Almer 07master:07596e45c5a0: avcodec/h264dec: export cropping information instead of handling it internally
[16:19:38 CEST] <cone-009> ffmpeg 03James Almer 07master:a9a6d51ca447: avcodec/theora: export cropping information instead of handling it internally
[16:22:57 CEST] <cone-009> ffmpeg 03James Almer 07master:5213c6d175ba: doc/libav-merge: remove lines about AVFrame crop fields
[16:23:03 CEST] <jamrial> ubitux: ^ another one down :D
[16:28:58 CEST] <BBB> noooooooooooooooo
[16:29:05 CEST] <BBB> a vp8 test failed with a tsan warning
[16:29:10 CEST] <BBB> THAT IS NOT ALLOWED!
[16:31:43 CEST] <BBB> so I *think* I understand the tsan warning from update_context_from_user now
[16:31:47 CEST] <BBB> its a very very tricky one
[16:32:07 CEST] <BBB> and likely the only way to truly fix it is to make AVCodecContext.debug atomic
[16:32:16 CEST] <BBB> but thats an API change
[16:32:17 CEST] <BBB> so...
[16:32:20 CEST] <BBB> any opinions?
[16:33:18 CEST] <cone-009> ffmpeg 03Vittorio Giovara 07master:6aafe56421de: zscale: Add pixdesc-API compatible color names to filter options
[16:33:19 CEST] <cone-009> ffmpeg 03Vittorio Giovara 07master:1f4454230d14: zscale: Add range options aliases to match scale ones
[16:36:25 CEST] <thardin> funny, afl turned my webm test file into mpegts
[16:37:32 CEST] <thardin> strange that it enables asf, ffm, mov, mpegts, rm and rtsp
[16:38:05 CEST] <thardin> configure that is
[16:40:00 CEST] <Gramner> atomnuker: gathers are only useful if you're doing the address calculations in SIMD. it's never worth doing with a constant offset register
[16:41:35 CEST] <Gramner> it's actually slower (on most cpu:s at least, can't say I've tested it on every µarch) to gather 8 elements than doing 8 separate loads
[16:41:45 CEST] <Gramner> which is interesting
[16:42:49 CEST] <ubitux> jamrial: yey \o/
[16:45:21 CEST] <ubitux> BBB: so what's up with that debug field?
[16:45:37 CEST] <BBB> any thread has lockless read access to it
[16:45:44 CEST] <BBB> so that sort of suggests it should be atomic
[16:45:58 CEST] <Gramner> load units are one of the main bottlenecks in many cases so having gathers faster than individual loads would require the cpu to have more load units than what's actually exposed to the instruction scheduler which I can't see happening any time soon
[16:46:06 CEST] <BBB> it causes the sporadic hevc/h264 fails also
[16:46:14 CEST] <BBB> its not related to interlacing/field coding afaics
[16:46:38 CEST] <ubitux> and wrapping it into atomics would break api?
[16:49:52 CEST] <atomnuker> Gramner: I was planning to use it to load things via a lookup table
[16:52:42 CEST] <Gramner> we tried doing that back when adding most avx2 stuff to x264 and came to the conclustion that it was worse than doing individual loads
[16:53:54 CEST] <atomnuker> wow
[16:54:03 CEST] <BBB> ubitux: I think so, yes
[16:54:18 CEST] <Gramner> maybe if you can reuse the lookup table a sizeable amount of times and the function is limited by computational execution units it could be useful
[16:54:44 CEST] <atomnuker> how did they manage to make it smaller than 8 loads, isn't it what the microcode resolves to?
[16:54:45 CEST] <Gramner> but getting a single cache miss on the lut will definitely make things a lot worse
[16:54:47 CEST] <atomnuker> *slower
[16:54:52 CEST] <jamrial> that header writing patch for ffmpeg.c by alevinsn that's rotting in the ml should go in, even if with changes to make everyone happy
[16:55:30 CEST] <Gramner> the microcode also handles masking
[16:55:33 CEST] <BBB> ooooo a new race
[16:55:38 CEST] <BBB> is init of av_crc_table not threadsafe?
[16:55:55 CEST] <BBB> that should probably be AV_ONCE or so?
[16:55:57 CEST] <Gramner> and the mask has to be updated after every element is loaded
[16:56:12 CEST] <BBB> Read of size 4 at 0x00000254abbc by thread T4:
[16:56:13 CEST] <BBB> #0 av_crc_get_table src/libavutil/crc.c:346 (ffmpeg+0x0000016d1a14)
[16:56:17 CEST] <BBB> Previous write of size 4 at 0x00000254abbc by thread T3:
[16:56:17 CEST] <BBB> #0 av_crc_init src/libavutil/crc.c:336 (ffmpeg+0x0000016d1926)
[16:56:21 CEST] <BBB> Location is global 'av_crc_table' of size 53248 at 0x000002545bc0 (ffmpeg+0x00000254abbc)
[16:56:25 CEST] <Gramner> because if you hit a page fault the instruction needs to be restarted in a astate where it's partially completed
[16:56:36 CEST] <Gramner> which adds some complexity
[16:58:24 CEST] <jamrial> BBB: yeah, wm4 wanted to make it use avonce
[16:58:25 CEST] <Gramner> also by using a lut you first need to wait until the lut load completes before you can start loading the actual data which adds latency, although it can somewhat be hidden by out-of-order execution
[17:00:07 CEST] <BBB> wm4: ok so I can leave that to you?
[17:00:11 CEST] <BBB> jamrial: tnx
[17:02:05 CEST] <kierank> thardin: yeah related to rtp i think
[17:02:17 CEST] <BBB> I guess it doesnt really fit AVOnce
[17:02:20 CEST] <BBB> hm...
[17:03:53 CEST] <wm4> yeah, the crc tables are annoying
[17:04:19 CEST] <wm4> probably should use a static mutex instead (which are not supported by the win32 pthread wrapper due to XP support)
[17:04:34 CEST] <rcombs> hot take:
[17:04:36 CEST] <rcombs> fuck XP
[17:05:11 CEST] <wm4> dropping XP support over something like this is unlikely yo gain acceptance
[17:05:18 CEST] <wm4> so it'd require complicated workarounds/whatever
[17:06:41 CEST] <thardin> kierank: I only enabled very few formats, codecs and protocols tho
[17:06:50 CEST] <thardin> perhaps matroska pulls rtmp in?
[17:06:56 CEST] <thardin> or some other strange thing
[17:15:11 CEST] <jamrial> wm4: i thought even nt6+ lacked static mutex init
[17:15:31 CEST] <BBB> so uh wm4& any ideas on how to solve this?
[17:15:41 CEST] <BBB> why dont we just init it (at runtime) all at once?
[17:15:45 CEST] <BBB> is it too slow?
[17:16:03 CEST] <kierank> the polynomial is fixed?
[17:16:12 CEST] <kierank> wrap it in a function that does pthread_once? or do I misunderstand?
[17:16:40 CEST] <wm4> jamrial: the required API (light weight mutexes) exists since Vista
[17:16:52 CEST] <wm4> BBB: no idea lol
[17:17:02 CEST] <wm4> it could increase memory footprint I guess
[17:17:02 CEST] <BBB> its 257 entries
[17:17:04 CEST] <BBB> that cant be so bad
[17:17:51 CEST] <jamrial> BBB: 257 if CONFIG_SMALL, 1024 otherwise
[17:18:03 CEST] <BBB> thats still very small
[17:18:12 CEST] <wm4> why not use the CONFIG_HARDCODED_TABLES code
[17:19:10 CEST] <wm4> I guess it makes av_crc() slower
[17:19:50 CEST] <jamrial> just extend the hardcoded tables to all 1024 elements
[17:20:17 CEST] <jamrial> but keep it as 257 for CONFIG_SMALL, of course
[18:28:20 CEST] <alevinsn> jamrial: just saw your message about my patch that has been "rotting" in the ML for some time
[18:28:35 CEST] <alevinsn> michaelni never responded to my last e-mail on the topic
[18:29:01 CEST] <alevinsn> then wm4 said that the long comment indicated that the patch wasn't sustainable (or something like that), which I dispute
[18:29:10 CEST] <alevinsn> and that was the last of it
[18:29:32 CEST] <alevinsn> I found it sort of tiresome to continually push the patch, so I took a break from it
[18:31:42 CEST] <alevinsn> michaelni: do you think you could respond to my last message for this patch, which was a response to your last e-mail?
[18:32:49 CEST] <alevinsn> This was the e-mail I sent on 5/12/2017 6:22 PST
[18:33:01 CEST] <alevinsn> with subject line: "Re: [FFmpeg-devel] [PATCH] Fixed bug encountered when decoding interlaced video"
[18:33:58 CEST] <jamrial> you sent a new iteration of the patch split in two in separate threads after that
[18:34:19 CEST] <wm4> I've said it many times: the existing code was already grossly invalid, and I don't understand why it can't just be fixed properly
[18:35:10 CEST] <alevinsn> jamrial: right, but that was a response to the new version of the patch
[18:35:19 CEST] <alevinsn> even though it was done in the context of the old e-mail
[18:36:06 CEST] <alevinsn> wm4: yes, the existing code is hard to understand and problematic, but doing it the "right" way likely involves restructuring the code
[18:36:08 CEST] <alevinsn> in ffmpeg.c
[18:36:25 CEST] <alevinsn> and you've admitted yourself that any time you have to work in ffmpeg.c is an extreme pain
[18:37:45 CEST] <wm4> that's why I'd rather have someone fix it rather than adding a hack (I'm not saying that it will have to be absolutely fixed, but at least TRY)
[18:38:45 CEST] <alevinsn> I don't agree that it is a hack--it makes the code paths more deterministic
[18:39:42 CEST] <michaelni> alevinsn, iam fine with any solution that works and that noone objects to, sorry for not replying. i forgot about that mail after i saw it and had the feeling that i misunderstood the old patch/code
[18:40:47 CEST] <jamrial> problem is wm4 objected to it
[18:44:00 CEST] <jamrial> he wants a complete, thorough restructure when a working if arguably bandaid fix is good enough until someone actually gets to rewrite ffmpeg.c
[18:51:08 CEST] <alevinsn> jamrial: well, you "threw down the gauntlet" so to speak in your last e-mail, if no response after two days, maybe that's sufficient to move ahead with it
[18:55:55 CEST] <jamrial> no, i will not push a patch he's against unless other devs are in favor
[19:00:43 CEST] <alevinsn> jamrial: ok, looks like wm4 left
[19:00:51 CEST] <alevinsn> after wm4 wrote the last message
[19:01:41 CEST] <alevinsn> I implemented that bug fix when I thought I was going to use ffmpeg.exe directly in my project
[19:01:56 CEST] <alevinsn> but now, I'm using the shared libraries, so it doesn't actually impact me anymore
[19:11:49 CEST] <JEEB> that's a usual thing
[19:12:05 CEST] <JEEB> ffmpeg.c gets you surprisingly far and then you stumble upon some ancient horror
[19:17:58 CEST] <alevinsn> "ancient horror"--that almost puts it pleasantly :-)
[20:35:08 CEST] <michaelni> JEEB, what code do you speak of ? i think this is relativly recent code
[20:35:44 CEST] <JEEB> just general
[20:36:03 CEST] <JEEB> because it seems like a general occurrence :) ffmpeg.c works until you hit some part of code
[20:36:08 CEST] <JEEB> for me it was the VSYNC stuff
[20:36:46 CEST] <michaelni> thats surely true that things work unti you hit some code ;) 
[20:37:15 CEST] <JEEB> yup
[21:14:38 CEST] <AaronL> michaelni: from your e-mail response to the reap_filters patch
[21:14:49 CEST] <AaronL> what is that command-line set supposed to do?
[21:15:14 CEST] <AaronL> I mean, what is it doing?
[21:15:37 CEST] <michaelni> h264 over rtp over udp test
[21:18:24 CEST] <AaronL> I guess when you output to RTP it writes out the SDP information to stdout?
[21:18:37 CEST] <AaronL> and that takes too long with the patch>
[21:18:38 CEST] <AaronL> ?
[21:22:52 CEST] <michaelni> that sounds plausible
[21:38:09 CEST] <AaronL> my guess is that the approach the patch takes of waiting a little bit is likely to be incompatible with this test case
[21:38:36 CEST] <AaronL> and something else entirely will need to be done to address the interlaced video issue
[21:38:57 CEST] <AaronL> although, I don't know how that fits in with jamrial's patch
[21:41:16 CEST] <jamrial> my patch removes the delayed header writing code in libavformat/mux.c as it's no longer needed
[21:41:21 CEST] <jamrial> with it but without your patch applied beforehand, the interlaced flag is not propagated to the output container in one fate test
[21:44:43 CEST] <AaronL> so, the delayed header writing code is technically no longer needed, but it was still being used, and eliminating it does change the behavior slightly?
[21:46:31 CEST] <alevinsn> by behavior, I mean the sequencing of actions
[21:46:37 CEST] <jamrial> apparently
[21:47:56 CEST] <alevinsn> regarding the regression that michaelni reported, however, I haven't looked into it yet, but my guess is the reap_filters() patch is incompatible with this example
[21:48:17 CEST] <alevinsn> because while it makes things more deterministic with respect to header writing, it does take longer to write the header in some cases
[21:48:21 CEST] <alevinsn> than it used to do
[21:48:27 CEST] <alevinsn> by design
[21:49:01 CEST] <alevinsn> I've pointed out that the best solution would be to parse the input header and not wait for the first video frame
[21:49:19 CEST] <alevinsn> use information from the input header instead of the first video frame in setting the interlaced video setting
[21:49:31 CEST] <alevinsn> but, I haven't looked into how or where to do that
[21:49:36 CEST] <jamrial> the delayed code in libavformat is run only with muxers that auto inject bitstream filters (AVFormatOutput.check_bitstream() is not NULL). in those, the header is not written until the first packet shows up
[21:50:33 CEST] <alevinsn> first output or first input packet?
[21:50:46 CEST] <jamrial> first output packet, i think
[21:51:09 CEST] <jamrial> by removing this code in mux.c and writing the header for every muxer, one fate test that needs avcodecparameters.field_order during avformatout.write_header() doesn't get it anymore
[21:51:29 CEST] <alevinsn> in all these cases, ffmpeg already knows that the input video is interlaced or progressive by examining the input header
[21:51:30 CEST] <jamrial> your patch makes do_video_out() in ffmpeg.c set said field before write_header() is called
[21:51:48 CEST] <alevinsn> yes, but it delays the call to write_header() compared to when it used to be called
[21:52:00 CEST] <alevinsn> and that is presumably breaking the RTP test case from michaelni
[21:53:15 CEST] <alevinsn> but, it doesn't propagate the input header interlaced info to the output header--this information is only propagated via the call to do_video_out(), which is silly
[21:53:32 CEST] <alevinsn> since even if interlaced bit can in theory change from frame to frame
[21:53:43 CEST] <alevinsn> well, type of interlacing vs. progressive
[21:53:54 CEST] <alevinsn> the header should only be written once
[22:09:54 CEST] <jamrial> alevinsn: i just sent the patch, in case you want to test it
[22:25:35 CEST] <alevinsn> k
[22:26:04 CEST] <alevinsn> not everyone may realize that this patch is "contingent" on the reap_filters() patch with respect to passing FATE
[22:27:49 CEST] <jamrial> i explained as much in it. anyone reviewing it will see the comment
[22:38:18 CEST] <alevinsn> I wonder if the following is the "right" way to go about this
[22:38:48 CEST] <alevinsn> copy the field_order setting from the associated input stream's codecpar as soon as the output stream is initialized
[22:40:09 CEST] <alevinsn> although, I'm not sure how to determine the "associated" input stream
[22:42:13 CEST] <alevinsn> source_index is used to indicate that
[22:42:25 CEST] <alevinsn> the index for the associated source stream
[22:46:30 CEST] <alevinsn> here's a solution that just might work
[22:46:49 CEST] <alevinsn> modify new_output_stream() as follows:
[22:46:54 CEST] <alevinsn> in ffmpeg_opt.c
[22:47:13 CEST] <alevinsn> at the bottom of the function
[22:47:23 CEST] <alevinsn> look for the code that sets ost->sync_ist
[22:47:56 CEST] <alevinsn> and add the line:
[22:49:02 CEST] <alevinsn> ost->st->codecpar->field_order = 
[22:49:04 CEST] <alevinsn> hmm
[22:50:29 CEST] <alevinsn> ost->st->codecpar->field_order = ost->sync_ist->st->codecpar->field_order;
[22:50:34 CEST] <alevinsn> I think that might do it
[22:52:45 CEST] <alevinsn> could potentially just do for AVMEDIA_TYPE_VIDEO, but I don't think it matters
[22:53:39 CEST] <alevinsn> if you feel so inclined to try that with your patch :-)
[23:17:44 CEST] <alevinsn> that might be wrong
[23:18:06 CEST] <alevinsn> options propagation may have already occurred by then?
[23:18:22 CEST] <jkqxz> alevinsn: There is no associated input stream with meaningful information, since everything can be changed by filters. You really do have to get a frame all the way to the output to know the parameters.
[23:18:42 CEST] <alevinsn> well, that's for a default value
[23:19:02 CEST] <alevinsn> it could be changed later
[23:19:17 CEST] <alevinsn> that would at least get things correct in most cases
[23:19:23 CEST] <nevcairiel> no, it can't, if the headers are already written
[23:19:39 CEST] <alevinsn> the headers haven't been written by that point yet
[23:19:50 CEST] <nevcairiel> then you dont need a hack =p
[23:19:53 CEST] <alevinsn> if it is calling new_output_stream(), then the headers haven't been written
[23:19:55 CEST] <alevinsn> yet
[23:20:09 CEST] <alevinsn> I was suggesting to modify new_output_stream() instead of the patch I submitted
[23:20:28 CEST] <alevinsn> which I think would address the RTP test case that michaelni reported had stopped working
[23:22:11 CEST] <alevinsn> jkqxz: I mean, in new_video_stream()
[23:23:06 CEST] <alevinsn> hmm
[23:23:07 CEST] <nevcairiel> the entire point of the recent changes was to not copy random values from the input stream, but take the data from a decoded and filtered frame, because only that is accurate - if that doesn't work, then it should be fixed properly, and not pile hacks on top
[23:24:36 CEST] <alevinsn> well, that wasn't working properly with respect to the order in which headers are written and when the first filtered frame is processed
[23:24:53 CEST] <alevinsn> but, when I addressed that, by making it more likely that the first filtered frame would be processed before headers are written
[23:25:16 CEST] <alevinsn> that appears to have caused things to slow down such that it breaks the RTP test case that michaelni submitted
[23:25:48 CEST] <alevinsn> that is, it is taking longer to write the headers now in this case than what happened previously
[23:25:53 CEST] <nevcairiel> thats mostly because your patch is also just a hack that shuffles stuff around in such a way that works in more cases, without really figuring out where the dataflow is stuck for this situation to even happen
[23:26:49 CEST] <alevinsn> based on the fact that the issue didn't occur when H.264 and AAC were used, but does occur when H.264 and Opus are used
[23:27:09 CEST] <alevinsn> that is, in the H.264/AAC case, AAC gets started up _after_ H.24
[23:27:11 CEST] <alevinsn> H.264
[23:27:21 CEST] <alevinsn> the output stream for H.264 is created before the AAC output stream
[23:27:29 CEST] <alevinsn> but vice versa for H.264/Opus
[23:27:48 CEST] <alevinsn> then I would guess there are timing differences depending on the codec used
[23:28:39 CEST] <rcombs> >ost->st->codecpar->field_order = ost->sync_ist->st->codecpar->field_order;
[23:28:47 CEST] Action: rcombs adds filters
[23:31:02 CEST] <alevinsn> nevcairiel: I think if it is an absolute requirement that the first filtered frames be received, for all output streams, prior to writing the header (my patch doesn't even do that)
[23:31:21 CEST] <alevinsn> then a bunch of FATE test cases, and likely other tests, will need to change
[00:00:00 CEST] --- Sat May 27 2017