Hi Alexandre, On 08/06/17 11:59, Alexandre Courbot wrote: > 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. Yeah, you went straight into the deep end of the pool :-) I am very, very pleased to see Google picking up this work. We need more core V4L2 developers, so welcome! > 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. Absolutely! > 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. Laurent has been the last one working on this, but his code doesn't have the control handling :-( My latest (well, December 2015) tree with the control request code is here: https://git.linuxtv.org/hverkuil/media_tree.git/log/?h=requests2 It's AFAIK a slightly newer version from what ChromeOS uses. > Excited to work with you all! :) Looking forward to your code! Regards, Hans
