[FFmpeg-devel] [PATCH]NVIDIA VDPAU patch for h264

[Jason Garrett-Glaser]

On Mon, Dec 1, 2008 at 11:17 AM, Stephen Warren <swarren at nvidia.com> wrote:
> Hi. I work for NVIDIA on VDPAU.
>
> First off, our current position on the VDPAU patches is that we're still working on them and are aware they aren't ready for inclusion in ffmpeg/MPlayer as-is. However, we have been benefiting from the discussion of the patches here, and have been implementing some of the feedback.
>
> I'd like to respond to a few of the comments:
>
> Michael Niedermayer wrote:
>> > @@ -101,6 +104,16 @@
>> >      {0,2,0,2,7,10,7,10}
>> >  };
>> >
>> > +static const enum PixelFormat pixfmt_vdpau_h264_baseline_420[] = {
>> > +                                           PIX_FMT_VDPAU_H264_BASELINE,
>> > +                                           PIX_FMT_NONE};
>> > +static const enum PixelFormat pixfmt_vdpau_h264_main_420[] = {
>> > +                                           PIX_FMT_VDPAU_H264_MAIN,
>> > +                                           PIX_FMT_NONE};
>> > +static const enum PixelFormat pixfmt_vdpau_h264_high_420[] = {
>> > +                                           PIX_FMT_VDPAU_H264_HIGH,
>> > +                                           PIX_FMT_NONE};
>> > +
>>
>> i still do not understand why these are split per profile
>
> There are a couple of reasons:
>
> 1) We were inspired by the model of the XvMC integration into ffmpeg. This separates IDCT v.s. MoCo into separate PIX_FMT values. Admittedly the data format for those is more different than for different H.264 profiles.
>
> 2) The data formats really are different; there are syntax elements or features allowed in H.264 BASELINE profile that are not allowed in MAIN or HIGH profiles (for example, FMO, ASO, RS). A conformant decoder for MAIN is allowed to solely implement the features required for MAIN, and omit those required for BASELINE.
>
> 3) Due to (2) above, the VDPAU API exposes the ability to specifically create a decoder object that is capable of decoding a specific profile. NVIDIA's implementation of VDPAU only supports MAIN and HIGH for example.

I have yet to see anyone use Baseline features that aren't a subset of
Main for any serious purpose.  Thus, your approach of splitting things
by profiles and "only playing Main and High" will completely kill
support for all Baseline streams which would have otherwise worked
just fine.  I have never seen FMO, ASO, or RS used outside of a
research paper.

Splitting by profile simply doesn't make any sense to me.  If you need
to pass the profile to the decoder, why not just create a variable and
enums?

> I'm not actually familiar with what SVQ3 is. Any explanation would be helpful.
>
> We applied the same set of changes to all the codecs in h264.c, in an attempt to keep everything consistent. Is this not the correct thing to do?

Certainly not, since I doubt your graphics cards support SVQ3!  SVQ3
is a proprietary ripoff of H.264 with some minor modifications used by
some Quicktime videos.  RV30/RV40 are similar, except ripoffs by Real
instead of Sorenson.

> Technically, the compiler is free to generate any non-zero value for comparison results, hence the "conversion" code, to ensure consistent values. Consistency helps when printing out and comparing dumps of structures to look for problems.

I'm pretty sure you should go back and read the C spec here.

> The H.264 spec allows a conformant HIGH profile decoder not to implement certain features required by BASELINE. Simply throwing a HIGH and a BASELINE stream into the same file will therefore yield a non-conformant stream; something that is neither HIGH nor BASELINE profile.

I don't think we should let features that nobody use and libavcodec
doesn't (and probably will never) support hold us up for implementing
things the right way.

Dark Shikari