This reverts commit 014773b6.

Since 230b1c07, 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>

This reverts commit 25bacd0a.

Since 230b1c07, the bytewise AV_W*() macros only expand their
argument once, so revert to the more readable version of these.
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>

If AV_RN and AV_WN are macros with multiple individual reads and
writes, the previous version of the AV_COPYU macro would fail if
the reads and writes overlap.

This should not be any less efficient in any case, given a
sensibly optimizing compiler.
Signed-off-by: Martin Storsjö <martin@martin.st>

AV_WB32 can be implemented as a macro that expands its parameters
multiple times (in case AV_HAVE_FAST_UNALIGNED isn't set and the
compiler doesn't support GCC attributes); make sure not to read
multiple times from the source in this case.
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

We do not strictly specify that hwaccel_context must be cleared if no
hwaccel is used.
Reported-By: wm4 <nfxjfg@googlemail.com>

Extend the probe function to validate the STREAMINFO block that must
follow the fLaC ID tag.

The XCB screen grabber is a drop-in replacement and not under GPL.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

skip_bits_long() can skip up to 32-bit ranges.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

IDs in MOV start from 1.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

The reference frames are used in update_thread_context(), so modifying
them after finish_setup() is a race. The frame in question will be
released during the next decode call.

CC: libav-stable@libav.org

This avoids a segfault on nonexisting codec names.

Signed-off-by: Martin Storsjö <martin@martin.st>

This allows these flags to be automatically enabled for clang,
when using MSVCRT headers.
Signed-off-by: Martin Storsjö <martin@martin.st>

This allows doing this redirection, if building with clang against
old enough MSVC headers that lack strtoll (2012 and older).
Signed-off-by: Martin Storsjö <martin@martin.st>

Avoid a warning for passing an unsigned value to abs(), some compilers
might optimize away abs().

The range field has been introduced in version 1.6.0

It should only be done for DEVICE_BUSY/IN_EXECUTION

Include the libmfx error code and its description

Other parameters, like the display size, should still be taken from the
codec context.

This will allow using this function for encoding as well, where the
input format is already the semi-packed version.

Currently it's memset to 0, which is YUV420P. It should be initialized
to none.

Do not hardcode NV12. This allows 10bit decoding with -hwaccel qsv.

This is required e.g. by HEVC.

The setpts filter does not signal to the rest of the filtergraph that
the stream is CFR. Just generate the timestamps manually instead.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

According to the specification on the MSDN [1], 0 is valid for that
particular field, and it should be ignored in that case.

[1]: http://msdn.microsoft.com/en-us/library/windows/desktop/dd757714(v=vs.85).aspx

Bug-Id: 950
Signed-off-by: Anton Khirnov <anton@khirnov.net>