While it is less featureful (and slower) than the built-in H264
decoder, one could potentially want to use it to take advantage
of the cisco patent license offer.

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

hevcenc -> hevcdec, this is a _decoder_ plugin.

All option names now match the ones provided by the av_color_*_name().

Drop ST from names and symbols, it does not add anything distinctive or
descriptive.

Previously we would allocate a new one for every frame.  This instead
maintains an AVBufferPool of them to use as-needed.

Also makes the maximum size of an output buffer adapt to the frame
size - the fixed upper bound was a bit too easy to hit when encoding
large pictures at high quality.

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

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

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

This was introduced by mistake in 39cdbb12aa (only one of the
added variables were really needed).

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+proposal

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

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

This field (which the spec calls max_num_ref_frames) must be less than
or equal to MaxDpbFrames, which is at most 16.

The PS parsing code is independent from the decoder, so it makes more
sense for it to have its own separate header.

The SVQ3 decoder has been decoupled from the H.264 decoder, so it can
now use its own data type.

Move the NAL unit types into it. This will allow to stop including the
whole decoder-specific h264dec.h in some code that is unrelated to the
decoder and only needs some enum values.

This is more consistent with the naming of other decoders.

Right now this code is mixed with selecting the next output frame. Move
it to a separate function called from h264_field_start(), which is a
more appropriate place for this.

This is a more appropriate place for it.

Doing this after ff_thread_finish_setup() is called is invalid and can
conflict with reads from the other thread.

While the value of those variables will be constant for the whole frame,
they are only used in two functions called from slice header decoding.
Moving them to the per-slice context allows us to make the H264Context
passed to slice_header_parse() constant.

Copy them into the decoder-global context in field_start(). This avoids
modifying the decoder-global context during bitstream parsing.

Avoid unnecessary modification of the decoder-global state in per-slice
code.

There is no bitstream parsing in that block and messing with
decoder-global state is not something that belongs into header parsing.

Nothing else in this function depends on the value of current_slice,
except for two validity checks. Those checks are also moved out of
slice_header_parse().

Replace the decoder-global nal_unit_type/nal_ref_idc variables with the
per-NAL ones. The decoder-global ones still cannot be removed because
they are used by hwaccels.

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>