There are two different ways KLV is used in MISB specs - sync and async.
The corresponding text (in ST1401) says:
ISO/IEC 13818-1 Table-34 defines a stream_type = 0x15 for “Metadata carried in PES packets,”
and Table 2-22 defines a stream_id = 0xFC for “metadata stream.”
and
In ISO/IEC 13818-1, Table-34 defines a stream_type = 0x06 for “PES packets containing private
data,” and Table 2-22 defines a stream_id = 0xBD for “private_stream_1.”
These constants allow us to distinguish the two cases, as codec profiles.
Signed-off-by: Marton Balint <cus@passwd.hu>
Both are codec properties and not encoder capabilities. The relevant
AVCodecDescriptor.props flags exist for this purpose.
Signed-off-by: James Almer <jamrial@gmail.com>
Previously, there was no way to flush an encoder such that after
draining, the encoder could be used again. We generally suggested
that clients teardown and replace the encoder instance in these
situations. However, for at least some hardware encoders, the cost of
this tear down/replace cycle is very high, which can get in the way of
some use-cases - for example: segmented encoding with nvenc.
To help address that use case, we added support for calling
avcodec_flush_buffers() to nvenc and things worked in practice,
although it was not clearly documented as to whether this should work
or not. There was only one previous example of an encoder implementing
the flush callback (audiotoolboxenc) and it's unclear if that was
intentional or not. However, it was clear that calling
avocdec_flush_buffers() on any other encoder would leave the encoder in
an undefined state, and that's not great.
As part of cleaning this up, this change introduces a formal capability
flag for encoders that support flushing and ensures a flush call is a
no-op for any other encoder. This allows client code to check if it is
meaningful to call flush on an encoder before actually doing it.
I have not attempted to separate the steps taken inside
avcodec_flush_buffers() because it's not doing anything that's wrong
for an encoder. But I did add a sanity check to reject attempts to
flush a frame threaded encoder because I couldn't wrap my head around
whether that code path was actually safe or not. As this combination
doesn't exist today, we'll deal with it if it ever comes up.
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).
Up until now, it was completely unspecified what the content of the
destination packet dst was on error. Depending upon where the error
happened calling av_packet_unref() on dst might be dangerous.
This commit changes this by making sure that dst is blank on error, so
unreferencing it again is safe (and still pointless). This behaviour is
documented.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
av_packet_ref() mostly treated the destination packet dst as uninitialized,
i.e. the destination fields were simply overwritten. But if the source
packet was not reference-counted, dst->buf was treated as if it pointed
to an already allocated buffer (if != NULL) to be reallocated to the
desired size.
The documentation did not explicitly state whether the dst will be treated
as uninitialized, but it stated that if the source packet is not refcounted,
a new buffer in dst will be allocated. This and the fact that the side-data
as well as the codepath taken in case src is refcounted always treated the
packet as uninitialized means that dst should always be treated as
uninitialized for the sake of consistency. And this behaviour has been
explicitly documented.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
"In both cases.." and "Repeat this call until.." would be better to
be in a separate line.
http://ffmpeg.org/doxygen/trunk/group__lavc__encdec.html
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This adds a decoder for Broderbund's sprite-based QuickTime CDToons
codec, based on the decoder I wrote for ScummVM.
Signed-off-by: Alyssa Milburn <amilburn@zall.org>
Adds support for the ADPCM variant used by some Simon & Schuster
Interactive games such as Real War, and Real War: Rogue States.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adds support for the ADPCM variant used by some Argonaut Games' games,
such as 'Croc! Legend of the Gobbos', and 'Croc 2'.
Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
This allows the fuzzer to target meaningfull codec tags instead
of hunting the 4gb space, which it seems to have problems with.
Suggested-by: James
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Explicitly allowing empty packets to signal flushing helps getting rid
of special cases. It does not hinder the ability to send i.e.
timing-only packets, because one can send packets with zero size and
pkt->data set.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
