Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

The command line parameter remains linear.
Signed-off-by: Marton Balint <cus@passwd.hu>

Fixes ticket #6116.

(cherry picked from commit ca62236a)

Only do this when building for a recent VAAPI version - initial
driver implementations were confused about the interpretation of the
framerate field, but hopefully this will be consistent everywhere
once 0.40.0 is released.

(cherry picked from commit ff35aa8c)

Default to using VBR when a target bitrate is set, unless the max rate
is also set and matches the target.  Changes to the Intel driver mean
that min_qp is also respected in this case, so set a codec default to
unset the value rather than using the current default inherited from
the MPEG-4 part 2 encoder.

(cherry picked from commit eddfb572)

This includes a backward-compatibility hack to choose CBR anyway on
old drivers which have no CBR support, so that existing programs will
continue to work their options now map to VBR.

(cherry picked from commit f033ba47)

(cherry picked from commit ca6ae3b7)

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.

(cherry picked from commit 89725a85)

(cherry picked from commit a3c3a5ea)

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.

(cherry picked from commit 37fab066)

Same issue as 17a0f948.

(cherry picked from commit 7d81698b)

(cherry picked from commit 5a5df90d)
(cherry picked from commit d08e02d9)

Fixes reading freed memory
Fixes: 568/clusterfuzz-testcase-6107186067406848

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

> seems to break
> make fate-vsynth1-mjpeg-444

Fixed.

Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643951Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check value reduced as the code does not support values beyond INT_MAX
Also the check is moved to a more common place and before integer truncation

Core of patch is from paul@paulmehta.com
Reference https://crbug.com/643950Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Check value reduced as the code does not support larger lengths

Make the comment message understandable and correct.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Fixes: 559/clusterfuzz-testcase-6424225917173760

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete.

This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Reviewed-by: Bodecs Bela <bodecsb@vivanet.hu>
Signed-off-by: Aman Gupta <aman@tmm1.net>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

This avoids issues with wrong parameter translation by msys on some systems,
and the Windows SDK tools accept both forms equally.

Fixes: null pointer dereference
Fixes: 555/clusterfuzz-testcase-5986646595993600

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

Blocks are marked as key frames whenever the "reference" field is
zero. This breaks for non-keyframe Blocks with a reference timestamp
of zero.

The likelihood of reference timestamp being zero is increased by a
longstanding bug in muxing that encodes reference timestamp as the
absolute time of the referenced frame (rather than relative to the
current Block timestamp, as described in MKV spec).

Now using INT64_MIN to denote "no reference".

Reported to chromium at http://crbug.com/497889 (contains sample)

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

Fixes CID1396242

Fixes Coverity CID 1396254.
Signed-off-by: Marton Balint <cus@passwd.hu>

Fixes CID 1374119.

Fixes CID 1398954.

The original code is correctly following the API - vaTerminate() must
be called to free the resources of a VADisplay after it is created by
any of the vaGetDisplay*() calls; it is not necessary to have
successfully called vaInitialize() on it.  The segfaults which
prompted this change must therefore be bugs in libva or the driver it
loads.

This reverts commit 3606602f.

This currently leaks if multiple device options are specified on the
command line.

This reworks the code a bit and also disallows NULL contexts.

Fixes Coverity CID 1396273, 1396279.
Signed-off-by: Marton Balint <cus@passwd.hu>

The user should supply a proper context.

Fixes Coverity CID 1396246.
Signed-off-by: Marton Balint <cus@passwd.hu>

Detecting a leap second depends on a lot of things, segment time, segment
offset, system leap second implementation, the removed part is a huge
simplification which can be misleading, so it is best to remove it.
Signed-off-by: Marton Balint <cus@passwd.hu>

Not starting a new segment if the elapsed microsecs since the start of the day
equals the the elapsed microsecs since the start of the day at the time of the
last cut seems plain wrong to me, Deti do you remember the original reason
behind this check?
Signed-off-by: Marton Balint <cus@passwd.hu>

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