Also, move a misplaced block to the right position.

The ogg serial number doubles as codec id and sequence
value for concatenated samples.

Currently, audio service type is a field in AVCodecContext. However,
side data is more appropriate for this kind of information.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Makes the example work with all the supported AAC encoders.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

It's better to steer users at these, since they are both better
and more alive than the mingw.org versions.

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Move the lavc/imgconvert functions and rename them as follows:
  avpicture_get_size -> av_image_get_buffer_size()
  avpicture_fill     -> av_image_fill_arrays()
  avpicture_layout   -> av_image_copy_to_buffer()

The new functions have an align parameter, which allows to define the
linesize alignment assumed in the buffer (which is set or read).

The names of the functions are consistent with the lavu/samples API
(av_samples_get_buffer_size(), av_samples_fill_arrays()).

A redundant check has been dropped from av_image_fill_arrays().

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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

Since the VDPAU pixel format does not distinguish between different
VDPAU video surface chroma types, we need another way to pass this
data to the application.

Originally VDPAU in libavcodec only supported decoding to 8-bits YUV
with 4:2:0 chroma sampling. Correspondingly, applications assumed that
libavcodec expected VDP_CHROMA_TYPE_420 video surfaces for output.
However some of the new HEVC profiles proposed for addition to VDPAU
would require different depth and/or sampling:
http://lists.freedesktop.org/archives/vdpau/2014-July/000167.html
...as would lossless AVC profiles:
http://lists.freedesktop.org/archives/vdpau/2014-November/000241.html



To preserve backward binary compatibility with existing applications,
a new av_vdpau_bind_context() flag is introduced in a further change.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This can be used by the application to signal its ability to cope with
video surface of types other than 8-bits YUV 4:2:0.

Signed-off-by: Rémi Denis-Courmont <remi@remlab.net>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This carries the pixel format that would be used if it were not for
hardware acceleration. This is equal to AVCodecContext.pix_fmt if
hardware acceleration is not in use.

Signed-off-by: Anton Khirnov <anton@khirnov.net>

makeinfo would otherwise refuse to build it.

QuickTime does support files with an empty initial movie
these days.

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

This is the same logic as is invoked on AVFMT_TS_NEGATIVE,
but which can be enabled manually, or can be enabled
in muxers which only need it in certain conditions.

Also allow using the same mechanism to force streams to start
at 0.

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

It is required by (at least) the ogg demuxer.

Mark the current semi-public apriv API for removal.

Similarly to the omit_tfhd_offset flag added in e7bf085b, this
avoids writing absolute byte positions to the file, making them
more easily streamable.

This is a new feature from 14496-12:2012, so application support
isn't necessarily too widespread yet (support for it in libav was
added in 20f95f21 in July 2014).

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

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>
Signed-off-by: Martin Storsjö <martin@martin.st>

Most importantly, it contains the encoder delay and replaygain info.

Make it more structured.

Since av_gettime() is used in a number of places where actual
real time clock is required, the monotonic clock introduced in
ebef9f5a would have consequences that are hard to handle. Instead
split it into a separate function that can be used in the cases
where only relative time is desired.

On platform where no monotonic clock is available, the difference
between the two av_gettime functions is not clear, and one could
mistakenly use the relative clock where an absolute one is
required. Therefore add an offset, to make it evident that the
time returned from av_gettime_relative never is actual current
real time, even though it is based on av_gettime.

Based on a patch by Olivier Langlois.

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

When decoding, this field holds the inverse of the framerate that can be
written in the headers for some codecs. Using a field called 'time_base'
for this is very misleading, as there are no timestamps associated with
it. Furthermore, this field is used for a very different purpose during
encoding.

Add a new field, called 'framerate', to replace the use of time_base for
decoding.

Decoding acceleration may work even if the codec level is higher than
the stated limit of the VDPAU driver. Or the problem may be considered
acceptable by the user. This flag allows skipping the codec level
capability checks and proceed with decoding.

Applications should obviously not set this flag by default, but only if
the user explicitly requested this behavior (and presumably knows how
to turn it back off if it fails).

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

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.

This function provides an explicit VDPAU device and VDPAU driver to
libavcodec, so that the application is relieved from codec specifics
and VdpDevice life cycle management.

A stub flags parameter is added for future extension. For instance, it
could be used to ignore codec level capabilities (if someone feels
dangerous).

Signed-off-by: Anton Khirnov <anton@khirnov.net>

The -hls_allow_cache parameter enables explicitly setting the
EXT-X-ALLOW-CACHE tag in the manifest file. That tag indicates
whether the client MAY or MUST NOT cache downloaded media
segments for later replay.

Valid values are 1 (=YES) or 0 (=NO) and the EXT-X-ALLOW-CACHE
will not show in the manifest for other values (or if
-hls_allow_cache is not used.

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

Bug-Id: 661
CC: libav-stable@libav.org

This is the expected behavior shared by all other cli multimedia players.

Bug-Id: 732

Signed-off-by: Diego Biurrun <diego@biurrun.de>

Intermixing =encoding utf-8 in the file can confuse some pod2man
implementations.

Signed-off-by: Diego Biurrun <diego@biurrun.de>

It allows to configure how long will avformat_find_stream_info() wait
to get the first timestamp.

A function declaration is the prototype.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>