[FFmpeg-devel] [PATCH 0/2] VDA decoder for ffmpeg
michaelni at gmx.at
Wed Aug 22 05:14:14 CEST 2012
On Wed, Aug 22, 2012 at 09:43:27AM +0800, Xidorn Quan wrote:
> On Wed, Aug 22, 2012 at 5:30 AM, Michael Niedermayer <michaelni at gmx.at>wrote:
> > > 1. Origin H.264 decoder never guarantees that HWAccel will be used.
> > >
> > > For some cases, the decoder doesn't call get_format, and we will
> > > have no chance to ask it to use HWAccel. If it happens,
> > > the h264_vda decoder will automatically fall back to software
> > > decoding without any warning or something like this.
> > >
> > > I don't think it is a proper behavior for this decoder. It should
> > > either succeed to initialize and then use VDA to decode, or fail
> > > if it can't and let caller to fall back itself.
> > >
> > > In fact, sometimes, VDA can decode a video but H.264 decoder
> > > refuses to use it and do decoding itself.
> > how can these problems be reproduced? / where can i find h264 samples
> > that show these problems ?
> Any H.264 video with bit depth other than 8bit will prevent
> the origin H.264 decoder from invoking get_format.
if you simply grep for get_format in h264.c you can see a switch()
for the various depths, adding get_format() calls to all depths
that VDA supports should be quite easy.
> My testing shows that VDA can decode video with 10bit bit depth
> though it doesn't output completely correct pictures.
what exactly is wrong on these pictures ? is VDA ignoring the depth
and using 8bit buffers/references ?
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
It is what and why we do it that matters, not just one of them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: Digital signature
More information about the ffmpeg-devel