start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to specify start_number source parameter by
introducing hls_start_number_source with 3 possible values:
generic/epoch/datetime. This ensures to set start sequence number
automatically for practically unique numbers. Generic option is the
default and this is the curent behaviour: start_number option value
specifies the start sequence number. (start_number default value is 0)
If hls_start_number_source is set to epoch, then the start number will
be the seconds since epoch (1970-01-01 00:00:00). If set to datetime,
then the start sequence number will be based on the current date/time
value as YYYYmmddHHMMSS. e.g. 20161231235659.
Hls speficication allows 64 bit integers as sequence numbers. This patch
also changes some code where only 32 bit integer values were handled
correctly.
Reviewed-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Bela Bodecs <bodecsb@vivanet.hu>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: James Almer <jamrial@gmail.com>

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

Reason: For some cases, such as 2 or more graphics cards existing, the
default command line may fail because ffmpeg does not open the correct
device node:
    ffmpeg -hwaccel qsv -c:v h264_qsv -i test.264 -c:v h264_qsv out.264
Let user choose the proper one by running like below:
    ffmpeg -hwaccel qsv -qsv_device /dev/dri/renderD128 -c:v h264_qsv \
-i test.264 -c:v h264_qsv out.264
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Huang, Zhengxu <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew, Zhang <huazh407@gmail.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

Fixes ticket #6072.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This decoder can decode all existing SpeedHQ formats (SHQ0–5, 7, and 9),
including correct decoding of the alpha channel.

1080p is decoded in 142 fps on one core of my i7-4600U (2.1 GHz Haswell),
about evenly split between bitstream reader and IDCT. There is currently
no attempt at slice or frame threading, even though the format trivially
supports both.

NewTek very helpfully provided a full set of SHQ samples, as well as
source code for an SHQ2 encoder (not included) and assistance with
understanding some details of the format.

Allows more codecs than mpeg12video to make use of it.

Mainly useful for supporting decoding of headerless files.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

CID: 1324298
add a label when error goto the label to release resource
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Fixes ticket #6044

Based on patch by Carl Eugen Hoyos

This is what gimp, ImageMagick and FreeImage do and what the
Adobe Photoshop file format specification suggests.
Fixes a sample from ticket #6045.

Reviewed-by: Martin Vignali

when the segments largest duration value is look like 4.000000, the
EXT-X-TARGETDURATION value should equ 4.
it's wrong when hlsenc use ceil, so fix it.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

 problem

fix ticket: #6067

Tested-by: Pero
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

cid: 1396268
when av_strdup(str) error, the lst need release
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

This should make no difference as the value should not be able to be that large
but its more correct this way

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

Default is "bicubic".
Signed-off-by: Lou Logan <lou@lrcd.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

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.

clock_gettime is avalible since macOS 10.12 and iOS 10.0. Because of
weak linking, clock_gettime can be build without error with new
macOS/iOS sdk, but the symbol may not exist on the target system.
Explicitly checking the symbol is required.
https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPFrameworks/Concepts/WeakLinking.htmlSigned-off-by: Wang Bin <wbsecg1@gmail.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Disable B frames when using baseline/constrained baseline profile,
following H.264 spec Annex A.2.1.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Yi A Wang <yi.a.wang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

The only thing we can do at such point is return samples unchanged.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Negate null check
Fixes CID1396248
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

When the command line for children is created, it is assumed that
my_program_name always ends with "ffserver", which doesn't have to
be true if ffserver is called through a symbolic link.

In such a case, it could be that not enough space for "ffmpeg" is
available at the end, leading to a buffer overflow.

One example would be:

$ ln -s /usr/bin/ffserver ~/f; ~/f

As this is only a local buffer overflow, i.e. is based on a weird
program call, this has NO security impact.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Newer version of encoder can create such files.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes ticket #6063.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

The following three commits created a regression by writing initially
invalid mkv headers:

650e17d8 avformat/matroskaenc: write a
CRC32 element on Tags
3bcadf82 avformat/matroskaenc: write a
CRC32 element on Info
ee888cfb avformat/matroskaenc: postpone
writing the Tracks master

Symptoms:

- You can no longer playback a file that is still processed by ffmpeg,
e.g. VLC fails playback
- You can no longer stream a file to a client while if is still being
processed
- Various diagnosing tools show header errors or incomplete headers
(e.g. ffprobe, mediainfo, mkvalidator)

Note: The symptoms do not apply to completed files or ffmpeg runs that
were interrupted with 'q'

Cause:

The mentioned commits made changes in a way that some header elements
are only partially written in
mkv_write_header, leaving the header in an invalid state. Only in
mkv_write_trailer, these elements
are finished correctly, but that does only occur at the end of the
process.

Regression:

Before these commits were applied, mkv headers have always been valid,
even before completion of ffmpeg.
This has worked reliably over many versions of ffmpeg, to it was an
obvious regression.

Bugtracker:

This issue has been recorded as #5977 which is resolved by this patch

Patch:

The patch adds a new function 'end_ebml_master_crc32_preliminary' that
preliminarily finishes the ebml
element without destroying the buffer. The buffer can be used to update
the ebml element later during
mkv_write_trailer. But most important: mkv_write_header finishes with a
valid mkv header again.
Signed-off-by: James Almer <jamrial@gmail.com>

This commit adds the avio_get_dyn_buf function which allows accessing
the
content of a DynBuffer without destroying it.

This is required in matroskaenc for preliminary writing (correct) mkv
headers.

Context for this change is fixing regression bug #5977.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>