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

[Stephen Warren]

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
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.
> 
> 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
can
> 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
complete
> > > > +    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
here...
> >
> > I'm not actually familiar with what SVQ3 is. Any explanation would
be
> 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.
-----------------------------------------------------------------------------------