On Mon, 12 Jan 2015 00:46:26 +0000 "Zhao, Halley" <halley.z...@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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
