subtitles.mak's fate-sub tests utilize a more strict comparator
("rawdiff"), which causes the tests fail in case of white space
differences, such as CRLF vs LF. This in turn causes these
ffprobe-using TTML-in-MP4 tests to fail on non-LF systems such as
Windows or wine.
Includes basic support for both the ISMV ('dfxp') and MP4 ('stpp')
methods. This initial version also foregoes fragmentation support
in case the built-in sample squashing is to be utilized, as this
eases the initial review.
Additionally, add basic tests for both muxing modes in MP4.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Up until now, the Matroska muxer did not use the dispositions it is
given as-is; instead it by default overrode the disposition of the first
track of a kind (audio, video, subtitles) if no track of this kind has
the default disposition set. And up until recently, it also enforced
by default that no more than one track of each kind be marked as
default.
The rationale for the former is that there are lots of containers which
lack the concept of default streams, so that it is not uncommon for no
stream to be marked as default at all; the rationale for the latter was
that up until recently, it was dubious whether the Matroska specification
allowed more than one default stream for track type (e.g. mkvmerge
disallowed it). It was this point which led to the implementation of
the above mentioned behaviour inspired by mkvmerge.
Yet the Matroska specifications have changed and now explicitly allow
to set more than one track of each type as default, so that the main
reason of not using the dispositions as-is was rendered moot. Therefore
this commit changes the default to pass the disposition through.
The matroska-mpegts-remux FATE-test has been updated to still use the
old "infer" mode so that it is still covered by FATE; the
matroska-zero-length-block test has also been updated to cover
the infer_no_subs mode. The references for lots of other FATE tests
needed to be updated because of a newly added FlagDefault element with
value zero (whereas a FlagDefault with value 1 needn't be coded at all,
as it coincided with the default value of said element).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The Matroska specifications have evolved and now allow to mark
multiple tracks of the same kind as default (whether this was legal or
not before was dubious; e.g. mkvmerge disallowed it). Yet when the
Matroska muxer is set to infer default dispositions if absent, it also
enforced the now outdated restriction. So update this.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
The MOV muxer can store streamids as track ids but they aren't
visible when probing the result via lavf/dump or ffprobe due to
lack of this flag in the demuxer.
Also adapt some FATE tests to already cover this.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
677a030b26 introduced more printable
side data types in ffprobe, however the Audio Service Type side data
'type' field that was introduced aliases an existing field of the same
name within the side data array, which can lead to JSON output like:
"side_data_list": [
{
"side_data_type": "Audio Service Type",
"type": 0
},
{
"side_data_type": "Stereo 3D",
"type": "side by side",
"inverted": 1
}
]
This, while technically valid JSON, is considered bad practice, since it
forces all downstream users to manually parse it and check all types;
it makes simple deserialization impossible. Worse, in som loosely
type languages, it can lead to silent bugs if exising code assumed
it was a different type.
As such, rename this second "type" field to "service_type".
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Adds schema validation for ffprobe XML output so that updating the
ffprobe.xsd file upon changes to ffprobe is not forgotten. This was
suggested by Marton Balint in:
http://ffmpeg.org/pipermail/ffmpeg-devel/2021-March/278428.html
The schema FATE test is only run if xmllint command is available.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
After fixing AV_PKT_DATA_SKIP_SAMPLES for reading vorbis packets from ogg,
the actual decoded samples become fewer. Three fate tests are failing:
fate-vorbis-20:
The samples in 6.ogg are not frame aligned. 6.pcm file was generated by
ffmpeg before the fix. After the fix, the decoded pcm file does not match
anymore. Ideally the ref file 6.pcm should be updated but it is probably
not worth it including another copy of the same file, only smaller.
SIZE_TOLERANCE is added for this test case.
fate-webm-dash-chapters:
The original vorbis_chapter_extension_demo.ogg is transmuxed to dash-webm.
The ref file webm-dash-chapters needs to be updated.
fate-vorbis-encode:
This exposes another bug in the vorbis encoder that initial_padding is not
correctly set. It is fixed in the previous patch.
Signed-off-by: Guangyu Sun <gsun@roblox.com>
Call the scaler function directly rather than through a function
pointer. Drop the now-unused return value from ff_getSwsFunc() and
rename the function to reflect its new role.
This will be useful in the following commits, where it will become
important that the amount of output is different for scaled vs unscaled
case.
The twoloop coder is highly loaded with (pseudo-)perceptual metrics,
and the aim of the tests is to piece-wise test each function of the
encoder, for which the 'fast' coder is perfect, since it only decides
on which scalefactors to use, rather than enable or disable encoder
features.
Also use helper function to set the timestamp. Maybe we could also use
nanosecond precision, but there were some float rounding concerns.
Signed-off-by: Marton Balint <cus@passwd.hu>
Export them in UTC, not the local timezone. This way the output is
the same everywhere. The timezone information stored in the file is
still ignored, since there seems to be no simple way to export it
correctly.
Format them according to ISO 8601, which we generally use for exporting
dates.
Fixes fate-flv-demux, which was broken since
958bea5248 on some platforms.
There are no guarantees that all side data types have the same
representation on all platforms.
Tests that change output due to this:
id3v2-priv-remux, cover-art-mp3-id3v2-remux, gapless-mp3: SKIP_SAMPLES,
which is tested by fate-gapless-mp3-side-data
matroska-vp8-alpha-remux: MATROSKA_BLOCKADDITIONAL, which is tested by
remux itself (side data is written into output)
matroska-mastering-display-metadata: MASTERING_DISPLAY_METADATA and
CONTENT_LIGHT_LEVEL, which are tested by ffprobe invocation in the same
test
matroska-spherical-mono-remux: STEREO3D and SPHERICAL, which are tested
by ffprobe invocation in the same test
segment-mp4-to-ts: MPEGTS_STREAM_ID, which is tested by ts remuxing
tests
webm-webvtt-remux: WEBVTT_IDENTIFIER/SETTINGS, which is tested by the
ffprobe invocation in the same test
mxf-d10-user-comments: CPB_PROPERTIES, which is tested by mxf-probe-d10
mov-cover-image: SKIP_SAMPLES, which is tested for mov by
mov-aac-2048-priming
copy-trac3074: AUDIO_SERVICE_TYPE, which is tested by fate-hls-fmp4_ac3
This simply performs a 2nd pass if a LSE is encountered with GRAY8
Fixes: tickets/3933/128.jls
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Deprecated in c29038f304.
The resample filter based upon this library has been removed as well.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Deprecated in ddef3d902f.
(The reference file of the mov-zombie test needed to be updated, because
a rotate metadata tag is no longer exported; the side-data is of course
still present.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Announced in 2e8b0446c6.
Two FATE-tests needed to be updated because the checksums of
side data containing an AVCPBProperties struct changed.
buffer_size has also been switched to 64bits because it is a bitsize.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The ASS margins are utilized to generate percentual values, as
the usage of cell-based sizing and offsetting seems to be not too
well supported by renderers.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Attempts to utilize the TTML cell resolution as a mapping to the
reference resolution, and maps font size to cell size. Additionally
sets the display and text alignment according to the ASS alignment
number.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
This sadly required making changes to the code itself,
due to the same context needing to be reused for both versions.
The lookup table had to be duplicated for both versions.
When parsing ID3v2 tags, special (non-text) metadata is not applied
directly and unconditionally; instead it is stored in a linked list
in which elements are prepended. When traversing the list to add APICs
(or private tags) at the end, the order is reversed. The same also
happens for chapters and therefore the chapter parsing code already
reverses the chapters.
This commit changes this: By keeping pointers to both head and tail
of the linked list one can preserve the order of the entries and
remove the reordering code for chapters. Only the pointer to head
will be exported: No current caller uses a nonempty list, so exporting
both head and tail is unnecessary. This removes the functionality
to combine the lists of special metadata read from different ID3v2 tags,
but that doesn't make really much sense anyway (and would be trivial
to implement if desired) and allows to remove the now unnecessary
initializations performed by the callers.
The FATE-reference for the id3v2-priv test had to be updated
because the order of the tags read into the dict is reversed;
for id3v2-priv-remux only the md5 and not the ffprobe output
of the remuxed file changes because the order of the private tags
has up until now been reversed twice.
The references for the aiff/mp3 cover-art tests needed to be updated,
because the order of the attached pics is reversed upon reading.
It is still not correct, because the muxers write the pics in the order
in which they arrive at the muxer instead of the order given by
pkt->stream_index.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Notice that the order of the APIC tracks is currently wrong. This is
a superposition of two bugs: (i) Both muxers write the attached
pictures in the order they arrive in the muxer and not in the
stream_index order, leading to attached pictures that are copied being
written earlier because their timestamp is AV_NOPTS_VALUE, whereas the
timestamp of the encoded pictures is 0. (ii) A bug in the id3v2 parsing
code reverses the order of the parsed pictures.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
Specifically test that the WebVTT flavour is correctly mapped to
the Matroska/WebM CodecID and back; and test that dispositions
unsupported by WebM are discarded even when they would be supported
by Matroska.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
This makes av_read_frame() return packets with proper timestamps.
As a result, seeking now works in combination with streamcopy.
A FATE-test for this has been added.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The test sample has to have no file extension, otherwise probing
happens to work, based off file extension alone, and we want to
test the actual probing function.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Enables writing TTML documents or encoded TTML paragraphs as such
documents.
Additionally, a test for the combined TTML encoder and muxer has
been added to validate that the components still work.
Signed-off-by: Jan Ekström <jan.ekstrom@24i.com>
Some FATE tests use files created by other FATE tests as input files;
this mostly affects the seek tests which use files from vsynth_lena as
well as acodec-pcm as input files. In order to make this possible the
temporary files of all the vsynth* and all acodec-pcm tests are kept.
Yet only a fraction of these files are actually used. This commit
changes this to only keep the files that are actually needed for other
tests. This reduces the size of the tests/data/fate folder after a full
FATE run from 2024727441B to 138739312B.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It only got added recently, and the new name makes it consistent with
product_version_num in the next patch.
Signed-off-by: Marton Balint <cus@passwd.hu>
AVID streams - currently handled by the AVRN decoder - can be (depending
on extradata contents) either MJPEG or raw video. To decode the MJPEG
variant, the AVRN decoder currently instantiates a MJPEG decoder
internally and forwards decoded frames to the caller (possibly after
cropping them).
This is suboptimal, because the AVRN decoder does not forward all the
features of the internal MJPEG decoder, such as direct rendering.
Handling such forwarding in a full and generic manner would be quite
hard, so it is simpler to just handle those streams in the MJPEG decoder
directly.
The AVRN decoder, which now handles only the raw streams, can now be
marked as supporting direct rendering.
This also removes the last remaining internal use of the obsolete
decoding API.
The FF_API macros are private and must not be used by external callers.
As the fields in question are to be removed without replacement, just
drop them.
The fields are:
AVPacket.convergence_duration
AVCodecContext.time_base
AVCodecContext.timecode_frame_start
AV_PIX_FMT_FLAG_PSEUDOPAL pixel descriptor flag
This provides coverage for writing BlockGroups with BlockAdditional
and ReferenceBlock elements. It also tests setting the hearing impaired
disposition (it fits given that this video has no audio so one needs to
be able to read lips to understand anything).
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The FATE suite already contains a file containing mastering display
and content light level metadata: Meridian-Apple_ProResProxy-HDR10.mxf
This file is used to test both the Matroska muxer and demuxer.
Reviewed-by: Ridley Combs <rcombs@rcombs.me>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The md5 test up until now ignored errors from ffmpeg (the cli) and just
md5'ed whatever ffmpeg has output; while testing scenarios in which
ffmpeg fails has its merits, errors should not be overlooked by default;
doing so also reduces the effectiveness of sanitizers as errors from
them are ignored. This has happened with a memleak in the AV1 decoder.
Reviewed-by: Anton Khirnov <anton@khirnov.net>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
The mxf_d10 muxer is very picky regarding the input it accepts:
The only video accepted is MPEG-2 with absolutely constant bitrate,
i.e. all packets need to have exactly the same size; and only a few
bitrates are accepted.
The sample file used did not abide by this: Writing the first packet
(a video packet) errors out and afterwards an audio packet from the
muxing queue has been written. That's all besides metadata (which this
test is about). The FFmpeg cli returned an error, but said error has
been ignored by the md5 test.
This commit changes the test to actually send a compliant stream to the
muxer, so that it does not error out; furthermore, the test is changed
to explicitly check the metadata instead of it only being implicitly
included in the md5 checksum. The compliant stream is created by our
encoder at runtime.
Finally, the test now also covers writing user-specified
product/company/version identification.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Also, test modifying colorspace properties and the default_mode
passthrough which is used here to create a file that has no default
track at all.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
It furthermore tests the demuxer's handling of chained SeekHeads,
level 1-elements after the Clusters and the muxer's capability of
writing huge TrackNumbers as well as expanding the Cues' length field
by one byte if necessary to fill the reserved space. It also tests
propagation of metadata.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
MJPEG does not have a single quantiser scale, so this does not fit into
the intended API use.
This removes the last use of the long-deprecated QP table API.
There is a minor bug in xbm encode which adds a trailing comma at the end
of data. This isn't a big problem, but it would be nicer to be more
technically true to an array of data (by not including the last comma).
This bug fixes the output from something like this (having 4 values):
static unsigned char image_bits[] = { 0x00, 0x11, 0x22, }
to C code that looks like this instead (having 3 values):
static unsigned char image_bits[] = { 0x00, 0x11, 0x22 }
which is the intended results.
Subject: [PATCH 1/3] avcodec/xbmenc: Do not add last comma into output array
xbm outputs c arrays of data.
Including a comma at the end means there is another value to be added.
This bug fix changes something like this:
static unsigned char image_bits[] = { 0x00, 0x11, 0x22, }
to C code like this:
static unsigned char image_bits[] = { 0x00, 0x11, 0x22 }
Signed-off-by: Joe Da Silva <digital@joescat.com>
If the edit lists remove parts of the output timeline, or add a
delay to it, this should be included in the mvhd/tkhd/mdhd durations,
which should correspond to the edit lists.
For tracks starting with pts < 0, the edit list trims out the segment
before pts=0. For tracks starting with pts > 0, a delay element is
added in the edit list, delaying the start of the track data.
In both cases, the practical effect is that the post-edit output
is as if the track had started with pts = 0. Thus calculate the range
from pts=0 to end_pts, for the purposes of mvhd/tkhd/mdhd, unless
edit lists explicitly are disabled.
mov_write_edts_tag needs to operate on the actual pts duration of
the track samples, not the duration that already takes the edit
list effect into account.
Signed-off-by: Martin Storsjö <martin@martin.st>
No longer used by anything.
Unfortunately the old FFT_FLOAT/FFT_FIXED_32 is left as-is. It's
simply too much work for code meant to be all removed anyway.
The AC3 encoder used to be a separate library called "Aften", which
got merged into libavcodec (literally, SVN commits and all).
The merge preserved as much features from the library as possible.
The code had two versions - a fixed point version and a floating
point version. FFmpeg had floating point DSP code used by other
codecs, the AC3 decoder including, so the floating-point DSP was
simply replaced with FFmpeg's own functions.
However, FFmpeg had no fixed-point audio code at that point. So
the encoder brought along its own fixed-point DSP functions,
including a fixed-point MDCT.
The fixed-point MDCT itself is trivially just a float MDCT with a
different type and each multiply being a fixed-point multiply.
So over time, it got refactored, and the FFT used for all other codecs
was templated.
Due to design decisions at the time, the fixed-point version of the
encoder operates at 16-bits of precision. Although convenient, this,
even at the time, was inadequate and inefficient. The encoder is noisy,
does not produce output comparable to the float encoder, and even
rings at higher frequencies due to the badly approximated winow function.
Enter MIPS (owned by Imagination Technologies at the time). They wanted
quick fixed-point decoding on their FPUless cores. So they contributed
patches to template the AC3 decoder so it had both a fixed-point
and a floating-point version. They also did the same for the AAC decoder.
They however, used 32-bit samples. Not 16-bits. And we did not have
32-bit fixed-point DSP functions, including an MDCT. But instead of
templating our MDCT to output 3 versions (float, 32-bit fixed and 16-bit fixed),
they simply copy-pasted their own MDCT into ours, and completely
ifdeffed our own MDCT code out if a 32-bit fixed point MDCT was selected.
This is also the status quo nowadays - 2 separate MDCTs, one which
produces floating point and 16-bit fixed point versions, and one
sort-of integrated which produces 32-bit MDCT.
MIPS weren't all that interested in encoding, so they left the encoder
as-is, and they didn't care much about the ifdeffery, mess or quality - it's
not their problem.
So the MDCT/FFT code has always been a thorn in anyone looking to clean up
code's eye.
Backstory over. Internally AC3 operates on 25-bit fixed-point coefficients.
So for the floating point version, the encoder simply runs the float MDCT,
and converts the resulting coefficients to 25-bit fixed-point, as AC3 is inherently
a fixed-point codec. For the fixed-point version, the input is 16-bit samples,
so to maximize precision the frame samples are analyzed and the highest set
bit is detected via ac3_max_msb_abs_int16(), and the coefficients are then
scaled up via ac3_lshift_int16(), so the input for the FFT is always at least 14 bits,
computed in normalize_samples(). After FFT, the coefficients are scaled up to 25 bits.
This patch simply changes the encoder to accept 32-bit samples, reusing
the already well-optimized 32-bit MDCT code, allowing us to clean up and drop
a large part of a very messy code of ours, as well as prepare for the future lavu/tx
conversion. The coefficients are simply scaled down to 25 bits during windowing,
skipping 2 separate scalings, as the hacks to extend precision are simply no longer
necessary. There's no point in running the MDCT always at 32 bits when you're
going to drop 6 bits off anyway, the headroom is plenty, and the MDCT rounds
properly.
This also makes the encoder even slightly more accurate over the float version,
as there's no coefficient conversion step necessary.
SIZE SAVINGS:
ARM32:
HARDCODED TABLES:
BASE - 10709590
DROP DSP - 10702872 - diff: -6.56KiB
DROP MDCT - 10667932 - diff: -34.12KiB - both: -40.68KiB
DROP FFT - 10336652 - diff: -323.52KiB - all: -364.20KiB
SOFTCODED TABLES:
BASE - 9685096
DROP DSP - 9678378 - diff: -6.56KiB
DROP MDCT - 9643466 - diff: -34.09KiB - both: -40.65KiB
DROP FFT - 9573918 - diff: -67.92KiB - all: -108.57KiB
ARM64:
HARDCODED TABLES:
BASE - 14641112
DROP DSP - 14633806 - diff: -7.13KiB
DROP MDCT - 14604812 - diff: -28.31KiB - both: -35.45KiB
DROP FFT - 14286826 - diff: -310.53KiB - all: -345.98KiB
SOFTCODED TABLES:
BASE - 13636238
DROP DSP - 13628932 - diff: -7.13KiB
DROP MDCT - 13599866 - diff: -28.38KiB - both: -35.52KiB
DROP FFT - 13542080 - diff: -56.43KiB - all: -91.95KiB
x86:
HARDCODED TABLES:
BASE - 12367336
DROP DSP - 12354698 - diff: -12.34KiB
DROP MDCT - 12331024 - diff: -23.12KiB - both: -35.46KiB
DROP FFT - 12029788 - diff: -294.18KiB - all: -329.64KiB
SOFTCODED TABLES:
BASE - 11358094
DROP DSP - 11345456 - diff: -12.34KiB
DROP MDCT - 11321742 - diff: -23.16KiB - both: -35.50KiB
DROP FFT - 11276946 - diff: -43.75KiB - all: -79.25KiB
PERFORMANCE (10min random s32le):
ARM32 - before - 39.9x - 0m15.046s
ARM32 - after - 28.2x - 0m21.525s
Speed: -30%
ARM64 - before - 36.1x - 0m16.637s
ARM64 - after - 36.0x - 0m16.727s
Speed: -0.5%
x86 - before - 184x - 0m3.277s
x86 - after - 190x - 0m3.187s
Speed: +3%
Do it only when requested with the AV_CODEC_EXPORT_DATA_VIDEO_ENC_PARAMS
flag.
Drop previous code using the long-deprecated AV_FRAME_DATA_QP_TABLE*
API. Temporarily disable fate-filter-pp, fate-filter-pp7,
fate-filter-spp. They will be reenabled once these filters are converted
in following commits.
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>
One of the inputs to the fate test has an rgba pixel format which needs
to be converted to rgb32 (argb on big-endian) for the hqx filter. Because auto
scaling in the fate test is disabled, this needs a separate scale
filter.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andriy Gelman <andriy.gelman@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>
the warning message:
warning: using floating point absolute value function
'fabs' when argument is of integer type
use FFABS to set the absolute value.
Signed-off-by: liuqi05 <liuqi05@kuaishou.com>
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>
av1dec should no longer attempt to output empty frames if another decoder
was used for probing and it sucessfully set a pix_fmt ever since 05872c67a4,
so we can re-add the AV_CODEC_CAP_AVOID_PROBING cap.
Signed-off-by: James Almer <jamrial@gmail.com>
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>
Filters mostly work in native endianness, but they must output
a specified endianness, usually little: that requires a final
conversion for big endian.
I do not know what's the deal with gif-deal: inserting explicitly
the filters that are implicitly inserted result in less frames in
output. Probably a strange problem of duration.
Otherwise the result of such tests will not accurately reflect the
current state.
Reviewed-by: Jan Ekström <jeebjp@gmail.com>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
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>
Use pthread to multithread dnn_execute_layer_conv2d.
Can be tested with command "./ffmpeg_g -i input.png -vf \
format=yuvj420p,dnn_processing=dnn_backend=native:model= \
espcn.model:input=x:output=y:options=conv2d_threads=23 \
-y sr_native.jpg -benchmark"
before patch: utime=11.238s stime=0.005s rtime=11.248s
after patch: utime=20.817s stime=0.047s rtime=1.051s
on my 3900X 12c24t @4.2GHz
About the increase of utime, it's because that CPU HyperThreading
technology makes logical cores twice of physical cores while cpu's
counting performance improves less than double. And utime sums
all cpu's logical cores' runtime. As a result, using threads num
near cpu's logical core's number will double utime, while reduce
rtime less than half for HyperThreading CPUs.
Signed-off-by: Xu Jun <xujunzz@sjtu.edu.cn>
Signed-off-by: Guo, Yejun <yejun.guo@intel.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.
Explicitly insert the scale or aresample filter where it would
have been inserted by the negotiation.
Re-enable conversions if it cannot be done easily.
If a conversion is needed in a test, we want to know about it.
If the negotiation changes and makes new conversion necessary,
we want to know about it even more.
