Include two values for it, a default one that sets/keeps the current behavior,
where the frame event generated by the primary input will have a timestamp
equal or higher than frames in secondary input, plus a new one where the
secondary input frame will be that with the absolute closest timestamp to that
of the frame event one.

Addresses ticket #9689, where the new optional behavior produces better frame
syncronization.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: James Almer <jamrial@gmail.com>

Stores the item ids of all the items found in the file and
processes the primary item at the end of the meta box. This patch
does not change any behavior. It sets up the code for parsing
alpha channel (and possibly images with 'grid') in follow up
patches.
Reviewed-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

These tables are only used by encoders and only for the current picture;
ergo they need not be put into the picture at all, but rather into
the encoder's context. They also don't need to be refcounted,
because there is only one owner.

In contrast to this, the earlier code refcounts them which
incurs unnecessary overhead. These references are not unreferenced
in ff_mpeg_unref_picture() (they are kept in order to have something
like a buffer pool), so that several buffers are kept at the same
time, although only one is needed, thereby wasting memory.

The code also propagates references to other pictures not part of
the pictures array (namely the copy of the current/next/last picture
in the MpegEncContext which get references of their own). These
references are not unreferenced in ff_mpeg_unref_picture() (the
buffers are probably kept in order to have something like a pool),
yet if the current picture is a B-frame, it gets unreferenced
at the end of ff_mpv_encode_picture() and its slot in the picture
array will therefore be reused the next time; but the copy of the
current picture also still has its references and therefore
these buffers will be made duplicated in order to make them writable
in the next call to ff_mpv_encode_picture(). This is of course
unnecessary.

Finally, ff_find_unused_picture() is supposed to just return
any unused picture and the code is supposed to work with it;
yet for the vsynth*-mpeg4-adap tests the result depends upon
the content of these buffers; given that this patchset
changes the content of these buffers (the initial content is now
the state of these buffers after encoding the last frame;
before this patch the buffers used came from the last picture
that occupied the same slot in the picture array) their ref-files
needed to be changed. This points to a bug somewhere (if one removes
the initialization, one gets uninitialized reads in
adaptive_quantization in ratecontrol.c).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Sufficiently recent Intel hardware is able to do encoding of 8bit 4:4:4
content in HEVC and VP9. The main requirement here is that the frames
must be provided in the AYUV format.

Enabling support is done by adding the appropriate encoding profiles
and noting that AYUV is officially a four channel format with alpha so
we must state that we expect all four channels.

vaapi_decode_find_best_format currently does not set the
VA_SURFACE_ATTRIB_SETTABLE flag on the pixel format attribute that it
returns.

Without this flag, the attribute will be ignored by vaCreateSurfaces,
meaning that the driver's default logic for picking a pixel format will
kick in.

So far, this hasn't produced visible problems, but when trying to
decode 4:4:4 content, at least on Intel, the driver will pick the
444P planar format, even though the decoder can only return the AYUV
packed format.

The hwcontext_vaapi code that sets surface attributes when picking
formats does not have this bug.

Applications may use their own logic for finding the best format, and
so may not hit this bug. eg: mpv is unaffected.

The present default value of 0 will render the overlay video invisible.
A default of 1.0 is consistent with most common use cases.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>

Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Reviewed-by: Philip Langdale <philipl@overt.org>
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>

Directly branch into the special 64-point deinterleave
subroutine rather than going through the general deinterleave.

64-point transform timings on Zen 3:
Before:
   1974 decicycles in           av_tx (fft),16776864 runs,    352 skips
After:
   1956 decicycles in           av_tx (fft),16775378 runs,   1838 skips

This codepath is enabled by default on arm, if the linux perf API
is available, unless disabled with --disable-linux-perf.
Signed-off-by: Martin Storsjö <martin@martin.st>

Its use is local to input_thread().

-stream_loop is currently handled by destroying the demuxer thread,
seeking, then recreating it anew. This is very messy and conflicts with
the future goal of moving each major ffmpeg component into its own
thread.

Handle -stream_loop directly in the demuxer thread. Looping requires the
demuxer to know the duration of the file, which takes into account the
duration of the last decoded audio frame (if any). Use a thread message
queue to communicate this information from the main thread to the
demuxer thread.

Reduces the diff in the following commit.

Also rename it to use the ifile_* namespace.

This avoids a potential race with the demuxer adding new streams. It is
also more efficient, since we no longer do inter-thread transfers of
packets that will be just discarded.

This is a more appropriate place for this.

This undocumented feature runtime-enables dumping input packets. I can
think of no reasonable real-world use case that cannot also be
accomplished in a different way. Keeping this functionality would
interfere with the following commit moving it to the input thread (then
setting the variable would require locking or atomics, which would be
unnecessarily complicated for a feature that probably nobody uses).

It will contain more demuxing-specific code in the future.

This will be required by the following architecture changes.

Use it to simplify some code and fix two off-by-one errors.

Similar to what was previously done for OutputFile.

Make it match reality (current text was not updated for stream
specifiers), extend and clarify the text.

It has not had any effect whatsoever for over 10 years.

It is not actually used for anything.

It is unnecessary, as it is always exactly equivalent to !!ost->enc_ctx

There are currently three possible modes for an output stream:
1) The stream is produced by encoding output from some filtergraph. This
   is true when ost->enc_ctx != NULL, or equivalently when
   ost->encoding_needed != 0.
2) The stream is produced by copying some input stream's packets. This
   is true when ost->enc_ctx == NULL && ost->source_index >= 0.
3) The stream is produced by attaching some file directly. This is true
   when ost->enc_ctx == NULL && ost->source_index < 0.

OutputStream.stream_copy is currently used to identify case 2), and
sometimes to confusingly (or even incorrectly) identify case 1). Remove
it, replacing its usage with checking enc_ctx/source_index values.

A decoder is already selected above, in choose_decoder().

The same information is available from AVStream.codecpar. This will
allow to stop allocating a decoder unless decoding is actually
performed.

Only the decoder itself should do that. Use NULL as is done by all other
logging code in ffmpeg.

The fLaC and dfLa box IDs have been registered with the MP4 RA
(they are now listed at https://mp4ra.org/#/codecs) and support
for muxing FLAC in MP4 has been experimental in ffmpeg for
6 years now, since Nov 21, 2016

This patch removes the experimental status and removes the MP4
object type, as none has been registered for FLAC as it was not
deemed necessary.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

In addition to .eac3, .ec3 is also commonly used by people to name raw
E-AC-3 streams. Enables automatic recognition of the eac3 format for
the .ac3 extension.

For instance Dolby Digital Plus software only support files with
.ec3. Files with .eac3 are not supported. Check issue #18 in the
public dlb_mp4base repository from DolbyLaboratories.
Signed-off-by: Ruben Gonzalez <rgonzalez@fluendo.com>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: James Almer <jamrial@gmail.com>