This allows specifying more dither algorithms without using up flags and
without ambiguities.
Also initialize the new field based on the flags and use it.
Note, improving the logic of the checks is left to subsequent
commits, this here only switches from flags to enum.
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
Using VDPAU correctly means checking for preemption
and possibly regenerating the context all the time.
With the current API there is no context or other
user-defined pointer and thus this in not possible
during decoding unless using some hack like global
variables.
The need to reinitialize both surfaces and even function
pointers makes handling preemption even more difficult.
This patch introduces a new render2 function that gets
both the AVCodecContext and AVFrame in addition,
in both the user can store additional opaque data.
This allows even advanced approaches like keeping a
"generation counter" for the surfaces so they can be
regenerated on the fly and efficiently.
In addition, the function has a return value that will
be passed through all the way instead of being silently
ignored as for the current render function.
Unfortunately the HWAccel API has no way of providing
API/ABI compatibility, so a currently disallowed
state (render pointer being NULL) is used to extend it.
Signed-off-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de>
The bitstream buffers are now private and freed by libavcodec. For
backward compatibility, the hold bitstream buffer pointer is left NULL
(applications were supposed to av_freep() it).
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Add function avfilter_graph_parse_ptr() and favor it in place of
avfilter_graph_parse(), which will be restored with the old/Libav
signature at the next bump.
If HAVE_INCOMPATIBLE_LIBAV_API is enabled it will use the
Libav-compatible signature for avfilter_graph_parse().
At the next major bump the current implementation of
avfilter_graph_parse() should be dropped in favor of the Libav/old
implementation.
Should address trac ticket #2672.
There are 4 separate WebVTT text track kinds: subtitles (the default
if not otherwise specified), captions, descriptions, and metadata.
The WebM muxer needs to know which WebVTT text track kind this is, in
order to synthesize the correct track type and codec id.
To allow a demuxer to indicate the text track kind of the input, a new
set of AV_DISPOSITION flag values has been added, corresponding to
each of the non-default text track kind values.
* commit '3b4feac1ec14f861bdd7f494f288f4d8dd7f449e':
movenc: Keep track of the allocated size for the cluster array
mem: Add av_realloc_array and av_reallocp_array
Conflicts:
doc/APIchanges
libavformat/movenc.c
libavutil/mem.c
libavutil/mem.h
libavutil/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
With the introduction of AVFilterContext->is_disabled, we can simplify
the custom passthrough mode in filters.
This commit is technically a small compat break, but the timeline was
introduced very recently.
Doxy by Stefano Sabatini.
* commit '507b1e454cf9953da3e18f33c9bd1fca78c97cb5':
avcodec: Add field order information to AVCodecParserContext.
Conflicts:
doc/APIchanges
libavcodec/version.h
Merged-by: Michael Niedermayer <michaelni@gmx.at>
Currently, we have a AV_CODEC_ID_SSA, which matches the way the ASS/SSA
markup is muxed in a standalone .ass/.ssa file. This means the AVPacket
data starts with a "Dialogue:" string, followed by a timing information
(start and end of the event as string) and a trailing CRLF after each
line. One packet can contain several lines. We'll refer to this layout
as "SSA" or "SSA lines".
In matroska, this markup is not stored as such: it has no "Dialogue:"
prefix, it contains a ReadOrder field, the timing information is not in
the payload, and it doesn't contain the trailing CRLF. See [1] for more
info. We'll refer to this layout as "ASS".
Since we have only one common codec for both formats, the matroska
demuxer is constructing an AVPacket following the "SSA lines" format.
This causes several problems, so it was decided to change this into
clean ASS packets.
Some insight about what is changed or unchanged in this commit:
CODECS
------
- the decoding process still writes "SSA lines" markup inside the ass
fields of the subtitles rectangles (sub->rects[n]->ass), which is
still the current common way of representing decoded subtitles
markup. It is meant to change later.
- new ASS codec id: AV_CODEC_ID_ASS (which is different from the
legacy AV_CODEC_ID_SSA)
- lavc/assdec: the "ass" decoder is renamed into "ssa" (instead of
"ass") for consistency with the codec id and allows to add a real
ass decoder. This ass decoder receives clean ASS lines (so it starts
with a ReadOrder, is followed by the Layer, etc). We make sure this
is decoded properly in a new ass-line rectangle of the decoded
subtitles (the ssa decoder OTOH is doing a simple straightforward
copy). Using the packet timing instead of data string makes sure the
ass-line now contains the appropriate timing.
- lavc/assenc: just like the ass decoder, the "ssa" encoder is renamed
into "ssa" (instead of "ass") for consistency with the codec id, and
allows to add a real "ass" encoder.
One important thing about this encoder is that it only supports one
ass rectangle: we could have put several dialogue events in the
AVPacket (separated by a \0 for instance) but this would have cause
trouble for the muxer which needs not only the start time, but also
the duration: typically, you have merged events with the same start
time (stored in the AVPacket->pts) but a different duration. At the
moment, only the matroska do the merge with the SSA-line codec.
We will need to make sure all the decoders in the future can't add
more than one rectangle (and only one Dialogue line in it
obviously).
FORMATS
-------
- lavf/assenc: the .ass/.ssa muxer can take both SSA and ASS packets.
In the case of ASS packets as input, it adds the timing based on the
AVPacket pts and duration, and mux it with "Dialogue:", trailing
CRLF, etc.
- lavf/assdec: unchanged; it currently still only outputs SSA-lines
packets.
- lavf/mkv: the demuxer can now output ASS packets without the need of
any "SSA-lines" reconstruction hack. It will become the default at
next libavformat bump, and the SSA support will be dropped from the
demuxer. The muxer can take ASS packets since it's muxed normally,
and still supports the old SSA packets. All the SSA support and
hacks in Matroska code will be dropped at next lavf bump.
[1]: http://www.matroska.org/technical/specs/subtitles/ssa.html
