Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Make sure that NVENC does not misbehave if other cuda usages happen
in the application.

The null demuxer does not have a backing AVIOContext.

Setting an invalid range for it makes the encoder behave inconsistently.

The current condition can trigger in cases where it shouldn't, with
unexpected results.
Make sure that:
- container cropping is really based on the original dimensions from the
  caller
- those dimenions are discarded on size change

The code is still quite hacky and eventually should be deprecated and
removed, with the decision about which cropping is used delegated to the
caller.

Also, add generic code for handling cropping, so the decoders can export
just the cropping size and not bother with the rest.

Extend the width/height doxy to clarify that it should store coded
values.

Introducing enforced sync points in arbitrary places is bad for
performance. Since the vast majority of receiving code (QSV VPP or
encoders, retrieving frames through hwcontext) will do the syncing, this
change should not be visible to most callers. But bumping micro just in
case.

This is also consistent with what VAAPI hwaccel does.

We can pick the correct slice index directly from the ID3D11VideoDecoderOutputView
casted from data[3].
Signed-off-by: Anton Khirnov <anton@khirnov.net>

No need to loop through the known surfaces, we'll use the requested surface
anyway.

The loop is only done for DXVA2.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Before this change, it was possible to overflow pic_order_cnt_lsb and
generate a stream with invalid POC numbering.  This makes sure that
the field is large enough that a single IDR B* P sequence uses fewer
than half the available POC lsb values.

This change makes the configured GOP size be respected exactly -
previously the value could be exceeded slightly due to flaws in the
frame type selection logic.

Fixes a number of warnings of the type
libavutil/hmac.c:61:21: warning: assignment from incompatible pointer type

size_t is the correct type to use for sizes.

It is not called from outside h264dec.c anymore.

Cropping parameters are already checked for validity during SPS parsing,
no need to check them again.

When allocating stack space with an alignment requirement that is larger
than the current stack alignment we need to store a copy of the original
stack pointer in order to be able to restore it later.

If we chose to use another register for this purpose we should not pick
eax/rax since it can be overwritten as a return value.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Especially config.log is often read by users trying to compile Libav, so
its move should be documented.

When building DLLs with MSVC, CONFIG_STATIC is disabled (see
d66c52c2 for a more verbose explanation) since the built
object files can't be linked statically (which checkasm does).

This worked up until recently, only by luck.
Signed-off-by: Martin Storsjö <martin@martin.st>

Given it's the same API than DVXA2 I don't know why the same output was not
enabled for both.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

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

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

If a read fails, the current code will free the data but leave the size
non-zero. Make sure the size is zeroed in such a case.

CC: libav-stable@libav.org
Bug-Id: 1001
Found-By: Kamil Frankowicz
Signed-off-by: Sean McGovern <gseanmcg@gmail.com>

In H.264 section 8.2.1, we have that "The bitstream shall not contain
data that result in Min(TopFieldOrderCnt, BottomFieldOrderCnt) not
equal to 0 for a coded IDR frame".  This fixes the encoder to always
conform to this - previously the POC values formed an unbroken
sequence, not resetting to zero on IDR frames.
Signed-off-by: Mark Thompson <sw@jkqxz.net>