Please testing with the following command:
./ffmpeg -y -i input.mkv \
 -b:v:0 5250k -c:v h264 -pix_fmt yuv420p -profile:v main -level 4.1 \
 -b:a:0 256k \
 -c:a mp2 -ar 48000 -ac 2 -map 0:v -map 0:a:0\
 -f hls -var_stream_map "v:0,a:0" \
 -master_pl_name master.m3u8 -t 300 -hls_time 10 -hls_init_time 4 -hls_list_size \
 10 -master_pl_publish_rate 10  -hls_flags \
 delete_segments+discont_start+split_by_time ./tmp/video.m3u8

then cat ./tmp/master.m3u8
before:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=6056600,RESOLUTION=1280x720,CODECS="avc1.4d4829,mp4a.40.33"
/video.m3u8

$ ./ffmpeg -i  ./tmp/master.m3u8 -c:v copy -c:a mp2 ./test.mkv
[hls @ 0x7f82f9000000] Skip ('#EXT-X-VERSION:3')
[hls @ 0x7f82f9000000] Opening '/video.m3u8' for reading
[hls @ 0x7f82f9000000] parse_playlist error No such file or directory [/video.m3u8]
./tmp/master.m3u8: No such file or directory

after:
#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=6056600,RESOLUTION=1280x720,CODECS="avc1.4d4829,mp4a.40.33"
video.m3u8
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

when deleting old segments.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

if the directory name of the segments contains "%v".

This memleak is caused by masking the pointer that will eventually
be freed by a variable of the same name in a smaller scope.
Therefore the pointer that gets freed is always NULL when it is
freed and the allocated data leaks.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This is mainly about improving legibility of the code and getting rid of
overlong lines by using variables for st->codecpar instead of accessing
the codecparameters via st->codecpar->.

Also, some code has been moved to better fitting places.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

This commit removes data that is only used during smacker_read_header()
from the demuxer's context and replaces the data that is used by local
variables. The other data is completely dropped.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

The Smacker demuxer currently parses several fields that indicate
how many audio streams a file contains. This data is parsed and stored
into arrays in the demuxer's context and although the data is used only
to initialize the audio streams, it is kept for the whole lifetime of
the demuxer.

This has been changed: The data is used directly to create
the audio streams and no longer kept at all.

This also simplifies error handling in case adding a new stream fails:
Several arrays which until now have been allocated between parsing the
data determining how many audio streams to create and actually creating
them would need to be freed in this case. Now the streams are created
first, so freeing is no longer an issue.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

The Smacker demuxer reads four consecutive 32bit values from the file
header into its demux context (as four uint32_t), converting it to
native endianness in the process and then writing these four values
later (after extradata has been allocated) to extradata as four 32bit
values (converting to little endian in the process).

This commit changes this: The stream and the extradata are allocated
earlier, so that the data destined for extradata can be read directly
into extradata.

Furthermore, given that these values are not needed for demuxing itself
they are now no longer kept as part of the demuxing context.

Finally, a check regarding the number of frames has been moved up,
too, in order to exit early before unnecessarily allocating the
stream and the extradata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Fixes: left shift of negative value -2
Fixes: 20303/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FLAC_fuzzer-5096829297623040

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

Fixes: Timeout (332 -> 21 sec)
Fixes: 20280/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCREENPRESSO_fuzzer-6238663432470528

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

Fixes: signed integer overflow: 23170 * 95058 cannot be represented in type 'int'
Fixes: 20295/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MJPEG_fuzzer-5800212870463488

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

Fixes: signed integer overflow: 9223372036854775775 + 128 cannot be represented in type 'long'
Fixes: 20054/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5686385113825280

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

Fixes: building without muxers
Fixes: 21594

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

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

The WebM DASH Manifest muxer only supports VP8, VP9, Vorbis and Opus,
but there was no check for this. The codec type is used to get a pointer
to a string containing the codec name or NULL if it is not one of those
four codecs. Said pointer has then been used without further checks as
string for the %s conversion specifier in an avio_printf()) call which
is undefined behaviour.

This commit adds a check for the supported codec types.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Some broken apps generate files that have a fake box named 'hoov'
instead of a proper 'moov' one. This is speculation but it seems like
this box contains data to be modified later (eg as file grows in size,
data gets re-written) and its name is supposed to be changed to 'moov'
once it can be used as a 'moov', but for some reason this step is skipped.

Since this is not the first time this happens ('moov' boxes can be found
in 'free' ones) extend the existing hacks to search for the moov in such
boxes and skip the moov_retry since it needs to be found right away.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The idea was to allow separate planes to be filtered independently, however,
in hindsight, literaly nothing uses separate per-plane semaphores and it
would only work when each plane is backed by separate device memory.

throughout vp3_decode_frame the error code was being captured (ret) but never returned.
Signed-off-by: Peter Ross <pross@xvid.org>
Reviewed-by: Anton Khirnov <anton@khirnov.net>

currently, the model outputs the rain, and so need a subtraction
in filter c code to get the final derain result.

I've sent a PR to update the model file and accepted, see at
https://github.com/XueweiMeng/derain_filter/pull/3Signed-off-by: Guo, Yejun <yejun.guo@intel.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Guo, Yejun <yejun.guo@intel.com>

more math binary operations will be added here
Signed-off-by: Guo, Yejun <yejun.guo@intel.com>

Signed-off-by: Guo, Yejun <yejun.guo@intel.com>

Fixes: assertion failure
Fixes: 20390/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_REDUNDANT_PPS_fuzzer-5683400772157440

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

Fixes the following warnings:
libavformat/chromaprint.c:117:42: warning: passing argument 2 of ‘chromaprint_feed’ from incompatible pointer type
libavformat/chromaprint.c:132:52: warning: passing argument 2 of ‘chromaprint_get_raw_fingerprint’ from incompatible pointer type
libavformat/chromaprint.c:143:71: warning: passing argument 4 of ‘chromaprint_encode_fingerprint’ from incompatible pointer type

The code for GAB2 subtitles predates refcounting AVPackets. So in order
to transfer the ownership of a packet's data pkt->data was simply stored
and the packet zeroed; in the end (i.e. in the read_close-function) this
data was then simply freed with av_freep(). This of course leads to a leak
of an AVBufferRef and an AVBuffer. It has been fixed by keeping and
eventually unreferencing the packet's buf instead.

Additionally, the packet is now reset via av_packet_unref().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

An AVIStream (intended to be used as private data for an AVStream) would
leak in this scenario.

Also return a more fitting error code instead of AVERROR_INVALIDDATA.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

If one uses a build without dv demuxer, an AVIStream struct that is
destined to be used as private data for an AVStream by the avi demuxer
would leak, because it has been moved from the AVStream (that is going
to be freed) and only stored in a local variable (in order to be used
for another AVStream), but if the dv demuxer is disabled, the earlier
code returned immediately instead.

Also return a better error code in this scenario (instead of
AVERROR_INVALIDDATA).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Using ff_free_stream() makes the code more readable, more future-proof
(the old code freed AVCodecContexts and AVCodecParameters and its
substructures manually, so that there is a chance that there would be a
memleak for some time if new substructures were added) and reduces
code size.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Suggested-by: James Almer

This reverts commit b7168586.

The commit lead to the use of an uninitialized variable.
Other issues were listed by Andreas Rheinhardt:
https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259150.html

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

Fixes the actual output duration of the sample in ticket #7113.

Related to this are the following changes:
* Mention the GNUmakefile that AviSynth+ provides for installing
  just the headers.
* Expand on users installing AviSynth on their system a little
  more.

AviSynth+ now supports non-Windows OSes, making AvxSynth
obsolete.  Since we no longer support AviSynth 2.5 (which is
essentially what AvxSynth is), remove AvxSynth support and
replace it with AviSynth+.

As a result, the USING_AVISYNTH defines can be switched back
to generic _WIN32.