Le mercredi 11 octobre 2017 à 23:08 +0300, Dmitry Osipenko a écrit : > diff --git a/drivers/staging/tegra-vde/TODO b/drivers/staging/tegra- > vde/TODO > new file mode 100644 > index 000000000000..e98bbc7b3c19 > --- /dev/null > +++ b/drivers/staging/tegra-vde/TODO > @@ -0,0 +1,5 @@ > +TODO: > + - Figure out how generic V4L2 API could be utilized by this > driver, > + implement it. > + That is a very interesting effort, I think it's the first time someone is proposing an upstream driver for a Tegra platform. When I look tegra_vde_h264_decoder_ctx, it looks like the only thing that the HW is not parsing is the media header (pps/sps). Is that correct ? I wonder how acceptable it would be to parse this inside the driver. It is no more complex then parsing an EDID. If that was possible, wrapping this driver as a v4l2 mem2mem should be rather simple. As a side effect, you'll automatically get some userspace working, notably GStreamer and FFmpeg. For the case even parsing the headers is too much from a kernel point of view, then I think you should have a look at the following effort. It's a proposal base on yet to be merged Request API. Hugues is also propose a libv4l2 adapter that makes the driver looks like a normal v4l2 m2m, hiding all the userspace parsing and table filling. This though, is long term plan to integrate state-less or parser-less encoders into linux-media. It seems rather overkill for state-full driver that requires parsed headers like PPS/SPS. https://lwn.net/Articles/720797/ regards, Nicolas
Attachment:
signature.asc
Description: This is a digitally signed message part
