Currently, it forces IDR frames for both true and false.
Not entirely sure what the original idea behind the tri-state bool
option is.
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

User selectable surfaces are not working correctly, if you set number of
surfaces on cmdline, it will always use minimum 32 or 48 depends on
selected resolution, but in nvenc it is not necessary to use so many
surfaces.

So from now you can define as low as 1 surface and nvenc will still
work, it will ofcourse lower GPU memory usage by 95% and async_delay to zero

That was the easy part, now littlebit more...

Next part of this patch is to always prefer rc_lookahead to be more
important for number of surfaces, than user defined surfaces value.
Maximum rc_lookahead from nvidia documentation is 32, but could increase
in future generations so there is no limit for this yet. Value
async_depth is still accepted and prefered over rc_lookahead.

There were also bug when you request more than rc_lookahead > 31, it
will always set maximum 31, because surface numbers recalculation was
after setting lookahead, which is now fixed.

Results:
If you set -rc_lookahead 32 and -bf 3 it will now use only 40 surfaces
and lower GPU memory usage by 20%, also it will now increase PSNR by 0.012dB

Two more comments:

1. from my internal test, i don't understand addition of 4 more surfaces
when lookahead is calculated, i didn't used this and everything works as
with those 4 more extra surfaces, does anybody know what is going on
there? I looks like it was used for B frames which are calculated
separately, because B frames maximum is 4.

2. rc_lookahead is defined default to -1, but in test condition if
(ctx->rc_lookahead) which sets lookahead it will be always true, i don't
know if this is intended behavior, so in default behavior is lookahead
always on!

This is default condition when rc_lokkahead is -1 (not defined on
cmdline), whis is maybe something that is not intended:
ctx->encode_config.rcParams.enableLookahead = 1;
ctx->encode_config.rcParams.lookaheadDepth  = 0;
ctx->encode_config.rcParams.disableIadapt   = 0;
ctx->encode_config.rcParams.disableBadapt   = 0;
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

Maximum usable surfaces is limited to MAX_REGISTERED_FRAMES constant in
nvenc.h
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>

And remove the now obsolete compat headers.

some flv have no metadata,
ffmpeg will same with the source flv stream.
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>

Found-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Same as e0df56f2.  This was accidentally
reintroduced while merging c8241e73.

when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix
this issue based on h264 spec. Some decoder don't care this case, but this
fix will enhance the encoder action. Before this fix, poc number is
negative in some case.
Reviewed-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Wang, Yi A <yi.a.wang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

A decoder may need this to be set correctly to output frames in the
right order.

(cherry picked from commit b8cac1e8)

This was not observed earlier because the only syntax element which
it normally misses with the current setup is slice_qp_delta, but that
is always going to be zero (in IDR frames QP isn't varied on the
slice) which will always exp-golomb code as a single 1 bit.  The
immediately following part is the byte alignment, which is always a 1
bit followed by 0s which are ignored, so as long as the bitstream is
never aligned at that point we will never notice because the only
difference is that an ignored bit is a 1 instead of a 0.

(cherry picked from commit fc30a908)

(cherry picked from commit ec17ab38)

(cherry picked from commit 17a0f948)

This was always too late; several fields related to it have been incorrectly
zero since the encoder was added.

(cherry picked from commit 314b421d)

(cherry picked from commit 956a5412)

While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder.  It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.

(cherry picked from commit 086e4b58)

This improves behaviour with drivers which do not support packed
headers, such as AMD VCE on mesa/gallium.

(cherry picked from commit 892bbbcd)

This allows better checking of capabilities and will make it easier
to add more functionality later.

It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.

(cherry picked from commit 80a5d051)

There should be an extra offset of 6 on bit_rate_scale and of 4 on
cpb_size_scale which were not accounted for here.

(cherry picked from commit 3a9662af)

Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: James Almer <jamrial@gmail.com>

Based on the draft spec at https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txtSigned-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: James Almer <jamrial@gmail.com>

Based on the draft spec at https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt

'-strict experimental' is required to create files in this format.
Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Marton Balint <cus@passwd.hu>

This fixes the crash reported in ticket #5947.
Signed-off-by: Marton Balint <cus@passwd.hu>

FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.
Signed-off-by: James Almer <jamrial@gmail.com>

This will allow us to write updated stream information not available
during write_header().
Signed-off-by: James Almer <jamrial@gmail.com>

Found-by: Andreas
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

A negative extradata size for example gets passed to memcpy in
avcodec_parameters_from_context causing a segmentation fault.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

Found-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

If realloc fails, the pointer is overwritten and the previously allocated
buffer is leaked, which goes against the expected behavior of keeping the
packet unchanged in case of error.

Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

This makes av_stream_add_side_data() consistent with av_packet_add_side_data().
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>