On 06/08/2017 06:56 PM, Hans Verkuil wrote:
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
That driver still lacks a number of feature comparing to the rockchip
android driver, since google never requests them. Also the performance
is not as good as the android one.
That is why I start to write a new driver myself.
Also the rockchip platform is very complex, that driver won't be work on
all the SoCs without a large of modification(now only two chips are
supported)
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
Well the request API looks fine for me, I just can't understand why it
is not merged except those are a few functions have a reference problem
stopping build v4l2 as a module.
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
