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

Stephen Warren swarren
Mon Dec 1 21:30:29 CET 2008

Uoti Urpala wrote:
> On Mon, 2008-12-01 at 11:17 -0800, Stephen Warren wrote:
> > 2) The data formats really are different; there are syntax elements
> features allowed in H.264 BASELINE profile that are not allowed in
> HIGH profiles (for example, FMO, ASO, RS). A conformant decoder for
> allowed to solely implement the features required for MAIN, and omit
> required for BASELINE.
> >
> > 3) Due to (2) above, the VDPAU API exposes the ability to
> create a decoder object that is capable of decoding a specific
> NVIDIA's implementation of VDPAU only supports MAIN and HIGH for
> Does the decoder really need to choose an explicit profile?

In a practical sense, yes; that's the way the VDPAU API works.

In cases where the spec defines a profile to be a pure superset of
another profile (e.g. MAIN and HIGH H.264), and both profiles are
implemented in the HW, then this doesn't matter; a decoder can simply
request HIGH all the time, and pass MAIN or HIGH data with no issue,
assuming the implementation claims to support HIGH.

However, note that HIGH is a superset, not the same, as MAIN. So, it's
possible for an implementation to support just MAIN and not HIGH. In
that scenario, the above technique would fail.

> You can't feed it data (with whatever profile) and see if the decoder
> handle the features used? Or is it less efficient to do so?

Even if this worked without caveat, it seems much more efficient to
determine this information immediately at decoder setup time, rather
than later once the first frame has been parsed, uploaded the the
accelerator, partially processed, etc.

> > > > -    if(avctx->codec_id == CODEC_ID_SVQ3)
> > > > -        avctx->pix_fmt= PIX_FMT_YUVJ420P;
> > > > -    else
> > > > -        avctx->pix_fmt= PIX_FMT_YUV420P;
> > > > +    // Set in decode_postinit() once initial parsing is
> > > > +    avctx->pix_fmt = PIX_FMT_NONE;
> > >
> > > What is the point of moving the SVQ3 case, I doubt the hardware
> > > acceleration supports that?
> > > Also without the profile stuff the pix_fmt could still be set
> >
> > I'm not actually familiar with what SVQ3 is. Any explanation would
> helpful.
> http://en.wikipedia.org/wiki/SVQ3

OK. I don't believe we support this.

I suppose we could rework this so that non-VDPAU paths initialize
pix_fmt immediately, and only VDPAU paths defer it.

This email message is for the sole use of the intended recipient(s) and may contain
confidential information.  Any unauthorized review, use, disclosure or distribution
is prohibited.  If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

More information about the ffmpeg-devel mailing list