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

[burek]

[00:13:31 CEST] <cone-830> ffmpeg 03James Almer 07master:712ee85816ef: avcodec/encode: free non-referenced packets' side data in the old encode API functions
[01:53:33 CEST] <jamrial> michaelni: the new test (fate-svq3-2) yields different results if configuring with --enable-memory-poisoning compared to not
[01:53:40 CEST] <jamrial> i think that hints at some issue somewhere...
[01:54:44 CEST] <jamrial> noticed this just now seeing that all the fate clients are failing at it (i didn't use --enable-memory-poisoning for the build i used to merge and test the commit)
[01:55:30 CEST] <jamrial> i'll update the hash so fate is not all yellow, but no idea what could be at fault here
[02:43:33 CEST] <cone-830> ffmpeg 03James Almer 07master:aa4fe2765746: fate: disable fate-svq3-2
[02:44:52 CEST] <jamrial> michaelni: disabled the test until it's fixed. some fate clients don't use memory poisoning, so there would have been failure reports no matter what
[06:53:09 CEST] <ldts> if anyone is interested, I have backported v4l2_m2m to 3.3.3 https://github.com/ldts/FFmpeg/commits/v3.3.3/v4l2_m2m_backport
[09:00:57 CEST] <wm4> ldts: normally we don't add new features to stable releases
[09:38:56 CEST] <ldts> wm4: yes makes sense...at Linaro we are making a release for db410/db820 had to backport to the OE release we have which uses 3.3.3 (so just sharing here in case anyone had any use for it since the changes to v4l2_m2m_dec.c (mayority of the backport) werent completly straightforward
[10:31:09 CEST] <ayum> Hi, I am using ffmpeg to read video from 2 v4l2 device(/dev/video0 and /dev/video1), I found that ffmpeg doesn't open 2 stream at same time,  so I want to modify the source code, and open 2 v4l2 device simultaneously.  I want to modified libavdevice/v4l2.c, but failed. any suggestions?
[10:35:20 CEST] <ldts> ayum: cant you use two separate ffmpeg instances, one for each device? 
[10:35:42 CEST] <kierank> You can't open two devices simultaneously
[10:35:47 CEST] <kierank> It's the major flaw in v4)
[10:35:50 CEST] <kierank> V4l
[10:36:05 CEST] <ayum> @ldts, I added a compare filter in ffmpeg, so it will compare 2 video stream
[10:36:48 CEST] <ayum> so I  can not use 2 ffmpeg read from 2 device separately
[10:37:21 CEST] <ayum> actually, second device will delay about 1 second, then open
[10:37:27 CEST] <wm4> kierank: wat
[10:38:19 CEST] <JEEB> funky
[10:38:41 CEST] <ldts> kierank: are you sure that the same process can not open to v4l2 devices? I can't imagine any reason why it shouldnt..
[10:38:56 CEST] <kierank> wm4: how do you sync video from v4l2 and audio from alsa
[10:39:06 CEST] <kierank> Answer is you can't they are two separate fds
[10:39:09 CEST] <wm4> isn't that a different issue
[10:40:47 CEST] <ldts> ayum: do you have your tree somewhere?
[10:40:52 CEST] <ldts> I can have a look if you want
[10:41:21 CEST] <kierank> You can't open two fds simultaneously
[10:41:39 CEST] <wm4> fd1=open("a"),fd2=open("b")
[10:41:48 CEST] <ayum> @ldts, I using this command to read from 2 devices: ffmpeg -i /dev/video0 -i /dev/video1 -filter_complex "compare" ....
[10:42:12 CEST] <ldts> I thought you said you modified v4l2.c?
[10:42:30 CEST] <wm4> kierank: I mean, I get it, they're not synced, but the way you say it doesn't make it obvious
[10:42:35 CEST] <ayum> yes, I am trying to modify v4l2.c, add some synchronize function
[10:42:48 CEST] <ldts> ayum: where is your v4l2.c?
[10:43:12 CEST] <ayum> libavdevice/v4l2.c
[10:44:35 CEST] <ayum> ffmpeg is using thread to manage the input, right? I use pthread_self() to print the thread ID, If I have 2 inputs, there are 2 different threads.
[10:45:04 CEST] <BtbN> ffmpeg.c does not use threads
[10:46:47 CEST] <ayum> yeah, but I think it's in somewhere
[10:55:41 CEST] <BtbN> threading generally only happens internally of codecs or filters
[10:56:57 CEST] <ayum> @BtbN, if that's true, how ffmpeg manage the multiple inputs?  I thought there is a thread queue for every input. 
[10:57:07 CEST] <BtbN> sequentially one after the other
[11:28:12 CEST] <JEEB> so whereabouts the mpeg-ts timestamp rolling was handled again?
[11:28:44 CEST] <JEEB> I remember it was in utils
[11:28:51 CEST] <JEEB> (in lavf, IIRC)
[12:00:22 CEST] <wm4> I thought there is threaded input
[12:00:34 CEST] <wm4> but generally ffmpeg.c isn't too well designed for blocking input
[13:48:31 CEST] <JEEB> michaelni or so, unless there's any additional comments on http://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/217102.html , can it be pushed?
[14:20:56 CEST] <michaelni> JEEB, no additional comments from me
[14:26:31 CEST] <wm4> libavcodec/vda.h:41:10: fatal error: VideoDecodeAcceleration/VDADecoder.h: No such file or directory
[14:26:35 CEST] <wm4> the fuck did I do now
[14:26:43 CEST] <wm4> it's not broken in master I assume
[14:27:01 CEST] <selsta> fd5f4ac0813c27c34c387f00044905a859e29e37 seems to break OS X compilation with `./configure --enable-opencl`
[14:53:15 CEST] <selsta> linkage error https://www.irccloud.com/pastebin/t7skbYvM/
[15:15:37 CEST] <wm4> ok this was much easier than I thought
[15:16:18 CEST] <wm4> uh did it send only mail 7/7
[15:23:22 CEST] <wm4> the server must be pretty slow
[15:31:29 CEST] <wm4> philipl, BtbN: review of the cuvid patches would be appreciated... there is also hevc support in Libav, which I'd merge later
[15:43:02 CEST] <BtbN> wm4, I really want to know how to use cuvid as a filter now
[15:44:03 CEST] <wm4> BtbN: hm?
[15:44:14 CEST] <wm4> it outputs the same thing as our cuvid decoder
[15:44:26 CEST] <BtbN> In theory, cuvid can take in raw frames, apply video processing on it, and return another raw frame
[15:44:31 CEST] <wm4> oh yeah,v if you mean stuff like deint, no idea
[15:44:36 CEST] <BtbN> So it can be used as a filter for scaling/deinterlacing
[15:44:55 CEST] <BtbN> The API is there, but absolutely no documentation on how to use it
[15:44:57 CEST] <wm4> for pure decoding, it will be better, because nvidia's parser tends to be flaky
[15:45:10 CEST] <BtbN> When I asked some nvidia people about it, they were like "Yes, that's possible."
[15:45:24 CEST] <wm4> you should ask them harder
[15:45:26 CEST] <philipl> wm4: renaming ours means a compatibility break. Is this in the context of the next break? I lost track.
[15:45:34 CEST] <BtbN> It does not rename ours
[15:45:36 CEST] <BtbN> just the file
[15:45:57 CEST] <wm4> yep
[15:46:02 CEST] <wm4> it also renames the Libav hwaccel names
[15:46:16 CEST] <wm4> so if anyone were to rely on those names, it wouldn't be API-compatible to Libav
[15:49:13 CEST] <jamrial> selsta: ping
[15:51:22 CEST] <philipl> wm4: ok
[15:53:18 CEST] <BtbN> wm4, I still don't quite understand how it solves the delay-problem. It seems to still immediately pull the frame from CUVID after it returns it
[15:53:59 CEST] <BtbN> Or does it rely on calling receive_frame late enough, so the delay has to be implemented outside?
[15:54:08 CEST] <wm4> BtbN: well there is infrastructure for delaying with the patches
[15:54:30 CEST] <wm4> not sure how that works though
[15:54:52 CEST] <BtbN> decode_receive_frame_internal pulls the frame from CUVID to CUDA
[15:55:20 CEST] <philipl> Well, we can try it out and see how fast it gets.
[15:55:25 CEST] <selsta> jamrial: Im here
[15:55:37 CEST] <wm4> hm I guess "delayed" refers to "after frame threading"
[15:55:51 CEST] <wm4> BtbN: did you look at cuvid_retrieve_data in cuvid.c?
[15:56:00 CEST] <BtbN> I'm not there yet.
[15:57:25 CEST] <jamrial> selsta: can you test https://pastebin.com/raw/1awDw01D to see if it fixes your opencl failure?
[15:59:48 CEST] <selsta> jamrial: will test it in ~30 minutes
[16:00:11 CEST] <philipl> wm4: I don't see you using the new codec_cap
[16:02:42 CEST] <wm4> philipl: which one?
[16:03:52 CEST] <philipl> wm4: Ah, ok. You don't need to add it to the new one
[16:35:41 CEST] <jkqxz> wm4:  Can we please not add more hacks around lavc get_format setup for hwaccels and instead delete all of the dummy ones?
[16:37:21 CEST] <jkqxz> <https://lists.libav.org/pipermail/libav-devel/2017-September/084804.html> and series.  If I sent it to ffmpeg would that be helpful?
[16:37:59 CEST] <jkqxz> (It was easier to sort out in libav because there are fewer of them there, but it should be pretty much identical here.)
[16:38:07 CEST] <wm4> jkqxz: yes I'd agree
[16:38:28 CEST] <wm4> also, a different mechanism than get_format, but that's even further out there
[16:39:26 CEST] <wm4> I'm also just noticing that "AVCodecHWConfig" sounds too much like a runtime thing (like instantiated decoder parameters or so) - bikeshed time?
[16:39:48 CEST] <jkqxz> What do you want there?  I tried to suggest making this configuration setup be used for software formats as well and making the new callback be select_config, but elenril at least didn't like that.
[16:40:04 CEST] <jkqxz> What do you want to call it?
[16:40:11 CEST] <wm4> so it's down to what elenril likes
[16:40:21 CEST] <wm4> instead of "AVCodecHWConfig"? uh good question... yellow?
[16:40:33 CEST] <wm4> or maybe AVCodecHWAccel (durrrrrrrrr)
[16:40:55 CEST] <iive> wm4: it has always been like that
[16:40:56 CEST] <jkqxz> It's not just for HWAccels, it also applies to decoders (like CUVID).
[16:41:12 CEST] <selsta> jamrial: I get `error: patch failed: fftools/Makefile:20`
[16:41:20 CEST] <wm4> iive: like what
[16:41:21 CEST] <iive> imho, that structure should not even exist, and avcodeccontext be used instead.
[16:41:35 CEST] <wm4> jkqxz: I know
[16:41:44 CEST] <wm4> but as in "hardware accelerated codec"
[16:41:55 CEST] <wm4> "AVCodecHWCaps"
[16:42:04 CEST] <wm4> "AVCodecHWSupport"
[16:42:14 CEST] <iive> "wm4> so it's down to what elenril likes" it has always been like that.
[16:42:14 CEST] <jkqxz> I hate the term "acceleration" here.  Most of these are just whole-decoder implementations in hardware, there is no acceleration.
[16:42:25 CEST] <iive> ofloading?
[16:42:31 CEST] <iive> offloading?
[16:42:37 CEST] <wm4> iive: well, it's actually possible to convince elenril of something, also he's often right
[16:42:41 CEST] <jkqxz> iive:  What do you mean?  There is no AVCodecContext at this point, it's in AVCodec.
[16:42:46 CEST] <jkqxz> offloading is good, yes.
[16:43:24 CEST] <iive> jkqxz: the one usually shorten to avxtx
[16:43:28 CEST] <iive> avctx
[16:44:54 CEST] <wm4> there isn't one
[16:45:03 CEST] <wm4> this is for information before a codec is opened
[16:45:30 CEST] <iive> applications used to pass info to the codecs there
[16:45:50 CEST] <wm4> wat
[16:47:39 CEST] <jamrial> selsta: it applies fine for me. try with git am
[16:49:31 CEST] <selsta> jamrial:  https://www.irccloud.com/pastebin/tWdZVC2a/
[16:52:40 CEST] <selsta> jamrial: wait a moment
[16:54:12 CEST] <selsta> your patch works :) I fucked up with the applying lol
[16:54:36 CEST] <jkqxz> wm4:  Ok, I'll look at making that series for ffmpeg later.
[16:54:50 CEST] <jkqxz> Assuming noone else has any objects to it.
[16:55:46 CEST] <wm4> I'd welcome it - I don't love these hacks
[16:55:56 CEST] <selsta> jamrial: would be good if this patch gets pushed soon, as homebrew ffmpeg git uses --enable-opencl
[16:56:05 CEST] <wm4> preferably they should not be applied in a slightly different way to Libav later, though
[16:56:12 CEST] <jamrial> selsta: yes, in a bit
[16:56:57 CEST] <jkqxz> That is generally why it is easier to start in libav.  Would you prefer I sent it again there?
[16:58:39 CEST] <wm4> jkqxz: that would probably be better - is it Elenril Approved (TM) yet?
[16:59:15 CEST] <iive> jkqxz: what is HWConfig supposed to do?
[16:59:33 CEST] <jkqxz> wm4:  We talked about it a bit at VDD, but not enough to get that badge.
[16:59:43 CEST] <cone-950> ffmpeg 03James Almer 07master:3e6829a8aa1e: build: fix compilation of tools with OpenCL enabled
[17:00:18 CEST] <jkqxz> iive:  Tell you how you need to configure a codec for it to use hardware.
[17:00:40 CEST] <iive> jkqxz: like *display ?
[17:01:20 CEST] <jkqxz> I'm not sure what you mean.
[17:01:34 CEST] <selsta> jamrial: bit OT, why does git apply fail and git am work? and thanks for the quick fix
[17:01:57 CEST] <iive> accelerations that go through X display driver, take display as parameter.
[17:02:00 CEST] <jamrial> no idea. maybe lack of newlines somewhere
[17:02:55 CEST] <jkqxz> iive:  Kindof.  If there were a hwcontext device encapsulating an X11 display then it could tell you that you need to pass that.
[17:03:57 CEST] <jkqxz> iive:  Though really those APIs work on a higher abstraction to avoid the dependence on X11.  You can pass a VAAPI or a VDPAU device.
[17:04:14 CEST] <jkqxz> (Which could have been created from an X11 display.)
[17:04:33 CEST] <iive> jkqxz: so you use it to pick the acceleration you want?
[17:05:09 CEST] <iive> do you have a link to the proposed patch/content of that hwconfig?
[17:05:10 CEST] <jkqxz> It describes what accele^Woffloading methods are possible, and what you need to do to use them.
[17:05:20 CEST] <jkqxz> Link above has it.
[17:06:33 CEST] <jkqxz> Later patches in the series use it in avconv (ffmpeg).
[17:08:35 CEST] <wm4> to be honest, "offloading" sounds just like "hwaccel" in that it's not clear whether all or just some decoding is done on the GPU
[17:09:37 CEST] <jkqxz> At least it doesn't imply that some happens on the CPU.
[17:10:10 CEST] <J_Darnley> FUCK THESE AUTOMATIC DEPENDENCIES!  I FUCKING HATE THEM!
[17:10:12 CEST] <wm4> "offloading" is often used for partial things
[17:10:42 CEST] <wm4> anyway.
[17:12:01 CEST] <iive> jkqxz: gah... what I see is completely useless.. It just connects pix_fmt to some flags...
[17:12:25 CEST] <wm4> ...
[17:13:04 CEST] <iive> some of these flags should not exist.
[17:13:29 CEST] <jkqxz> Such as?
[17:14:05 CEST] <iive> hw_device_ctx, I do assume that one depends heavily of the acceleration that is going to be picked
[17:14:19 CEST] <iive> but that is done by get_format().
[17:14:41 CEST] <iive> I guess this whole thing is an attempt to get rid of the get_format() path?
[17:14:55 CEST] <jkqxz> Not yet, but it could be at some later stage.
[17:15:08 CEST] <wm4> getting rid of get_format would be a bonus
[17:15:15 CEST] <wm4> but certainly not the whole purpose
[17:17:00 CEST] <wm4> iive: anyway, get_format and AVHWAccel is even more useless than the proposed patch (which you call useless)
[17:17:34 CEST] <wm4> both ffmpeg.c and mpv have to keep their own lists of supported hwaccels, and they contain redundant info that could be exported via the proposed patch
[17:20:12 CEST] <jkqxz> Note that one end result of this patch series is that there is that there is no mention at all of the generically-implemented hwaccels (DXVA2, VAAPI, etc.) in fftools/*.
[17:21:28 CEST] <wm4> jkqxz: I also wonder if we should avoid arrays of structs, so we can add new fields to it
[17:22:03 CEST] <wm4> so, we'd have either "const AVCodecHWConfig **hw_configs;", or accessor functions which access the struct array internally
[17:22:10 CEST] <jkqxz> Would you prefer an iterate_hw_configs function?
[17:22:37 CEST] <iive> wm4: yeh... it's all bad design from everywhere. and
[17:22:44 CEST] <wm4> jkqxz: it might be needed
[17:22:45 CEST] <jkqxz> Yeah, maybe.  Care to define exactly how that works?
[17:22:46 CEST] <wm4> iive: what
[17:23:03 CEST] <iive> yes, **hw_configs is a must 
[17:23:59 CEST] <iive> most of these pix_fmt <> flags would be generic and constant.
[17:24:02 CEST] <wm4> we could also add a "void *extensions;" field to the end of the struct, but that doesn't seem very nice either
[17:24:29 CEST] <wm4> (then we could use or replace this pointer and have it point to a new struct with new fields)
[17:24:46 CEST] <wm4> whatever avoids potential ABI issues
[17:25:14 CEST] <wm4> jkqxz: the simplest would be an accessor: const AVCodecHWConfig *av_codec_get_hw_config(AVCodec *codec, int index);
[17:25:27 CEST] <wm4> then the user would never see a AVCodecHWConfig[]
[18:36:12 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:a56ec48d426f: avformat/mxfenc: Add IEC DV25
[18:36:13 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:ef973bd98d8e: avformat/mxfenc: Fix labels for IEC PAL DV 420
[19:04:16 CEST] <cone-950> ffmpeg 03James Almer 07master:87e625c2633a: avcodec/encode: do proper cleanup on failure
[20:38:01 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:fbdab6eca787: avcodec/hevcdsp_template: Fix undefined shift
[20:38:02 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:c37138e01a93: avcodec/proresdec2: SKIP_BITS() does not work with len=32
[20:38:03 CEST] <cone-950> ffmpeg 03Michael Niedermayer 07master:4ee77cefaed0: avcodec/proresdec2: Use LAST_SKIP_BITS where possible
[21:30:13 CEST] <pgorley> rcombs: hi, i tested your patch on today's master (https://ffmpeg.org/pipermail/ffmpeg-devel/2017-September/216828.html) and it fails to compile, here are my logs: https://pastebin.com/6Ekess4M
[21:30:29 CEST] <pgorley> this is on android api 18, btw
[21:31:39 CEST] <rcombs> ah
[21:31:44 CEST] <rcombs> I think v4l2_buffers.c was added since I wrote that
[21:32:04 CEST] <rcombs> should just need to #include "libavformat/os_support.h" in that file
[21:32:06 CEST] <rcombs> give it a go?
[21:32:37 CEST] <pgorley> sure, i'll test that out
[21:33:54 CEST] <rcombs> pgorley: oh, that should correct the mmap issue you're seeing there, but it won't correct the lfind issue; that's independent
[21:34:28 CEST] <pgorley> yes i know, but if it does correct the mmap issue it's a step in the right direction
[21:34:59 CEST] <rcombs> do you actually need v4l2 on android pre-21?
[21:35:57 CEST] <pgorley> no clue, i was having trouble compiling ffmpeg on android earlier because of mmap, and that lead me to this
[21:36:08 CEST] <jkqxz> I noticed that function (lfind) in review and thought wtf because I'd never seen it before, but apparently it's in POSIX since 2001.
[21:36:13 CEST] <pgorley> it does fix the mmap issue
[21:36:23 CEST] <jkqxz> So another case of Android totally failing at standards?
[21:36:26 CEST] <rcombs> yup
[21:36:41 CEST] <rcombs> OK, sounds like we'll just want an ff_lfind or something
[21:36:53 CEST] <rcombs> it's pretty trivial: https://github.com/bminor/glibc/blob/73dfd088936b9237599e4ab737c7ae2ea7d710e1/misc/lsearch.c#L43
[21:36:55 CEST] <jkqxz> Or just write it in code, because it's trivial.
[21:37:02 CEST] <rcombs> yeah, or that
[21:37:08 CEST] <rcombs> it's used 5 times, though
[21:37:17 CEST] <jkqxz> And, like, you wouldn't need the pointless compare function.
[21:37:19 CEST] <rcombs> could just poach the glibc impl (LGPL!)
[21:38:02 CEST] <JEEB> jkqxz: welcome to bionic
[21:38:05 CEST] <jkqxz> Is it in more recent Bionic?
[21:38:09 CEST] <rcombs> yeah, 21
[21:38:18 CEST] <JEEB> right
[21:38:24 CEST] <JEEB> so if he raises API level it gets OK
[21:38:26 CEST] <rcombs> I feel like this could probably be done well by a macro that takes a comparator as an arg (rather than a function pointer)
[21:39:17 CEST] <rcombs> but ¯\_(Ä)_/¯ whatever works, as long as it's not leaving the call to glibc lfind
[21:39:30 CEST] <rcombs> could do a wrapper in os_support.h, alternately
[21:43:24 CEST] <rcombs> jkqxz: hey, did that API to check whether a hardware device advertises support for a given profile ever pan out?
[21:50:34 CEST] <jkqxz> For probing?  It got a bit further, but it's a bit too awkward to do in a useful way because you don't know enough information without some of the stream.  The conclusion was that it's better to just make the codec and try to use it.
[21:51:25 CEST] <jkqxz> pgorley:  Testplz <http://sprunge.us/JRgU>.
[21:52:01 CEST] <jkqxz> Definitely a "why would you ever use this function":  "30 insertions(+), 71 deletions(-)".
[21:54:56 CEST] <pgorley> corrupt patch at line 158 there's the version number missing
[21:55:21 CEST] <JEEB> that usually means a missing endline when you grabbed the patch
[21:55:29 CEST] <pgorley> ah maybe
[21:56:03 CEST] <pgorley> yup
[21:56:57 CEST] <jkqxz> Yeah.  git-formatted patches avoid that by the trailing thing at the end, but that's just a diff.
[21:57:27 CEST] <pgorley> jkqxz: is this for android?
[21:57:35 CEST] <jkqxz> Removing lfind.
[21:57:54 CEST] <jkqxz> I can build it here, I'm really wondering whether there are any other crazy functions which don't work.
[21:58:02 CEST] <pgorley> oh, alright
[21:58:11 CEST] <rcombs> jkqxz: I've got code to try it and fallback, but it involves actually starting ffmpeg.c, probing, etc&, so I'd like to get around that overhead in the common "device supports what it advertises and the file is pretty vanilla" case
[21:58:40 CEST] <rcombs> I mean, did you see how mmap() doesn't
[21:59:29 CEST] <jkqxz> Well, you were fixing that :P
[21:59:41 CEST] <jkqxz> Or shall I add that too?
[21:59:53 CEST] <rcombs> nah I'll get it
[21:59:58 CEST] <rcombs> just a missing #include
[22:06:32 CEST] <pgorley> jkqxz: it successfully built
[22:08:04 CEST] <rcombs> filed an issue about this: https://github.com/android-ndk/ndk/issues/537
[22:08:37 CEST] <jkqxz> Thanks for testing.  Patch on ML.
[23:15:58 CEST] <tmm1> jkqxz: have you seen this before (h264_qsv fails randomly with MFX_ERR_DEVICE_FAILED on windows)?
[23:17:10 CEST] <jkqxz> I've seen that bug, but I've never seen it at all myself.  I think it must be somehow restricted to only some subset of devices, but I've no idea how.
[23:17:50 CEST] <tmm1> i have a windows machine that never hits it, but i just got access to another one which is hitting it very often
[23:18:13 CEST] <tmm1> i can run the same command over and over and it fails almost half the time
[23:19:56 CEST] <jkqxz> Maybe write in the bug exactly what those machines are and the driver versions?
[23:21:09 CEST] <cone-950> ffmpeg 03Carl Eugen Hoyos 07master:9ba9c08aab9d: fate: Add a test for latm-in-dvb auto-detection, ticket #6657.
[23:22:55 CEST] <tmm1> sure, i'll add more details to the ticket
[23:23:29 CEST] <tmm1> trying to think of things i can try changing in qsvenc.c now that i'm able to repro consistently
[23:25:17 CEST] <BtbN> wm4, what's wrong with the hwaccel class logic? It looks fine to me?
[23:29:50 CEST] <cone-950> ffmpeg 03Carl Eugen Hoyos 07master:4590d073ccdc: lavf/mxfdec: Search all components of material track for source package.
[00:00:00 CEST] --- Wed Oct  4 2017