Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Prior to this it was possible that format reduction was ended
before it fully propagated leading to failure later in picking
formats.
No testcase with unmodified source exists, the case was reproduced
with less aggressive list merging though.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* cus/stable:
  ffplay: fix build with disabled avfilter
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This issue is hypothetical and no testcase is available.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Revert "avformat/utils: Close codec context since it is allocated by avformat_new_stream in refrence to ticket 2716"

This causes a race condition with VLC. Its plausible that other
applications also would have races with it and its just fixing a memleak when
the user application forgets to free the codec. It causes more
problems than it solves in its current form, thus the revert.
Better solutions are welcome

This reverts commit 0f229f9b.

This matches the matroska defintion of stereo_mode, with
no metadata written if no info exist in sei
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

avformat/utils: Close codec context since it is allocated by avformat_new_stream in refrence to ticket 2716
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* qatar/master:
  dsicinav: Clip the source size to the expected maximum

Clipping the compressed size based on the uncompressed size is not correct
thus this commit is not merged, and the merge is for git metadata only
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Got broken in b383498e.
Signed-off-by: Marton Balint <cus@passwd.hu>

* commit 'dd0bfc3a':
  dsicinav: Bound-check the source buffer when needed

Conflicts:
	libavcodec/dsicinav.c

See: 47f0beadMerged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'fcae3ff1':
  dsicinav: K&R formatting cosmetics

Conflicts:
	libavcodec/dsicinav.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Should fix compile issues with MSVC
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This applies changes similar to fc6de70c
to the >8bit codepath
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

Should fix trac ticket #2797 because of the progress line.

* qatar/master:
  lavfi: filtfmts: use newer avfilter APIs
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '36fb0d02':
  rtsp: Support multicast source filters (RFC 4570)
  rtpproto: Check the source IP if one single source has been specified
  rtpproto: Support IGMPv3 source specific multicast inclusion

Conflicts:
	libavformat/rtpproto.c
	libavformat/rtsp.c
	libavformat/rtsp.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Theoretically using start_time should also work if seeking is available and we
could determine that the next packet after a flush packet is the first packet
of a stream, but I could not think of an easy and clean way to do that, that is
why I sticked to the no seeking available condition for now.

Fixes ticket #2647.
Signed-off-by: Marton Balint <cus@passwd.hu>

Previously we estimated the audio packet pts instead of the frame pts,
therefore it only worked within a single packet (containing multiple frames).

The new method works accross seperate audio packets as well and also handles
better the case if a decoder buffers several packets before outputting a
decoded frame.
Signed-off-by: Marton Balint <cus@passwd.hu>

Also use negative stream_index for signaling obsolete audio packets. Using the
size alone is not enough, because size is 0 for null packets as well.
Signed-off-by: Marton Balint <cus@passwd.hu>

Found-by: llogan
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This also fixes the case where negative chapter ids where input
And fixes the case where remuxing from mkv changed chapter ids

Found-by: Luca Barbato
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

A packet larger than cin->bitmap_size does not make sense.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This is the only such occurance on tests/
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>