[FFmpeg-devel] please don't install libavcodec/vdpau.h [was: Re: [PATCH] don't install rtsp.h]

[Stephen Warren]

Michael Niedermayer wrote:
> 
> * PGP Signed by an unknown key
> 
> On Fri, Feb 06, 2009 at 08:07:02AM -0800, Stephen Warren wrote:
> > Gwenole Beauchesne
> > >
> > > Hi,
> > >
> > > On Fri, 6 Feb 2009, Ronald S. Bultje wrote:
> > >
> > > >> On Fri, Feb 06, 2009 at 08:57:54AM -0500, Ronald S. Bultje wrote:
> > > >>> Why is vdpau.h installed in libavcodec/?
> > > >>
> > > >> because i skiped reviewing the build system part and the build
> > > >> system maintainers either missed it or didnt complain ...
> > > >
> > > > Can any of the vdpau or build people comment and possibly remove it?
> > >
> > > Where should it be installed instead? In any case, this needs to be
> > > installed somewhere so that video player developers can actually
> > > pass/get the right data from FFmpeg.
> >
> > Indeed; during review of the patches it was specifically requested that
> > this file be installed.
> >
> > As Gwenole mentioned, applications need to include this file to get the
> > definition of the data structures that represent video surfaces.
> >
> > What is the problem with installing it?
> 
> The end result is ugly
> i mean having in every decoder code to support XVMC, VDPAU and VAAPI
> (and then DXVA and and and)
> then having a header and seperate struct using a mix of structs from
> these APIs installed as for the 3+ interfaces between lavc and players
> with these 3+ APIs.
> 
> i mean if i compare this to the case where lavc had a single API defined
> in avcodec.h or some avcodec_hwaccel.h that was used by codecs to export
> information needed for the 3 hw accel APIs and then seperately provide
> 3 converters that convert it to XVMC/VDPAU/VAAPI compatible structs
> well IMHO that would be cleaner.

Yes, it'd be great if there were just one data structure, and one header,
which contained the union of all information needed by any VLD-level
decoder.

In that case, we could even unify PIXFMT_H264_VDPAU and PIXFMT_H264_VAAPI
into a single PIXFMT_H264_VLD_ACCEL.

Then, either the app (e.g. MPlayer VO) would implement the conversion to
API-specific format, or as you say, ffmpeg could provide helpers to
centralize the code.

> Also having some converter that converts the VDPAU/VAAPI structs by
> using the hardware to YV12 in a normal accessable buffer would be nice ...

I think some version of Gwenole's patches actually made ffmpeg call the
decoding functions directly, rather than passing them through to e.g.
MPlayer's vo module. Long-term, I think that's an even better way to go.

I would imagine this would work by ffmpeg exposing PIXFMT's for the API-
specific surface: PIXFMT_VDPAU_VID_SURFACE, PIXFMT_VAAPI_SURFACE. Plus,
some filter API to hide the details of converting those PIXFMTs to
something standard like PIXFMT_YV12 using getbits.

I just wish I had more time to hack on ffmpeg/MPlayer to push that kind
of thing through.

-- 
nvpublic