Hello Svyatoslav,
On Tue Oct 7, 2025 at 6:02 PM CEST, Svyatoslav Ryhel wrote:
> пн, 6 жовт. 2025 р. о 21:55 Luca Ceresoli <[email protected]> пише:
>>
>> Hello Svyatoslav,
>>
>> On Thu Oct 2, 2025 at 8:20 AM CEST, Svyatoslav Ryhel wrote:
>> >> > > > 12 represents amount of bits used per pixel, 8 for Y plane, 2 for U
>> >> > > > plane and 2 for V plane, total is 12. "but explainable with a
>> >> > > > comment
>> >> > > > and improve-able later" why then we cannot use 12 with a comment?
>> >> > > > this
>> >> > > > is all arbitrary. Downstream is not wrong from this perspective, you
>> >> > > > don't take into account that YUV420 is planar and it uses 3 planes a
>> >> > > > whole Y plane and 1/4 of U and V which in total results in wigth +
>> >> > > > 2 *
>> >> > > > 1/4 width which is width * 3/2
>> >> > >
>> >> > > Yes -- but AIUI, the only thing the bpp value is used for the
>> >> > > bytesperline calculation. When we add the special case for planar
>> >> > > formats, which doesn't use the bpp value, then the value 12 is never
>> >> > > used anywhere. We should at least have a comment saying it is unused.
>> >> > > (At that point, we could just hardcode the bpp values in the
>> >> > > fmt_align function -- but I don't mind either way.)
>> >> > >
>> >> > https://ffmpeg.org/pipermail/ffmpeg-user/2023-June/056488.html
>> >>
>> >> I understand very well that for YUV420, each pixel has 12 bits of color
>> >> information. But how many bits of color information each pixel has is not
>> >> useful in the context of this driver. The number of bytes per line is not
>> >> related to how many bits of color information each pixel has for planar
>> >> formats.
>> >
>> > No, it has direct impact. This is how buffer size / image size is
>> > calculated since we place each plane consecutive. And bytes per line
>> > is used specifically in image size calculation. This is common part
>> > with non-planar formats. Then since Tegra provides a dedicated
>> > channels/buffers for each plane, configuration of planar format
>> > includes an additional step with calculation for each plane.
>>
>> Sorry, I haven't followed the discussion in detail, but I tested you series
>> on Tegra20 VIP and capture does not work, with a SIGSEGV in
>> gstreamer. Bisecting pointed to this as the first commit where the issue
>> happens.
>>
>> I compared the input and output values of tegra20_fmt_align() at this
>> commit and at the previous one, and this is the result:
>>
>> before this patch with this patch
>> At function entry:
>> bpp 1 12
>> pix->width 640 640
>> pix->height 480 480
>>
>> On return:
>> pix->bytesperline 640 960
>> pix->sizeimage 460800 460800
>>
>> I hope these info will help.
>
> Which command did you use? I have tested with ffmpeg and
> yuv422/yuv420p and it worked perfectly fine.
I have a simple testing script that runs these commands, with
VNODE="/dev/video0":
v4l2-ctl -d ${VNODE} --set-ctrl horizontal_flip=1 --set-ctrl vertical_flip=1
gst-launch-1.0 -ve v4l2src device=${VNODE} num-buffers=500 \
! video/x-raw,width=640,height=480,framerate=50/1,format=I420 \
! videorate drop-only=true skip-to-first=true \
! video/x-raw,framerate=50/4 \
! queue \
! avenc_mpeg4 \
! mp4mux \
! filesink location=/tmp/grab.mp4
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
