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

[burek]

[01:07:19 CEST] <jkqxz> wm4:  I agree that the Raspberry Pi / OpenMAX patch isn't very good (and OpenMAX deserves all hate we can throw at it), but this seems like a case where the thing should probably be accepted (suitably cleaned up) because it does have significant value to users and currently there is no sensible alternative.
[01:07:43 CEST] <nevcairiel> does mmal not offer encoding?
[01:08:07 CEST] <jkqxz> Is anyone actually working on it?
[01:08:22 CEST] <rcombs> I had a patch to add encoding once
[01:08:44 CEST] <rcombs> and have been saying ever since that one day I'll clean it up and get it working properly again
[01:09:54 CEST] <wm4> jkqxz: probably
[01:15:34 CEST] <rcombs> jkqxz: is all the infrastructure required to do relatively-painless full-hardware transcode pipelines (including filtering) already merged?
[01:15:46 CEST] <jkqxz> wm4:  And is going to post something working in the near future?
[01:15:54 CEST] <rcombs> (i.e. not actual encoder and filter implementations, but the mechanisms they need to wkr)
[01:15:56 CEST] <rcombs> *work
[01:16:52 CEST] <jkqxz> rcombs:  hwcontext stuff?  The remaining parts are stuck behind codecpar.
[01:17:04 CEST] <rcombs> ah
[01:17:09 CEST] <rcombs> so merged in libav and just not in ffmpeg yet?
[01:17:40 CEST] <jkqxz> Yes.  You can VAAPI decode-filter-encode in hardware with libav now.
[01:18:19 CEST] <rcombs> oh, those implementations have also been merged?
[01:18:20 CEST] <rcombs> sweet
[01:19:58 CEST] <jkqxz> There are still a lot of missing features, but the structural stuff is all there.
[01:21:57 CEST] <michaelni> wm4, patch works fine
[01:22:57 CEST] <wm4> michaelni: then I'll add some comments and push if nev is fine with it (tomorrow)
[01:23:34 CEST] <nevcairiel> i still find it fishy that codecpar could end up with no w/h at all w hen lowres is used
[01:23:48 CEST] <nevcairiel> but what do i care, people that use lowres deserve sillyness i guess
[01:24:31 CEST] <wm4> ffmpeg.c and maybe ffplay.c is most likely the only software using it this way
[01:36:45 CEST] <Daemon404> wm4, or at all
[01:47:16 CEST] <nevcairiel> once st->codec compat is removed we could probably force-disable lowres in find_stream_info and populate codecpar properly
[01:54:04 CEST] <BBB> ubitux: thanks for review!
[01:54:20 CEST] <BBB> ubitux: a few of those I already addressed in my github repo, Ill address the rest in next round
[01:54:31 CEST] <BBB> ubitux: and yes I have assembly for pretty much everything (on github)
[03:17:58 CEST] <cone-545> ffmpeg 03Michael Niedermayer 07master:2c697c650ca7: fate: force fixed point aac decoder in filter-meta-4560-rotate0
[03:29:22 CEST] <jamrial> michaelni: that test, shouldn't it do a codec copy for the audio?
[03:30:15 CEST] <jamrial> the important part is the video stream, there's no need to reencode the audio afaik
[03:31:11 CEST] <jamrial> you could even create the temp mov file without the audio stream from the source sample
[03:31:20 CEST] <jamrial> unless i'm missing something
[03:44:19 CEST] <michaelni> jamrial, i thought about using copy too but thought more testing maybe cant hurt, actually would have been nice we could have used float aac if it was bitexact on all platforms as that would have been the only float aac test that would have detected a +-1 difference
[03:50:37 CEST] <jamrial> alright
[04:14:16 CEST] <cone-545> ffmpeg 03Claudio Freire 07master:8005b6de4f88: AAC encoder: fix valgrind errors
[05:21:49 CEST] <cone-545> ffmpeg 03James Almer 07master:374974886aa7: fate: add missing filter-meta-4560-rotate0 dependencies
[07:09:08 CEST] <rcombs> just filed a radar for a ridiculous audiotoolbox issue
[07:10:03 CEST] <rcombs> was trying to tweak the decoder to not rely on parsers for channel counts + sampling rates, since I'm not sure how that'll interact with codecpar changes and there are some APIs that are meant to serve that purpose
[07:10:46 CEST] <rcombs> there's a property called "kAudioFormatProperty_ASBDFromMPEGPacket", which you pass to AudioFormatGetProperty ( AudioFormatPropertyID inPropertyID, UInt32 inSpecifierSize, const void *inSpecifier, UInt32 *ioPropertyDataSize, void *outPropertyData );
[07:11:03 CEST] <rcombs> and it's meant to parse an MPEG audio packet and give you some basic info (codec ID, channel count, sampling rate)
[07:11:26 CEST] <rcombs> you'd think `inSpecifier` would be a pointer to the packet data, and `inSpecifierSize` would be the size of the packet
[07:11:57 CEST] <rcombs> nope, `inSpecifierSize` is 4, and `inSpecifier` is& the first 4 bytes of the packet (containing the sync word)
[07:12:07 CEST] <rcombs> not a pointer to the first 4 bytes, just the first 4 bytes casted to `const void*`
[07:13:22 CEST] <rcombs> naturally, none of this is documented
[11:21:16 CEST] <nevcairiel> rcombs: giving it 4 bytes of the packet seems fine for mpeg audio, but the type casting sure is mad
[11:21:26 CEST] <rcombs> nevcairiel: yeah
[11:21:39 CEST] <rcombs> I think it's probably a mistake somewhere
[11:22:03 CEST] <rcombs> like, someone meant to take a void** or something
[11:22:19 CEST] <rcombs> I can't find any instance of code that actually uses this
[11:23:30 CEST] <rcombs> but hey there's always ff_mpa_decode_header
[11:23:50 CEST] <wm4> but that's cheating!
[11:24:39 CEST] <rcombs> while researching this I found code in the lib to parse the same information out of AC3 headers
[11:24:45 CEST] <rcombs> (undocumented, unsupported)
[11:25:43 CEST] <rcombs> though technically usable without any private symbols, since it's all via this "property" API
[11:31:26 CEST] <ubitux> anyone has some video tearing stress test?
[11:32:46 CEST] <wm4> those vertically moving bars are good for it
[12:08:22 CEST] <wm4> ubitux: OGM with srt subtitles that are exported as "text", opinion? https://0x0.st/PWS.ogm
[12:08:40 CEST] <wm4> also, ogm still has completely broken timestamps
[12:09:00 CEST] <nevcairiel> kierank: since this is likely from your world somewhere, do you know if mpeg2 intra-refresh has some sort of metadata to indicate how long until the image is fully reconstructed, like h264 has?
[12:10:04 CEST] <ubitux> wm4: looks wrong since it contains markup
[12:10:21 CEST] <ubitux> probably safer to make them export as subrip by default
[12:10:29 CEST] <wm4> maybe the text decoder should always redirect to srt
[12:10:48 CEST] <wm4> since that is what many players probably do anyway
[12:11:32 CEST] <ubitux> i don't know, maybe&
[12:11:45 CEST] <ubitux> quick fix is to just fix the codec id in the demuxer
[12:23:45 CEST] <wm4> ubitux: also, converting subs from ogm to srt with ffmpeg makes the tags show up
[12:23:51 CEST] <wm4> strictly speaking this is incorrect
[12:24:18 CEST] <ubitux> ?
[12:24:44 CEST] <wm4> the srt file contains things like "<i>The wind came down... </i>"
[12:24:54 CEST] <wm4> no attempt to escape the tags
[12:25:06 CEST] <wm4> the source codec is "text", so it should do that
[12:28:34 CEST] <ubitux> codec being text means it will consider tags are part of the text, they're not going to be stripped
[12:28:43 CEST] <ubitux> if you want "text" in your srt, you need to -c:s text
[12:29:02 CEST] <ubitux> again, the issue is simply that it's exported as text while it's actually not
[12:40:27 CEST] <wm4> I don't get that but whatever
[12:55:02 CEST] <kierank> nevcairiel: yes I have seen it
[12:55:23 CEST] <kierank> Not sure about metadata
[13:12:43 CEST] <cone-807> ffmpeg 03Martin Vignali 07master:6d7f5667a0c4: avcodec/exr: enable mipmap, ripmap decoding
[14:39:21 CEST] <ghici> hello
[14:48:26 CEST] <ghici> i`m trying to re encode just audio from e-ac3 to mp2 audio from a ts to a ts, video is copied without transcoding, and from time to time i get some : exponent out-of-range , error decoding the audio block
[14:48:46 CEST] <ghici> and at that time you can hear some glitches. 
[14:50:57 CEST] Action: durandal_1707 summons reviews
[14:54:56 CEST] <BtbN> Hm, is there no way to select a specific decoder with the ffmpeg cli util, or am I just blind?
[15:00:23 CEST] <nevcairiel> specify -c before the inpout file
[15:00:24 CEST] <atomnuker1> yeah there is, put -c:a <decoder> before -i
[15:05:33 CEST] <BtbN> It didn't like that, but I'll rebuild and try again
[15:16:34 CEST] <BtbN> There's a space at the end of the decoder name, nevermind...
[15:59:07 CEST] <kierank> does libavcodec allow proprietary codec plugins?
[15:59:12 CEST] <kierank> seems to be what that guy is doing
[15:59:24 CEST] <BtbN> libavcodec supports plugins?
[16:00:33 CEST] <BtbN> you mean that guy on the ml, right?
[16:01:20 CEST] <TD-Linux> kierank, yes, libfdk-aac
[16:01:32 CEST] <kierank> that's not distributable
[16:01:47 CEST] <BtbN> libfdk-aac isn't proprietary. It just has a weird as hell license that's not GPL compatible.
[16:02:07 CEST] Action: TD-Linux is not sure how that's better than AGPL
[16:02:20 CEST] <BtbN> It doesn't taint the stream coming out of it?!
[16:02:38 CEST] <BtbN> it only has weird clauses about what derived works have to be named, which is what makes it incompatible
[16:02:56 CEST] <TD-Linux> I don't think the interpretation of AGPL "taining the stream" is correct
[16:03:12 CEST] <TD-Linux> might be wise to email the fsf
[16:03:28 CEST] <TD-Linux> (or not care about j2k...)
[16:03:47 CEST] <BtbN> This is unrelated to the j2k guy.
[16:03:53 CEST] <thardin> agpl doesn't taint anything. it just prevents you from doing SaaS kind of things
[16:04:35 CEST] <Daemon404> "just"
[16:04:50 CEST] <BtbN> If youtube would use an AGPL ffmpeg for encoding their videos, they would have to give their modified ffmpeg source along with it.
[16:04:56 CEST] <BtbN> I'd call that "tainting the stream"
[16:05:07 CEST] <thardin> no, they would have to give the source code for all of youtube
[16:05:36 CEST] <kierank> I wasn't even talking about lgpl
[16:05:38 CEST] <durandal_1707> nice
[16:05:39 CEST] <kierank> I'm talking about that suresh guy
[16:06:05 CEST] <thardin> so as a license it's a tool that should be used.. carefully
[16:06:11 CEST] <BtbN> kierank, it's fine what he's doing, as long as he doesn't distribute his modified copy, he can do whatever he wants.
[16:06:19 CEST] <kierank> ofc
[16:06:31 CEST] <ubitux> http://sprunge.us/fLCI thanks gdb
[16:06:38 CEST] <ubitux> useful as usual
[16:27:08 CEST] <Daemon404> wow no new codecpar bugs today?
[16:31:32 CEST] <durandal_1707> just because no time...
[16:31:44 CEST] <RiCON> how much time left on that 2-day deadline?
[16:31:56 CEST] <RiCON> some bug will show up in the last minutes
[16:36:29 CEST] <wm4> concat is still left
[16:37:27 CEST] <Daemon404> yeah
[16:37:36 CEST] <Daemon404> im not sure whats going on with it
[16:37:54 CEST] <Daemon404> it's a 1 byte difference, and the decoded result is the same
[16:38:00 CEST] <Daemon404> as is output to e.g. .h264
[16:38:13 CEST] <Daemon404> i resent that demxuer
[16:38:44 CEST] <ubitux> did you ask nicolas?
[16:39:08 CEST] <Daemon404> i dont think he'd be able to to help re: codecpar
[16:39:35 CEST] <Daemon404> also some bsf crap is happening, which im convince is workign correctly... but yet
[16:39:48 CEST] <Daemon404> also it leaks memory in git master (which i fixed in codecpar because i had to)
[16:40:06 CEST] <Daemon404> it's just an all around meh piece of code that is "useful"
[17:17:38 CEST] <Daemon404> wm4, yeah i just cant figure out why concatdec is being this way
[17:17:51 CEST] <Daemon404> i mean, it *must* be to do with bsf crap
[17:20:12 CEST] <wm4> so all packets are 1 byte too long?
[17:21:00 CEST] <Daemon404> no
[17:21:05 CEST] <Daemon404> there's some odd difference
[17:21:37 CEST] <Daemon404> and it's all in the packets themselves afaict
[17:21:49 CEST] <Daemon404> (if i mux to mp4, the only non-pos differences are in mdat(
[17:22:36 CEST] <Daemon404> going to binary diff the .avi output now
[17:27:03 CEST] <Daemon404> http://chromashift.org/a.tar.xz <-- output in 3 formats
[17:31:37 CEST] <wm4> h264: AVC: nal size 100663272
[17:31:44 CEST] <Daemon404> yes i know
[17:33:23 CEST] <Daemon404> oh... hmmm
[17:33:33 CEST] <Daemon404> it is perhaps the way teh bsd inside concatdec.c is acting with the muxing
[17:33:45 CEST] <Daemon404> because when you output to a format that uses annexb (.h264, .ts) it is fine
[17:33:55 CEST] <Daemon404> but when it is a mp4-like output, it fucks uo
[17:34:07 CEST] <Daemon404> when it does mp4style->annexb->backtomp4
[17:34:41 CEST] <Daemon404> likely because concatdec is doing bistream filtering in the demuxer itselg
[17:36:06 CEST] <Daemon404> though im not sure where/why it messes up
[17:38:56 CEST] <Daemon404> actually where the hell is concatdec creating streams
[17:41:37 CEST] Action: Daemon404 donest understand this crap at all
[17:42:51 CEST] <nevcairiel> does concatdec even work on master for mp4?
[17:42:57 CEST] <Daemon404> yes
[17:43:03 CEST] <nevcairiel> i remember it forcing annexb conversion, so how would that work with mp4
[17:43:16 CEST] <Daemon404> i assumign during muxing it parses it back to mp4 format
[17:43:20 CEST] <Daemon404> in the muxer
[17:43:24 CEST] <Daemon404> this is concat*dec*
[17:43:58 CEST] <Daemon404> it might have relied on updating stuff during ff_read_packet that cant be now
[17:43:58 CEST] <nevcairiel> maybe whatever the bsf is doing needs to shove the new extradata somewhere?
[17:44:20 CEST] <nevcairiel> its probably the same old problem, extradata can't be updated after-the-fact
[17:44:29 CEST] <Daemon404> oh
[17:44:34 CEST] <Daemon404> i think it might be that it shouldnt have extradata
[17:44:51 CEST] <Daemon404> maybe the muxer is getting the old mp4 extradata + annexb format packets
[17:45:00 CEST] <nevcairiel> sounds like it from that error
[17:45:40 CEST] <nevcairiel> the bsf usually converts the extradata to annexb format
[17:45:51 CEST] <nevcairiel> not sure if mp4 needs that or it would find it from the stream
[17:46:08 CEST] <nevcairiel> h264 split function would probably extract it from the stream either way
[17:48:06 CEST] <Daemon404> i have no idea where/how to fix this though
[17:48:51 CEST] <Daemon404> i cant even figure out where concatdec is creating streams
[17:49:57 CEST] <Daemon404> hmm copy_stream_props
[17:56:11 CEST] <Daemon404> nevcairiel, setting extradata to NULL (and size to 0) right after  avcodec_parameters_copy fixes it
[17:56:19 CEST] <Daemon404> but uh... i highly doubt that is correct.
[17:56:33 CEST] <nevcairiel> yes, you should free it and not just null it
[17:56:34 CEST] <nevcairiel> :D
[17:56:42 CEST] <Daemon404> i mean for non-h264 codecs :P
[17:56:50 CEST] <nevcairiel> well clearly only for h264
[17:57:02 CEST] <Daemon404> if h264 -> null?
[17:57:05 CEST] <Daemon404> is that ok? lol
[17:57:08 CEST] <nevcairiel> av_freep!
[17:57:16 CEST] <Daemon404> same idea
[17:57:20 CEST] Action: Daemon404 leaks nevcairiel's memoru
[17:57:57 CEST] <nevcairiel> its not ideal, but it is "correct" for some definitions of the word
[17:57:59 CEST] <wm4> add random hacks until fate passes
[17:58:00 CEST] <Daemon404> i guess i dont feel too bad about it
[17:58:09 CEST] <Daemon404> concatdec already has stupid h264-specific bsfs
[17:58:20 CEST] <wm4> oooh
[17:58:25 CEST] <nevcairiel> the ideal case would be to get the annexb extradata out of the bsf and set that as extradata instead
[17:58:29 CEST] <Daemon404> yes concatdec ONLY uses bsfs for h264
[17:58:30 CEST] <wm4> is it related to the fact that the h264 bsf changes the avctx extrdata?
[17:58:47 CEST] <kierank> Gramner: any suggested speedups to atomnuker1's code: https://0x0.st/PWU.patch
[17:58:54 CEST] <wm4> can't wait for the new bsf API
[17:58:56 CEST] <kierank> it's doing planar 10-bit to uyvy422 10-bit
[17:59:02 CEST] <nevcairiel> but if you can't do the ideal case, then set no extradata for h264, because then some other code will step in and extract the new extradata back out of the actual stream =p
[17:59:11 CEST] <Daemon404> yes
[17:59:22 CEST] <Daemon404> concatdec is a poo-pile.
[17:59:58 CEST] <Daemon404> keep in midn concatdec onyl even does this for h264
[18:00:00 CEST] <Daemon404> hevc? nah.
[18:01:00 CEST] <jamrial> kierank: that function is sse2, not ssse3
[18:02:53 CEST] <Daemon404> fix pushed
[18:02:59 CEST] <Daemon404> \o/
[18:04:28 CEST] <Daemon404> no open bugs \o/
[18:04:57 CEST] <wm4> awesome
[18:07:04 CEST] <neufeld> Just a heads-up, I've filed a bug against glibc https://sourceware.org/bugzilla/show_bug.cgi?id=19917 in which the ffmpeg x.264 library multi-threading is badly broken (adding a second thread slows things down, adding more makes it worse).  I found the bad commit with a git bisect.  I figured people here might be interested as well.
[18:08:40 CEST] <wm4> wow
[18:08:50 CEST] <wm4> can you link the commit? (a gitweb url or so)
[18:09:00 CEST] <Daemon404> luckily not much ahs moved to 2.23 yet...
[18:10:31 CEST] <Gramner> kierank: the loads could be done as 3-arg avx ops instead of explicit mova:s (maybe by changing the CLIPW macro to take 3-4 args?). one of the unpacks doesn't have to be 3-arg, also the punpckh + punpckl combo is called a butterfly and the SBUTTERFLY macro does that. you can use fewer vector registers
[18:10:41 CEST] <Gramner> those changes aren't really going to make stuff faster though
[18:10:57 CEST] <Daemon404> wm4, https://sourceware.org/ml/glibc-cvs/2015-q3/msg00435.html
[18:11:07 CEST] <Daemon404> seems liek an odd revision to break on?
[18:11:32 CEST] <Daemon404> oh, reading closer, maybe not
[18:11:37 CEST] <wm4> didn't he say it's bisected
[18:12:10 CEST] <wm4> lol at glibc delayed loading making everythign horrible
[18:28:01 CEST] <BBB> ubitux: the obvious answer is I dont really care about it"
[18:28:34 CEST] <ubitux> then ignore and move on :p
[18:29:48 CEST] <BBB> the nice thing on top of colormatrix is that this thing actually *does* have simd
[18:30:32 CEST] <BBB> I can work on mt also, shouldnt be difficult (although you never know&)
[18:31:11 CEST] <Shiz> unsurprisingly, ifunc hell makes things worse
[18:31:54 CEST] <BBB> brb
[18:56:50 CEST] <BtbN> oh great. This CUVID decoder does not have its own parser... I guess the ffh264 bitstream parser can't be invoked independently?
[18:58:18 CEST] <nevcairiel> actually the cuvid api has a parser
[18:58:28 CEST] <BtbN> only on Windows
[18:58:36 CEST] <nevcairiel> well then you are screwed =p
[18:59:05 CEST] <BtbN> it wants all kind of h264 bitstream info, just like the normal hwaccels
[18:59:08 CEST] <nevcairiel> without that cuvid is a slice decoder, so make it a hwaccel
[18:59:20 CEST] <nevcairiel> everything else would be insane :)
[19:00:13 CEST] <BtbN> it's pointless as a hwaccel, the whole idea is that it generates AV_PIX_FMT_CUDA frames that the potential future CUDA filters and nvenc can then process without the frames ever leaving GPU memory
[19:00:51 CEST] <nevcairiel> hwaccels generate frames in a hwaccel pixfmt
[19:01:41 CEST] <BtbN> CUVID would be a very weird hwaccel, it doesn't need any other outside help like the other ones
[19:02:04 CEST] <Daemon404> [17:58] <@BtbN> only on Windows <-- wut
[19:02:08 CEST] <Daemon404> lol.
[19:02:24 CEST] <BtbN> Daemon404, it probably just uses some Windows-Media-API for the parsing?
[19:02:37 CEST] <Daemon404> no idea
[19:02:38 CEST] <nevcairiel> it does not
[19:02:47 CEST] <Daemon404> even more lulz then
[19:07:02 CEST] <nevcairiel> anyway if the complexity of that code goes through the roof, it also kinda defeats the point =p
[19:10:15 CEST] <BtbN> it would probably work as hwaccel and with an additional ffmpeg_cuda.c
[19:18:52 CEST] <BtbN> meh, don't feel like digging into that right now
[19:19:01 CEST] <BtbN> It seems pretty straight forward though
[19:19:25 CEST] <BtbN> Just _a lot_ of code that's required before testing it becomes possible at all
[19:21:04 CEST] <Daemon404> isnt that kind of par for the course for most hw things
[19:22:21 CEST] <BtbN> depends, it's usualy worse if Intel is involved.
[19:27:28 CEST] <jkqxz> BtbN:  Making the hwaccel output work sensibly isn't too bad.  Look at <https://git.libav.org/?p=libav.git;a=commit;h=5d273d3efac340ef8de445c955ff44c7abed4e8f>.
[19:28:06 CEST] <BtbN> I'm aware of how it works, I just don't feel like implementing all that stuff for CUDA right now
[19:30:13 CEST] <fritsch> when reading this diff
[19:30:20 CEST] <fritsch> wondering if the "output_format" makes any sense
[19:30:28 CEST] <fritsch> or if it's really coming via VPP
[19:30:32 CEST] <fritsch> mapped to something ffmpeg internal
[19:30:39 CEST] <fritsch> else: it's pointless
[19:31:07 CEST] <BtbN> which output_format?
[19:31:37 CEST] <fritsch> ah I see it
[19:31:40 CEST] <fritsch> they do it with vpp in deed
[19:32:04 CEST] <fritsch> they specify it in the ctx
[19:32:09 CEST] <fritsch> i wonder if they really tested it
[19:32:20 CEST] <fritsch> last I looked ... VAAPI could not reliable share buffers
[19:32:23 CEST] <fritsch> other than NV12
[19:32:31 CEST] <fritsch> or RGBA via vaPutSurface
[19:32:50 CEST] <BtbN> it's probably left inside of its buffer, and passed around as VAAPI frame
[19:33:00 CEST] <fritsch> av_hwframe_transfer_data <-
[19:33:24 CEST] <BtbN> that's called in vf_hwdownload/hwupload
[19:33:36 CEST] <fritsch> yeah and here the output->format is set via the ctx
[19:34:27 CEST] <fritsch>     // do so.  Assume for now that we are always dealing with YUV 4:2:0, so
[19:34:30 CEST] <fritsch> +    // pick a format which does that
[19:34:33 CEST] <jkqxz> The transfer is only done there if you actually want output in normal memory.  "-hwaccel_output_format vaapi" gives you the hardware surface directly with no copying.
[19:34:34 CEST] <fritsch> haha
[19:34:56 CEST] <fritsch> knowing the internals of the vaapi driver ...
[19:35:09 CEST] <fritsch> it's not easily possible to get those without a copy
[19:35:41 CEST] <fritsch> last I looked they did a full copy to either an X11Picture or you got the data by using EGL transfer via drm
[19:36:13 CEST] <fritsch> ouh and it seems the run it frame_threaded
[19:36:24 CEST] <jkqxz> An AV_PIX_FMT_VAAPI AVFrame is just a VASurfaceID.
[19:36:28 CEST] <fritsch> yeah
[19:36:51 CEST] <fritsch> if we talk about color conversion
[19:37:08 CEST] <fritsch> you can only do that in VPP
[19:37:18 CEST] <fritsch> and after that is done - you did not yet share those buffers (data)
[19:37:46 CEST] <fritsch> so getting the frames out there for display / postprocessing (without vpp) was the big issue with vaapi
[19:37:49 CEST] <fritsch> in the past
[19:37:58 CEST] <BtbN> the idea is to not get them out of there, ever
[19:38:08 CEST] <fritsch> good :-)
[19:38:29 CEST] <fritsch> so use the c*pled vaapi display api?
[19:38:41 CEST] <BtbN> or just encode it again
[19:38:58 CEST] <jkqxz> The case that patch adds is intending to support hardware transcode, not output of any form.
[19:39:01 CEST] <fritsch> which also only works if you use vaapi again
[19:39:04 CEST] <BtbN> libav is pushing hard for full-hw-transcode
[19:39:07 CEST] <fritsch> jep
[19:39:12 CEST] <fritsch> seen that in libyami
[19:39:33 CEST] <jkqxz> (You can also pass them into opencl and do whatever there, if you like.)
[19:39:35 CEST] <fritsch> vaapi's big problem is: sharing the (decoded) data with something standard
[19:39:48 CEST] <fritsch> jkqxz: how does that passing happen without a copy?
[19:40:11 CEST] <fritsch> how to acces the real data from opencl?
[19:40:17 CEST] <jkqxz> They're just DRM surfaces.  Both APIs can deal with them.
[19:40:27 CEST] <fritsch> drm can to my knowledge only deal with NV12
[19:40:52 CEST] <jkqxz> (You can also do whatever else with DRM surfaces that you like, like DRI2 for display in X.)
[19:41:44 CEST] <fritsch> this again depends on the surface layout / format
[19:41:53 CEST] <fritsch> to my knowledge the only direct transferable is NV12
[19:42:01 CEST] <fritsch> which also only works for intel's libva-driver
[19:43:03 CEST] <jkqxz> No, VPP can do arbitrary transformations between surface formats.
[19:43:13 CEST] <fritsch> :-) ey
[19:43:16 CEST] <fritsch> we talk about sharing those
[19:43:19 CEST] <fritsch> not about what vpp can do
[19:43:34 CEST] <fritsch> i fixed some segfaults with VPP in the intel driver when implemented:
[19:43:36 CEST] <fritsch> https://github.com/xbmc/xbmc/blob/master/xbmc/cores/VideoPlayer/DVDCodecs/Video/VAAPI.cpp#L1255
[19:43:58 CEST] <fritsch> and when we last checked, we only could share NV12 which got implemented for us
[19:44:03 CEST] <fritsch> and RGBA which is expensive
[19:44:46 CEST] <fritsch> is there a real drm api in place now, that works completely without EGL? or is it still used the same?
[19:45:21 CEST] <fritsch> i did not see that gwenole's patches would have been merged into mesa / nor intel driver
[19:45:32 CEST] <jkqxz> You share by using VPP to go to/from whatever DRM buffer you have from somewhere else?  So far I've only used this with DRI2, but it certainly works for both capture and display in X.
[19:45:45 CEST] <fritsch> can you show me your code?
[19:50:09 CEST] <jkqxz> For what?  To read from/write to DRM buffers you get the buffer name (from whatever other place, like DRI2) and then create VA surfaces out of them with the attributes for that.  Then using VPP on them just works and everything is good.
[19:51:17 CEST] <fritsch> for display would have been interesting
[19:51:24 CEST] <fritsch> but I see you are mainly into transcoding
[19:54:35 CEST] <BBB> ubitux: github now has multithreading and all your comments are addressed
[19:54:48 CEST] <BBB> ubitux: I can simply split it in two patches and re-submit, is that ok with you?
[19:54:56 CEST] <ubitux> sure
[19:56:26 CEST] <jkqxz> fritsch:  Most of an lavd driver for X11 capture is at <http://ixia.jkqxz.net/~mrt/vaapi/ffmpeg/v6/0006-libavdevice-XCB-DRI2-VAAPI-screen-capture-driver.patch> (working but never cleaned up; also uses the older form of the VAAPI stuff, which got replaced by hwcontext).
[19:56:39 CEST] <wm4>  concatdec is f0 9f 92 a9
[19:56:42 CEST] <wm4> uh what
[19:56:53 CEST] <Daemon404> wm4, ?
[19:56:58 CEST] <Daemon404> i already pushed a fix to concatdec
[19:56:59 CEST] <wm4> your commit message
[19:57:01 CEST] <BtbN> is that hwcontext stuff for vaapi even in ffmpeg?
[19:57:10 CEST] <wm4> BtbN: no
[19:57:11 CEST] <Daemon404> wm4, your unicode is outdated
[19:57:19 CEST] <Daemon404> lacks emoji
[19:57:25 CEST] <wm4> ok
[19:57:29 CEST] <wm4> (good)
[19:57:29 CEST] <Daemon404> its the "pile of poo" emoji
[19:58:35 CEST] <fritsch> jkqxz: thx much - i am looking
[20:02:49 CEST] <jkqxz> Output is basically the same, you just write to the surfaces and swap buffers rather than waiting for buffer changes and reading.
[20:06:06 CEST] <fritsch> i will have a detailed look when we get hevc-10 bit support as we need a new way in kodi for handling these
[20:08:59 CEST] <wm4> I wonder how anyone will do hevc 10 on GLES shit
[20:09:03 CEST] <wm4> because it has no matching texture format
[20:09:57 CEST] <jkqxz> Convert to 8-bit and hope noone notices.
[20:10:06 CEST] <fritsch> hehehehe
[20:10:12 CEST] <BBB> ubitux: enjoy round 2 of review!
[20:10:20 CEST] <wm4> good joke... oh wait they'll totally do that
[20:10:30 CEST] <fritsch> they really do that ...
[20:10:40 CEST] <fritsch> to keep their vaPutSurface working
[20:10:46 CEST] <BBB> wm4: Im confused, cant you upload to uint16 in opengl?
[20:11:00 CEST] <wm4> BBB: GLES has no 16 bit fixed point texture format
[20:11:03 CEST] <BBB> wm4: (and then have a shader that multiplies by 64)
[20:11:14 CEST] <fritsch> we basically want to avoid the conversion of the originally decoded data ..
[20:11:16 CEST] <wm4> desktop GL does and always did
[20:11:35 CEST] <BBB> oh I see
[20:11:44 CEST] <BBB> es
[20:11:45 CEST] <BBB> :-p
[20:11:47 CEST] <fritsch> but vaapi guys do it that way ... they make an RGB32 conversion
[20:11:58 CEST] <fritsch> to keep their api working
[20:12:51 CEST] <wm4> without colorspace/range hints?
[20:12:55 CEST] <jkqxz> vaPutSurface() is an abomination.
[20:13:09 CEST] <fritsch> vaPutSurface has some old flags
[20:13:14 CEST] <BBB> ubitux: next thing I could do is to add scaling to this filter, and then call it swscale :-p
[20:13:16 CEST] <fritsch> for BT709 / BT 601
[20:13:24 CEST] <fritsch> but now they have proper implemented VPP color conversion
[20:13:46 CEST] <wm4> not too much better
[20:13:49 CEST] <fritsch> not really
[20:13:56 CEST] <fritsch> but they wanted to do it without it
[20:14:14 CEST] <fritsch> when the first patches appeared I intervened and asked to do it "right"
[20:14:25 CEST] <fritsch> and in deed the intel guy came back with vpp patches
[20:14:32 CEST] <fritsch> i was quite impressed
[20:15:27 CEST] <fritsch> for the buffer sharing ... perhaps one can misuse a RGBA32 buffer (just the data) to get the values in
[21:11:46 CEST] <ubitux> BBB: wait, you added rgb2yuv too?
[21:11:53 CEST] <BBB> ?
[21:12:03 CEST] <BBB> rgb2yuv was always there
[21:12:11 CEST] <ubitux> erh yeah indeed my bad
[21:12:18 CEST] <ubitux> my brain didn't process it
[21:12:32 CEST] <BBB> to convert yuv to yuv with a rgb intermediate, you need rgb2yuv and yuv2rgb :-p
[21:26:14 CEST] <Daemon404> wm4, https://github.com/dwbuiten/FFmpeg/issues/31
[21:26:33 CEST] <Daemon404> oh, duh youre there
[21:27:06 CEST] <Daemon404> reading is hard
[21:28:50 CEST] <wm4> parsers should have been fixed before that but elenril doesn't have anything ready lol
[21:42:42 CEST] <wm4> " This file can be READ ONLY on a Panasonic TV (HDR + 4K) !!! "
[21:42:43 CEST] <wm4> lol?
[21:44:10 CEST] <nevcairiel> proprietary formats etc
[21:44:34 CEST] <wm4> that's the thing that was just posted to ffmpeg-devel, according to durandal_1707 it's DRMed
[21:44:39 CEST] <BBB> security through obscurity
[21:44:49 CEST] <BBB> if you make sure only these tvs can read it, you dont need drm
[21:44:54 CEST] <BBB> \o/
[21:50:31 CEST] <durandal_1707> av_strcasecmp is broken
[00:00:00 CEST] --- Thu Apr  7 2016