Re: [PATCH 1/3] media: rockchip: Introduce the rkvdec2 driver

Le lundi 17 juin 2024 à 10:20 -0400, Detlev Casanova a écrit :

On Monday, June 17, 2024 10:04:59 A.M. EDT Nicolas Dufresne wrote:

quoted

Hi,

Le lundi 17 juin 2024 à 17:47 +0800, Jianfeng Liu a écrit :

quoted

Hi Detlev,

Thanks a lot for your work! I try to use rkvdec2 with chromium but it
can't play h264 video. Here is the log of chromium:

[5799:5873:0617/171224.850061:VERBOSE2:video_decoder_pipeline.cc(473)]
Initialize(): config: codec: h264, profile: h264 high, level: not
available, alpha_mode: is_opaque, coded size: [1920,1080], visible rect:
[0,0,1920,1080], natural size: [1920,1080], has extra data: true,
encryption scheme: Unencrypted, rotation: 0°, flipped: 0, color space:
{primaries:BT709, transfer:BT709, matrix:BT709, range:LIMITED}
[5799:5886:0617/171224.850915:VERBOSE2:v4l2_video_decoder.cc(182)]
V4L2VideoDecoder():
[5799:5886:0617/171224.851218:VERBOSE1:v4l2_device.cc(128)] Open(): No
devices supporting H264 for type: 0
[5799:5886:0617/171224.851346:VERBOSE4:v4l2_queue.cc(1069)] This queue
does  support requests.: No such file or directory (2)

This one indicates that V4L2_BUF_CAP_SUPPORTS_REQUESTS might be missing in
the REQBUFS implementation. I suspect GStreamer simply assumes this today
for driver exposing stateless formats (which is fair, its not a compliance
test, and we don't have a codec compliance yet).

There is a src_vq->supports_requests = true; Do I also need to set a flag on 
the device caps ?

I don't know, but you can check very easily what flags you have out of REQBUFS
with the dev_debug output or using v4l2-tracer.

regards,
Nicolas

quoted

I'd suggest to check and fix this one, and retry, might only be noise, might
be the main cause, we cannot tell.

quoted

[5799:5886:0617/171224.851426:VERBOSE1:v4l2_video_decoder.cc(476)]
InitializeBackend(): Using a stateless API for profile: h264 high and
fourcc: S264
[5799:5886:0617/171224.851687:VERBOSE1:v4l2_video_decoder.cc(598)]
SetupInputFormat(): Input (OUTPUT queue) Fourcc: S264
[5799:5886:0617/171224.851797:VERBOSE1:v4l2_video_decoder.cc(636)]
AllocateInputBuffers(): Requesting: 17 OUTPUT buffers of type
V4L2_MEMORY_MMAP
[5799:5886:0617/171224.867687:VERBOSE1:v4l2_queue.cc(1511)] Streamon():
(OUTPUT_MPLANE) VIDIOC_STREAMON failed: Invalid argument (22)
[5799:5886:0617/171224.867902:VERBOSE1:v4l2_video_decoder.cc(937)]
StartStreamV4L2Queue(): Failed to streamon V4L2 queue.
[5799:5886:0617/171224.868009:VERBOSE1:v4l2_video_decoder.cc(1377)]
SetState(): Error occurred, stopping queues.
[5799:5886:0617/171224.868105:ERROR:v4l2_video_decoder.cc(120)]
StartStreamV4L2Queue failed at
Decode@media/gpu/v4l2/v4l2_video_decoder.cc:915
[5799:5886:0617/171224.871898:WARNING:v4l2_video_decoder_backend_stateles
s.cc(126)] There is/are 0 pending CAPTURE queue buffers pending dequeuing.
This might be fine or a problem depending on the destruction semantics
(of theclient code.

Here is the chromium code failed when calling VIDIOC_STREAMON:
https://github.com/chromium/chromium/blob/125.0.6422.60/media/gpu/v4l2/v4l
2_queue.cc#L1508

I'm running chromium v125.0.6422.60 and I can decode 1080p h264 with
hantro g1 decoder on rk3588.

Are you using minigbm ? Because if you do, we don't have minigbm code for
this driver (and have no plan to do so, since we don't aim for ChromeOS
support).

Nicolas

quoted

Best regards,
Jianfeng