because the flv specification said the video frametype
should use value range from 0x00 to 0x70,
so use 0xF0 have no problem before support enhanced flv,
but the 0xF0 will get incorrect result after support enhanced flv,
so should set the video frametype mask 0x70 to make it correct now.
Reported-By: flvAnalyser <hybase@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Writing the duration SimpleTag is special: It's size is
reserved in advance via an EBML Void element (if seekable)
and this reserved space is overwritten when writing the trailer;
it does not use put_ebml_string().
The string to write is created via snprintf on a buffer
of size 20; this buffer is then written via put_ebml_binary()
with a size of 20.
EBML strings need not be zero-terminated; if not, they
are implicitly terminated by the element's length field.
snprintf() always zero-terminates the buffer, i.e.
the last byte can be discarded when using an EBML string.
This patch does this.
The FATE changes are as expected: One byte saved for every
track; the only exception is the matroska-qt-mode test:
An additional byte is saved because an additional byte
could be saved from the enclosing Tags length field.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Do it only for video (the only thing for type for which HDR10+
makes sense).
This effectively reverts changes to several FATE ref-files
made in bda44f0f39.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Pass it as void* instead. While just at it, also constify
the pointee of AVDOVIDecoderConfigurationRecord* in
ff_isom_put_dvcc_dvvc().
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These two AVIOContexts currently coincide, but this is not
guaranteed to remain so (in fact, I have plans to write each
TrackEntry into its own AVIOContext).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It is only WebVTT which is special in WebM; hypothetical future
subtitle codecs in WebM will presumably use the ordinary code.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Specifically, test copying a channel layout with custom order,
so that the allocation codepath of av_channel_layout_copy()
is executed.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This test does not need access to the internals of said compilation
unit.
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
av_channel_name(), av_channel_description() and
av_channel_layout_describe() are supposed to return the size
of the needed buffer to allow the user to check for truncation;
the documentation ("If the returned value is bigger than buf_size,
then the string was truncated.") confirms that size does not
mean strlen.
Yet the AVBPrint API, i.e. AVBPrint.len, does not account for
the terminating '\0'. Therefore the returned length is off by one.
Furthermore, also check for whether the returned value actually
fits in an int (which is the return value of these functions).
Reviewed-by: Nicolas George <george@nsup.org>
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The AVBPrint API guarantees that the string buffer is always
zero-terminated; in order to honour this guarantee, there
obviously must be a string buffer at all and it must have
a size >= 1. Therefore av_bprint_init_for_buffer() treats
passing a NULL buffer or size == 0 as invalid data that
leads to undefined behaviour, namely NPD in case NULL is provided
or a write to a buffer of size 0 in case size == 0.
But it would be easy to support this, namely by using the internal
buffer with AV_BPRINT_SIZE_COUNT_ONLY in case size == 0.
There is a reason to allow this: Several functions like
av_channel_(description|name) are actually wrappers
around corresponding AVBPrint functions. They accept user
provided buffers and are supposed to return the required
size of the buffer, which would allow the user to call
it once to get the required buffer size and call it once
more after having allocated the buffer.
If av_bprint_init_for_buffer() treats size == 0 as invalid,
all these users would need to check for this themselves
and basically add the same codeblock that this patch
adds to av_bprint_init_for_buffer().
This change is in line with e.g. snprintf() which also allows
the pointer to be NULL in case size is zero.
This fixes Coverity issues #1503074, #1503076 and #1503082;
all of these issues are about providing NULL to the channel-layout
functions that are wrappers around AVBPrint versions.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The demuxer uses a extradata offset of 26, so we would need
to recreate the missing 26 bytes somehow in the muxer, but
we just don't. Remuxed files (like real/rv30.rm from the FATE-suite)
don't work due to missing extradata.
(The extradata offset also applies to RV40 and the extradata
is indeed lost upon remuxing, yet remuxing real/spygames-2MB.rmvb
works; our RV40 decoder does not use extradata at all.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
RV10 and RV20 are unsupported because creating the correct CodecPrivate
is unsupported (the demuxer uses a codecpriv_offset of 26, so one
would need to recreate the missing 26 bytes); COOK and SIPR are
unsupported, because Matroska uses a packetization mode that is
different from what FFmpeg uses in its packets (see
matroska_parse_rm_audio() in the demuxer).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Provides coverage for the code transforming the ALAC extradata.
Also set creation_time metadata to test this, too.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
bda44f0f39 added code that
potentially added another BlockMore master and BlockAdditional
data as well as BlockAddID number, yet it bumped the number
of EBML elements by four instead of only three.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Matroska supports orthogonal transformations (both pure rotations
as well as reflections) via its 3D-projection elements, namely
ProjectionPoseYaw (for a horizontal reflection) as well as
ProjectionPoseRoll (for rotations). This commit adds support
for this.
Support for this in the demuxer has been added in
937bb6bbc1 and
the sample used in the matroska-dovi-write-config8 FATE-test
includes a displaymatrix indicating a rotation which is now
properly written and read, thereby providing coverage for
the relevant code in the muxer as well as the demuxer.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Note: There is a slight difference in the handling of
the max_file_size option: The earlier code used it to mean
to limit the size of the buffer to allocate; the new code
treats it more literally as maximum size to read from
the input.
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This is a bit cleaner as int need not be the underlying type
of an enum if a smaller type can hold all its values.
Also declare the children_ids array as const as it never changes.
Reviewed-by: Stefano Sabatini <stefasab@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Also rename the contexts and the functions so their names will reflect their
intended size.
With the earlier patch this fixes the audio corruption regression caused by
6ba0aa1770.
Fixes ticket #10029.
Signed-off-by: Marton Balint <cus@passwd.hu>
Improves the audio corruption regression caused by
6ba0aa1770 reported in ticket #10029.
There is still however a noticable audio glitch, so the FFT conversion to AVTX
probably also needs some modifications.
Signed-off-by: Marton Balint <cus@passwd.hu>
This patch changes the return instruction in the tr_32x4 macro from
BR to RET.
Function returns should always use the RET instruction instead of BR,
to avoid interfering with branch prediction.
On devices that support BTI, this is observeable as a landing pad is
required when branching with BR. The change fixes
fate-hevc-hdr-vivid-metadata when on hardware with BTI support.
Signed-off-by: Casey Smalley <casey.smalley@arm.com>
Signed-off-by: Martin Storsjö <martin@martin.st>
