More exactly, factor codec-specific video parsing out of
matroska_parse_tracks(). This is intended to improve readability.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
If the size of the data of an EbmlBin is > 0, its data is always
present, as ebml_read_binary() always leaves the buffer
in a consistent state (even on error).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
More exactly, factor codec-specific audio parsing out of
matroska_parse_tracks(). This is intended to improve readability.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Up until now, matroska_parse_tracks() has two main ways
to set AVCodecParameters.extradata: A generic way via CodecPrivate
(possibly with an offset) and by allocating a buffer manually;
the pointer to this buffer is stored in a stack pointer.
In particular, the latter method is problematic, as the buffer
needs to be freed manually in case of error (currently there
are no error conditions between the place where it is set
to AVCodecParameters.extradata).
Most of these buffers are very small (<= 22B), so replace
the pointer to an allocated buffer with a stack buffer
and set the extradata directly for the one place where
the buffer may not be small.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
add option named rtmp_enhanced_codec,
it would support hvc1,av01,vp09 now,
the fourcc is using Array of strings.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
In order to send VP9 tracks with FLV or RTMP, the enhanced RTMP
specification tells that VPCodecConfigurationRecord, a.k.a. vpcC
ISO-BMFF box, must be inserted into a metadata message. However, the
function responsible for generating vpcCs currently returns invalid
boxes, that are lacking the Version and Flag fields, inherited from
FullBox. For some reason, both flags were being added manually in
movenc. This patch fixes the issue.
Signed-off-by: Alessandro Ros <aler9.dev@gmail.com>
Reviewed-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
winbase.h defines IGNORE and is included via bzlib.h when compiling
for Windows. So rename this macro to NOTHING.
Also rename the muxer macro for consistency.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It includes various Windows-specific headers when compiling
for Windows and these sometimes cause issues: E.g. winbase.h
defines IGNORE, which clashes with a macro used in the Matroska
muxer (since 884653ee5b) and demuxer.
This header provides fallback defines for various stuff that is
mostly not used directly by (de)muxers at all:
mkdir, rename, rmdir, unlink, access, poll, pollfd, nfds_t,
closesocket, socklen_t, fstat, stat, lseek, SHUT_(RD|WR|RDWR)
and various POLL* constants.
Ergo fix this issue by not auto-including this header in lots
of places via an inclusion in internal.h and instead include
it everywhere where the above stuff is used (most of these
translation units already included os_support.h).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This simplification reduces codesize.
(It even reduces the size of .rodata here, because
the jump table used by the compiler is bigger than
the actual array.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When muxing, the AVStreams' side-data is typically set
by the caller before avformat_write_header();
it is not documented to be else. Yet the Matroska muxer
added an AVStereo3D side data if certain metadata
was present:
Since commit 4d686fb721
(adding support for AVStereo3D stream side-data),
the Matroska muxer checked certain stream tags that
contain Matroska's StereoMode and (if they are present)
converted this value into an AVStereo3D struct that
gets attached to the AVStream (reusing a function from
the demuxer). Afterwards the AVStereo3D side data struct
(whether it has just been added by the muxer or not) gets
parsed and converted back into a Matroska StereoMode.
Besides being an API violation this change broke
StereoMode values without a corresponding AVStereo3D
(namely the anaglyph ones).
This commit fixes this: A StereoMode given via tags
is now used-as-is; if no such tag exists and an AVStereo3D
side data exists, it is converted into the corresponding
StereoMode (if possible). This approach also fixes
handling of the anaglyph ones; the changes to the
matroska-stereo_mode are due to this.
The new STEREOMODE_STEREO3D_MAPPING has been put to
good use for this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It will allow to create tables for easy conversion from AVStereo3D
to stereomode and back again as well as derive the properties
of a given stereomode.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
It has undefined behaviour in case the value does not fit into an int.
Also stop allowing to override a stream level "alpha_mode" tag
by an AVFormatContext one and properly check that the stereo_mode
number given via a tag is actually in the range 0..14: Negative
values would have been treated as zero before this patch.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
When the marker writing code was merged from libav to FFmpeg
in dc62016c, it failed to take into account that the meaning of
cluster_pos had changed in bda5b662; in particular, the special
value for “I'm not currently working on a cluster” had changed
from 0 to -1. This makes the avio_write_marker() call never
be called. Update the if statement to fix it.
Fixes: Ticket9843
Signed-off-by: Steinar H. Gunderson <steinar+ffmpeg@gunderson.no>
Signed-off-by: Martin Storsjö <martin@martin.st>
This prevents code duplication in the source form by calling the parse
code that was moved to avcodec last commit. The code will be duplicated
in binary form for shared builds (it's not that large), but for source
code it will only exist in one location now.
Signed-off-by: Leo Izen <leo.izen@gmail.com>
Including winsock2.h or windows.h without WIN32_LEAN_AND_MEAN cause
bzlib.h to parse as nonsense, due to an instance of #define char small
in rpcndr.h.
See:
https://stackoverflow.com/a/27794577
Signed-off-by: L. E. Segovia <amy@amyspark.me>
Signed-off-by: Martin Storsjö <martin@martin.st>
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>
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>
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>
