[media-workshop] Agenda for the Edinburgh mini-summit

Pawel Osciak posciak at chromium.org
Wed Sep 4 10:35:05 CEST 2013


On Sun, Sep 1, 2013 at 5:19 AM, Laurent Pinchart <
laurent.pinchart at ideasonboard.com> wrote:

> On Saturday 31 August 2013 09:04:14 Pawel Osciak wrote:
> > On Sat, Aug 31, 2013 at 9:03 AM, Laurent Pinchart wrote:
> > > On Saturday 31 August 2013 08:58:41 Pawel Osciak wrote:
> > > > On Sat, Aug 31, 2013 at 1:54 AM, Laurent Pinchart wrote:
> > > > > On Friday 30 August 2013 10:31:23 Mauro Carvalho Chehab wrote:
> > > > > > Em Fri, 30 Aug 2013 15:21:05 +0200 Oliver Schinagl escreveu:
>
> [snip]
>
> > > > > > > What about a hardware accelerated decoding API/framework? Is
> there
> > > > > > > a proper framework for this at all? I see the broadcom module
> is
> > > > > > > still in staging and may never come out of it, but how are
> other
> > > > > > > video decoding engines handled that don't have cameras or
> > > > > > > displays.
> > > > > > >
> > > > > > > Reason for asking is that we from linux-sunxi have made some
> > > > > > > positive progress in Reverse engineering the video decoder
> blob of
> > > > > > > the Allwinner A10 and this knowledge will need a kernel side
> > > > > > > driver in some framework.
> > > > > > >
> > > > > > > I looked at the exynos video decoders and googling for
> linux-media
> > > > > > > hardware accelerated decoding doesn't yield much either.
> > > > > > >
> > > > > > > Anyway, just a thought; if you think it's the wrong place for
> it
> > > > > > > to be discussed, that's ok :)
> > > > > >
> > > > > > Well, the mem2mem V4L2 devices should provide all that would be
> > > > > > needed for accelerated encoders/decoders. If not, then feel free
> to
> > > > > > propose extensionsto fit your needs.
> > > > >
> > > > > Two comments regarding this:
> > > > >
> > > > > - V4L2 mem-to-mem is great for frame-based codecs, but SoCs
> sometimes
> > > > >   only implement part of the codec in hardware, leaving the rest to
> > > > >   the software.
> > > > >
> > > > > Encoded bistream parsing is one of those areas that are left to the
> > > > > CPU, for instance on some ST SoCs (CC'ing Benjamin Gaignard).
> > > >
> > > > This is an interesting topic for me as well, although I'm still not
> sure
> > > > if I can make it to the workshop. Would it make sense to have v4l
> parser
> > > > plugins hook up to qbuf and do the parsing there?
> > >
> > > Do you mean in libv4l ?
> >
> > Yes...
>
> Let's discuss that in Edinburgh then. The major problem as I see it is that
> the hardware codec might consume and produce data that wouldn't fit the
> spirit
> of the current V4L2 API. We might end up with passing register lists in a
> V4L2
> buffer, which would be pretty ugly.
>

Well, this is exactly what I'm wondering about. What should we suggest
vendors who have devices that require preprocessing in the userspace do...


>
> Benjamin, do you plan to attend the conference ?
>
> > > > > - http://www.linuxplumbersconf.org/2013/ocw/sessions/1605
>
> --
> Regards,
>
> Laurent Pinchart
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.linuxtv.org/pipermail/media-workshop/attachments/20130904/722c9242/attachment.html>


More information about the media-workshop mailing list