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

[burek]

[00:17:58 CET] <nevcairiel> jkqxz: so now vdpau works on amd but vaapi fails?
[00:18:25 CET] <nevcairiel> is any of these amd modes not hacky? :d
[00:18:37 CET] <nevcairiel> but hey it did improve on intel
[00:22:21 CET] <nevcairiel> considering intel is likely the reference for vaapi behavior..
[00:23:50 CET] <jkqxz> Yeah.  I think it's definitely a net positive change now, even if some mesa-vaapi does regress.
[00:24:41 CET] <nevcairiel> i wonder what one has to do to get vaapi work with field coding
[00:25:39 CET] <nevcairiel> the hwaccel hooks for that are mostly designed around how dxva2 wants it to happen, which is basically decoding both fields individually onto the same surface
[00:26:05 CET] <nevcairiel> maybe vaapi is just missing the bitstream data though, i see a lot of empty values with "XXX: interlaced" :D
[00:29:27 CET] <jkqxz> Yeah, I imagine VAAPI will work like that too.  I'm only familiar with H.264, but that indeed does it by decoding onto the same surface twice.
[00:30:35 CET] <jamrial> why isn't out software vc1 decoder bitexact anyway?
[00:30:56 CET] <nevcairiel> mostly lack of interest from any good devs
[00:31:04 CET] <nevcairiel> we lacked field coding support entirely for a long time
[00:31:17 CET] <iive> it isn't?
[00:31:20 CET] <nevcairiel> i think it was added in gsoc
[00:31:35 CET] <nevcairiel> but its not bitexact, obviously
[00:31:54 CET] <jamrial> kurosu touched it a couple years ago and yeah, he mentioned he didn't bother much with it since anyone watching vc1 would be using hardware decoding
[00:32:44 CET] <nevcairiel> at some point i hacked in field coding hwaccel despite the software decoder not even supporting that yet, just so hw decoding would at least work
[00:33:33 CET] <jkqxz> The gstreamer implementation for vaapi has a suspiciously matching set of "XXX: interlaced" comments.
[00:33:41 CET] <nevcairiel> heh
[00:33:50 CET] <nevcairiel> not very surprising
[00:33:57 CET] <nevcairiel> stuff like vc1 doesnt get implemented multiple times
[00:34:01 CET] <iive> they are (l)gpl, aren't they?
[00:34:45 CET] <nevcairiel> nothing wrong with that, just sad sometimes to not have another independent implementation to bugcheck against
[00:35:26 CET] <iive> :)
[00:36:11 CET] <Compn> because we are all hoping vc1 dies a painful death
[00:36:15 CET] <Compn> and we can just go h264 :P
[00:36:51 CET] <nevcairiel> it gets very rarely used these days only, some odd blu-rays use it, but only very rarely, and outside of that its probably dead now
[00:36:57 CET] <jkqxz> libyami looks different, possibly more complete.
[00:37:00 CET] <nevcairiel> wonder what stuff like windows movie maker encodes into these days
[00:37:01 CET] <jamrial> vc1 hasn't been relevant in forever. there are probably more blu-ray discs using mpeg2 than it
[00:37:36 CET] <iive> it's like a zombie. it is dead, but it still goes on, because it is part of a standard.
[00:38:31 CET] <nevcairiel> a few of the bbc documentary blu-rays used it, in field mode no less, it was quite odd =p
[00:38:51 CET] <jkqxz> Compn:  But I thought VP8^H9^H^H^HAV1 was the future...
[00:39:13 CET] <jamrial> several years ago game a lot of trailers would be released in wmv/vc1. mainly those for x360 games
[00:39:14 CET] <nevcairiel> we're undecided what the future is, but h264 is not it, its getting too old for that
[00:39:24 CET] <jamrial> but nowadays everything is just dumped to youtube
[00:39:25 CET] <iive> so AV1 is  vp10?
[00:39:36 CET] <nevcairiel> its like a hybrid of vp10, dalaa and t hor
[00:39:49 CET] <iive> with wavelets?
[00:39:50 CET] <nevcairiel> mostly vp10 with things from the others grafted on
[00:40:39 CET] <nevcairiel> there was an article once exploring the techs they imported from dalaa
[00:40:58 CET] <jamrial> it's pretty much vp10 with things like PVQ taken from daala and such
[00:42:52 CET] <jamrial> i'm glad they are being combined for that matter. we really didn't need three formats competing for the same market (web video)
[00:43:44 CET] <nevcairiel> vp9 was already pretty decent, it just lacked an ecosystem, maybe the AOM can fix that with AV1 and catch up to HEVC tech-wise in the same process
[00:44:27 CET] <nevcairiel> they just need to put more effort into the encoder beyond the use-cases that google needs it for :/
[00:51:39 CET] <TD-Linux> yeah, there's a lot of stuff in the pipe for webrtc style use cases
[02:44:43 CET] <cone-974> ffmpeg 03Thierry Foucu 07master:c512546689eb: Fix -Werror=parentheses error
[02:44:43 CET] <cone-974> ffmpeg 03Vittorio Giovara 07master:00c80798160f: fate: Add h264 extradata reload tests
[05:50:56 CET] <wpm> HELP: ERROR: gnutls not found using pkg-config when running configure on freebsd (freenas jail)
[05:54:35 CET] <wpm> what do I need to do to move past this?
[14:14:47 CET] <cone-248> ffmpeg 03Hendrik Leppkes 07master:99218ee30d7c: configure: properly add dxva2 link dependencies
[15:06:49 CET] <cone-248> ffmpeg 03Michael Niedermayer 07master:d79d8ef92762: cmdutils: remove duplicate windows.h include
[15:06:50 CET] <cone-248> ffmpeg 03kieranjol 07master:605f3084fc85: doc/filters: adds recently added -vf colorspace options
[16:12:57 CET] <wm4> michaelni: e5c7229999182ad1cef13b9eca050dba7a5a08da breaks my code
[16:13:54 CET] <wm4> it's also inconsistent with the audio path
[16:23:23 CET] <michaelni> wm4, do you have a sample with which this results i wrong values being returned ?
[16:23:50 CET] <wm4> hm didn't look at the date (2014), so it's unlikely that this caused my regression, odd
[16:24:25 CET] <wm4> it's just a decoder wrapper which wants to allocate a frame using a different pixfmt from AVCodecContext
[16:24:35 CET] <wm4> (not in git master)
[16:39:12 CET] <nevcairiel> why wouldnt you update the avctx format then
[16:44:14 CET] <wm4> because it's the format the user sees
[17:21:09 CET] <wm4> when does an encoder need to set extradata?
[17:27:19 CET] <nevcairiel> init
[17:27:35 CET] <wm4> what if I have it only on the first frame?
[17:27:45 CET] <nevcairiel> then you are screwed
[17:27:53 CET] <nevcairiel> or do what some other do, encode a fake frame
[17:28:10 CET] <jamrial> wm4: new extradata as side data?
[17:28:13 CET] <wm4> that's terrible
[17:28:24 CET] <wm4> jamrial: well it should be muxed properly
[17:28:28 CET] <nevcairiel> jamrial: that doesnt work with the majority of containers
[17:28:39 CET] <jamrial> containers should be adapted to handle it, then
[17:28:43 CET] <jamrial> look at my flac matroskaenc patch
[17:28:49 CET] <jamrial> which needs a review btw :p
[17:28:49 CET] <nevcairiel> not all cases can, reliably
[17:29:28 CET] <nevcairiel> you want streaming to work, so no seeking and writing it back later
[17:31:36 CET] <wm4> obviously it could delay writing the first packet and thus everything else)
[17:32:09 CET] <nevcairiel> for a generic solution you then end up delaying all streams by x packets in the hope the one stream you want finally sends its first frame
[17:33:43 CET] <nevcairiel> what encoder is this about anyway?
[17:34:01 CET] <wm4> mediafoundation
[17:34:09 CET] <nevcairiel> thats not an encoder
[17:35:09 CET] <nevcairiel> thats just an api
[17:35:27 CET] <wm4> mf encoders are supposed to have s somewhat uniform behavior, but in this case it's the intel qsv mft
[17:35:43 CET] <nevcairiel> why dont you use qsv as is
[17:36:13 CET] <wm4> does intel ship libmfx with their normal drivers?
[17:36:20 CET] <nevcairiel> the hardware variant yes
[17:36:35 CET] <nevcairiel> software only comes with the sdk
[17:36:41 CET] <nevcairiel> but who cares about the software decoder
[17:37:15 CET] <wm4> anyway, my hope was that it's also going to work on nvidia
[17:37:18 CET] <nevcairiel> also for MF, i would think the IMFMediaType would have a chance to contain extradata after init
[17:37:36 CET] <wm4> yes, but it doesn't
[17:41:03 CET] <wm4> actually it eats no less than 4 packets before it changes the output type
[17:42:15 CET] <wm4> this might even be against the MSDN docs (and the MS h264 encoder includes the extradata on init)
[17:43:46 CET] <nevcairiel> the funny thing is that QSV actually provides the extradata fter init, so there is no reason a MFT wrapping this couldnt do it
[17:44:01 CET] <wm4> yeah
[17:44:01 CET] <nevcairiel> but intel isnt very good at software
[17:44:02 CET] <nevcairiel> so
[17:45:05 CET] <nevcairiel> in any case still not sure what you hope to gain over just using qsvenc and nvenc respectively, after jkqxz recent work qsv at least works ok-ish again
[17:47:32 CET] <nevcairiel> i should setup some intel test rig again to see if qsv is worth using now for $work
[17:47:58 CET] <wm4> hm was the nvenc license situation resolved?
[17:48:17 CET] <nevcairiel> nvenc is no longer nonfree
[17:49:13 CET] <nevcairiel> the header was re-licensed as MIT by NVIDIA, and the binary it talks to is part of the driver, and if a driver isnt a system library worthy of the exception, then i dont know what is
[17:49:24 CET] <wm4> I also can't find a libmfx.dll on my system
[17:50:05 CET] <nevcairiel> it would be called libmfxhw(32|64).dll
[17:50:18 CET] <nevcairiel> or sw for the software variant
[17:50:52 CET] <wm4> oh right, they exist
[17:51:07 CET] <wm4> same for nvenc I suppose (no nvidia windows system here)
[17:51:19 CET] <nevcairiel> nvenc is directly part of the driver, yes
[17:51:25 CET] <wm4> so can qsv and nvenv return/take d3d surfaces?
[17:51:30 CET] <wm4> *nvenc
[17:51:40 CET] <nevcairiel> nvenc can, not sure if avcodec exports that yet
[17:52:00 CET] <nevcairiel> qsv probably as well, the qsv hwsurface stuff uses d3d surfaces in the background somewhere
[17:52:33 CET] <nevcairiel> since d3d is windows specific it may not be exposed in either
[17:52:44 CET] <wm4> because I'd like to avoid at least duplicating the filtering parts (the hope was that MF would make this transparent, but didn't test yet)
[17:53:09 CET] <nevcairiel> i only ever used MF for software decoding of vc1, never had it deal with d3d
[17:53:46 CET] <wm4> decoding to d3d surfaces works fine
[17:55:13 CET] <nevcairiel> would be interesting to get a dxva2 zero-copy path from dxva2 decoding to nvenc and/or qsvenc, because dxva2 is just d3d9 surfaces, so it would be very generic
[17:55:30 CET] <wm4> indeed
[17:56:05 CET] <wm4> btw. the intel mft explicitly doesn't support d3d9 on windows 10
[17:56:33 CET] <nevcairiel> intel likes deprecating stuff fast
[17:56:48 CET] <jkqxz> Hardware frame mapping support in libav should already be able to do that?  I think it might be missing the explicit d3d->qsv mapping, but the support is all there.
[17:56:53 CET] <nevcairiel> i still havent even bothered to play around with d3d11va because i have no reason to
[17:57:08 CET] <wm4> what frame mapping
[17:57:33 CET] <wm4> nevcairiel: the ability to actually access the nv12 data on the GPU without RGB conversion isn't a reason?
[17:57:55 CET] <jkqxz> Also retrieve_data forces it into software in avconv/ffmpeg, so a bit more funny needed there.  The equivalent cases in vaapi do work (decode with vaapi and encode with qsv).
[17:58:01 CET] <nevcairiel> my main focus is copy back which w orks fine as-is
[17:58:38 CET] <jkqxz> wm4:  av_hwframe_map() and vf_hwmap
[17:59:53 CET] <wm4> nevcairiel: well we want to be able to do it without copyback (later)
[18:01:46 CET] <nevcairiel> zero-copy encoding isn't something I'm personally very interested in, just playback
[18:02:32 CET] <nevcairiel> adding a full hardware path to the work encoding enging would probably mean i have to rebuild it .. again :p
[18:03:28 CET] <wm4> you don't use ffmpeg.c?
[18:03:44 CET] <nevcairiel> nah
[18:04:13 CET] <wm4> what's your work anyway?
[18:04:17 CET] <nevcairiel> that would give me way too many headaches
[18:04:32 CET] <nevcairiel> rather have something simple and feature-limited that I know does what I tell it to do :D
[19:40:32 CET] <cone-248> ffmpeg 03Andreas Cadhalpun 07master:90ebf3c42835: dds: limit 4 bpp handling to AV_PIX_FMT_PAL8
[19:40:33 CET] <cone-248> ffmpeg 03Andreas Cadhalpun 07master:a86ebbf7f641: libschroedingerdec: don't produce empty frames
[19:40:34 CET] <cone-248> ffmpeg 03Andreas Cadhalpun 07master:3c0328d58d98: libschroedingerdec: fix leaking of framewithpts
[20:37:04 CET] <rcombs> wm4: nevcairiel: fwiw autobsf delays muxing until the first frame is encoded; it'd probably be easy enough to provide some way to do that delay even when the muxer isn't using autobsf itself
[20:39:57 CET] <nevcairiel> doesnt autobsf assume the  to-bsf stream is also the first one to send a frame?
[20:40:14 CET] <nevcairiel> or does it queue frames from other streams?
[20:46:16 CET] <rcombs> it queues frames from everything until all streams have passed the muxer's check
[20:47:10 CET] <wm4> and then there's the question how the extradata would even be propagated
[21:26:30 CET] <cone-248> ffmpeg 03Michael Niedermayer 07master:2acee08a4a53: avutil/frame: Copy size=0 side data in ff_init_buffer_info()
[21:26:31 CET] <cone-248> ffmpeg 03Michael Niedermayer 07master:721c90f0f99c: avutil/frame: fix indention after last commit
[21:27:10 CET] <rcombs> wm4: it just waits to call write_header until all streams pass the check, so the encoder just has to put it in avctx (which ffmpeg copies to codecpar iirc)
[22:39:29 CET] <cone-248> ffmpeg 03Andreas Cadhalpun 07master:ffdc5d09e498: exr: fix out-of-bounds read
[22:39:30 CET] <cone-248> ffmpeg 03Andreas Cadhalpun 07master:ce3147eb1987: exr: reindent after previous commit
[23:59:58 CET] <cone-248> ffmpeg 03Martin Vignali 07master:52da3f6f70b1: libavcodec/exr : fix channel size calculation for uint32 channel
[00:00:00 CET] --- Thu Nov 17 2016