[FFmpeg-devel] [PATCH]Possible configure support for VDPAU

Diego Biurrun diego
Mon Feb 9 01:09:44 CET 2009


On Mon, Feb 09, 2009 at 02:06:21AM +0200, Ivan Kalvachev wrote:
> On 1/6/09, M?ns Rullg?rd <mans at mansr.com> wrote:
> >
> > Gwenole Beauchesne wrote:
> >>
> >> On Tue, 6 Jan 2009, M?ns Rullg?rd wrote:
> >>
> >>>> I would like to avoid plain header name provided by the vendor, even if
> >>>> it's installed under another directory. i.e. avoid plain vdpau.h, or
> >>>> plain
> >>>> va.h (or other_kind_hwaccel_api.h) in the future.
> >>>>
> >>>> e.g. for VA API, va.h is currently not installed under a specific va/
> >>>> directory. So, a #include "va.h" would be ambiguous.
> >>>
> >>> Yes!  Now we can have a code-gem like this:
> >>>
> >>> #include <va.h>
> >>> #include "va.h"
> >>
> >> Except that <va.h> would be in the "va.h" file, so are you fan of some
> >> #include_next magic?
> >
> > No magic needed, unless you used -I. on the compiler command line, and
> > FFmpeg doesn't do that.
> 
> We are not talking about FFmpeg only, as vdpau<_render>.h is (going to
> be) public api.
> An application can do -Ilibavcodec -Ix11 and then include vdpau.

You have missed an old discussion.  We have a lot of non-unique header
names already.  An example is png.h.  That's why we have changed FFmpeg
internally to always use full relative paths with e.g. libavcodec/
prefixes in the #include.

It is the only way to use FFmpeg or libavcodec correctly.  Everything
else is bound to fail.

Diego




More information about the ffmpeg-devel mailing list