The segment path is desumed from the playlist path, recording a
relative path in the playlist while serving the file could lead
to misleading results.

Thread safe version of the common basename and dirname.

Also fixes linking in various configs with only individual parts enabled
because the RTP muxer chaining code depends on the general RTP code,
which is now accounted for.

This option disables all programs, libraries and other parts of Libav
that get built as part of the compilation process.

Fixes decoding of 9/10 bit per pixel h264 videos as reported in
https://bugzilla.libav.org/show_bug.cgi?id=404 .

This function used to be shared with the xxan decoder, but that is not
true anymore.

The background changes from 128 (used by the default/cmdutils
get_buffer()) to 0. This looks more correct.

Do not overwrite linesize set by get_buffer().

The last frame in the FATE test is not decoded anymore, since the file
is cut and a part of it is missing.

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

If s->filename doesn't contain any period/filename extension to strip
away, the buffer will be too small to fit both strings. This isn't
any buffer overflow since the concatenation uses av_strlcat with
the right buffer size.
Signed-off-by: Martin Storsjö <martin@martin.st>

The description as updated in 6e5c44b0f made it sound like it is
handled exactly like the pts, which it is not. Clarify that it
is the packet that triggered returning the frame instead of just
the last avpacket (in case of frame threading, it won't be the
dts of the last packet).
Signed-off-by: Martin Storsjö <martin@martin.st>

Building libavfilter without that functionality makes little sense.

Also move mpegvideo_select statement to the correct position.

Remove some pointless comments and empty lines.

CC: libav-stable@libav.org

Using a frame count, as is done currently, does not work at all with
seeking. Instead, when the number of samples in the final frame has
been decoded, we check if only the 32-bit CRC is remaining. If so, we
assume that it is the final frame.

There is no longer a need to keep total_frames in TTAContext.

Sometimes the extradata has duplicate atoms, but that shouldn't prevent
decoding. Just ensure that it is at least 36 bytes as a sanity check.

CC: libav-stable@libav.org

Fixes Bug 402

This is built on the assumption that the first partition of each
VP8 packet is essential for decoding any later packet - if this
partition is broken/missed, the arithmetic coder gets out of sync
and decoding the bitstream in further packet ends up with total
garbage. If packets of a frame are lost, make sure the first
partition is intact (return only this part of the packet, nothing
else), otherwise stop returning data until the next keyframe is
received.

Alternatively, one would simply not return any packets at all
until the next keyframe, if packet loss is detected.
Signed-off-by: Martin Storsjö <martin@martin.st>