On 11.10.2017 23:47, Nicolas Dufresne wrote: > 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. Thanks! 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 ? > That's correct. I think it's quite common among embedded (mobile) and desktop-grade decoders to require some auxiliary info from the media headers. > 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. > Parsing bitstream in kernel feels a bit dirty, although it's up to media maintainers to decide. > 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/ > I'll take a look at the Request API / libv4l2 adapter, thank you very much for pointing to it. _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
