sailus: that property should be set in per-SoC .dtsi files, not in per-board files
pinchartl: Yes, makes sense.
I don't understand this log: https://p.mort.coffee/U3O (from the program https://p.mort.coffee/vL3.c, with debug prints enabled; the log shows a mix of dmesg output and the program's output)
setting format width=640, height=416, format=NV12, yet buffers come back with a bytesused of 40889472
a 40MB NV12 image corresponds to around 5221x5221, not exactly 640x416...
mort: memset(&imageFormat, 0, sizeof(imageFormat)); before calling S_FMT
This only happens on some optimization levels, but even if there's some fucky undefined behavior in the code, the v4l2 interface or driver shouldn't care about that, and all the logged ioctls look good, even from the dmesg output...
ah.
thanks.
or better
        struct v4l2_format imageFormat = {
                .type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE,
                .fmt = {
                        .pix = {
                                .width = width,
                                .height = height,
                                .pixelformat = V4L2_PIX_FMT_NV12,
                                .field = V4L2_FIELD_NONE,
                        },
                },
        };
isn't there some weirdness where initializing like that doesn't guarantee to set all bytes to 0, just all members to 0, which could potentially be an issue
probably doesn't matter in this context
the padding bytes will indeed not be initialized, but that shouldn't matter
it's a problem in kernel code as it could leak data to userspace
right
ezequielg: jernej: I think it should be made HW specific which format of interlaced buffer it to be outputed, so for this reason, I think the driver mu handle and report the V4L2 field order
currently, non of the drivers reports it and FFMPEG just hardcode V4L2_FIELD_INTERLACED_TB or something
I'm saying that, since I know some HW will produce FIELD_ALTERNATE (that is going to be complicated), but also SEQ_*
interlaced is common, but we still need to know if which lines is top/bottom
ezequielg: jernej: also, for interlaced H264, when the fields are split, are the field decoded in separate requests or in the same request on Hantro/RKVDEC ?
nudfresne: I'm aware of those limitations, but we have to start somewhere...
ndufresne: I don't know Hantro much, but maybe kwiboo knows
right, ping Kwiboo  ^^^
jernej: the problem is that we need to make sure the spec covers that, specially that it's going stable now, so it will be tricky to fix if we got it wrong
its seems really easy to implement in cerdus, basically, if (!sps->frame_mbs_only_flag) -> field = V4L2_FIELD_INTERLACED_TB/BT
not sure yet how to figure-out TB vs BT though ;-P
Isn't field handling effectively already part of V4L2 specs?
So that would mean that this could be treated just as bug in driver
for reporting the proper field on G_FMT, yes
basically cedrus report NONE (progressive) even if sps->frame_mbs_only_flag isn't set, which is a bug of course
but there is a larger bug is that userspace makes a guess about the field arrangement in the capture buffer, and even makes a guess on having a single buffer ;-P
Allegro DTV HW found on Xilinx SoC notably produce 1 buffer per field (ALTERNATE)
I'll need to read a bit more how that work in cedrus, it might be more flexible then I think (aka it's all driver decision)
I think H264 even allows mixed progressive and interlaced frames in same stream
ndufresne: BT/TB is derived in this way: https://github.com/Kwiboo/FFmpeg/blob/v4l2-request-hwaccel-4.3/libavcodec/h264_slice.c#L1202-L1222
ndufresne: I'm not sure we have SEI data
in driver
ndufresne: Driver should at least give field type, like V4L2_FIELD_INTERLACED or ALTERNATE. top/bottom can be more easily tracked from user space
I see, the order is the order we decode the picture
well, except for the case we have both in the same picture
I don't think having the same poc for both fields is actually legal
so I bet this SEI thing is a hack to support some broken streams
jernej: thank!
btw, for VDEC and DXVA, even if these are frame based, split field are decoded indepently, I wonder if hantro is the same
I wonder if a buffer mark to ERROR state will trigger the request completion or not
I'm seeing stuff were I may suspect it's not doing that
ndufresne: Note that broken streams are not so rare as you might hope. LibreELEC users gave me several such samples.
yeah, I know
including one where references were omitted
well, one
but enough to wreck decoding
but for this kernel interface, I think it's up to userspace to workaround
in fact, if field order remain up to userspace, it simplify few things, but it collide a bit with V4L2_FIELD_INTERLACED being deprecated iirc
well, we can try to deduce based on poc
but user space can ignore actual value and use only type
ndufresne: re hantro and rkvdec, each field is decoded using its own request (two request for each full frame), both request target same capture buffer
do you really need to know the the field order for a decoded field/frame? is not the top/bottom only for what order they are decoded in, in the resulting buffer top will always be odd lines and bottom even lines
unless the fields is decoded into separate buffers
also if the fields is decoded into separate buffers, how does display controller render such frame? sound like a special drm fourcc/modifier must be used in such case? it it is even possible
Kwiboo: what a relief, thanks
I found that gst got the top/bottom stuff implemented in userspace already
with a FIXME for the identical POC case
Kwiboo: currently it's not supported by DRM, in fact, it a bit of a clash, since you need 2 buffers to represent a complete scannout
Xilinx is fight a bit with the DRM APIs here
since they want low latency, but bad things happens over SDI if the second field didn't arrive on time ...
basically, if userspace go slow, and you send the first field, you have to send again the first field, or worst send previous second field to complete the refresh
which breaks the "every frame is perfect" moto
Kwiboo: ndufresne: If I'm not mistaken, Cedrus uses same approach, e.g. two requests in same buffer, one with odd another with even lines
I think with DRM rules, you cannot do low latency, and you must submit both fields in one commit
jernej: indeed, hopefully I get that working in few days in gst too
I'm fighting with the fact that gst went async for the request, I think I'll change the approach drastically
ndufresne: I didn't sure, but I believe also ALTERNATE approach can be implemented somehow
but it's not so useful, because HW deinterlace core can only process interlaced BT/TB frames
ALTERNATE and SEQ (since SEQ is like alternate, but using single allocation)
yeah, we should only support things base on what other HW needs
interleaved is by far the most commonly supported, and already works with DRM so ...
with the fun bit that with interleaved, you can always ignore the fact it's interlaced and it renders something vieable
ndufresne: what kind of DRM support you have in mind?
anything special?
jernej: on Xilinx Zynq they have SDI and HDMI transmitters as DRM driver
they are transmitters, so not really meant to plug you TV, but more to pass signal between TV headend component
Hi, I'm setting the pixelformat of an attached USB webcam to MJPG using v4l2-ctl. However, as soon as VLC or mpv open the device, the pixel format switches back to YUYV. Is it possible to prevent that?
LuKaRo: could it be vlc setting it to YUYV explicitly ?
I don't know. I thought as it happens with both VLC and mpv, it might as well be something v4l2 related...