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

[Michael Niedermayer]

On Fri, Feb 06, 2009 at 10:27:04AM -0800, Stephen Warren wrote:
> 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.

yes


> 
> > 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.

This sounds quite interresting, i think i do like the idea

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090206/e6087e94/attachment.pgp>