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>

A number of new pix_fmts have been added to AviSynth+:
16-bit packed RGB and RGBA
10-, 12-, 14, and 16-bit YUV 4:2:0, 4:2:2, and 4:4:4
8-, 10-, 12-, 14-, and 16-bit Planar RGB
8-, 10-, 12-, 14-, and 16-bit Planar YUVA and Planar RGBA*
10-, 12-, 14-, and 16-bit GRAY variants*
32-bit floating point Planar YUV(A), Planar RGB(A), and GRAY*

*some of which are not currently available pix_fmts here and were
 not added to the demuxer due to this
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

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

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

It was source of crashes. Use division instead.

Original patch by author. Log message by comitter.

To be used in following commits.

Reviewed-by: Ibrahim Tachijian <barhom@netsat.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

recover segments duration time by hls_time after init hls window.
This is reuqested by Ibrahim Tachijian
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

av_log() expects its first parameter to be a pointer to a struct whose
first element is a pointer to an AVClass. In what I can only imagine is
a typo, one call to av_log() in the AAX decryption code instead passes
a pointer to an AVSHA struct, which doesn't even contain a pointer as
its first element, much less a pointer to an AVClass. Change the call to
pass the current MOVContext, as surrounding calls do.

The incorrect AVClass was causing mpv to emit the warning "av_log
callback called with bad parameters" when playing an .aax file.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>