On Thu, Jun 8, 2017 at 5:56 PM, Pawel Osciak <posciak@xxxxxxxxxxxx> wrote: > Hi, > > On Fri, May 19, 2017 at 1:08 AM, Hugues FRUCHET <hugues.fruchet@xxxxxx> wrote: >> Before merging this work Hans would like to have feedback from peers, in >> order to be sure that this is inline with other SoC vendors drivers >> expectations. >> >> Thomasz, Pawel, could you give your view regarding ChromeOS and Rockchip >> driver ? > > The drivers for Rockchip codecs are submitted to the public Chromium OS kernel > and working on our RK-based platforms. We have also since added a VP9 API as > well, which is also working on devices that support it. This gives us > a set of H.264, > VP8 and VP9 APIs on both kernel and userspace side (in the open source > Chromium browser) that are working currently and can be used for > further testing. > > We are interested in merging the API patches as well as these drivers upstream > (they were posted on this list two years ago), however we've been blocked by the > progress of request API, which is required for this. Alexandre Courbot > is currently > looking into creating a minimal version of the request API that would provide > enough functionality for stateless codecs, and also plans to further work on > re-submitting the particular codec API patches, once the request API > is finalized. Hi everyone, It is a bit scary to start hacking on V4L with something as disruptive as the request API, so please bear with me as I will inevitably post code that will go from cutely clueless to downright offensive. Thankfully Pawel is not too far from my desk, and we (Pawel, Tomasz and myself) had a very fruitful in-person brainstorming session last week with Laurent, so this should limit the damage. In any case, I think that everybody agrees that this needs to be pushed forward. Chromium OS in particular has a big interest to see this feature landing upstream, so I will dedicate some cycles to this. >From reading the meetings reports (e.g. https://www.spinics.net/lists/linux-media/msg106699.html) I understand that we want to support several use-cases with this and we already have several proposals with code. Chromium in a first time is interested in stateless codecs support, and this use-case also seems to be the simplest to implement, so we would like to start pushing in that direction first. This should give us a reasonably sized code base to rely upon and implement the other use-cases as we see clearer through this. I still need to study a bit the existing proposals and to clearly lay out the conclusions of our meeting with Laurent, but the general idea has not changed too much, except maybe that we thought it may be nice to make state management less explicit to userspace by default. I would be interested in knowing whether there are updated versions of the implementations mentioned in the meeting report above, and/or a merge of these work? Also, if someone is actively working on this at the moment, we will definitely want to sync on IRC or anywhere else. Excited to work with you all! :) Cheers, Alex.
