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

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

* commit 'eabdc2a8':
  lavf: use initial_padding instead of deprecated delay

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

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

* commit '2df0c32e':
  lavc: use a separate field for exporting audio encoder padding

Conflicts:
	libavcodec/audio_frame_queue.c
	libavcodec/avcodec.h
	libavcodec/libvorbisenc.c
	libavcodec/utils.c
	libavcodec/version.h
	libavcodec/wmaenc.c
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

* commit 'c80a8161':
  h263dec: call get_format() on resolution changes
Merged-by: Michael Niedermayer <michaelni@gmx.at>

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

* commit '1f29e5d7':
  h263dec: call get_format after setting resolution and profile
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Currently, the amount of padding inserted at the beginning by some audio
encoders, is exported through AVCodecContext.delay. However
- the term 'delay' is heavily overloaded and can have multiple different
  meanings even in the case of audio encoding.
- this field has entirely different meanings, depending on whether the
  codec context is used for encoding or decoding (and has yet another
  different meaning for video), preventing generic handling of the codec
  context.

Therefore, add a new field -- AVCodecContext.initial_padding. It could
conceivably be used for decoding as well at a later point.

E-AC-3 samples should contain 6 audio blocks, so concatenate syncframes
in order to achieve this.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

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

Fail safe if the pixel format changes.

Bug-Id: 541

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

This introduces a new option to the mov demuxer: -use_mfra_for
(pts|dts). When it's given and moofs and a MFRA are present, the MFRA's
TFRAs are read for fragment start times.

Unfortunately some programs that produce fragmented mp4s use the TFRA
time field for dts and some for pts. There is no realistic way to detect
which is the case, hence the responsibility is punted onto the user.
This also means that no behavioural change is enabled by default - you
must pass either dts or pts for anything to happen.

Without this change, timestamps for some discontinuous fragmented mp4 are
wrong, and cause audio/video desync and are not usable for generating
HLS.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>

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

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

* commit '76c70e33':
  icecast: Do not use chunked post
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'e44ee1eb':
  movenc: Simplify code by using an existing local pointer
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit 'dad12ce4':
  movenc: Print a warning for an unhandled case of nonzero start dts with empty_moov

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

* commit 'dbb472cb':
  movenc: Write edit lists for fragmented files as well, if necessary

Conflicts:
	libavformat/movenc.c

The default for writing EDTS for fragmented mp4 is left at disabled
this can be overridden via command line with -use_editlist
but EDTS + fragments still does not fully work, which is why it is
left disabled by default
Merged-by: Michael Niedermayer <michaelni@gmx.at>

Regression test for the bug from trac ticket #3849 fixed in commit 14e30255Reviewed-by: Ronald S. Bultje <rsbultje@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

* commit '95ee4e2c':
  movenc: Add some comments explaining subtle details in writing the edit lists
Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '72f80161':
  movenc: Adjust edit lists to trim out parts of tracks with negative pts

Conflicts:
	libavformat/movenc.c

See: 66b45d8f
See: 14fd34d7Merged-by: Michael Niedermayer <michaelni@gmx.at>

* commit '8bef4338':
  smoothstreamingenc: Simplify code by removing a redundant variable
Merged-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>

Icecast uses HTTP 1.0 while Libav uses HTTP 1.1 and enables by
default chunked post.

Icecast actually forwards the HTTP chunk headers to the listener
as part of the media stream (without the chunk encoding HTTP headers)
causing the players to lose sync.

Disabling the option is enough to feed icecast properly.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

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

This is necessary to get the right timestamp offset for content
that starts with dts != 0.

This currently only helps when writing fragmented files with a non-empty
moov atom. When writing an empty moov atom, we don't have any packets
yet, so we don't know the starting dts for the tracks.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

This makes sure that audio preroll for e.g. AAC is signaled correctly.

Previously we only wrote the edit list correctly if we had negative
dts but started with pts == 0 (e.g. for video with B-frames).
Signed-off-by: Martin Storsjö <martin@martin.st>

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