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>
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>
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 Matroska muxer has quite a lot of dependencies and lots of them
are unnecessary for WebM. By disabling the Matroska-only code
at compile time one can get rid of them.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
In this case ff_isom_put_dvcc_dvvc() might not be available, leading
to linking failures. Given that WebM currently doesn't support DOVI,
this is fixed by #if'ing the offending code away if the Matroska
muxer is not enabled.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Adds handling of dvcC/dvvC block addition mappings.
The parsing creates AVDOVIDecoderConfigurationRecord side data.
The configuration block is written when muxing into Matroska,
if DOVI side data is present for the track.
Most of the Matroska element parsing is based on Plex's FFmpeg source code.
Signed-off-by: quietvoid <tcChlisop0@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently they are ordered as-written (i.e. by increasing position);
in case av_interleaved_write_frame() is used, this is (mostly)
the same as ordered by increasing dts.
Yet the Matroska specification strongly recommends (SHOULD) that
the CuePoints be sorted by CueTime. mkvalidator warns when they are
not. Therefore this commit sorts them accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
For most check_bitstream() functions this just avoids having
to dereference s->streams[pkt->stream_index] themselves; but for
meta-muxers it will allow to forward the packet to stream with
a different stream_index (belonging to a different AVFormatContext)
without using a spare packet.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do this by allocating AVFormatContext together with the data that is
currently in AVFormatInternal; or rather: Put AVFormatContext at the
beginning of a new structure called FFFormatContext (which encompasses
more than just the internal fields and is a proper context in its own
right, hence the name) and remove AVFormatInternal altogether.
The biggest simplifications occured in avformat_alloc_context(), where
one can now simply call avformat_free_context() in case of errors.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Currently AVIOContext's private fields are all over AVIOContext.
This commit moves them into a new structure in avio_internal.h instead.
Said structure contains the public AVIOContext as its first element
in order to avoid having to allocate a separate AVIOContextInternal
which is costly for those use cases where one just wants to access
an already existing buffer via the AVIOContext-API.
For these cases ffio_init_context() can't fail and always returned zero,
which was typically not checked. Therefore it has been made to not
return anything.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, the Matroska muxer did not use the dispositions it is
given as-is; instead it by default overrode the disposition of the first
track of a kind (audio, video, subtitles) if no track of this kind has
the default disposition set. And up until recently, it also enforced
by default that no more than one track of each kind be marked as
default.
The rationale for the former is that there are lots of containers which
lack the concept of default streams, so that it is not uncommon for no
stream to be marked as default at all; the rationale for the latter was
that up until recently, it was dubious whether the Matroska specification
allowed more than one default stream for track type (e.g. mkvmerge
disallowed it). It was this point which led to the implementation of
the above mentioned behaviour inspired by mkvmerge.
Yet the Matroska specifications have changed and now explicitly allow
to set more than one track of each type as default, so that the main
reason of not using the dispositions as-is was rendered moot. Therefore
this commit changes the default to pass the disposition through.
The matroska-mpegts-remux FATE-test has been updated to still use the
old "infer" mode so that it is still covered by FATE; the
matroska-zero-length-block test has also been updated to cover
the infer_no_subs mode. The references for lots of other FATE tests
needed to be updated because of a newly added FlagDefault element with
value zero (whereas a FlagDefault with value 1 needn't be coded at all,
as it coincided with the default value of said element).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Matroska specifications have evolved and now allow to mark
multiple tracks of the same kind as default (whether this was legal or
not before was dubious; e.g. mkvmerge disallowed it). Yet when the
Matroska muxer is set to infer default dispositions if absent, it also
enforced the now outdated restriction. So update this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The child_class_next API relied on different (de)muxers to use
different AVClasses; yet this API has been replaced by
child_class_iterate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is possible now that the next-API is gone.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
ffio_fill() is used when initially writing unknown length elements;
yet it can happen that the amount of bytes written by it is zero in
which case it is of course unnecessary to ever call it. Whether it is
possible to know this during compiletime depends upon how aggressively
the compiler inlines function calls (i.e. if it inlines calls to
start_ebml_master() where the upper bound for the size of the element
implies that the size will be written on one byte) and this depends upon
optimization settings. It is not the aim of this patch to inline all
calls where it is known that ffio_fill() will be unnecessary, but merely
to make compilers that inline such calls aware of the fact that writing
zero bytes with ffio_fill() is unnecessary. To this end
av_builtin_constant_p() is used to check whether the size is a
compiletime constant.
For GCC 10 this made a difference at -O3 only: The size of .text
decreased from 0x747F (with 29 calls to ffio_fill(), eight of which
use size zero) to 0x7337 (with 21 calls to ffio_fill(), zero of which
use size zero).
For Clang 11 it made a difference at -O2 and -O3: At -O2, the size of
.text decreased from 0x879C to 0x871C (with eight calls to ffio_fill()
eliminated); at -O3 the size of .text decreased from 0xAF2F to 0xAEBF.
Once again, eight calls to ffio_fill() with size zero have been
eliminated.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The value zero for AVPacket.duration means that the duration is unknown,
which in practice means "play this subtitle until overridden by the next
subtitle". Yet for Matroska a BlockGroup with duration zero means
that the subtitle really has a duration zero. "Display until overridden"
is achieved by not setting a duration on the container level at all and
this is achieved by using a SimpleBlock or a BlockGroup without
duration. This commit implements this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
64 bits are needed in order to retain the uid values of Matroska
chapters; the type is kept signed because the semantics of NUT chapters
depend upon whether the id is > 0 or < 0.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Andreas Rheinhardt
quietvoid
Andreas Rheinhardt
Anton Khirnov