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

This is more correct
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

This fixes CID 1257827.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

Generally, libavformat exports cover art pictures as video streams with
1 packet and AV_DISPOSITION_ATTACHED_PIC set. Only matroskadec exported
it as attachment with codec_id set to AV_CODEC_ID_MJPEG.

Obviously, this should be consistent, so change the Matroska demuxer to
export a AV_DISPOSITION_ATTACHED_PIC pseudo video stream.

Matroska muxing is probably incorrect too. I know that it can create
broken files with an audio track and just 1 video frame when e.g.
remuxing mp3 with APIC to mkv. But for now this commit does not change
anything about muxing, and also continues to write attachments with
AV_CODEC_ID_MJPEG should the muxer application have special knowledge
that the Matroska is broken in this way.

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

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

* cehoyos/master:
  Fix codec fps diplay for very small fps.
  lavf/mpeg: Support alaw in Hikvision CCTV recordings.
  lavf/mpeg: Support more audio codecs in Hikvision CCTV recordings.
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

Signed-off-by: Lou Logan <lou@lrcd.com>

ER with slice threads is buggy and since the merge of the libav cleanup broken
as the ER context which is supposed to be per frame has been placed in
the slice context, so there are multiple per frame which does not work as is.

Theres no bug report about ER with frame threads. If someone knows of a
case where it crashes / fails without slice threads please mail me and
open a ticket on trac.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'a4d34e21':
  h264: disable ER by default

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

* commit '3892bdab':
  avconv: do not overwrite the stream codec context for streamcopy

Conflicts:
	ffmpeg.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

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

* commit 'b2965ec7':
  FATE: add a test for parameter changes in HEVC
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'df528b11':
  hevc: make sure no dangling pointers remain around on VPS/SPS change

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

* commit 'ce0bc09e':
  hevc: do not change the VPS if its contents are the same

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

* commit '7693ba0a':
  hevc: export stream parameters from extradata
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Fixes codec banner for the sample from ticket #4369.

Fixes a sample from ticket #4182.

Fixes a sample from ticket #4182.

* commit '1ae7afd2':
  hevc: split out setting AVCodecContext parameters

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

* commit '7d097a0f':
  mpegtsenc: Take max_delay into account when buffering multiple audio packets into one PES packet

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

Signed-off-by: Lou Logan <lou@lrcd.com>

Otherwise it is shown even after the file was fixed with avidemux,
because the userdata string still ends with 'p'.
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

This improves the last frames duration with CFR and when the input durations
are inaccurate or missing

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

add marcos VEC_FMERGEH() VEC_FMERGEL()
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

I found another MXF File containing ProRes with the following
codec_uls: 060E2B34040101010E04020102110500
Therefor I relaxed the pattern.

Related to issue #4349
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

The way it is currently designed is fundamentally unsafe and cannot be
reasonably fixed without completely rewriting it.

Since we are not doing encoding, there is no point in ever touching the
separate encoding context. Always use the stream codec context.

Fixes writing attachments.

CC:libav-devel@libav.org

This is the same as is done for SPS.

This allows the callers to have a hint of the probable stream parameters
without actually decoding anything.

Additionally always set the software pixel format, so it's available
even if ff_get_format() is not called later. This will be useful for
exporting stream parameters from init().

Make sure we don't buffer up more than max_delay worth of data
before writing a PES packet, even if pes_payload_size is set to
a larger value.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

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