If a sequence display extension is read with colour_description equal to
zero, but a user wants to add one or more of the colour_description
elements, then the colour_description elements the user did not explicitly
request to be set are set to zero and not to the value equal to
unknown/unspecified (namely 2). A value of zero is not only inappropriate,
but explicitly forbidden. This is fixed by inferring the right default
values during the reading process if the elements are absent; moreover,
changing any of the colour_description elements to zero is now no longer
possible.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If a new sequence display extension had to be added, this was up until
now done at two places: One where a sequence display extension was
initialized with default values and one where the actual sequence
display extension was inserted into the fragment. This division of
labour is unnecessary and pointless; it has been changed.
Furthermore, if a sequence display extension has to be added, the
earlier code set some fields to their default value twice. This has been
changed, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This commit changes mpeg2_metadata to (a) use ff_bsf_get_packet_ref
instead of ff_bsf_get_packet (thereby avoiding one malloc and free per
filtered packet) and (b) to use only one packet structure at all,
thereby avoiding a call to av_packet_copy_props.
(b) has been made possible by the recent changes to ff_cbs_write_packet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Currently, a fragment's unit array is constantly reallocated during
splitting of a packet. This commit changes this: One can keep the units
array by distinguishing between the number of allocated and the number
of valid units in the units array.
The more units a packet is split into, the bigger the benefit.
So MPEG-2 benefits the most; for a video coming from an NTSC-DVD
(usually 32 units per frame) the average cost of cbs_insert_unit (for a
single unit) went down from 6717 decicycles to 450 decicycles (based
upon 10 runs with 4194304 runs each); if each packet consists of only
one unit, it went down from 2425 to 448; for a H.264 video where most
packets contain nine units, it went from 4431 to 450.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@googlemail.com>
This makes it easier for users of the CBS API to get alloc/free right -
all subelements use the buffer API so that it's clear how to free them.
It also allows eliding some redundant copies: the packet -> fragment copy
disappears after this change if the input packet is refcounted, and more
codec-specific cases are now possible (but not included in this patch).