[FFmpeg-devel] [RFC][PATCH 0/3] VC-1 HW Accel field interlaced decoding

Michael Niedermayer michaelni at gmx.at
Fri Aug 24 04:38:28 CEST 2012

On Mon, Aug 20, 2012 at 06:18:13PM +0200, Hendrik Leppkes wrote:
> On Mon, Aug 20, 2012 at 5:27 PM, Gwenole Beauchesne <gb.devel at gmail.com>wrote:
> > Hi,
> >
> > 2012/8/19 Hendrik Leppkes <h.leppkes at gmail.com>:
> >
> > > this patchset adds support for HW accel decoding of VC-1 field
> > interlaced pictures.
> > > It is tested using the DXVA2 hwaccel implementation only, because i do
> > not have a system setup for VA-API (the only other VC1 HW accel).
> >
> > This patch series does not work with VA-API and I am even surprised it
> > works with DXVA.
> >
> I actually compared the calls to the accelerator with other closed-source
> DXVA decoders, and they match this functionality.
> I don't see whats so surprising about it, the two fields are simply being
> submitted seperately to the HW decoder.
> >
> > > The first two patches are simple preparations and essentially usable
> > stand-alone without any (known) issues.
> > >
> > > Patch 1 disables the full picture header parsing when using a hw accel,
> > because it is not required.
> > > The HW accelerator will perform this parsing itself, and none of the
> > values parsed from the bistream are passed to the HW accelerator. In
> > addition, VC-1 interlaced parsing is known to not be completely tested, so
> > disabling it in a code path where its not required avoids potential bugs.
> >
> > The HW accelerator won't always parse the headers itself. Besides,
> > even for DXVA2, you need to correctly fill in wMBbitOffset. If you
> > stop the parsing earlier, get_bits_count() won't return the expected
> > value. So, wMBbitOffset will get wrong and some HW accelerators may
> > fail. Some other bits are also needed for DXVA2 like MV mode types,
> > etc.
> DXVA2 APIs may have fields for this, however neither NVIDIA or AMD seem to
> care.
> It works just beautifully on cards from both vendors the way it is.
> I personally don't care either way, if the parsing should be performed, go
> for it.
> Note that the wMBbitOffset will have to be handled seperately for the
> second field anyway then, because the bit parser is not advanced through
> the frame.
> Anyway, like i mentioned, its a RFC. All i know is that it works perfectly
> on both AMD and NVIDIA hardware. I briefly tested Intel, and i think they

i think if it works perfectly then its better to apply and improve
the code instead of waiting a long time because its not filling all
API fields

Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Complexity theory is the science of finding the exact solution to an
approximation. Benchmarking OTOH is finding an approximation of the exact
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20120824/68a9ea28/attachment.asc>

More information about the ffmpeg-devel mailing list