The destination filter might expect the hw frames context to be already
set (this is the case e.g. for hwdownload).

The encode function is supposed to just return 0 on success.
This stems from a mixup with the return value of decode functions.
Signed-off-by: Martin Storsjö <martin@martin.st>

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

libavcodec/h264_slice.c:1384:9: warning: variable 'droppable' set but not used

The exit condition was missing.

CC: libav-stable@libav.org

No longer make a dummy device configuration to query.  Instead, just
return everything we recognise from the whole format list.  Also
change the device setup code to query that list only, rather than
intersecting it with the constraint output.

This makes hwupload more usable on mesa/gallium where the video
processor only declares support for RGB formats, making it unable to
deal with YUV formats before this patch.  It might introduce some
different trickier failures in the internal upload/download code
because the set of allowed formats there has changed, though I didn't
find any obvious regressions with i965.

Just a typo.  Add a comment to make it clearer what it's doing.

This was introduced by mistake in 39cdbb12 (only one of the
added variables were really needed).
Signed-off-by: Martin Storsjö <martin@martin.st>

The functions may not clean up properly after using MMX
registers. For the normal testing calls, the checkasm_checked_call
functions will do the cleanup (and check that functions that
should clean up do it as well), but when benchmarking functions
that don't clean up, we don't currently properly clean up at all.

This causes issues if a benchmarked function is followed by testing
of a function that is supposed to not clobber the MMX/FPU state but
doesn't touch it at all.
Signed-off-by: Martin Storsjö <martin@martin.st>

Currently it's exported as AVFrame.pkt_pts, which is also the only use
for that field. The reason it is done like this is that lavc used to
export various codec-specific "timing" information in AVFrame.pts, which
is not done anymore.

Since it is confusing to the callers to have a separate field which is
used only for decoder timestamps and nothing else, deprecate pkt_pts and
use just AVFrame.pts everywhere.

This is a more appropriate place for it.

For now it will only be used by the default get_buffer2 callback for
allocating hw frames.

Appeared in H.264 2016/02.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Adding hybrid log-gamma (https://en.wikipedia.org/wiki/Hybrid_Log-Gamma)
based on the standardization in ARIB STD-B67:
http://www.arib.or.jp/english/html/overview/doc/2-STD-B67v1_0.pdf

The choice of enum value of 18 is consistent with HEVC:
http://phenix.it-sudparis.eu/jct/doc_end_user/current_document.php?id=10481

And also with latest proposal for color format in mkv:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&q=Colour+Format+proposalSigned-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

This will be needed in the following commits.

Fail immediately if automatic encoder selection failed. Always set the
stream_copy/encoding_needed flags in one place.

The current code assumes that encoding_needed is simply an inverse of
stream_copy, which is not true for manually attached files (for which
neither of those is true).

We already have all the necessary information in open_output_file().
This makes the information about the stream/filtergraph mappings
available earlier.

This makes the code easier to read.

This is a more appropriate place for this. H264Context.recovery_frame is
shared between frame threads, so modifying it where it is right now is
invalid.

Going through the whole decoder initialization process for a slice we
are not going to decode is unnecessary and potentially dangerous.

It is always checked in the surrounding code, so this make sure we don't
see a value from an old slice.

This is a more appropriate place for it.

This should make it more clear that this function does not need any
decoder-global state other than the parameter sets.

The code does some weird casting to a 2-dimensional sub-array of
ref2frm. This is not necessary, since only one dimension is needed
there.

Those are unused remnants of the old SVQ3 code.

This will prevent conflicts e.g. in code that deals with both h264 and
hevc.

The code does not depend on the h264 decoder anymore and only needs
information from h264_ps