Otherwise the buffer for the hdr10+ blockadditional would
be clobbered if both are present (the buffers can only be
reused after the ebml_writer_write() call).
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
7faa6ee2aa added support
for writing AV_PKT_DATA_DYNAMIC_HDR_SMPTE_2094_APP5,
yet forgot to update the size of the EBML element buffer.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
AlphaMode should indicate whether the BlockAdditional Element with BlockAddID
of "1" contains Alpha data, as defined by to the Codec Mapping for the `CodecID`.
Only VP8 and VP9 Codec Mappings define this, so writing it for all codecs with
a pixel format of YUVA420P, or for codecs other than VP8/VP9 (if the alpha_mode
metadata entry was set) was wrong.
Signed-off-by: Marton Balint <cus@passwd.hu>
This avoids avpriv functions from lavc/opus/parse.c
(which parse way more than we need, necessitating
parsing the extradata).
It furthermore makes the output of the muxer consistent,
i.e. no longer depending upon whether the Opus parser
or decoder are enabled (the avpriv functions would just
return AVERROR(ENOSYS)).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Before this patch, the last packet in the affected fate test would be written
without a BlockDuration element despite the packet's duration being shorter
than the Opus frame size.
Signed-off-by: James Almer <jamrial@gmail.com>
This is required placement by standard [[maybe_unused]] attribute, works
the same for __attribute__((unused)).
Signed-off-by: Kacper Michajłow <kasper93@gmail.com>
In general, a provider code corresponds to a company/organization, and
the name should be that of the company, not of a given feature.
The feature is signalled in the "provider oriented code".
The exception is HDR Vivid, where the code 0x0004 indicates the HDR Vivid
feature itself rather than CUVA (China UHD Video Industry Alliance),
according to the UHD World Associations 'HDR Video Technology Part 2-1
Application Guide to System Integration' document.
ITU_T_T35_PROVIDER_CODE_CUVA -> ITU_T_T35_PROVIDER_CODE_HDR_VIVID
ITU_T_T35_PROVIDER_CODE_LCEVC-> ITU_T_T35_PROVIDER_CODE_VNOVA
ITU_T_T35_PROVIDER_CODE_SMTPE -> ITU_T_T35_PROVIDER_CODE_SAMSUNG
Signed-off-by: Maryla Ustarroz-Calonge <maryla@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Up until now, our muxer wrote FFV1 in video-for-windows
compatibility mode out of concern for old demuxers that
only support that (whereas the demuxer accepts V_FFV1).
This commit switches to using native mode, because
a) V_FFV1 is around long enough so that old demuxers
should not be an issue (support in FFmpeg has been added
in commit 9ae762da7e
in March 2017/FFmpeg 3.3),
b) using native mode uses fewer bytes for the CodecPrivate,
c) the VfW extradata is zero-padded to an even length
if necessary, but our demuxer forgot to undo the padding
until very recently (92e310eb82),
so that there are many versions of our demuxer around that
are buggy wrt VFW, but not V_FFV1.
This affects the FFV1 extradata checksums, specifically
the (experimental) version 4 files with error check version 2*
as created by
ffmpeg -i ../fate-suite/mpeg2/sony-ct3.bs -c:v ffv1 \
-slices 16 -frames 1 -level 4 -strict experimental ffv1.mkv
VFW files like the above created by this muxer before this patch
would not work with an old demuxer.
*: Without error check version 2, the CRC for the whole extradata
is zero, which is not changed by appending a zero byte.
Reviewed-by: compn <ff@hawaiiantel.net>
Reviewed-by: Dave Rice <dave@dericed.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Legal since commit 1cd0a9be4b2d1e7c60184ec68404e00e46e3123e
(Jan 4) in the Cellar Matroska specification git repo.
We still hold out on muxing it due to compatibility with
old demuxers.
Reviewed-by: compn <ff@hawaiiantel.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Use the already available AVCodecParameters pointer instead.
Shortens lines.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The check "left >= INT_MAX - right" is supposed to check for
whether left + right does not overflow/wraparound, but given that
left and top are uint32_t INT_MAX - right can already wraparound
for big values of right (and ordinary 32-bit ints):
If right == UINT32_MAX, INT_MAX - right is INT_MAX + 1;
for left in 0..par->width both checks will be passed.
Fix this and simplify the check by using 64-bit types,
where the addition is guaranteed not to overflow.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
There are lots of files that don't need it: The number of object
files that actually need it went down from 2011 to 884 here.
Keep it for external users in order to not cause breakages.
Also improve the other headers a bit while just at it.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Makes it robust against adding fields before it, which will be useful in
following commits.
Majority of the patch generated by the following Coccinelle script:
@@
typedef AVOption;
identifier arr_name;
initializer list il;
initializer list[8] il1;
expression tail;
@@
AVOption arr_name[] = { il, { il1,
- tail
+ .unit = tail
}, ... };
with some manual changes, as the script:
* has trouble with options defined inside macros
* sometimes does not handle options under an #else branch
* sometimes swallows whitespace
Unnecessary since acf63d5350adeae551d412db699f8ca03f7e76b9;
also avoids relocations.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Deprecate AVStream.side_data and its helpers in favor of the AVStream's
codecpar.coded_side_data.
This will considerably simplify the propagation of global side data to decoders
and from encoders. Instead of having to do it inside packets, it will be
available during init().
Global and frame specific side data will therefore be distinct.
Signed-off-by: James Almer <jamrial@gmail.com>
It is of no value to the user, because every muxer can always
be flushed with a NULL packet. As its documentation shows
("If not set, the muxer will not receive a NULL packet in
the write_packet function") it is actually an internal flag
that has been publically exposed because there was no internal
flags field for output formats for a long time. But now there is
and so use it by replacing the public flag with a private one.
Reviewed-by: James Almer <jamrial@gmail.com>
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Reviewed-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
We have to write an explicit BlockDuration element (and use
a BlockGroup instead of a SimpleBlock) in case the Track
has a DefaultDuration that is inconsistent with the duration
of the packet.
The matroska-h264-remux test uses a file with coded fields
where the duration of a Block is the duration of a field,
not of a frame, therefore this patch writes said BlockDuration
elements.
(When using a BlockGroup, one has to add ReferenceBlock elements
to distinguish keyframes from non-keyframes. Unfortunately,
the AV1 codec mapping [1] requires us to reference all references
and to really use the real references, which requires a lot of
effort for basically no gain. When BlockGroups are used with AV1,
the created files are most likely invalid, both before and after
this patch, but this patch makes this more likely to happen.)
[1]: https://github.com/ietf-wg-cellar/matroska-specification/blob/master/codec/av1.md
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
These defines are also used in other contexts than just AVCodecContext
ones, e.g. in libavformat. Furthermore, given that these defines are
public, the AV-prefix is the right one, so deprecate (and not just move)
the FF-macros.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.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>
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 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>
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>
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>
