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

[burek]

[01:39:23 CEST] <ZeroWalker> can someone help me understand YUV422, a bit confused as to how it's packed. From my understanding it's something like YUVY, which turns into 2 pixels?
[01:45:21 CEST] <iive> kind of,
[01:45:35 CEST] <iive> do you know how yuv444 works is?
[01:51:05 CEST] <ZeroWalker> isn't that YUV = 1 pixel?
[01:51:16 CEST] <ZeroWalker> so 24bit
[02:03:38 CEST] <Mista_D> Ticket #6575 added bounty if anyone's interested
[02:14:46 CEST] <J_Darnley> ZeroWalker: Yes, 444 has one luma, one Cb, and one Cr sample per pixel.
[02:15:14 CEST] <J_Darnley> 422 has it's chroma scaled to half the width.
[02:15:50 CEST] <ZeroWalker> which means, 4 bytes = 2 pixels right?
[02:16:05 CEST] <J_Darnley> For 8-bit samples, yes
[02:16:29 CEST] <ZeroWalker> so, y0 + uv and y1 +uv? (not that math, but yeah)
[02:16:43 CEST] <J_Darnley> Not nessecarily
[02:16:45 CEST] <ZeroWalker> the luma use the same chroma samples?
[02:16:45 CEST] <ZeroWalker> oh
[02:16:58 CEST] <J_Darnley> Chroma can be placed almost anywhere
[02:17:08 CEST] <J_Darnley> it is tricky
[02:17:31 CEST] <ZeroWalker> do you mean like, planar vs interleaved, and all the weird YUVY UVYU etc
[02:18:00 CEST] <J_Darnley> the chroma could be aligned with the first luma sample, or aligned with the second luma sample, or between the two.
[02:18:22 CEST] <ZeroWalker> but isn't that format specific?
[02:18:30 CEST] <J_Darnley> Generally yes.
[02:18:33 CEST] <ZeroWalker> thought YUV2 was, YUVY (like that in the address)
[02:18:46 CEST] <ZeroWalker> meaning Luma0, Chroma, Luma2
[02:18:54 CEST] <ZeroWalker> Luma1*
[02:18:55 CEST] <J_Darnley> But ffmpeg isn't going to realign everything when it reads video.
[02:19:21 CEST] <ZeroWalker> yeah it's not specific to ffmpeg, i am wondering about the format as i am learning to convert it via shaders
[02:19:46 CEST] <ZeroWalker> and well it's not super clear how the format works for me, hence me asking here
[02:21:23 CEST] <J_Darnley> If you just want to know how a pixel format (in ffmpeg's language) is laid out in memory then you probably need to read the relevant header.
[02:21:42 CEST] <J_Darnley> avutil/pixel*something*.h
[02:21:48 CEST] <ZeroWalker> ah
[02:22:05 CEST] <iive> ZeroWalker: sorry i went away
[02:22:18 CEST] <ZeroWalker> ah no worries;d
[02:22:47 CEST] <ZeroWalker> packed YUV 4:2:2, 16bpp, Y0 Cb Y1 Cr
[02:22:48 CEST] <iive> yuv444 has 3 planes, where each plane represents one component, Y U V (U V are shorts for Cr Cb)
[02:23:14 CEST] <iive> so you can think of Y plane like grayscale bitmap
[02:23:26 CEST] <ZeroWalker> yeah that's kinda what i see it as, black/white
[02:23:57 CEST] <iive> to calculate rgb. you take the samples from the same positions.
[02:24:30 CEST] <iive> yuv422 has the U and V plane resized, so they have half width compared to the Y
[02:25:03 CEST] <iive> so if you have to calucate rgb, you'd have to interpolate (at least) half the values.
[02:25:36 CEST] <ZeroWalker> but if Y0 and Y1 basically share UV
[02:25:36 CEST] <iive> or you can say, that 2 horizontal Y pixels share same UV samples
[02:26:04 CEST] <ZeroWalker> yeah so, how would one interpolate it, there's nothing to interpolate is there?
[02:26:49 CEST] <iive> ?
[02:27:11 CEST] <iive> you do that with the next pixel, just like you would if you upscale an image
[02:27:41 CEST] <ZeroWalker> so, Y1 would interpolate UV0 and UV1 ?
[02:28:03 CEST] <iive> yes
[02:28:12 CEST] <iive> or you can not interpolate at all
[02:28:54 CEST] Action: J_Darnley shudders at the thought of nearest neighboring the chroma.
[02:28:57 CEST] <ZeroWalker> oh phew, well the only scaling experience i have is point resize if you will, so no fancy stuff, but i guess even that would work here?
[02:29:08 CEST] <ZeroWalker> haha, what timing to write that
[02:30:48 CEST] <iive> well, to complicate matters more, it is possible a standard to define UV sample centers that are off compares to the Y samples, so you never have an exact match.
[02:31:07 CEST] <iive> s/compares/compared
[02:32:28 CEST] <ZeroWalker> oh, yay xd
[02:33:15 CEST] <ZeroWalker> well at least i get the default structure of it. basically i could take YUY2 (YUVY) and produce 2 pixels with it. Ugly but it Would work right?
[02:33:46 CEST] <iive> yes
[02:34:21 CEST] <iive> most video codecs however expect planar formats, so they will want to convert. (swscale)
[02:36:34 CEST] <ZeroWalker> well in my case this is for converting from YUY2 or probably other interleaved YUV to RGB for displaying. So i can probably get away from the planar part there. For encoding i use swscale
[04:28:27 CEST] <jamrial> atomnuker: the af_compand compilation issue on gcc trunk is fixed
[07:35:59 CEST] <ZeroWalker> well yuv to rgb with shaders was harder than expected cause of it being more pixels per package. it's simple to just turn the YUV to RGB, but YUVY to RGBRGB, not so much xd
[07:51:40 CEST] <thebombzen> YUVY? is that a thing?
[07:51:50 CEST] <thebombzen> isn't it usually yuyv
[10:12:33 CEST] <wm4> death to packed yuv
[10:12:57 CEST] <wm4> 4 byte non-subsampled packed yuv can stay
[10:22:29 CEST] <cone-063> ffmpeg 03Andy 07master:448c88e1a586: avfilter/dynaudnorm: increment input outside of the FFMIN macro so it doesn't get double incremented
[16:55:19 CEST] <J_Darnley> Does ffmpeg have a helper function to copy a rectangle from one AVFrame to another?
[17:03:43 CEST] <JEEB> J_Darnley: av_frame_move_ref or so?
[17:03:58 CEST] <JEEB> unless you actually mean a memcpy
[17:04:14 CEST] <JEEB> although that's moving the buffer to another AVFrame instead of copying it
[17:05:28 CEST] <J_Darnley> I do mean a memcpy, yes.
[17:09:49 CEST] <wm4> av_frame_copy or so
[17:18:35 CEST] <JEEB> yea, I think that
[17:19:26 CEST] <nevcairiel> thats for full frames tho, not sub-rectangles, if thats what you wanted
[17:20:25 CEST] <wm4> you could use the new crop function, although that's pretty roundabout
[17:20:54 CEST] <J_Darnley> Thanks for the suggestions but I'll just do it myself
[17:24:01 CEST] <kierank> J_Darnley: why do you need to copy rectangles?
[17:24:35 CEST] <J_Darnley> To copy slices of the picture drawn in encode_video
[17:25:28 CEST] <durandal_1707> vf_swaprect
[17:25:56 CEST] <wm4> we're getting way too many vf_veryspecific
[17:25:59 CEST] <kierank> J_Darnley: why?
[17:26:11 CEST] <wm4> (it would be ok if those were functions)
[17:26:16 CEST] <J_Darnley> So I can see whether I do anything correctly in the encoder
[18:19:12 CEST] <BtbN> Coverity has some issues with the new vf_premultiply patches
[21:11:19 CEST] <durandal_1707> wm4: what filters must be very generic?
[21:20:02 CEST] <durandal_1707> would ffedit using qt be accepted in repo?
[21:20:50 CEST] <ubitux> tools/ffedit.c?
[21:21:07 CEST] <wm4> I don't think it's going to be .c
[21:21:18 CEST] <ubitux> with qt, yeah i guess so
[21:21:28 CEST] <ubitux> durandal_1707: what does it do?
[21:21:37 CEST] <ubitux> construct lavfi graph with a gui?
[21:21:52 CEST] <durandal_1707> similar as vsedit
[21:22:13 CEST] <ubitux> i don't know vsedit
[21:22:20 CEST] <durandal_1707> preview filtergraph output
[21:23:17 CEST] <ubitux> how are you going to cumulate them?
[21:23:39 CEST] <durandal_1707> what?
[21:24:08 CEST] <ubitux> how are you going to represent multiple filters and their settings in the UI?
[21:24:40 CEST] <ubitux> https://cloud.githubusercontent.com/assets/8057201/9976995/e81ac04a-5ef7-11e5-872b-acd54fbeee03.gif
[21:24:43 CEST] <ubitux> something like this?
[21:25:09 CEST] <ubitux> (source: github/vurtun/nuklear)
[21:25:24 CEST] <durandal_1707> maybe
[21:25:39 CEST] <ubitux> you'll be forced to use C for that
[21:25:45 CEST] <durandal_1707> but first simple script
[21:25:48 CEST] <ubitux> or a binding to ffmpeg
[21:26:04 CEST] <ubitux> (because some filters have dynamic inputs so you need to have some exec)
[21:26:12 CEST] <ubitux> inputs+outputs*
[21:26:53 CEST] <durandal_1707> why ? i cant call c from c++?
[21:27:04 CEST] <ubitux> if you make a simple py+qt script that parses ffmpeg -h filter=xxx, that may be good enough for tools/ sure 
[21:27:17 CEST] <ubitux> i meant use C versus scripts
[21:27:44 CEST] <ubitux> like, you'll have trouble calling lavfi API with scripting languages 
[21:27:53 CEST] <ubitux> unless you make some cython bindings or whatever
[21:28:14 CEST] <durandal_1707> i plan to call api
[21:28:44 CEST] <durandal_1707> and do it in C++
[21:30:19 CEST] <durandal_1707> idea is to provide seeking in filtergraph
[21:32:57 CEST] <FishPencil> What's a decent way to find a group of pixels that match a certain criteria? Right now I loop through the image and add each of the pixels that match to an array. I then loop through that array and look for p[x+1][y+1] to see if there's another in an adjacent spot. Is there a better way?
[21:35:22 CEST] <durandal_1707> give more details, does it need to be all pixels with certain criteria?
[21:36:07 CEST] <FishPencil> I'm looking for bright pixels and using summed RGB values over some threshold 
[21:37:34 CEST] <durandal_1707> i doubt there is faster way
[21:38:08 CEST] <FishPencil> I guess I could also go row by row, recording the bright "group" start and end and then compare that to groups in y+/-[1-n]
[21:38:41 CEST] <FishPencil> [1+n]
[21:40:58 CEST] <FishPencil> I was thinking I would start at the first pixel that's bright (top left) and go x+1 and y+1 until no match is found diagonally. Then record the center x,y and remove the surround pixels in the radius so the next row doesn't look for them too
[21:42:22 CEST] <FishPencil> All I care about in the end is x and y's of the center point for groups and the radius of the group
[21:46:33 CEST] <atomnuker> durandal_1707: sure, I'd like for it to be part of the repo
[21:47:11 CEST] <durandal_1707> even in c++ with qt?
[21:47:17 CEST] <atomnuker> yep
[21:47:19 CEST] <atomnuker> (having some lua scripting interface would probably make it replace anything else)
[21:47:54 CEST] <atomnuker> just make sure to use qt 5 and not rely on kde stuff, its not very heavy then
[22:05:06 CEST] <FishPencil> Should the 2D array of "found" pixels contain all pixels in the image, and a 1 for "found", 0 for not? something like if (p[1234][123]) for x = 1234, y = 123, so that I can do y + 1 to get the next row?
[22:06:23 CEST] <FishPencil> or should it only contain those that are found, so that p[n][0] = 1234 and p[n][1] = 123
[22:09:07 CEST] <cone-035> ffmpeg 03Nicolas Sugino 07master:df884e038f5d: avcodec/aacdec: Fix PCE channel_layout verification
[22:09:22 CEST] <iive> FishPencil: i think opencv might already have something that does it.
[22:13:28 CEST] <FishPencil> it has a threshold feature but I don't see grouping
[22:15:54 CEST] <atomnuker> FishPencil: you do know ffmpeg doesn't deal with 2d arrays any code dealing with images, right?
[22:17:07 CEST] <durandal_1707> FishPencil: i did floodfill filter recently which may come handy
[22:19:20 CEST] <FishPencil> is there something wrong with multidim arrays that FFmpeg doesn't like?
[22:20:06 CEST] <durandal_1707> they consume memory
[22:20:23 CEST] <atomnuker> FishPencil: an extra dereference per row
[22:20:52 CEST] <atomnuker> memory too
[22:20:53 CEST] <FishPencil> so pseudo-2d is needed?
[22:21:16 CEST] <atomnuker> we use a single large buffer with dimensions stride*height
[22:21:33 CEST] <atomnuker> where stride is generally width aligned to some amount of bytes for simd
[22:21:52 CEST] <atomnuker> so to address arbitrary pixels you use buffer[y*stride + x]
[22:23:28 CEST] <FishPencil> interesting
[22:23:29 CEST] <atomnuker> (never noticed this until now but this neatly fits with how x86 does addressing)
[00:00:00 CEST] --- Thu Aug 10 2017