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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <e5d2f6d735bb4c997393e6d3ace53953b062ecd8.camel@ndufresne.ca>
Date: Mon, 17 Jun 2024 11:22:23 -0400
From: Nicolas Dufresne <nicolas@...fresne.ca>
To: Detlev Casanova <detlev.casanova@...labora.com>, Jianfeng Liu
	 <liujianfeng1994@...il.com>
Cc: alchark@...il.com, andy.yan@...k-chips.com, conor+dt@...nel.org, 
	cristian.ciocaltea@...labora.com, devicetree@...r.kernel.org, 
	didi.debian@...ow.org, dsimic@...jaro.org, gregkh@...uxfoundation.org, 
	heiko@...ech.de, krzk+dt@...nel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, linux-media@...r.kernel.org, 
	linux-rockchip@...ts.infradead.org, linux-staging@...ts.linux.dev, 
	mchehab@...nel.org, robh@...nel.org, sebastian.reichel@...labora.com
Subject: 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:
> > Hi,
> > 
> > Le lundi 17 juin 2024 à 17:47 +0800, Jianfeng Liu a écrit :
> > > 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

> 
> > I'd suggest to check and fix this one, and retry, might only be noise, might
> > be the main cause, we cannot tell.
> > 
> > > [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@...ia/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
> > 
> > > Best regards,
> > > Jianfeng
>