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

[burek]

[01:07:25 CEST] <atomnuker> jkqxz: so I'm writing a protocol for screen capture for wayland and I'm wondering whether to assume there'll only be a single drm object or many
[01:07:50 CEST] <atomnuker> it'll be used to get the display dmabuf and random client's dmabufs
[01:08:24 CEST] <atomnuker> I'm asking since you told me there are usually multiple objects on amd
[01:08:27 CEST] <TD-Linux> atomnuker, out of curiosity what happens if you're using multiple planes/overlays
[01:10:17 CEST] <atomnuker> you can capture one of them by specifying which one you want (if you're asking if for example a client has 2 dmabufs corresponding to 2 overlays like 2 different windows)
[01:10:46 CEST] <atomnuker> as for multiple planes, they're a single dmabuf with multiple objects
[01:11:01 CEST] <TD-Linux> ah okay. would ffmpeg composite them automatically for you?
[01:11:23 CEST] <TD-Linux> (I guess capturing the mouse cursor is the most common instance)
[01:11:26 CEST] <atomnuker> no, the hardware frames would carry a reference to all of them
[01:11:38 CEST] <atomnuker> hm, hadn't thought about the cursor surface
[01:12:04 CEST] <atomnuker> still, that would be a surface you could specify to capture as well, map it and overlay it yourself
[01:12:29 CEST] <atomnuker> anyway, the only way as far as I know to get multiple planes on desktop linux is if you try to map a VAAPI frame to DRM on AMD
[01:12:39 CEST] <TD-Linux> yeah. the protocol would need to give you enough information for you to composite it yourself identically to the hardware
[01:13:18 CEST] <atomnuker> trivial, cursor surfaces are always rgba
[01:13:37 CEST] <atomnuker> you just do a simple blend, nothing extra needed
[01:14:04 CEST] <TD-Linux> atomnuker, skylake+ has like 8 planes so the idea has been tossed around of putting windows on planes. no one does it yet but I think the weston atomic patches had that in mind
[01:14:07 CEST] <atomnuker> all that you would need is a way to determine whether a surface is a cursor surface and to which window it belongs to
[01:14:15 CEST] <TD-Linux> should also be trivial, but needs to be handled.
[01:14:59 CEST] <atomnuker> TD-Linux: yes, wlroots will handle that for 1.0 if SirCmpwn's roadmap is to be believed
[01:16:15 CEST] <atomnuker> (only 8? that's low, but I guess those could be made into pools for clients to get whenever they can, and if they can't a fallback path will be used)
[01:16:37 CEST] <atomnuker> so if clients aren't visible they won't use any
[01:17:11 CEST] <TD-Linux> yeah I think you'd have one be a "base layer" that has opengl compositing minus the layerized windows. that's why atomic is so important, to keep that in sync with the others.
[01:19:04 CEST] <TD-Linux> (maybe convert it to a "top layer" when you have a fullscreen window)
[01:19:34 CEST] <atomnuker> if done properly you wouldn't need a specialcase for that
[01:19:52 CEST] <atomnuker> because everything below would be invisible and therefore get no frame callbacks -> waste no overlay planes
[01:20:06 CEST] <atomnuker> suprisingly, gnome almost does that
[01:20:34 CEST] <cone-608> ffmpeg 03Aman Gupta 07master:19128408ac3a: avcodec/mpegpicture: fix "stride changed" failures in gray mode
[01:20:35 CEST] <atomnuker> if a window's fully hidden behind another one it'll halve the rate at which the invisible window gets callback events
[01:21:57 CEST] <atomnuker> btw you should check out the wlroots port of sway, I've been using it for a couple of days now, its very nice
[01:22:13 CEST] <atomnuker> and I've never used tiling WMs before
[01:25:05 CEST] <atomnuker> TD-Linux: do you know if those overlay planes are buffered (e.g. each plane has 4 or whatever the hardware's native number of buffers is) or if they're just single unbuffered planes
[01:26:11 CEST] <atomnuker> nah, they must be buffered, with vulkan the client aquires the swapchain surfaces beforehand, it wouldn't make sense to not have the ability to lose one suddenly
[01:26:26 CEST] <TD-Linux> atomnuker, I'm not sure, I can't even find a citation for the 8 planes. I think I'd have to read drm source
[01:26:29 CEST] <atomnuker> *to have the ability
[01:34:50 CEST] <atomnuker> TD-Linux: apparently there's a difference
[01:35:05 CEST] <atomnuker> so fullscreen surfaces would need scanout planes
[01:35:14 CEST] <atomnuker> and non-fullscreen ones would need sprite planes
[01:36:38 CEST] <atomnuker> I think for scanout planes you just provide a framebuffer (which you can easily get)
[01:48:27 CEST] <klaxa> atomnuker: i think i'm at at presentable state of my qualification task, do i split it into multiple commits for each file or just add the whole thing in one commit?
[01:48:48 CEST] <klaxa> if you want to take a look before: https://gogs.klaxa.eu/stephan.holljes/ffserver
[01:49:18 CEST] <klaxa> i thought about using ffmpeg's segment implementation but it seemed a lot more complex than what i need
[01:49:47 CEST] <klaxa> i swiched my own fifo buffer for AVFifoBuffer
[01:50:06 CEST] <klaxa> ah, i also found a bug in http.c i introduced 3 years ago and nobody noticed (not even me)
[01:53:17 CEST] <JEEB> :D
[01:53:27 CEST] <JEEB> classic
[01:53:52 CEST] <JEEB> given that I use http pretty often for both GET and PUT/POST
[01:54:13 CEST] <JEEB> that seems to have been a pretty well working (in general) brokenness
[01:56:47 CEST] <klaxa> aaaaah, so i'm doing all my dev stuff on my server
[01:56:57 CEST] <klaxa> and git send-email fails because google has no cookie of my server or something
[01:56:59 CEST] <klaxa> :I
[01:57:29 CEST] <JEEB> classic. I also have git send-email only set up on one of my boxes
[01:57:42 CEST] <JEEB> so I usually push onto my github repo, then fetch it on that box and send the e-mails
[01:57:51 CEST] <JEEB> because I'm a lazy git
[02:08:25 CEST] <klaxa> wew finally
[02:09:04 CEST] <klaxa> so, do i just send one giant commit with all the files or each file in another email?
[02:11:30 CEST] <SirCmpwn> break up your work into logical commits and send an email for each commit (git-send-email will do this for you)
[02:11:46 CEST] <SirCmpwn> ideally add a cover letter (git-send-email can do this too) summarizing the incoming patches as well
[02:34:07 CEST] <cone-608> ffmpeg 03Carl Eugen Hoyos 07master:b5c877a55415: configure: Disable direct stripping for AIX.
[03:11:04 CEST] <cone-608> ffmpeg 03Jérôme Martinez 07master:b5788e70255a: avcodec/dpx: Support for RGB 12-bit packed decoding
[03:11:05 CEST] <cone-608> ffmpeg 03Mattias Amnefelt 07master:a26c9fdd1b4c: libavformat/aac: Parse all ID3 tags present between ADTS frames
[08:46:07 CEST] <cone-163> ffmpeg 03Tobias Rapp 07master:bc62d20dc415: doc: update loglevel option documentation
[09:55:59 CEST] <BodecsB> is there any way to run just a specific fate test, but not all?
[10:05:25 CEST] <nevcairiel> sure, you can refefrence them by name
[10:05:30 CEST] <nevcairiel> make fate-<name>
[10:06:35 CEST] <BodecsB> thank you, it works
[10:10:17 CEST] <cone-163> ffmpeg 03Jun Zhao 07master:cdd107b96586: lavf/aviobuf: add ff_get_chomp_line
[10:10:18 CEST] <cone-163> ffmpeg 03Jun Zhao 07master:0e49118271ce: lavf/hls: use ff_get_chomp_line
[10:10:19 CEST] <cone-163> ffmpeg 03Jun Zhao 07master:f1ccb4dbcf0b: lavf/hlsenc: use ff_get_chomp_line
[10:10:20 CEST] <cone-163> ffmpeg 03Jun Zhao 07master:52623bc26fc4: lavf/hlsproto: use ff_get_chomp_line
[12:07:59 CEST] <durandal_1707> looks like --disable-v4l2-m2m is not enabled when autodetect is disabled?
[12:08:14 CEST] <durandal_1707> *not disabled
[12:19:27 CEST] <durandal_1707> why is dirac build if i disable almost everything?
[12:21:10 CEST] <jdarnley> I wonder similar things too.
[12:21:25 CEST] <jdarnley> For Dirac it is probably some format having a dep on the parser, like most things.
[12:21:43 CEST] <jdarnley> Which is odd because the parser is really, really basic
[12:23:34 CEST] <durandal_1707> v4l2_m2m seems to always be enabled, i cant disable it
[12:25:45 CEST] <durandal_1707> from >5mb to 2.9 mb by disabling swscale lib
[12:27:05 CEST] <jkqxz> durandal_1707:  67e8f476b7d3c21686a2d453d052818ac92688b3 incorrectly changed the disable-if-no-header to enable-if-header?
[12:27:19 CEST] <jkqxz> (configure line 6196.)
[12:28:32 CEST] <jkqxz> I don't think the top check_cc should be that, but I'm not sure what it should be.
[12:48:29 CEST] <durandal_1707> also ffmpeg can be build without swresample just fine with some small changes
[14:44:40 CEST] Action: durandal_1707 fuzzing latest dxv patch posted on ml
[14:57:57 CEST] <atomnuker> durandal_1707: mate?
[14:58:23 CEST] <atomnuker> you're doing pixel conversion inside the decoder
[14:59:10 CEST] <wm4> call the police
[14:59:25 CEST] <wm4> doing it in the decoder is probably faster than in swscale
[15:01:21 CEST] <durandal_1707> +1
[15:01:56 CEST] <atomnuker> not doing it at all is faster than that
[15:02:15 CEST] <durandal_1707> atomnuker: does anything support 420 subsampled YCoCg, and YCoCgA ?
[15:02:24 CEST] <atomnuker> yes, mpv
[15:02:34 CEST] <atomnuker> vf_colorspace can convert it too
[15:02:40 CEST] <durandal_1707> but not freaking swscale
[15:02:53 CEST] <durandal_1707> and we lack pixel format?
[15:03:09 CEST] <atomnuker> no, yuv420p/yuv444p/yuvaXXXX
[15:03:20 CEST] <atomnuker> you just flag the ycgco colorspace
[15:03:42 CEST] <atomnuker> yuv might imply its yuv but really the pixel format only defines how the data is laid out in the buffers
[15:05:51 CEST] <atomnuker> and for historical reasons it has yuv in its name
[15:15:40 CEST] <durandal_1707> but swscale does not
[15:16:32 CEST] <durandal_1707> does vlc support YCoCg at all?
[15:18:58 CEST] <durandal_1707> also ref decoder outputs in rgba only
[15:23:00 CEST] <durandal_1707> no decoder currently in lavc sets such colorspace
[15:32:28 CEST] <nevcairiel> ? h264 at least supports ycocg
[15:44:46 CEST] <durandal_1707> i do not see it supported in our libavcodec
[15:45:34 CEST] <nevcairiel> it is however
[15:45:41 CEST] <nevcairiel> just play a file like that and see
[16:04:10 CEST] <wm4> mpv supports ycgco
[16:04:22 CEST] <wm4> it's easy to do if you can configure the color matrix
[16:05:24 CEST] <wm4> gawd ffserever is back?
[16:06:09 CEST] <wm4> actually it looks cute
[16:06:37 CEST] <wm4> not your grandpa's ffserver
[16:08:48 CEST] <klaxa> th-thanks
[16:09:04 CEST] <klaxa> it only uses public api
[16:09:23 CEST] <klaxa> when i looked at ffserver 3 years ago it was... an experience
[16:09:26 CEST] <wm4> jesus christ why do things like avio_accept exist
[16:10:10 CEST] <Chloe> klaxa: 'not your grandpa's ffserver' is now the tagline for the new ffserver ktnx
[16:14:31 CEST] <atomnuker> durandal_1707: even dirac supports ycgco
[16:14:42 CEST] <atomnuker> and the vc2 encoder also accepts it
[16:14:59 CEST] <atomnuker> I'm pretty sure vlc supports playing files with such a colorspace too
[16:15:29 CEST] <atomnuker> and as for libswscale support I'm sure it won't be too difficult to add support, its a simple transform after all
[16:15:57 CEST] <wm4> I think libswscale has problems here because of certain assumptions (from what I remember others talking about it)
[16:16:21 CEST] <wm4> when will someone rewrite libswscale
[16:18:37 CEST] <atomnuker> if we base it off of vf_colorspace that would be nice, not necessarily the fastest but definitely the most correct
[16:21:30 CEST] <wm4> I imagine a new libswscale should at least have the ability to chain filters that work on individual slices
[16:32:50 CEST] <durandal_1707> texturedsp have ycgco2rgb code
[16:36:18 CEST] <atomnuker> should be removed then
[16:37:12 CEST] <durandal_1707> atomnuker: cant. texturedsp solely work on rgba
[16:48:29 CEST] <atomnuker> I meant the ycgco code
[17:31:02 CEST] <ldts> g160
[19:22:14 CEST] <durandal_1707> lol, i keep getting crash reports with afl
[20:24:59 CEST] <atomnuker> oh wow the shared thread pool topic is back, its been 2 years since the last time
[20:59:55 CEST] <wm4> yeah... strange how the one who proposed it had such strong opinions about it, yet nothing happened
[22:09:37 CEST] <durandal_1707> jamrial: when to expect new release?
[22:54:38 CEST] <cone-163> ffmpeg 03Lou Logan 07master:4d544f608608: doc/filters: fix lenscorrection k1 & k2 typo
[23:54:41 CEST] <cone-163> ffmpeg 03Bela Bodecs 07master:37d0213968a2: avformat/utils: Stream specifier enhancement
[23:54:42 CEST] <cone-163> ffmpeg 03Bela Bodecs 07master:a06175d73923: fate: to test program sub stream selection by its type in mpegts
[23:54:43 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:0a8133119ca5: avformat/mov: Fix extradata memleak
[23:54:44 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:8c02cd8ca097: avcodec/h264_slice: Fix integer overflow with last_poc
[23:54:45 CEST] <cone-163> ffmpeg 03Michael Niedermayer 07master:8d381b57fd9d: avcodec/mjpegdec: Check input buffer size.
[00:00:00 CEST] --- Fri Apr 13 2018