This is by definition the appropriate place for it.
Remove all the now unnecessary libavcodec/internal.h inclusions;
also remove other unnecessary headers from the affected files.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
avpriv_find_start_code() supports non-contiguous buffers
by maintaining a state that allows to find start codes
that span across multiple buffers; a consequence thereof
is that avpriv_find_start_code() is given a zero-sized
buffer, it does not modify this state, so that it appears
as if a start code was found if the state contained a start code.
This can e.g. happen with Sequence End units in MPEG-2 and
to counter this, cbs_mpeg2_split_fragment() reset the state
when it has already encountered the end of the fragment
in order to add the last unit (if it is only of the form 00 00 01 xy)
only once; it also used a flag to set whether this is the final unit.
Yet this can be improved by simply resetting state unconditionally
(thereby avoiding a branch); the flag can be removed by just checking
whether we have a valid start code (of the next unit to add)
at the end.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use -1 as the position in ff_cbs_insert_unit_data()
which implicitly reuses frag->nb_units as the counter.
Also switch to a do-while-loop, as it is more natural
than a for-loop now that the counter is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use -1 as the position in ff_cbs_insert_unit_data()
which implicitly reuses frag->nb_units as the counter.
Also switch to a do-while-loop, as it is more natural
than a for-loop now that the counter is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids code duplication. It furthermore properly checks
for buf_size to be > 0 before doing anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_dict_set() with AV_DICT_DONT_STRDUP_VAL takes ownership
of the string it is passed to as val; this includes freeing it
on error.
Fixes Coverity issue #1497468.
Reviewed-by: Eran Kornblau <eran.kornblau@kaltura.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Since e1027aba68,
ALLOW_INTERLACED is no longer defined in h264_ps.c,
leading to a warning when encountering an SPS compatible
with MBAFF. This warning was always nonsense, because
ff_h264_decode_seq_parameter_set() is also used by the parser
and it makes no sense for the parser to warn about missing
decoder features; after all, it is not a parser's job
to warn when a feature is unsupported by a decoder
(and in this case it is even weirder, because even if the H.264
decoder is disabled, the warning will only be shown for MBAFF
sequence parameter sets). So remove the warning in h264_ps.c.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
use_intra_dc_vlc is currently kept in sync between frame threads
in mpeg4_update_thread_context(), yet it is set when decoding
blocks, i.e. after ff_thread_finish_setup(). This is a data race
and therefore undefined behaviour.
This race can be fixed easily by moving the variable from the context
to the stack: use_intra_dc_vlc is only read in
mpeg4_decode_block() and only if one is decoding an intra block.
There are three callsites for this function: One in
mpeg4_decode_partitioned_mb() which always sets use_intra_dc_vlc
before the call and two in mpeg4_decode_mb(). One of these callsites
is for intra blocks and use_intra_dc_vlc is set before it;
the last callsite is for non-intra blocks, where use_intra_dc_vlc
is ignored. So if it is used, it always uses a new value and can
therefore be moved to the stack.
The above also explains why this data race did not lead to
FATE-test failures.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
An offset has the advantage of not needing to be updated
when the buffer is reallocated. Furthermore, the way the pointer
is currently updated is undefined behaviour in case the pointer
is not already set (i.e. when not encoding MPEG-1/2), because
it calculates the nonsense NULL - s->pb.buf.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also use said function in mpegvideo.c and mpegvideo_enc.c;
and make ff_free_picture_tables() static as it isn't needed anymore
outside of mpegpicture.c.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that dealing with the Simple Studio Profile
has been moved to mpeg4videodec.c. It also allows to avoid
allocations, because one can simply put the required buffers
on the context (if one made these buffers part of MpegEncContext,
the memory would be wasted for every codec other than MPEG-4).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The sample mpeg4/mpeg4_sstp_dpcm.m4v existed in the FATE-suite,
but it was surprisingly unused.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case the macroblocks written to are smaller, yet
the MPEG-4 Simple Studio Profile code for 10bit DPCM ignored this;
e.g. in case of lowres = 2 or = 3, the sample mpeg4_sstp_dpcm.m4v
from the FATE-suite reads beyond the end of the buffer.
This commit fixes this by taking lowres into account.
The DPCM macroblocks of the aforementioned sample look
as good as can be expected after this patch; yet the non-DPCM
coded macroblocks are simply corrupt.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
jpeg2000_decode_tile() (which is run concurrently by several threads
when using slice threading) currently modifies some joint values
before doing its actual work. This is a data race that happens to work
because all threads set the same values; but it is nevertheless
undefined behaviour.
Fix this by performing said preparatory work in the main thread instead.
This fixes the vsynth(1|2|_lena)-jpeg2000(-97)? FATE-tests when using
TSAN and slice threading.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
E.g. the inclusion of parser.h comes from a time when
the parser used a H264Context.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is only needed by h264_cabac.c and h264_cavlc.c.
Also fix up the other headers while at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Inside a function an unnecessary ';' is just a null statement;
yet outside of it it is actually illegal (but compilers happen
to accept it without warning except when using -pedantic).
So modify the macros to always expect the user to add a ';'.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Peeking into the muxing queue can improve the estimate of
the lowest timestamp needed for avoid_negative_ts in case
the lowest timestamp is in a packet other than the first packet
to be muxed.
This fixes tickets #4536 and #5784 as well as the output from
the matroska-avoid-negative-ts FATE-test.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
write_packet() has code to shift the packets timestamps
to make them nonnegative or even make them start at ts zero;
this code inspects every packet that is written and if a packet
with negative timestamp (whether this is dts or pts depends upon
another flag; basically: Matroska uses pts, everyone else dts)
is encountered, this is offset to make the timestamp zero.
All further packets will be offset accordingly (with the offset
converted according to the streams' timebases).
This is based around an assumption, namely that the timestamps
are indeed non-decreasing, so that the first packet with negative
timestamps is the first packet with timestamps. This assumption
is often fulfilled given that the default interleavement function
by default interleaves per dts; yet there are scenarios in which
it may not be fulfilled:
a) av_write_frame() instead of av_interleaved_write_frame() is used.
b) The audio_preload option is used.
c) When the timestamps that are made nonnegative/zero are pts
(i.e. with Matroska), because the packet with the smallest dts
is not necessarily the packet with the smallest pts.
d) Possibly with custom interleavement functions.
In these cases the relative sync of the first few packet(s) is offset
relative to the later packets. This contradicts the documentation
("When shifting is enabled, all output timestamps are shifted by
the same amount").
Therefore this commit changes this: As soon as the first packet
with valid timestamps is output, it is checked and recorded whether
the timestamps need to be shifted. Further packets are no longer
checked for needing to be offset; instead they are simply offset.
In the cases above this leads to packets with negative timestamps
(and the appropriate warnings) instead of desync. This will mostly
be fixed in the next commit.
This commit also factors handling the avoid_negative_ts stuff out
of write_packet() in order to be able to return immediately.
Tickets #4536 and #5784 as well as the matroska-avoid-negative-ts-test
are examples of c); as has been said, some timestamps are now negative,
yet the ref file update does not show it because ffmpeg.c sanitizes
the timestamps (-copyts disables it; ffprobe and mkvinfo also show
the original timestamps).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This assert is based upon the wrong assumption that
the noninterleaved codepath is never used; if it is used,
max_interleave_delta is irrelevant. It furthermore
ignores audio_preload.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
MOVAtom.type is always read as a little-endian number
(despite MOV/ISOBMFF being big-endian).
Fixes the matroska-dovi-write-config8 FATE-test on big-endian
arches (which runs into the "index out of range" warning message).
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
According to the documentation, the ISOBMFF 'equi' box must
be present for equirectangular projections.
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids copying the data in small chunks (1024B) into
the dynamic buffer's small buffer before finally writing them
into the "big" buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the WebM variant of WebVTT subtitles has been handled
specially: It had its own function to write it, because the data
had to be reformatted before writing. But given that other codecs
also need reformatting, this is no good reason to also duplicate the
generic stuff for writing Block(Group)s.
This commit therefore uses an ordinary reformatting function for
this task; writing WebVTT subtitles now uses the generic code
and therefore automatically uses the least amount of bytes
for its BlockGroup length fields whereas the earlier code used
an overestimation for the length of the Duration element.
This is the reason for the changes to the webm-webvtt-remux FATE-test.
(This commit does not implement support for Matroska's way of muxing
WebVTT; it also does not add checks to ensure that WebM-style subtitles
don't get muxed in Matroska. But the function for reformatting gets a
webm prefix to indicate that this is for WebM.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This commit uses the new EbmlWriter API to write the length fields
of the BlockGroup and its descendants that are themselves Master
elements (namely BlockAdditions and BlockMore) on the least amount of
bytes.
This fixes regressions introduced when the special code for writing
general subtitles was removed. Accordingly, the binsub-mksenc and
matroska-zero-length-block FATE-tests have now been reverted back
to their old state again; the advantages of this approach are evident
with the matroska-vp8-alpha-remux test which up until now wrote
all the length fields of all BlockGroups, BlockAdditions and BlockMore
on eight bytes.
Using the EbmlWriter API also allowed to improve locality in
mkv_write_block(): E.g. both DiscardPadding as well as the
BlockAdditional side-data are now directly used to add elements
to the writer whereas the earlier code had to first check
for whether a BlockGroup should be used and then check again
(after the place where a BlockGroup would be opened if one were
used) for whether there is DiscardPadding or BlockAdditional
side-data to write.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Add a field to mkv_track that is set to the offset instead
of checking for whether the track is ProRes when writing
the Block. This makes writing the Block independent
of the AVCodecParameters.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This e.g. stops recalculating ts again.
Also pass the AVFormatContext as pointer to void as it is only used
for logging.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Once upon a time, mkv_write_block() only wrote a (Simple)Block,
not a BlockGroup which is needed for subtitles to convey
the duration. But with the introduction of support for writing
BlockAdditions and DiscardPadding (both of which require a BlockGroup),
mkv_write_block() can also open and close a BlockGroup of its own. This
naturally led to some code duplication which is removed in this commit.
This new code leads to one regression: It always uses eight bytes for
the BlockGroup's length field, whereas the earlier code usually used the
lowest amount of bytes needed. This will be fixed in a future commit.
This temporary regression is also the reason for changes to the
binsub-mksenc and matroska-zero-length-block fate tests.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by using the new NALUList API. This avoids an allocation
of a dynamic buffer per packet as well as the (re)allocation
of the actual buffer as well as copying the data around.
This improves performance: The time for one call to write_packet
decreased from 703501 to 357900 decicyles when remuxing a 5min
14000 kb/s H.264 transport stream.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This will allow to avoid the temporary buffer and memcpys
when repacketing annex B to mp4-style H.264/H.265 without
searching twice for start codes.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Matroska does not have different profiles that allow or disallow
in-band extradata, so one can just use the ordinary H.264 function
for H.265, too. (Both use ff_avc_parse_nal_units() internally anyway.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This avoids allocations+copies in all cases, not only those
in which the desired OBUs are contiguous in the input buffer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Document that it can be used with a NULL AVIOContext to
get the output size in a first pass.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
WavPack's blocks use a length field, so that parsing them is fast.
Therefore it makes sense to parse the block twice, once to get
the length of the output packet and once to write the actual data
instead of writing the data into a temporary buffer in a single pass.
This speeds up muxing from 1597092 to 761850 Decicycles per
write_packet call for a 2000kb/s stereo WavPack file muxed to /dev/null
with writing CRC-32 disabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Matroska uses variable-length elements and in order not to waste
bytes on length fields, the length of the data to write needs to
be known before writing the length field. Annex B H.264/5 and
WavPack need to be reformatted to know this length and this
currently involves writing the data into temporary buffers;
AV1 sometimes suffers from this as well.
This commit aims to solve this by adding a callback that is called
twice per packet: Once to get the size and once to actually write
the data. In case of WavPack and AV1 (where parsing is cheap due
to length fields) both calls will just parse the data with only
the second function writing anything. For H.264/5, the position
of the NALUs will need to be stored to be written lateron.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Avoids the surprise of using pb for the main AVIOContext
at the beginning and end of mkv_write_header() and for
for the dynamic buffer opened for the Info element
in the middle of mkv_write_header().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Using start/end_ebml_master() to write an EBML Master element
uses seeks under the hood. This does not work if the output is
unseekable with the AVIOContext's buffer being very small
(the size of the currently written Matroska EBML header is 40)
or with the AVIOContext being in direct mode, because then
this seek can't be performed in the AVIOContext's buffer.
So using an approach that does not rely on seeking at all
is preferable; this is achieved by switching to EbmlWriter.
Also factor writing the EBML header out into a function of its own.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also check the (user-provided) tags for being overlong; the earlier
code had an implicit unchecked size_t->int conversion.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This muxer currently uses two ways to ensure that no bytes
are wasted by writing unnecessary long EBML length fields
for Master elements and the (Simple)Block element
(all the other elements are fine as one either already has
the right length or getting the actual length is easy
and necessary anyway):
Either use an upper bound that is good enough in case one
is available or write the data into a dynamic buffer first
to get the length; the former approach is impossible in
lots of cases, whereas the latter incurs allocations and
memcpying. It is therefore unfeasible to use the latter
for e.g. the attachments or the BlockGroups.
This patch adds a third alternative to complement the other two:
It consists of an EbmlWriter that one can add EBML elements to
that can be written later by calling ebml_writer_write();
the latter function first traverses the written elements recursively
and calculates the length of each element; then a second pass
is performed in which all the elements are written directly
(without any seeks).
This new API also performs checks for overlong elements;
this is in contrast to put_ebml_string() which simply performs
a size_t->int conversion even for strings originating from the user.
The new API is designed to have very low overhead: It uses
stack arrays and performs no allocations; this also comes
at a price: Right now, it can only be used in contexts in which
there is a compile-time upper bound for the number of elements.
It is also incompatible with storing the offset of an element
in order to update this field later. Furthermore, it puts
the onus of memory management (i.e. ensuring that pointers stay valid)
on the user.
These restrictions might be overcome in the future.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This would happen in case non-WebVTT-subtitles had BlockAdditional
or DiscardPadding side-data. Given that these are not accounted for
in the length of the outer BlockGroup (which is a quite sharp upper
bound) it is possible for the outer BlockGroup to use an insufficient
number of bytes which leads to an assert in end_ebml_master().
Fix this by not opening a second BlockGroup inside an already opened
BlockGroup.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is similar to the faststart option of the mov muxer, yet
in contrast to it it works together with reserve_index_space
(the equivalent to reserved_moov_size): If the reserved space
does not suffice, the data is shifted; if not, the Cues are
written at the front without shifting the data.
Several tests that cover (not only) this have been added.
Implements #7017.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The current size is AV_NUM_DATA_POINTERS (i.e. eight).
This number is chosen in order to minimize the amount of allocations
for AVFrame.extended_(data|buf) for audio; it is meaningless
for video for which four is sufficient. So decrease this array
in order to minimize what is copied in ff_mpeg_ref_picture()
and at the places that copy a whole MpegEncContext.
Also do the same for snowenc.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These messages belong together, yet they can be torn apart
if some other call to av_log() happens between them.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
RV40, SVQ3 and VP7/VP8 are eight-bit only, so it makes no sense
to check for them in the codepath initializing > eight bit contexts.
Move the codec-specific code to a switch located after the eight-bit
init code where this is easily possible; and add checks to the macro
to enable the compiler to remove the remaining checks when initializing
bitdepths > 8 at compile-time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Andreas Rheinhardt