On Saturday 31 August 2013 09:04:14 Pawel Osciak wrote:
> On Sat, Aug 31, 2013 at 9:03 AM, Laurent Pinchart wrote:[snip]
> > 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:
Let's discuss that in Edinburgh then. The major problem as I see it is that
> > > > > > 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...
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.
Benjamin, do you plan to attend the conference ?