encode buffer size was ignored
Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

If the video dimensions are different than the ASS play_res then the
font sizes need to be adjusted to get the same apparent render size.
Signed-off-by: Philip Langdale <philipl@overt.org>

Initializes the mov text sample description from the ASS header and
creates an mov font table from the fonts available in the ASS Styles.
Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

The last record at the end of each dialog was never closed
Signed-off-by: Philip Langdale <philipl@overt.org>

Makes style update code easier to extend for style types not yet handled
Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

The [Script Info] section was skipped if starts with UTF8 BOM
Signed-off-by: Philip Langdale <philipl@overt.org>

Font sizes are relative to the subtitle frame dimensions. If the
expected frame dimensions are not known, the font sizes will most
likely be incorrect.
Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Signed-off-by: Philip Langdale <philipl@overt.org>

Style flags were only being turned on.  If the default was on and style
record turned off, style flag remained on.
Signed-off-by: Philip Langdale <philipl@overt.org>

They should be 0 or 1 so that 0 or -1 is written to the ass header
Signed-off-by: Philip Langdale <philipl@overt.org>

It's not necessary to walk the style record list twice per subtitle
character.  style records are in order and do not overlap.
Signed-off-by: Philip Langdale <philipl@overt.org>

A conversion from rgb to bgr is necessary
Signed-off-by: Philip Langdale <philipl@overt.org>

Forgotten in 672946c7

This has been cargo culted from mpegvideo and serves no useful purpose.
It will be initialize correctly in h264_field_start()

The name is misleading, this function does a lot more than just flushing
the DPB.

It represents the relationship between them more naturally and will be
useful in the following commits.

Allows significantly more frames in fate-h264-attachment-631 to be
decoded.

Those SEIs refer to the currently active SPS. However, since the SEI
NALUs precede the coded picture data in the bitstream, the active SPS is
in general not known when we are decoding the SEI.

Therefore, store the content of the picture timing SEIs and actually
parse it when the active SPS is known.

This tells the parsing functions the payload size and prevents them from
overreading.

Such errors are not necessarily fatal and decoding might still be
possible, e.g. it happens for MVC streams where we do not handle the
subset SPS thus failing to parse its corresponding PPS.

Currently the frame pool used by the default get_buffer2()
implementation is a single struct, allocated when opening the decoder.
A pointer to it is simply copied to each frame thread and we assume that
no thread attempts to modify it at an unexpected time. This is rather
fragile and potentially dangerous.

With this commit, the frame pool is made refcounted, with the reference
being propagated across threads along with other context variables. The
frame pool is now also immutable - when the stream parameters change we
drop the old reference and create a new one.

This is extremely fragile against reordering and hides what is actually
being copied. Copy all the fields manually instead.

Use the AVFrame API to properly allocate and free frames for delayed
release.

Specifically, between the user-facing one and the first frame thread
one.

This is fragile and dangerous, allocate separate private data for each
per-thread context.

The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
  other threads
- a "fixup" function is called for all the other threads to e.g.
  allocate dynamically allocated data
is very fragile and hard to follow, so it is abandoned. Instead, the
same init function is used to init each per-thread context. Where
necessary, AVCodecInternal.is_copy can be used to differentiate between
the first thread and the other ones (e.g. for decoding the extradata
just once).

This is a constant codec property, so a capability flag is more appropriate.

This is extremely fragile against reordering and hides what is actually
being copied. Copy all the fields manually instead.