On 05.12.2017 16:03, Hans Verkuil wrote: > On 12/05/17 13:17, Dmitry Osipenko wrote: >> Hi Hans, >> >> On 04.12.2017 17:04, Hans Verkuil wrote: >>> Hi Dmitry, >>> >>> As you already mention in the TODO, this should become a v4l2 codec driver. >>> >>> Good existing examples are the coda, qcom/venus and mtk-vcodec drivers. >>> >>> One thing that is not clear from this code is if the tegra hardware is a >>> stateful or stateless codec, i.e. does it keep track of the decoder state >>> in the hardware, or does the application have to keep track of the state and >>> provide the state information together with the video data? >>> >>> I ask because at the moment only stateful codecs are supported. Work is ongoing >>> to support stateless codecs, but we don't support that for now. >>> >> >> It is stateless. Is there anything ready to try out? If yes, could you please >> give a reference to that work? > > I rebased my two year old 'requests2' branch to the latest mainline version and > gave it the imaginative name 'requests3': > > https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=requests3 > > (Note: only compile tested!) Thank you very much. > This is what ChromeOS has been using (actually they use a slightly older version) > and the new version that is currently being developed will be similar, so any work > you do on top of this will carry over to the final version without too much effort. > > At least, that's the intention :-) > > I've CC-ed Maxime and Giulio as well: they are looking into adding support for > the stateless allwinner codec based on this code as well. There may well be > opportunities for you to work together, esp. on the userspace side. Note that > Rockchip has the same issue, they too have a stateless HW codec. IIUC, we will have to define video decoder parameters in V4L API and then make a V4L driver / userspace prototype (ffmpeg for example) that will use the requests API for video decoding in order to upstream the requests API. Does it sound good? >> >>> Anyway, I'm OK with merging this in staging. Although I think it should go >>> to staging/media since we want to keep track of it. >>> >> >> Awesome, I'll move driver to staging/media in V5. Thanks! > > Nice, thanks!
