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

[burek]

[01:00:11 CEST] <jkqxz> philipl:  What else do you want?  The DRM API sits underneath both VAAPI and all existing Linux Vulkan drivers for device and memory management, so introducing anything else seems pretty weird to me.
[04:18:35 CEST] <philipl> jkqxz: I wasn't asking for anything new - more just what I should use if I want to try and wire them together.
[04:27:03 CEST] <philipl> Wouldn't be surprised if this doesn't work well in practice. The dma_buf extension for vulkan doesn't provide a way to specify the memory layout of the image you are trying to import.
[04:28:44 CEST] <philipl> Ok, There's another extension for that.
[04:29:18 CEST] <atomnuker> that extension was just merged into the spec
[04:29:27 CEST] <atomnuker> and isn't enabled by default
[04:29:31 CEST] <philipl> yay
[04:29:39 CEST] <atomnuker> no implementation supports it yet either
[04:29:46 CEST] <philipl> So today it probably requires the same intermediate buffer thing I'm doing with cuda.
[04:30:22 CEST] <atomnuker> be happy there's been progress, I've been bugging the people responsible since february
[04:30:59 CEST] <philipl> I appreciate it.
[04:31:15 CEST] <philipl> It'll be a while before I have the opportunity to try this out, so maybe it'll get implemented somewhere by then.
[04:31:29 CEST] <philipl> I guess I should dig up an nvidia person to bug about their problems...
[11:07:10 CEST] <durandal_1707> michaelni: you gonna apply patches soon?
[11:37:15 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:c905840e8c0a: avcodec/tiff: check remaining packet size for strips
[11:37:15 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:9a9034958aec: avcodec/rasc: Fix off by 1 error in vertical coordinate
[11:37:17 CEST] <cone-030> ffmpeg 03Michael Niedermayer 07master:f515c978f63f: avcodec/rasc: unref both frames on reinit
[11:37:31 CEST] <michaelni> durandal_1707, rasc/tiff pathes applied
[13:23:00 CEST] Action: durandal_1707 puts self into hibernation mode, wake me up when someone pings me!
[13:41:46 CEST] <atomnuker> durandal_1707: you seem bored
[13:42:15 CEST] <durandal_1707> so?
[13:42:40 CEST] <atomnuker> try finishing diablo 1 in 12 hours (making sure you clean up each floor)
[13:43:15 CEST] <durandal_1707> im playing portal games
[13:43:43 CEST] <durandal_1707> still not finished
[13:44:11 CEST] <atomnuker> eh? the first portal is beatable in 3 hours max, the second one in 12
[13:44:46 CEST] <durandal_1707> playing mel version
[13:44:58 CEST] <durandal_1707> very hard
[13:46:40 CEST] <atomnuker> huh, didn't know there were mods for portal 2, will give it a go
[14:44:20 CEST] Action: gnafu notices mention about HEVC-in-AVI, winces.
[17:09:27 CEST] <kierank> durandal_1707: we should have fps multiplayer
[17:11:43 CEST] <atomnuker> the classic quake-style genre died years ago, now its all team shooters
[17:12:05 CEST] <atomnuker> shootmania tried to revive it 6 years ago but failed
[17:15:53 CEST] <iive> isn't battle royal the current trend?
[17:17:34 CEST] <atomnuker> that's how out of date I am, I was thinking of csgo and overwatch
[17:18:11 CEST] <atomnuker> I guess battle royale is deathmatch but I don't like the shrinking arena part of it or anything fortnite added
[17:20:14 CEST] <iive> i think they still have teams... so not that far off.
[18:07:08 CEST] <jya> BBB: do you have some code that could tell me what chrome subsampling a compressed would use, something that doesn't require to decode anything. 
[18:07:13 CEST] <jya> for vp9 that is
[18:07:33 CEST] <JEEB> don't we have the bit stream parser thing for that?
[18:07:44 CEST] <JEEB> I think we have the basics for VP9 as well
[18:07:45 CEST] <BBB> yes we do
[18:07:47 CEST] <BBB> use the cbs
[18:08:17 CEST] <jya> on windows, the VP9 hardware decoder doesn't fail at all, and it returns a GPU frame stating it's NV12
[18:08:37 CEST] <JEEB> lovely
[18:08:44 CEST] <jya> that gives me the same issue on edge, chrome, firefox with an intel or nvidia supporting vp9
[18:08:46 CEST] <jya> display crap
[18:09:08 CEST] <jya> so I want to scan the first sample, see that it's 444 and bugger off
[18:09:22 CEST] <JEEB> sounds warranted enough
[18:09:37 CEST] <jya> haven't tested profile 2 444
[18:10:12 CEST] <jya> but i'm assuming it's the same.. I tried to generate content with ffmpeg to that extent. 
[18:10:55 CEST] <jya> BBB: could you point me at the code in ffvp9 where I could extract that info?
[18:11:19 CEST] <JEEB> I think you'd be better off looking at the VP9 CBS
[18:11:40 CEST] <jya> there may be some info in the windows vp9 MFT, but I can't find it
[18:12:02 CEST] <BBB> is it ok if I let others answer that? I think CBS is the right approach here
[18:12:15 CEST] <BBB> and Im trying to keep my head focused on av1 for a bit longer :)
[18:12:20 CEST] <BBB> sorry
[18:12:59 CEST] <JEEB> jya: see cbs_vp9*.c
[18:13:35 CEST] <jya> JEEB: i know nothing on vp9 bitstream (other than having looked at the code telling me it's a keyframe or what the resolution is)
[18:13:43 CEST] <JEEB> neither do I
[18:13:47 CEST] <jya> BBB: that's okay.. thank you for your work
[18:13:54 CEST] <JEEB> that's just the parser we use for dumping out packet info
[18:14:01 CEST] <JEEB> including stuff like chroma subsampling etc
[18:14:16 CEST] <jamrial> chroma subsampling is not signaled in the bitstream, afaik
[18:14:47 CEST] <jya> jamrial: it's not?
[18:14:58 CEST] <JEEB> ok, I just saw subsampling_x in the CBS and assumed :P
[18:15:21 CEST] Action: jya not finding cbs_vp9 in ffvp9 code
[18:16:05 CEST] <jamrial> wait, you mean pix_fmt?
[18:16:30 CEST] <jya> jamrial: I jsut want to know if it's 422 or 444
[18:16:31 CEST] <jamrial> was thinking sample position, sorry
[18:16:42 CEST] <JEEB> jya: it is not in the decoder, since I expected the code you'd probably end up copypasting to be simpler in the CBS :P
[18:16:52 CEST] <jamrial> yeah, that's in the bitstream alright
[18:16:59 CEST] <BBB> you could also extend the vp9_parser to signal the pix_fmt
[18:17:01 CEST] <jamrial> cbs has no public interface
[18:17:01 CEST] <BBB> its fairly trivial
[18:17:19 CEST] <jamrial> i submitted a patch for that some time ago, but it's not complete afaik
[18:18:05 CEST] <JEEB> I'd expect jya to not want to drag more stuff from FFmpeg but rather just copypasta the required minimum into firefox
[18:18:09 CEST] <JEEB> or something
[18:18:22 CEST] <JEEB> and I just happened to think that CBS code would have been simpler to follow for parsing
[18:18:23 CEST] <jya> JEEB: we have the vp9 parser included in our source tree
[18:18:42 CEST] <jamrial> it can't not be there seeing it's pulled by the vp9 decoder
[18:18:51 CEST] <jamrial> but yeah, let me dig my patch
[18:19:27 CEST] <jya> would likely have to get that change upstreamed. don't want to carry on patches 
[18:19:42 CEST] <jya> TD-Linux: had provided some links inside libvpx
[18:19:51 CEST] <jya> need to find what he wrote :)
[18:20:09 CEST] <jamrial> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-January/224219.html
[18:20:22 CEST] <jamrial> i can try to tidy it up a bit and resubmit it
[18:22:06 CEST] <jamrial> in any case, if you only want to know if the bitstream is i420 (where hw decoding is know to work), then shouldn't looking at profile be enough?
[18:22:57 CEST] <jya> jamrial: it works for 10/12 bits 420
[18:23:02 CEST] <jya> so that's profile 2 still
[18:28:01 CEST] <jamrial> i was under the impression that profile 0 is 420 8 bit, profile 2 is 420 10/12, then 422, 440 and 444 are profile 1 (8 bit) and profile 3 (10/12 bit)
[18:28:38 CEST] <jamrial> so if the stream is profile 0 or 2, it can't be 444 as you mentioned above
[18:30:28 CEST] <BBB> thats correct btw
[18:31:02 CEST] <jya> jamrial: I got led to believe differently by the samples someone provided to me:
[18:31:25 CEST] <jya> https://jyavenard.github.io/htmltests/tests/webm-hdr.html
[18:31:47 CEST] <jamrial> the last two there should say profile 3
[18:31:56 CEST] <jya> jamrial: that's good to know !
[18:33:40 CEST] <jamrial> jya: https://pastebin.com/raw/zXaGWK9F
[18:34:23 CEST] <jya> jamrial: what's 422 10/12 bits?
[18:34:45 CEST] <jamrial> also profile 3
[18:34:53 CEST] <nevcairiel> https://www.webmproject.org/vp9/profiles/
[18:35:45 CEST] <jya> need to wrap some samples , the windows MFT decoders can't do odd width/height. so none of those samples are of any use when it comes to testing the hw decoder
[19:13:30 CEST] <cone-030> ffmpeg 03Paul B Mahol 07master:4c514edc5bc0: avfilter/avfilter: fix typos in comments
[20:28:37 CEST] <jya> jamrial: thanks for suggesting reading the profile.. simple and neat
[20:28:43 CEST] <jya> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/vp9_parser.c#L41
[20:29:13 CEST] <jya> that frame header, is this a constant value? (Wonder if I could use this to detect I'm not parsing vp9)
[20:30:39 CEST] <jya> ah 2 the doc tells me
[21:15:58 CEST] <azaki> jamrial, i noticed that jkqxz's av1 stuff landed a few days ago, i'm guessing the parser isn't too far behind?
[21:16:20 CEST] <jya> BBB: I created samples of all type (https://jyavenard.github.io/htmltests/tests/webm-hdr.html) this particular one : https://jyavenard.github.io/htmltests/mediatest/webm/vp9/yuv422p10.webm doesn't decode with ffvp9. It's a single frame, the compressed sample is 227748 . First call to avcodec_decode_video2 shows that it used the entire buffer, but nothing is
[21:16:20 CEST] <jya> returned. Next when you drain the decoder, avcodec_decode_video2 it will return -1  
[21:16:39 CEST] <jamrial> azaki: no, i'll commit it soon
[21:16:51 CEST] <jya> all decode fine with libvpx
[21:16:58 CEST] <BBB> can you file bugs somewhere?
[21:17:03 CEST] <BBB> Im unlikely to be able to look right away
[21:20:14 CEST] <jamrial> jya: the ffmpeg cli handles it just fine
[21:20:35 CEST] <jya> jamrial: indeed, ffplay plays it.
[21:20:55 CEST] <jya> i wonder if it's the wrapper around avcodec_decode_video2 
[21:24:10 CEST] <jya> it has that behaviour just for 422 10/12 bits and 420 12 bits. all the others are fine on that page
[21:49:08 CEST] <cone-030> ffmpeg 03Paul B Mahol 07master:9e45364a80f9: avfilter/af_afir: make IR gain control more flexible
[21:50:30 CEST] <kierank> durandal_1707: do you play fortnite
[21:51:51 CEST] <durandal_1707> kierank: i play only linux games
[21:52:59 CEST] <BradleyS> fortnite runs on linux
[21:53:21 CEST] <TheAMM> linux was a mistake
[21:53:36 CEST] <BradleyS> s/linux/wine/ :)
[22:05:22 CEST] <cone-030> ffmpeg 03Marton Balint 07master:45fa756fa4dd: avformat/ip: factorize some IP filtering and resolving functions to a new file
[22:05:23 CEST] <cone-030> ffmpeg 03Marton Balint 07master:826972c9d81a: avformat/udp: use factorized ip functions
[22:05:24 CEST] <cone-030> ffmpeg 03Marton Balint 07master:9d4829f3c915: avformat/rtpproto: use factorized ip functions
[22:05:25 CEST] <cone-030> ffmpeg 03Marton Balint 07master:91a136345273: avformat/udp: add support for generic source filtering
[22:05:26 CEST] <cone-030> ffmpeg 03Marton Balint 07master:d3bda871f033: avformat/udp: specify the local address for some source filtered multicast joins
[22:05:27 CEST] <cone-030> ffmpeg 03Marton Balint 07master:ab0812c1a892: avformat/udp: always use IP_ADD_SOURCE_MEMBERSHIP for subscribing to an UDP multicast source group in IPv4
[22:05:28 CEST] <cone-030> ffmpeg 03Marton Balint 07master:934432257396: doc/protocols: simplify and clarify UDP localaddr option
[22:16:45 CEST] <cone-030> ffmpeg 03Marton Balint 07master:8f14170b9a4e: avfilter/filters: add ff_inlink_peek_frame and ff_inlink_queued_frames to access frames in the inlink fifo
[22:16:46 CEST] <cone-030> ffmpeg 03Marton Balint 07master:7ca2ee059e3d: avfilter/f_cue: use inlink fifo for queueing frames
[00:00:00 CEST] --- Thu Oct  4 2018