The demuxer returned INVALIDDATA and failed to demux the remaining data
when an invalid stream index was read, now it just skips the asf packet
for the stream with an invalid stream index and continues demuxing.

Reported-By: Hendrik Leppkes

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This feature allows making associations between audio tracks
that apple players recognize.  E.g. when an ac3 track has a
tref that points to an aac track, devices that don't support
ac3 will automatically fall back to the aac track.

Apple used to *guess* these associations, but new products
(AppleTV 4) no longer guess and this association can only
be made explicitly now using the "fall" tref.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Also, extend the documentation about setting timestamps.

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

Signed-off-by: Martin Storsjö <martin@martin.st>

The XTEA algorithm operates on 32 bit numbers, not on byte sequences.
The XTEA implementation in libavutil is written assuming big endian
numbers, while the rtmpe signature encryption assumes little endian.

This fixes rtmpe communication with rtmpe servers that use signature
type 8 (XTEA), e.g. crunchyroll.

Signed-off-by: Martin Storsjö <martin@martin.st>

Some entries might be either empty or contain types we do not parse
(eg. 'url '). In both cases, if an 'alis' is not the first entry,
external references are not loaded, so make sure that the array starts
with an 'alis' dref.

Rather than reading the alternate absolute path version from dref
type 18, make sure that 0s are considered as '/'. These values are
sometimes present in the full path, and are mistakenly interpreted as
line terminators othewise.

With the correct handling of this dref type, parsing type 18 is not
needed any more.

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

Signed-off-by: Martin Storsjö <martin@martin.st>

By writing a zero-sized packet, the caller can communicate the
start_dts/start_cts for the stream without actually writing
the first packet.

This allows doing random-access writing of fragments when the
start dts of the stream isn't zero, so that the edit list in the moov
is written based on timestamps from the nominal start time signaled
via the zero-sized packet, while the first proper packet written
corresponds to a later fragment.

To avoid potential unexpected behaviour, empty packets only set
start_dts if the frag_discont flag is set.

Signed-off-by: Martin Storsjö <martin@martin.st>

This tests the case where the muxer correctly guesses that a stream
starts at pts=0.

Signed-off-by: Martin Storsjö <martin@martin.st>

This allows producing fragments discontinously where the video
stream has b-frames (but starts at pts=0), but doesn't work for the
cases with audio with preroll.

Signed-off-by: Martin Storsjö <martin@martin.st>

Contrary to the normal fate tests that run via avconv, this tests
nontrivial call sequences that are only doable via the API
(mainly for different corner cases when using the muxer for
segmenting).

The test muxes fake packet data (with extradata that looks
enough like proper data to make the file be viewable with e.g.
boxdumper) and checks the hash of the produced files. The test also
verifies that fragments produced via different call sequences remain
identical (to avoid e.g. updating the output hashes and suddenly
having fragments that used to be identical suddenly diverging), for
fragments written with frag_discont and/or delay_moov.

Signed-off-by: Martin Storsjö <martin@martin.st>

In most other cases when writing fragmented mp4 files, the output
IO context is flushed after each fragment. Also flush it after
writing the initial moov, to have it behave in the same way.

Signed-off-by: Martin Storsjö <martin@martin.st>

All encoders set pts and dts properly now (and have been doing that for
a while), so there is no good reason to do any timestamp guessing in the
muxer.

The newly added AVStreamInternal will be later used for storing all the
private fields currently living in AVStream.

It will be needed in other functions.

The reasoning for setting it to zero only applies to demuxing.

This seems not to do anything any more since a long time, and removing
it avoids using uninitialized memory. Also change the error value
forwarding as done everywhere else.

Partly fixes: msan_uninit-mem_7fb7d24780d0_2744_R03T.CAK
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

I've got some m4a samples that had jpeg cover art marked as png. Since
these files were supposedly written by iTunes, and other software can
read it (e.g. clementine does), this should be worked around.

Since png has a very simple to detect header, while it's apparently a
real pain to detect jpeg in the general case, try to detect png and
assume jpeg otherwise. Not bothering with bmp, as I have no test case.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

And prevent a memory leak

CC: libav-stable@libav.org

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Some codecs use the codec_tag to signal specific information and
picking the first one would lead to a broken file.

Bug-Id: 883
CC: libav-stable@libav.org

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Some systems may be lacking getservbyport; the previous ifdef wasn't
quite enough since it still assumed that struct servent was defined,
as pointed out by Clément Gregoire.

Simply remove the possibility to return non-numeric services in
getnameinfo; no caller of getnameinfo within libavformat
currently try to use getnameinfo for retrieving the port number without
NI_NUMERICSERV, and falling back on getservbyport may be non-threadsafe.

Signed-off-by: Martin Storsjö <martin@martin.st>

As documented, `av_dup_packet` is broken by design, `av_packet_ref`
matches the AVFrame ref-counted API and can be safely used instead.

Make it return an error and check its return value when it is used.
Simplify the usage by calling `av_packet_ref` internally when needed.

`av_packet_unref` matches the AVFrame ref-counted API and can be used as
a drop in replacement.

Deprecate `av_free_packet`.

And drop the av_dup_packet from the input_thread.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Some server in the wild do not put the boundary at a newline
as rfc1347 7.2.1 states.
Cope with that by reading a line and if it is not empty reading
a second one.

Reported-By: bitingsock

Users that want to generate a live-preview and serve it
would otherwise get partial images.

This also makes sure that a fragmented file without the empty_moov
flag (i.e. with a non-empty initial moov fragment) actually gets
written, if some of the tracks turn out to not have any samples.

Signed-off-by: Martin Storsjö <martin@martin.st>

Some RTSP servers ("HiIpcam/V100R003 VodServer/1.0.0") respond to
our keepalive GET_PARAMETER request by a truncated RTSP header
(lacking the final empty line to indicate a complete response
header). Prior to 764ec701, this worked just fine since we
reacted to the $ as interleaved packet indicator anywhere.

Since $ is a valid character within the response header lines,
764ec701 changed it to be ignored there. But to keep
compatibility with such broken servers, we need to at least
allow reacting to it at the start of lines.

Signed-off-by: Martin Storsjö <martin@martin.st>