вт, 7 жовт. 2025 р. о 22:37 Luca Ceresoli <[email protected]> пише: > > 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
I can reproduce what you are observing. ok, I will drop this commit. > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com
