[VDPAU] [PATCH 0/1] Add new frame and field mode chroma types. Add VdpDecoderQueryProfileCapability API

[Manoj Bonda]

Hi Philip, 

Thanks for the comments on the changes. We are going a ahead with our current design. 

Thanks,
ManojGupta.

> -----Original Message-----
> From: VDPAU <vdpau-bounces at lists.freedesktop.org> On Behalf Of Philip
> Langdale
> Sent: Friday, November 16, 2018 10:54 AM
> To: vdpau at lists.freedesktop.org
> Subject: Re: [VDPAU] [PATCH 0/1] Add new frame and field mode chroma types.
> Add VdpDecoderQueryProfileCapability API
> 
> On Thu, 15 Nov 2018 03:46:35 +0000
> Manoj Bonda <mbonda at nvidia.com> wrote:
> 
> > Hi Philip,
> >
> > Agreed that media players currently might not use the new enums.
> > But the API changes are done to cater , for all potential use cases vs
> > known use cases. we believe that the API need to address all the use
> > cases hence it is designed as such.
> >
> > > * mpv: As discussed, it does reinterleaving as a separate step, so
> > >   whether the copy is done in the driver or the app makes little
> > >   difference
> >
> > I would just like to clarify that for  Existing chroma types and new
> > interop API, The implementation is free to decode to any surface
> > format internally whichever is the best suited for the underlying h/w
> > and codec. field combining / field splitting is done only if
> > necessary.
> >
> > Thanks,
> > ManojGupta.
> 
> Hi Manoj,
> 
> I understand. You guys should do what you think is best. But, from the
> perspective of ffmpeg and mpv, speaking as the person most likely to update the
> vdpau code, I expect we will use the existing chroma types when decoding, and
> let the implementation do whatever it wants to do, and then use the new
> interop API where available with isFrameStructure=1 always set.
> 
> Thanks,
> 
> --phil
> _______________________________________________
> VDPAU mailing list
> VDPAU at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/vdpau