This way, Doxygen is happier as aliases are now grouped together, and
it never handled #define's in an enum well in the first place.
Y400A already exists as an enum assignment.
Including this header in a C++11 program (inside extern "C") will
throw an error because it looks like a user-defined literal. Add a
space between the two tokens to avoid the problem.
memalign() is not guranteed to be compatible with free() or realloc()
and for platforms in this category we have --enable-memalign-hack
(which should be enabled automatically if such system is detected)
Trying to somehow half support systems that can free() memalign memory
but not reallocate it seems not worth the amount of work needed to
keep 2 then incompatible allocation systems and ensure their
seperation. That is unless this would affect a major platform
on which we want to avoid the memalign hack code
The warnings also cause wasted time and effort as people try
to maintain a separation that does not exist currently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If no string argument is supplied when av_hwdevice_ctx_create() is
called to create a VAAPI device, we currently only try the default
X11 display (that is, $DISPLAY) to find a device, and will therefore
fail in the absence of an X server to connect to. Change the logic
to also look for a device via the first DRM render node (that is,
"/dev/dri/renderD128"), which is probably the right thing to use in
most simple configurations which only have one DRM device.
A non-existent av_buffer_pool_can_uninit() function is mentioned instead
of av_buffer_pool_uninit(). Also, this function is to be called by the
caller, not the pool itself.
In such a case behave as if the buffer was not reallocatable -- allocate a
new one and copy the data (preserving just the part described by the
reference passed to av_buffer_realloc).
CC: libav-stable@libav.org
Reported-By: wm4 <nfxjfg@googlemail.com>
This reverts commit 014773b66b.
Since 230b1c070, the bytewise AV_W*() macros only expand their
argument once, i.e. doing exactly the same change as was done
in the AV_COPY*U macros, so this change is no longer necessary.
Signed-off-by: Martin Storsjö <martin@martin.st>
AV_WN64 is meant for unaligned data, but the existing av_alias* unions
(without a definition for the av_alias attribute - we don't have one
for MSVC) indicate to the compiler that they would have sufficient
alignment for normal access, i.e. the compiler is free to assume
8 byte alignment.
On ARM, this makes sure that AV_WN64 (or two consecutive AV_WN32) is
done with two str instructions instead of one strd.
Signed-off-by: Martin Storsjö <martin@martin.st>
This avoids issues with expanding the argument multiple times,
and makes sure that it is of the right type for the following shifts.
Even if the caller of a macro could be expected not to pass parameters
that have side effects if expanded multiple times, these fallback
codepaths are rarely, if ever, tested, so it is expected that such
issues can arise.
Thefore, for safety, make sure the fallback codepaths only expand
the arguments once.
Signed-off-by: Martin Storsjö <martin@martin.st>