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

[wm4]

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 
>