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>

* 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>

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

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

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

Fixes ticket #2794
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

Adjust the code so that a working ffplay command is printed in the
planar audio case.

There is no reason why this should copy the audio data in a very
complicated way. Also, strictly write the first plane, instead of
writing the whole buffer. This is more helpful in context of the
example. This way a user can clearly confirm that it works by playing
the written data as raw audio.

This assumes one audio packet is decoded one time. This is not true:
packets can be partially decoded. Then you have to "adjust" the packet
and pass the undecoded part of the packet to the decode function again.

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