| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| *** | ndec has quit IRC (Ping timeout: 244 seconds) | [00:56] |
| ....................................................................... (idle for 5h52mn) | ||
| pinchartl | sailus: that property should be set in per-SoC .dtsi files, not in per-board files | [06:48] |
| ................................................ (idle for 3h55mn) | ||
| sailus | pinchartl: Yes, makes sense. | [10:43] |
| mort | 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... | [10:48] |
| pinchartl | mort: memset(&imageFormat, 0, sizeof(imageFormat)); before calling S_FMT | [10:51] |
| mort | 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. | [10:51] |
| pinchartl | 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, }, }, }; | [10:52] |
| mort | 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 | [10:56] |
| pinchartl | 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 | [11:01] |
| mort | right | [11:02] |
| ................................................................. (idle for 5h21mn) | ||
| ndufresne | 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 | [16:23] |
| ....... (idle for 31mn) | ||
| 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 ? | [16:56] | |
| jernej | nudfresne: I'm aware of those limitations, but we have to start somewhere...
ndufresne: I don't know Hantro much, but maybe kwiboo knows | [17:05] |
| ndufresne | 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 | [17:06] |
| jernej | Isn't field handling effectively already part of V4L2 specs?
So that would mean that this could be treated just as bug in driver | [17:08] |
| ndufresne | 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) | [17:10] |
| jernej | I think H264 even allows mixed progressive and interlaced frames in same stream | [17:16] |
| 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 | [17:22] | |
| ndufresne: Driver should at least give field type, like V4L2_FIELD_INTERLACED or ALTERNATE. top/bottom can be more easily tracked from user space | [17:31] | |
| ndufresne | 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 | [17:32] |
| jernej | ndufresne: Note that broken streams are not so rare as you might hope. LibreELEC users gave me several such samples. | [17:35] |
| ndufresne | yeah, I know | [17:35] |
| jernej | including one where references were omitted
well, one but enough to wreck decoding | [17:35] |
| ndufresne | 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 | [17:36] |
| jernej | well, we can try to deduce based on poc
but user space can ignore actual value and use only type | [17:39] |
| .... (idle for 15mn) | ||
| Kwiboo | 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 | [17:55] |
| ndufresne | 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 | [17:59] |
| jernej | 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 | [18:03] |
| ndufresne | 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 | [18:04] |
| jernej | 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 | [18:06] |
| ndufresne | 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 | [18:07] |
| jernej | ndufresne: what kind of DRM support you have in mind?
anything special? | [18:08] |
| ............ (idle for 55mn) | ||
| ndufresne | 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 | [19:03] |
| .................................................. (idle for 4h9mn) | ||
| LuKaRo | 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? | [23:13] |
| pinchartl | LuKaRo: could it be vlc setting it to YUYV explicitly ? | [23:17] |
| LuKaRo | I don't know. I thought as it happens with both VLC and mpv, it might as well be something v4l2 related... | [23:17] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |