[FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264 decoding by libyami

[Zhao, Halley]

> There's already vaapi support in ffmpeg though. While I'm not opposed
> to improving the hw decoding situation in general. I think it'd be
> better to improve the ffmpeg code and API itself, instead of adding a
> wrapper for an API that behaves completely different.
I don't know current status of vaapi support in ffmpeg, the following codec 
are supported by libyami but may not in ffmpeg-vaapi yet:
h264enc/vp8dec/vp8enc/vp9dec/jpegdec/jpegenc

to be honest, libyami is core codec library for vaapi (especially on Intel
platform). The purpose is to not implement each codec for each media frameworks.
Libyami is used in chromeos, the same interface works on android as well; as talked
in 0.2.0 release, it can support gstreamer with least effort basing on dma_buf.


> At least export of metadata like profile, color matrix, and so on
> (there are a bunch of these, parsed from the h264 bitstream).
> 
> There's also the question what happens if the hardware can't decode the
> given video.
Thanks, we will follow it next.

 
> Shouldn't this use vaapi surfaces (VASurfaceID)? I'm pretty sure this
> dma_buf stuff is not supported by all backends.
VASurfaceID is platform dependent opaque handle, depends on vaapi context to be used;
decoder and render are tightly coupled.

while dma_buf is Linux kernel buffer sharing mechanism, it can be better
inter-operated among camera/video/egl,opengl/opencl etc. in theory, the only dependency
is Linux kernel. dma_buf is not limited to Intel platform as well.
Vaapi API and Intel i965 driver starts supporting dma_buf half a year ago, I believe it is
the right direction to go.
By the way, 4 rendering-modes are supported in my example player; dma_buf is one of them.


> -----Original Message-----
> From: ffmpeg-devel-bounces at ffmpeg.org [mailto:ffmpeg-devel-
> bounces at ffmpeg.org] On Behalf Of wm4
> Sent: Monday, January 12, 2015 9:35 AM
> To: ffmpeg-devel at ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] add libyami.cpp for h264
> decoding by libyami
> 
> On Mon, 12 Jan 2015 00:46:26 +0000
> "Zhao, Halley" <halley.zhao at intel.com> wrote:
> 
> > > Maintaining decoders is the point of this project.
> > Yes, I agree the core of ffmpeg is codec; But, from the user, ffmpeg
> > is usually treated as a light-weight media framework. Being a media
> framework, it is good to leverage hw codec in many cases.
> 
> There's already vaapi support in ffmpeg though. While I'm not opposed
> to improving the hw decoding situation in general. I think it'd be
> better to improve the ffmpeg code and API itself, instead of adding a
> wrapper for an API that behaves completely different.
> 
> > > Besides, there are some more things missing from the patch.
> > What's the missing? I'm glad to hear it and to fix it.
> 
> At least export of metadata like profile, color matrix, and so on
> (there are a bunch of these, parsed from the h264 bitstream).
> 
> There's also the question what happens if the hardware can't decode the
> given video.
> 
> > > The libstagefright decoding wrapper is apparently a piece of shit.
> Who even uses it?
> > I think libstagefright wrapper is good by giving more options to
> application, you dislike it, but other may do.
> > The bad of it is on buffer sharing; we solve it by dma_buf.
> 
> Shouldn't this use vaapi surfaces (VASurfaceID)? I'm pretty sure this
> dma_buf stuff is not supported by all backends.
> 
> > > I don't see any nice things.
> > The example player demonstrates how the AVFrame interface will be
> improved with dma_buf.
> > I do think dma_buf is a good buffer sharing mechanism to promote hw
> codec.
> > https://github.com/01org/player-ffmpeg-yami
> >
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel