Fixes a decoding regression introduced by e9a2a87773, and as a side effect also
fixes bogus values set to certain audio frames that had some samples discarded,
where the offsets added to pts, pkt_dts and pkt_duration were not reflected in
best_effort_timestamp.
Signed-off-by: James Almer <jamrial@gmail.com>
SMVJPEG stores frames as slices of a big JPEG image. The decoder is
implemented as a wrapper that instantiates a full internal MJPEG
decoder, then forwards the decoded frames with offset data pointers.
This is unnecessarily complex and fragile, not supporting useful decoder
capabilities like direct rendering.
Re-implement the decoder inside the MJPEG decoder, which is accomplished
by returning each decoded frame multiple times, setting cropping
information appropriately on each instance.
One peculiar aspect of the previous design is that since
- the smvjpeg decoder returns one frame per input packet
- there are multiple frames in each packets (the aformentioned slices)
the demuxer needs to return each packet multiple times.
This is now also eliminated - the demuxer now returns each packet
exactly once, with the duration set to the number of frames it decodes
to.
This also removes one of the last remaining internal uses of the old
video decoding API.
It depends on the muxer generating the timestamps, which is deprecated
and scheduled for removal on next bump.
A bunch of tests change timestamps, because of ffmpeg.c is not
generating them correctly. This should be fixed later.
Factor out the code into a separate muxing-specific function.
Stop accessing the deprecated AVStream-embedded codec context, use the
average framerate (if specified) instead.
By using the frame counter (and the video time base) for audio pts we lose some
timestamp precision but we ensure that video and audio coming from the same DV
frame are always in sync.
This patch also makes timestamps after seek consistent and it should also fix
the timestamps when the audio clock is unlocked and have a completely
indpendent clock source. (E.g. runs on fixed 48009 Hz which should have been
exact 48000 Hz)
Fixes out of sync timestamps in ticket #8762.
Signed-off-by: Marton Balint <cus@passwd.hu>
The previous threshold, 4 KB, maybe was reasonable when it was set
(in 2010), but in today's settings and with typical network speeds
and data sizes, it's pretty small. 32 KB probably is a more reasonable
default now, regardless of input.
This changes the test references for two seek tests.
When using the normal seek function, which boils down to the lseek(2)
function, a seek to an out of bounds position doesn't return an error,
but that condition is only reported when doing the subsequent read
(which returns EOF). When doing more seeks by fast forwarding, the
fact that the seeked to destination is out of bounds is noticed and
reported sooner in these cases.
Signed-off-by: Martin Storsjö <martin@martin.st>
While the FATE suite contains a sample file for Musepack 8, it did not
use it to test the decoder; it is only used in the mpc8-demux test that
tests the demuxer via streamcopy. Therefore this commit adds an actual
encoder test.
The test uses the framecrc output, because Musepack SV8 is an encoder
that returns multiple frames for a single packet, so that timing
information in the test output is valueable. Output seeking has been
used in order to limit the size of the ref file as well as to test this
codepath for the first time.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
We now have the possibility of getting AVFrames here, and we should
not touch the muxer's codecpar after writing the header.
Results of FATE tests change as the MXF and Matroska muxers actually
write down the field/frame coding type of a stream in their
respective headers. Before this change, these values in codecpar
would only be set after the muxer was initialized. Now, the
information is also available for encoder and muxer initialization.
Additionally, reap the first rewards by being able to set the
color related encoding values based on the passed AVFrame.
The only tests that seem to have changed their results with this
change seem to be the MXF tests. There, the muxer writes the
limited/full range flag to the output container if the encoder
is not set to "unspecified".
This disallows the usage of ? and # in libavformat specific scheme options
(e.g. subfile,,start,32815239,end,0,,:video.ts) but this change was considered
acceptable.
Signed-off-by: ruiquan.crq <caihaoning83@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
These conversion appears to be exhibiting the same rounding error as the rgbf32 formats where.
I seperated the rounding value from the 16 and 128 offsets, I think it makes it a little more clear.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
changes since v1:
- made into fate test
- fixed c90 warnings
- tests more intermediate formats
- tested on BE mips too
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If the average bit rate cannot be calculated, such as in the case
of streamed fragmented mp4, utilize various available parameters
in priority order.
Tests are updated where the esds or btrt or ISML manifest boxes'
output changes.
This is utilized by various media ingests to figure out the bit
rate of the content you are pushing towards it, so write it for
video, audio and subtitle tracks in case at least one nonzero value
is available. It is only mentioned for timed metadata sample
descriptions in QTFF, so limit it only to ISOBMFF (MODE_MP4) mode.
Updates the FATE tests which have their results changed due to the
20 extra bytes being written per track.
SMPTE 12M timecode can only count frames up to 39, because the tens-of-frames
value is stored in 2 bit. In order to resolve this 50/60 fps SMPTE timecode is
using the field bit (which is the same bit as the phase correction bit) to
signal the least significant bit of a 50/60 fps timecode. See SMPTE ST
12-1:2014 section 12.1.
Therefore we slightly change the format of the return value of
av_timecode_get_smpte_from_framenum and AV_FRAME_DATA_S12M_TIMECODE and start
using the previously unused Phase Correction bit as Field bit. (As the SMPTE
standard suggests)
We add 50/60 fps support to av_timecode_get_smpte_from_framenum by calling the
recently added av_timecode_get_smpte function in it which already handles this
properly.
This change affects the decklink indev and the DV and MXF muxers. MXF has no
fate test for 50/60fps content, DV does, therefore the changes.
MediaInfo (a recent version) confirms that half-frame timecode must be inserted
to DV. MXFInspect confirms valid timecode insertion to the System Item of MXF
files. For MXF, also see EBU R122.
Note that for DV the field flag is not used because in the HDV specs (SMPTE
370M) it is still defined as biphase mark polarity correction flag. So it
should not matter that the DV muxer overrides the field bit.
Signed-off-by: Marton Balint <cus@passwd.hu>
This AV1 decoder is currently only used for hardware accelerated decoding.
It can be extended into a native decoder in the future, so set its name to
"av1" and temporarily give it the lowest priority in the codec list.
Signed-off-by: Fei Wang <fei.w.wang@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Allow to set the EOF timestamp.
Also: doc/filters/testsrc*: specify the rounding of the duration option.
The changes in the ref files are right.
For filter-fps-down, the graph is testsrc2=r=7:d=3.5,fps=3.
3.5=24.5/7, so the EOF of testsrc2 will have PTS 25/7.
25/7=(10+5/7)/3, so the EOF PTS for fps should be 11/7,
and the output should contain a frame at PTS 10.
For filter-fps-up, the graph is testsrc2=r=3:d=2,fps=7,
for filter-fps-up-round-down and filter-fps-up-round-up
it is the same with explicit rounding options.
But there is no rounding: testsrc2 produces exactly 6 frames
and 2 seconds, fps converts it into exactly 14 frames.
The tests should probably be adjusted to restore them to
a useful coverage.
The implementation of the tag tree did not
set the correct reset value for the encoder.
This lead to inefficent tag tree being encoded.
This patch fixes the implementation of the
ff_tag_tree_zero() function.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This patch allows setting a compression ratio and to
set multiple layers. The user has to input a compression
ratio for each layer.
The per layer compression ration can be set as follows:
-layer_rates "r1,r2,...rn"
for to create 'n' layers.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The dvbsubtest_filter.ts sample is a filtered version of the Videolan
sample database (samples/sub/dvbsub/dvbsubtest.ts) using Project X. It
originates from ticket #8844.
The write_colr flag has been marked as experimental for over 5 years.
It should be safe to enable its behavior by default as follows:
- Write the colr atom by default for mp4/mov if any of the following:
- The primaries/trc/matrix are all specified, OR
- There is an ICC profile, OR
- The user specified +write_colr
- Keep the write_colr flag for situations where the user wants to
write the colr atom even if the color info is unspecified (e.g.,
http://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/259334.html)
This fixes https://trac.ffmpeg.org/ticket/7961
Signed-off-by: Michael Bradshaw <mjbshaw@google.com>
The new code is analog to how it's done in our mpegaudio parser.
Acked-by: Jun Zhao <barryjzhao@tencent.com>
Signed-off-by: Alexander Strasser <eclipse7@gmx.net>
Also add and update some tests.
Change the semantic a little, because for filesytem paths
symlinks complicate things.
See the comments in the code for detail.
Fix trac tickets #8813 and 8814.
Reads color_primaries, color_trc and color_space from mxf
headers. ULs are from https://registry.smpte-ra.org/ site.
Signed-off-by: Harry Mallon <harry.mallon@codex.online>
add probeaudiostream for get audio stream's codec_name,codec_time_base,
sample_fmt,channels and channel_layout.
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Important part of this algorithm is the double threshold step: pixels
above "high" threshold being kept, pixels below "low" threshold dropped,
pixels in between (weak edges) are kept if they are neighboring "high"
pixels.
The weak edge check uses a neighboring context and should not be applied
on the plane's border. The condition was incorrect and has been fixed in
the commit.
Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com>
Reviewed-by: Andriy Gelman <andriy.gelman@gmail.com>
floating point precision will cause rgb*max generate different value on
x86_32 and x86_64. have pass fate test on x86_32 and x86_64 by using
lrintf to get the nearest integral value for rgb * max before av_clip.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Now we just use one ADTS raw frame to calculate the bit rate, it's
lead to a larger error when get the duration from bit rate, the
improvement cumulate Nth ADTS frames to get the average bit rate.
e,g used the command get the duration like:
ffprobe -show_entries format=duration -i fate-suite/aac/foo.aac
before this improvement dump the duration=2.173935
after this improvement dump the duration=1.979267
in fact, the real duration can be get by command like:
ffmpeg -i fate-suite/aac/foo.aac -f null /dev/null with time=00:00:01.97
Also update the fate-adtstoasc_ticket3715.
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
This is a requirement of the AV1-ISOBMFF spec. Section 2.1.
General Requirements & Brands states:
* It SHALL have the av01 brand among the compatible brands array of the FileTypeBox
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
This causes regressions in end to end timestamps with mp3s and ffmpeg.
The revert is to avoid this regression in the 4.3 release
See: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.
This reverts commit 460132c998.
7546ac2fee made it so that the start_time for mp3 files is
adjusted for skip_samples. However, this appears incorrect because
subsequent packet timestamps are not adjusted and skip_samples are
applied by deleting data from a packet without changing the timestamp.
E.g., we are told the start_time is ~25ms and we get a packet with a
timestamp of 0 that has had the skip_samples discarded from it. As such
rendering engines may incorrectly discard everything prior to the
25ms thinking that is where playback should officially start. Since the
samples were deleted without adjusting timestamps though, the true
start_time is still 0.
Other formats like MP4 with edit lists will adjust both the start
time and the timestamps of subsequent packets to avoid this issue.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>
changes since v1
- default behavior, no longer hidden behind decoder parameter
- updated tests to reflect change
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The Matroska muxer writes the Chapters early when chapters were already
available when writing the header; in this case any tags pertaining to
these chapters get written, too.
Yet if no chapters had been supplied before writing the header, Chapters
can also be written when writing the trailer if any are supplied. Tags
belonging to these chapters were up until now completely ignored.
This commit changes this: Writing the tags belonging to chapters has
been moved to mkv_write_chapters(). If mkv_write_tags() has not been
called yet (i.e. when chapters are written when writing the header),
the AVIOContext for writing the ordinary Tags element is used, but not
output, as this is left to mkv_write_tags() in order to only write one
Tags element. Yet if mkv_write_tags() has already been called,
mkv_write_chapters() will output a Tags element of its own which only
contains the tags for chapters.
When chapters are available initially, the corresponding tags will now
be the first tags in the Tags element; but the ordering of tags in Tags
is irrelevant anyway.
This commit also makes chapter_id_offset local to mkv_write_chapters()
as it is used only there and not reused at all.
Potentially writing a second Tags element means that the maximum number
of SeekHead entries had to be incremented. All the changes to FATE
result from the ensuing increase in the amount of space reserved for the
SeekHead (21 bytes more).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
We won't be able to seek back to write the actual duration anyway.
FATE-tests using the md5pipe command had to be updated due to this change.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
have tested on linux x86_32/64, mingw32/64 arm & mips qemu
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Tested on x86-32/64, mingw32/64, arm & mips qemu
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Up until now, the Matroska muxer would mark a track as default if it had
the disposition AV_DISPOSITION_DEFAULT or if there was no track with
AV_DISPOSITION_DEFAULT set; in the latter case even more than one track
of a kind (audio, video, subtitles) was marked as default which is not
sensible.
This commit changes the logic used to mark tracks as default. There are
now three modes for this:
a) In the "infer" mode the first track of every type (audio, video,
subtitles) with default disposition set will be marked as default; if
there is no such track (for a given type), then the first track of this
type (if existing) will be marked as default. This behaviour is inspired
by mkvmerge. It ensures that the default flags will be set in a sensible
way even if the input comes from containers that lack the concept of
default flags. This mode is the default mode.
b) The "infer_no_subs" mode is similar to the "infer" mode; the
difference is that if no subtitle track with default disposition exists,
no subtitle track will be marked as default at all.
c) The "passthrough" mode: Here the track will be marked as default if
and only the corresponding input stream had disposition default.
This fixes ticket #8173 (the passthrough mode is ideal for this) as
well as ticket #8416 (the "infer_no_subs" mode leads to the desired
output).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Several EBML Master elements for which a good upper bound of the final
length was available were nevertheless written without giving an
upper bound of the final length to start_ebml_master(), so that their
length fields were eight bytes long. This has been changed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The Matroska muxer currently only adds CuePoints in three cases:
a) For video keyframes. b) For the first audio frame in a new Cluster if
in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
files won't have any Cues which impedes seeking.
This commit changes this. For every track in a file without video track
it is checked and tracked whether a Cue entry has already been added
for said track for the current Cluster. This is used to add a Cue entry
for each first packet of each track in each Cluster.
Implements #3149.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Moreover, putting the Cues in front of the Clusters by reserving space
in advance is also tested.
The new capability of using ffprobe during a remux/transcode test are
used here for information about the chapters.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Using random values for TrackUID and FileUID (as happens when the
AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making
the output indeterministic. This commit mitigates this by writing the
potentially random values with a fixed size of eight byte, even if their
actual values would fit into less than eight bytes. This ensures that
even in non-bitexact mode, the differences between two files generated
with the same settings are restricted to a few bytes in the header.
(Namely the SegmentUID, the TrackUIDs (in Tracks as well as when
referencing them via TagTrackUID), the FileUIDs (in Attachments as
well as in TagAttachmentUID) as well as the CRC-32 checksums of the
Info, Tracks, Attachments and Tags level-1-elements.) Without this
patch, there might be an offset/a size difference between two such
files.
The FATE-tests had to be updated because the fixed-sized UIDs are also
used in bitexact mode.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
If there are Attachments to write, the Matroska muxer currently
allocates two objects: An array that contains an entry for each
AttachedFile containing just the stream index of the corresponding
stream and the FileUID used for this AttachedFile; and a structure with
a pointer to said array and a counter for said array. These uids are
generated via code special to Attachments: It uses an AVLFG in the
normal and a sha of the attachment data in the bitexact case. (Said sha
requires an allocation, too.)
But now that an uid is generated for each stream in mkv_init(), there is
no need any more to use special code for generating the FileUIDs of
AttachedFiles: One can simply use the uid already generated for the
corresponding stream. And this makes the whole allocations of the
structures for AttachedFiles as well as the structures itself superfluous.
They have been removed.
In case AVFMT_FLAG_BITEXACT is set, the uids will be different from the
old ones which is the reason why the FATE-test lavf-mkv_attachment
needed to be updated. The old method had the drawback that two
AttachedFiles with the same data would have the same FileUID.
The new one doesn't.
Also notice that the dynamic buffer used to write the Attachments leaks
if an error happens when writing the buffer. By removing the
allocations potential sources of errors have been removed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Tags in the Matroska file format can be summarized as follows: There is
a level 1-element called Tags containing one or many Tag elements each
of which in turn contain a Targets element and one or many SimpleTags.
Each SimpleTag roughly corresponds to a single key-value pair similar to
an AVDictionaryEntry. The Targets meanwhile contains information to what
the metadata contained in the SimpleTags contained in the containing Tag
applies (i.e. to the file as a whole or to an individual track).
The Matroska muxer writes such metadata. It puts the metadata of every
stream into a Tag whose Targets makes it point to the corresponding
track. And if the output is seekable, then it also adds another Tag for
each track whose Targets corresponds to the track and where it reserves
space in a SimpleTag to write the duration at the end of the muxing
process into.
Yet there is no reason to write two Tag elements for a track and a few
bytes (typically 24 bytes per track) can be saved by adding the duration
SimpleTag to the other Tag of the same track (if it exists).
FATE has been updated because the output files changed. (Tests that
write to unseekable output (pipes) needn't be updated (no duration tag
has ever been written for them) and the same applies to tests without
further metadata.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It represents the relationship between them more naturally and will be
useful in the following commits.
Allows significantly more frames in fate-h264-attachment-631 to be
decoded.
containing updated extradata, in this case a new FLAC streaminfo.
Furthermore, it also tests that the Matroska muxer is able to preserve
uncommon channel layouts by adding Vorbis comments to the CodecPrivate.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
mkvmerge versions 6.2 to 40.0 had a bug that made it not propagate the
WavPack extradata (containing the WavPack version) during remuxing from
a Matroska file; currently our demuxer would treat every WavPack block
encountered as invalid data (unless the WavPack stream is to be
discarded (i.e. the streams discard is >= AVDISCARD_ALL)) and try to
resync to the next level 1 element.
Luckily, the WavPack version is currently not really important; so we
fix this problem by assuming a version. David Bryant, the creator of
WavPack, recommended using version 0x410 (the most recent version) for
this. And this is what this commit does.
A FATE-test for this has been added.
Reviewed-by: David Bryant <david@wavpack.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Up until e7ddafd5, the Matroska muxer wrote two SeekHeads: One at the
beginning referencing the main level 1 elements (i.e. not the Clusters)
and one at the end, referencing the Clusters. This second SeekHead was
useless and has therefore been removed. Yet the SeekHead-related
functions and structures are still geared towards this usecase: They
are built around an allocated array of variable size that gets
reallocated every time an element is added to it although the maximum
number of Seek entries is a small compile-time constant, so that one should
rather include the array in the SeekHead structure itself; and said
structure should be contained in the MatroskaMuxContext instead of being
allocated separately.
The earlier code reserved space for a SeekHead with 10 entries, although
we currently write at most 6. Reducing said number implied that every
Matroska/Webm file will be 84 bytes smaller and required to adapt
several FATE tests; furthermore, the reserved amount overestimated the
amount needed for for the SeekHead's length field and how many bytes
need to be reserved to write a EBML Void element, bringing the total
reduction to 89 bytes.
This also fixes a potential segfault: If !mkv->is_live and if the
AVIOContext is initially unseekable when writing the header, the
SeekHead is already written when writing the header and this used to
free the SeekHead-related structures that have been allocated. But if
the AVIOContext happens to be seekable when writing the trailer, it will
be attempted to write the SeekHead again which will lead to segfaults
because the corresponding structures have already been freed.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
This fixes mpeg2video stream copies to mpeg muxer like this:
ffmpeg -i xdcamhd.mxf -c:v copy output.mpg
Signed-off-by: Anton Khirnov <anton@khirnov.net>
Utilizes a subpicture sample with one decodable subpicture for the
test.
Based on a failing test case in reported by Michael in
https://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240398.html
which at the time had no test case for it.
Additionally, this is the first test case for the presentation
graphics format.
According to the H.264 specifications, the only NAL units that need to
have four byte startcodes in H.264 Annex B format are SPS/PPS units and
units that start a new access unit. Before af7e953a, the first of these
conditions wasn't upheld as already existing in-band parameter sets
would not automatically be written with a four byte startcode, but only
when they already were at the beginning of their input packets. But it
made four byte startcodes be used too often as every unit that is written
together with a parameter set that is inserted from extradata received a
four byte startcode although a three byte start code would suffice
unless the unit itself were a parameter set.
FATE has been updated to reflect the changes. Although the patch leaves
the extradata unchanged, the size of the extradata according to the FATE
reports changes. This is due to a quirk in ff_h2645_packet_split which
is used by extract_extradata: If the input is Annex B, the first zero of
a four byte startcode is considered a part of the last unit (if any).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The standard does not seem to require the counter to be zero based, but some
checker tools (MyriadBits MXFInspect, Interra Baton) have validations against 0
start...
Fixes ticket #6781.
Signed-off-by: Marton Balint <cus@passwd.hu>
RFC 3986 states that the generic syntax uses the slash ("/"), question mark
("?"), and number sign ("#") characters to delimit components that are
significant to the generic parser's hierarchical interpretation of an
identifier.
Signed-off-by: Marton Balint <cus@passwd.hu>
When a Matroska Block is only stored in compressed form, the size of
the uncompressed block is not explicitly coded and therefore not known
before decompressing it. Therefore the demuxer uses a guess for the
uncompressed size: The first guess is three times the compressed size
and if this is not enough, it is repeatedly incremented by a factor of
three. But when this happens with lzo, the decompression is neither
resumed nor started again. Instead when av_lzo1x_decode indicates that x
bytes of input data could not be decoded, because the output buffer is
already full, the first (not the last) x bytes of the input buffer are
resent for decoding in the next try; they overwrite already decoded
data.
This commit fixes this by instead restarting the decompression anew,
just with a bigger buffer.
This seems to be a regression since 935ec5a1.
A FATE-test for this has been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This test tests that demuxing ProRes that is muxed like it should be in
Matroska (i.e. with the first header ("icpf") atom stripped away) works;
it also tests bz2 decompression as well as the handling of
unknown-length clusters.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now, the microdvd demuxer uses av_strdup() to allocate the
extradata from a string; its length is set to strlen() + 1, i.e.
including the \0 at the end. Upon remuxing, the muxer would simply copy
the extradata at the beginning, including the \0.
This commit changes this by not adding the \0 to the size of the
extradata; the muxer now delimits extradata by inserting a \n. This
required to change the subtitles-microdvd-remux FATE-test.
Furthermore, the extradata is now allocated with zeroed padding.
The microdvd decoder is not affected by this, as it didn't use the size
of the extradata at all, but treated it as a C-string.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
5 cabac states for cbf_cb and cbf_cr are supported according to
Table 9-4.
Add a test for 64x64 4:4:4 8bit HEVC clips with TUDepth = 4, cbf_cr > 0.
Signed-off-by: Xu Guangxin <guangxin.xu@intel.com>
Signed-off-by: Linjie Fu <linjie.fu@intel.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The IVF muxer autoinserts the av1_metadata filter unconditionally, which is
not desirable for these tests.
Signed-off-by: James Almer <jamrial@gmail.com>
The tremolo filter uses floating point internally, and uses
multiplication factors derived from sin(fmod()), neither of
which is bitexact for use with framecrc.
This fixes running this test when built with for mingw/x86_32
with clang.
In this case, a 1 ulp difference in the output from fmod() would
end up in an output from the filter that differs by 1 ulp, but
which makes the lrint() in swresample/audioconvert.c round in a
different direction.
Signed-off-by: Martin Storsjö <martin@martin.st>
contained in Vorbis comments in the CodecPrivate of flac tracks.
Moreover, it also tests header removal compression.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
This test contains a track with zlib compressed CodecPrivate in addition
to compressed frames; the former was unchecked before.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Fixes: fate-fitsdec-bitpix-64
Possibly Fixes: -nan is outside the range of representable values of type 'unsigned short'
Possibly Fixes: 17769/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5678314672357376
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Allows the creation of the sdtp atom while remuxing MP4 to MP4. This
atom is required by Apple devices (iPhone, Apple TV) in order to accept
2160p medias.
A threshold of 1 is sufficient for simple_dump_cut.webm, 10 is used
just to be sure the next truncated file doesnt cause the same issue
Obvious alternative fixes are to simply accept that the file is broken or to
write some advanced error concealment or to
simply accept that the decoder wont stop at the end of input.
Fixes: Ticket 8069 (artifacts not the differing md5 which was there before 1afd246960)
Fixes: simple_dump_cut.webm
Fixes: regression of 1afd246960
fate-vp5 changes because the last frame is truncated and now handled
differently.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Right now, the concat filter does not set the frame_rate value on any of
the out links. As a result, the default ffmpeg behaviour kicks in - to
copy the framerate from the first input to the outputs.
If a later input is higher framerate, this results in dropped frames; if
a later input is lower framerate it might cause judder.
This patch checks if all of the video inputs have the same framerate, and
if not it sets the out link to use '1/0' as the frame rate, the value
meaning "unknown/vfr".
A test is added to verify the VFR behaviour. The existing test for CFR
behaviour passes unchanged.
This makes the code bitexact between platforms.
Intermediate timestamps between frames are preserved.
The timebase is simplified.
Rounding differs from doubles in cases where timestamps/durations
are "funny"
Suggested-by: jb
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit a9dacdeea6.
This patch effectively made the decoder output vfr content out of samples
where cfr is expected.
Addresses ticket #7880.
Signed-off-by: James Almer <jamrial@gmail.com>
The packet counting based approach caused excessive sdt/pat/pmt for VBR, so
let's use a timestamp based approach instead similar to how we emit PCRs.
SDT/PAT/PMT period should be consistent for both VBR and CBR from now on.
Also change the type of sdt_period and pat_period to AV_OPT_TYPE_DURATION so no
floating point math is necessary.
Fixes ticket #3714.
Signed-off-by: Marton Balint <cus@passwd.hu>
This fixes make fate issue for frame thread scale in my local testing
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
At the moment scene change detection score uses all planes to detect scene
changes. In this regard this is similar how the frozen frames detection works.
However, in classic encoding scene change detection typically only uses the Y
plane.
We might get more resonable scores for scene change if we also use only
the Y plane for calculating the score if the pixel format is YUV. Although
this will require additional work once packed YUV formats are added,
because for the moment the generic scene sad score calculation has no way
to ignore some components in a packed format.
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
cuda_runtime.h as well as dynlink_loader.h used nonstandard inclusion
guards with an AV_ prefix, although these files are not in an libav*/
path. So change the inclusion guards and adapt the ref file of the
source fate test accordingly.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
why change .4 to .25, it's for:
one scenecut(pkt_pts=20040) isn't detected by 0.4 threshold
why not change to 0.3 instead of 0.25:
it will miss the scenecut(pkt_pts=20040) after applying the next
patch which enables yuvj420
for fate testing, it's better to catch all scenecut scenes.
Reviewed-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
The tests previously rounded the timestamps. Its better in a fate test to preserve
the data from the demuxer and decoder.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Commit cd48318035 added support for NV24 and NV42, including several
fate tests for these formats, but did not include the reference files
for the tests filter-pixdesc-nv24 and filter-pixdesc-nv42. As a result,
these two tests were broken.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The implementation is pretty straight-forward. Most of the existing
NV12 codepaths work regardless of subsampling and are re-used as is.
Where necessary I wrote the slightly different NV24 versions.
Finally, the one thing that confused me for a long time was the
asm specific x86 path that did an explicit exclusion check for NV12.
I replaced that with a semi-planar check and also updated the
equivalent PPC code, which Lauri kindly checked.
These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.
These formats are not used much, so we've never had a reason to add
them until now. VDPAU recently added support HEVC 4:4:4 content
and when you use the OpenGL interop, the returned surfaces are in
NV24 format, so we need the pixel format for media players, even
if there's no direct use within ffmpeg.
Separately, there are apparently webcams that use NV24, but I've
never seen one.
Up until now, the length field of most level 1 elements has been written
using eight bytes, although it is known in advance how much space the
content of said elements will take up so that it would be possible to
determine the minimal amount of bytes for the length field. This
commit changes this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Given that in both the seekable as well as the non-seekable mode dynamic
buffers are used to write level 1 elements and that now no seeks are
used in the seekable case any more, the two modes can be combined; as a
consequence, the non-seekable mode automatically inherits the ability to
write CRC-32 elements.
There are no differences in case the output is seekable; when it is not
and writing CRC-32 elements is disabled, there can still be minor
differences because before this commit, the EBML ID and length field
were counted towards the cluster size limit; now they no longer are.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Up until now the EBML Header length field has been written with eight
bytes, although the EBML Header is always so small that only one byte
is needed for it. This patch saves seven bytes for every Matroska/Webm
file.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The spec in https://xiph.org/vorbis/doc/v-comment.html states that
the metadata keys are case-insensitive, so don't change the case
and update the fate test case.
Fix#7784
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Jun Zhao <barryjzhao@tencent.com>
write_tmcd allows tmcd track to be created with any mode but in
mov_write_header, index for first tmcd track is only set for modes
MP4 or MOV, causing a crash if tmcd creation is attempted with other
modes.
* commit 'f8df5e2f31a5ba7b30a0e1caaaf5a03c753b3f9b':
tests: Add a convenience function for video-only lavf tests
Merged-by: James Almer <jamrial@gmail.com>
* commit 'a70eac7a9b193e8434b5bed90bd72aa4cb688363':
tests: Convert image2pipe tests to non-legacy test scripts
Merged-by: James Almer <jamrial@gmail.com>
When a JACOsub subtitle has two timestamps, they represent its start and
end times (http://unicorn.us.com/jacosub/jscripts.html#l_times); the
duration is the difference between the two, not the sum of the two.
The subtitle end times in the FATE test for this were wrong as a result;
fix them too. (This test is based on JACOsub's demo.txt, and the end
time computed for the last line using @ now matches what the comments
there say it should be.)
Also tested in practice using MPV, a LaserDisc, and some authentic 1993
JACOsub files.
Signed-off-by: Adam Sampson <ats@offog.org>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
If we fill with black then the generated palette will have one color more
than what the user requested. This also resulted in unwanted black specks in
the output of paletteuse, especially when generating small palettes.
The VP3/4/5/6 reference decoders all use three IDCT versions: one for the
DC-only case, another for blocks with more than 10 coefficients, and an
optimised one for blocks with up to 10 AC coefficents. VP6 relies on the
sparse 10 coefficient version, and without it, IDCT drift occurs.
Fixes: https://trac.ffmpeg.org/ticket/1282
Signed-off-by: Peter Ross <pross@xvid.org>
Change the some options location in avcodec_options to make code more
readable. And update the fate test with this change.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Now "-c copy" works.
Update FATE files.
Demuxer only split file into packets, no data is trimmed.
Encoder & muxer currently expect completely another format
where muxer writes stuff like disposal method which should
be really encoder job.
With this patch muxer only modifies delay between two packets.
Codec copy need to have same behavior between demuxer and
muxer to work correctly.
Fixes#6640.
The header guards were unnecessarily non-standard and the c file
inclusion trick means the files dont't have standard licence
headers.
Based on a patch by: Martin Vignali <martin.vignali@gmail.com>
This is needed because of 32bit float formats (which are difficult to
store in 16bits)
This also fixes undefined behavior found by fate
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
