Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes ticket #5774.

Fixes ticket #5805.

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

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

Tested by trac user NTAuthority.
Fixes ticket #5786.

DQT segments may contain 0xFFs which break auto-detection.

They may contain 0xFFs, confusing the start code finding algorithm.

Fixes ticket #5819.

For some reason, when compiling with gcc-asan and a recent enough gcc
version(seen on 5.3+ so far), linking dlopen works without -ldl, but
dlsym fails with:

undefined reference to symbol 'dlsym@@GLIBC_2.2.5'

So this patchs checks for both dlopen and dlsym to work for determining
if -ldl is needed.

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

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

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

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

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

Fixes: 360/test.poc
Found-by: 连一汉 <lianyihan@360.cn>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

also use AVPixFmtDescriptor instead of avcodec_get_chroma_sub_sample()
for log2_chroma*.

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

This allows libavcodec/opus to demux ambisonics in an ogg/opus container.
Channel mapping family 2 is being added in this standards track IETF draft:
tools.ietf.org/html/draft-ietf-codec-ambisonics-00
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Including this header in a C++11 program (inside extern "C") will
throw an error because it looks like a user-defined literal.  Add a
space between the two tokens to avoid the problem.

Commit 2b1d316f made nvenc depend on
LoadLibrary, but the availability of the latter was never checked.

This fixes nvenc on Windows platforms
Signed-off-by: James Almer <jamrial@gmail.com>

Sometimes it's useful to be able to define the exact track numbers in
the generated track, instead of always beginning at track id 1. Using
the option use_stream_ids_as_track_ids now copies the use stream ids
to track ids. Dynamically generated tracks (ie. tmcd) have their track
numbers defined as continuing from the highest numbered stream id.
Signed-off-by: Erkki Seppälä <erkki.seppala.ext@nokia.com>
Signed-off-by: OZOPlayer <OZOPL@nokia.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

This allows retroactive calculation/aggregation of PSNR from the stats
log.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

When use append_list mode, the hls_init_time set nouse,
Because the append_list only support append at the old m3u8 end
cannot set init segments durations at the middle of the list.
That's invalid. and show a warning message for user.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Umair Khan <omerjerk@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

cyrpto allows reading of data which has been aes-128-cbc encrypted given a key and an iv. But it did not handle filetypes which require seeking... e.g. it failed on an encrypted .mp4 file.

example:
take 25.mp4 created with:
ffmpeg -f lavfi -i sine=frequency=1000:beep_factor=2:r=48000:duration=720.0 -f lavfi -i testsrc=duration=720.0:rate=25 -vcodec libx264 -cmp 22 -timecode 10:00:00:00 -r 25 -y out\25.mp4

encrypt with:
openssl enc -aes-128-cbc -K 12345678901234567890123456789012 -iv 12345678901234567890123456789012 -in 25.mp4 -out 25.enc
then to transcode in ffmpeg:
ffmpeg -key 12345678901234567890123456789012 -iv 12345678901234567890123456789012 -i crypto:25.enc -vcodec mpeg4 -r 25 -y 25dec.mp4

prior to this modification, the transcode would fail.

Note also:  crypto previously maked both reads and writes as streamed, which caused the whole file
to be read before the transcode started.  Now, for read only, if the underlying layer is not marked as streamed,
then crypto is not.  This should enable efficient reading of encrypted containers which require seeking.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

the current implementation reads in chunks of 149x16=2384 bytes.
Seems more logical for it to read in chunks of 4096
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Signed-off-by: James Almer <jamrial@gmail.com>

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