For fate-h264_mp4toannexb_ticket5927 and
fate-h264_mp4toannexb_ticket5927_2, they work by accident
previously. The sample file has two 'avc1' entries, and video
samples use the second one. It means packets should be decoded with
new extradata in side data. Before this patch, only extradata was
kept in the output, new extradata has been dropped. The output can
be decoded because the two extradata are almost the same, except
level indication. This patch fixed the issue, and add another
fate test.
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
Current code tracks min/max pts for each stream separately; then when
the file ends it combines them with last frame's duration to compute the
total duration of each stream; finally it selects the longest of those
durations as the file duration.
This is incorrect - the total file duration is the largest timestamp
difference between any frames, regardless of the stream.
Also change the way the last frame information is reported from decoders
to the muxer - previously it would be just the last frame's duration,
now the end timestamp is sent, which is simpler.
Changes the result of the fate-ffmpeg-streamloop-transcode-av test,
where the timestamps are shifted slightly forward. Note that the
matroska demuxer does not return the first audio packet after seeking
(due to buggy interaction betwen the generic code and the demuxer), so
there is a gap in audio.
These are not supported by the drawing functions at all, and were
incorrectly advertised as supported in the past.
Note: This check is added only to separate the logic change from the API
change in the following commit, and will be removed again after it
becomes redundant.
Mapping to ITU-R BS.2051-3 "Sound System J" and ITU-R BS.1196-8 "Channel
Configuration 19".
Signed-off-by: Will Wolcott <wwolcott@netflix.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This layout maps to ITU-R BS.2051-3 "Sound System C" and ITU-R BS.1196-8 "Channel
Configuration 14", and it being the first layout with top layer channels, it's
best to use a different scheme to properly convey the presence and amount of said
channels.
The new name will also be a better fit for the additions in the following commits.
Signed-off-by: James Almer <jamrial@gmail.com>
Fix rendering of int values within a side data element, which was
broken since commit d2d3a83ad9, where the side data element was
correctly marked as a variable fields element. Logic to render a
string variable was implemented already, but it was not implemented
for the int fields path, which was enabled by that commit.
Also, code and schema is changed in order to account for multiple
variable-fields elements - such as side data, contained within the
same parent. Previously it was assumed that a single variable-fields
element was contained within the parent, which was the case for tags,
but is not the case for side-data.
Previously data was rendered as:
<side_data_list>
<side_data side_data_type="CPB properties" max_bitrate="0" min_bitrate="0" avg_bitrate="0" buffer_size="327680" vbv_delay="-1"/>
</side_data_list>
Now as:
<side_data_list>
<side_data type="CPB properties">
<side_datum key="side_data_type" value="CPB properties"/>
<side_datum key="max_bitrate" value="0"/>
<side_datum key="min_bitrate" value="0"/>
<side_datum key="avg_bitrate" value="0"/>
<side_datum key="buffer_size" value="49152"/>
<side_datum key="vbv_delay" value="-1"/>
</side_data>
</side_data_list>
Variable-fields elements are rendered as a containing element wrapping
generic key/values elements, enabling use of strict XML schema.
Fix trac issue:
https://trac.ffmpeg.org/ticket/10613
Always use the functionality of the latter, which makes more sense as it
avoids losing keyframes due to vsync code dropping frames.
Deprecate the 'source_no_drop' value, as it is now redundant.
This is no longer needed as the side data is available for decoders in the
AVCodecContext.
The tests affected reflect the removal of useless CPB and Stereo 3D side
data in packets.
Signed-off-by: James Almer <jamrial@gmail.com>
The changed references for fate-hevc-dv-rpu fate-mov-zombie happen because,
unlike ffmpeg and ffplay, ffprobe never injected packet side data, so the
display matrix side data at the container level is now present in the output
frames.
Signed-off-by: James Almer <jamrial@gmail.com>
Also, avoid spurious end-of-line after side data entries, and improve
rendering of compact output, by adding an indication of the side data
type for each entry.
Also fixes issue:
http://trac.ffmpeg.org/ticket/9266
In this case any timestamps are guessed by compute_pkt_fields() in
libavformat. Since we are decoding the stream, we have more accurate
information from the decoder and do not need any guesses.
Eliminates spurious PTS gaps in a number of FATE tests.
Also avoids dropping the majority of frames in fate-dirac*
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>
And remove the AVOID_PROBING flag, given it's the last av1 decoder to be tested
either way.
This fixes a regression introduced in 1652f2492f,
where even if forcing the native av1 decoder, if another decoder was present,
like libdav1d or libaom-av1, they'd be used for probing and some fate tests
would have different results.
Signed-off-by: James Almer <jamrial@gmail.com>
Makes the output of the native decoder consistent with external decoders like
libdav1d with fate-enhanced-flv-av1.
Reviewed-by: Zhao Zhili <quinkblack@foxmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Adds a fate test for the jpegxl_anim demuxer, that should allow testing
for true positives and false positives for animated jpegxl files. Note
that two of the test cases are not animated, in order to help sort out
false positives.
Signed-off-by: Leo Izen <leo.izen@gmail.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>
When no output video framerate is specified by the user with -r or can
be inferred from the filtergraph, encoder setup will arbitrarily decide
that the framerate is 25fps. However, making up any framerate value for
VFR encoding is at best unnecessary.
Changes the results of the sub2video tests, where the input timebase is
now used instead of 1/25.
The fate-run.sh shell script exports LC_ALL=C before invoking the
test executables; this is probably done for consistency.
When executing Windows binaries with Wine, it normally handles
UTF-8 command line parameters just fine - but with LC_ALL set to
C, it treats them as plain ASCII.
As the unicode command line parameters wasn't the main thing
being tested here, just convert them to plain ASCII, for
portability. This fixes the test for all test configurations that
use Wine.
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>
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>
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>
