[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