Compared to existing, common opensource H264 encoders, this can be
useful since it has got a different license (BSD instead of GPL).

Performance- and qualitywise it is comparable to x264 in ultrafast
mode.

Hooking it up as an encoder in libavcodec also simplifies comparing
it against other common encoders.

This requires OpenH264 1.3 or newer. Since the OpenH264 API and ABI
changes frequently, only releases are supported.

To take advantage of the OpenH264 patent offer, the OpenH264 library
must not be redistributed, but downloaded at runtime at the end-user's
system.
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

This was removed accidentally as part of 847bf598. This could cause
groundless warning logging.
Signed-off-by: NMartin Storsjö <martin@martin.st>

As referenced in the CoreMedia API docs.
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

Bug-Id: CID 1257781

This is the order that the caller uses in the rest of the file.
Variables are modified to reflect the order above too and their
initialization is merged with their declarationt. No behavioral
change.

Bug-Id: CID 732286

The log level is already a warning.

Based on a patch by Michael Niedermayer <michaelni@gmx.at>.

Reduce the chance of introducing a class of bugs quite hard to track.

On some video samples, VDA silently fails to decode frames and returns
kVDADecoderNoErr. Error out in these cases to avoid producing AVFrames with
empty planes.
Signed-off-by: NStefano Pigozzi <stefano.pigozzi@gmail.com>

libavcodec/ffv1enc.c:922:53: warning: passing argument 5 of ‘encode_rgb_frame’ discards ‘const’ qualifier from pointer target type

libavcodec/ffv1dec.c:898:36: warning: cast discards ‘const’ qualifier from pointer target type

CC: libav-stable@libav.org
Bug-Id: CID 1257779

CC: libav-stable@libav.org
Bug-Id: CID 1257771

Being able to write editlists properly is one of the main points
in the delay_moov flag.
Signed-off-by: NMartin Storsjö <martin@martin.st>

CC: libav-stable@libav.org
Signed-off-by: NMartin Storsjö <martin@martin.st>

This comment can be traced back to the initial commit from 2001,
and it seemed to be misleading/incorect already back then. (It
was used for normal, non-raw file formats already then.)
Signed-off-by: NMartin Storsjö <martin@martin.st>

This allows using libraries that are detected via pkg-config with
msvc. (The libraries themselves may have to be built with MSVC
though.)
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

There shouldn't be any need to add the loaded libraries to the global
symbol namespace.
Signed-off-by: NMartin Storsjö <martin@martin.st>

When we don't adjust the Period start time, we don't need to
parse the earliest_presentation_time from the sidx boxes either.
Signed-off-by: NMartin Storsjö <martin@martin.st>

This was only necessary to get playback to start with dash.js 1.2.0,
it has been fixed in the git version.

The previous behaviour was incorrect - the Period's start time
is irrespective of the actual first timestamp of the contents
within the period. The Period start time only says when, within the
global timeline, this particular piece should start to be played
back.
Signed-off-by: NMartin Storsjö <martin@martin.st>

This should be more correct. This also should give more sensible
switching between video streams with different amount of b-frame
delay.

The current dash.js release (1.2.0) fails to start playback of
such files from the start (if the start pts is > 0), but this has
been fixed in the current git version of dash.js.

Also enable the use of edit lists, so that streams in many cases
start at pts=0.
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

Use the more generic approach with the delay_moov flag, instead of
having a update mechanism specific to this one single atom.
Signed-off-by: NMartin Storsjö <martin@martin.st>

This delays writing the moov until the first fragment is written,
or can be flushed by the caller explicitly when wanted. If the first
sample in all streams is available at this point, we can write
a proper editlist at this point, allowing streams to start at
something else than dts=0. For AC3 and DNXHD, a packet is
needed in order to write the moov header properly.

This isn't added to the normal behaviour for empty_moov, since
the behaviour that ftyp+moov is written during avformat_write_header
would be changed. Callers that split the output stream into header+segments
(either by flushing manually, with the custom_frag flag set, or by
just differentiating between data written during avformat_write_header
and the rest) will need to be adjusted to take this option into use.

For handling streams that start at something else than dts=0, an
alternative would be to use different kinds of heuristics for
guessing the start dts (using AVCodecContext delay or has_b_frames
together with the frame rate), but this is not reliable and doesn't
necessarily work well with stream copy, and wouldn't work for getting
the right initialization data for AC3 or DNXHD either.
Signed-off-by: NMartin Storsjö <martin@martin.st>

This allows writing edit lists even when track->entry == 0, if
the start times have been set.
Signed-off-by: NMartin Storsjö <martin@martin.st>

If fragments == 0 it means we haven't written any moov atom yet.
If the empty_moov flag is set, we already have written an empty moov
atom at startup. Thus, the check for empty_moov is redundant.

This is in preparation for allowing writing the moov atom later,
even when using the empty moov flag.
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

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

When writing an explicit time, reset the cur_time variable to this
value as well. This avoids writing excessive time attributes for each
segment in the timeline, as long as the segments are continuous.
Signed-off-by: NMartin Storsjö <martin@martin.st>

This fixes fate on e.g. ppc.
Signed-off-by: NMartin Storsjö <martin@martin.st>

CC: libav-stable@libav.org
Bug-ID: 781

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

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

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

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: NRémi Denis-Courmont <remi@remlab.net>
Signed-off-by: NAnton 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: NRémi Denis-Courmont <remi@remlab.net>
Signed-off-by: NAnton Khirnov <anton@khirnov.net>