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>
ISMV lacks any sort of edit list support, as well as tfxd is
effectively the PTS of the fragment for most intents and purposes.
Thus, if b-frames are requested without negative CTS offsets you
end up with N frames' worth of delay (tfxd PTS plus the CTS offset
of the first sample). Negative CTS offsets enable the first sample
to have CTS=DTS, and thus a/v desync due to b-frame reorder delay
is avoided.
Fixes vorbis mp4 audio files, with edit list specified. Since
st->skip_samples is not set in case of vorbis , ffmpeg computes the
start_time as negative.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Add tests for upmixing and downmixing with audio channel counts that
have a corresponding default layout and also tests where there is no
default layout.
Update the existing "stereo4" test so it actually outputs stereo like
the other stereo tests. Rename the previous "stereo4" test into
"upmix1".
Reviewed-by: Nicolas George <george@nsup.org>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
da9cc22d5b allowed the MOV muxer to relay a custom stream handler name,
whether populated from the input stream or user-set. However, the entry
key didn't match the key set by the MOV demuxer, so it wasn't
effective. Fixed.
Due to the change, four FATE refs have to be updated. Verified that the
target payload of the tests hasn't changed in terms of CRC.
If start_time is not set, ffmpeg takes the duration from the global
movie instead of the per stream duration.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This improves performance and makes qtrle behave more similar to other decoders.
Libavcodec does generally not output known duplicated frames, instead the calling Application
can insert them as it needs.
Fixes: Timeout
Fixes: 6383/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_QTRLE_fuzzer-6199846902956032
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This new optional flag makes it easier to deal with mpegts
samples where the PMT is updated and elementary streams move
to different PIDs in the middle of playback.
Previously, new AVStreams were created per PID, and it was up
to the user to figure out which streams had migrated to a new PID
(by iterating over the list of AVProgram and making guesses), and
switch seamlessly to the new AVStream during playback.
Transcoding or remuxing these streams with ffmpeg on the CLI was
also quite painful, and the user would need to extract each set
of PIDs into a separate file and then stitch them back together.
With this new option, the mpegts demuxer will automatically detect
PMT changes and feed data from the new PID to the original AVStream
that was created for the orignal PID. For mpegts samples with
stream_identifier_descriptor available, the unique ID is used to
merge PIDs together. If the stream id is not available, the demuxer
attempts to map PIDs based on their position within the PMT.
With this change, I am able to playback and transcode/remux these
two samples which previously caused issues:
https://tmm1.s3.amazonaws.com/pmt-version-change.tshttps://kuroko.fushizen.eu/videos/pid_switch_sample.ts
I also have another longer sample in which the PMT changes
repeatedly and ES streams move to different pids three times
during playback:
https://tmm1.s3.amazonaws.com/multiple-pmt-change.ts
Demuxing this sample with the new option shows several new log
messages as the PMT changes are handled:
[mpegts] detected PMT change (program=1, version=3/6, pcr_pid=0xf98/0xfb7)
[mpegts] re-using existing video stream 0 (pid=0xf98) for new pid=0xfb7
[mpegts] re-using existing audio stream 1 (pid=0xf99) for new pid=0xfb8
[mpegts] re-using existing audio stream 2 (pid=0xf9a) for new pid=0xfb9
[mpegts] detected PMT change (program=1, version=6/3, pcr_pid=0xfb7/0xf98)
[mpegts] detected PMT change (program=1, version=3/4, pcr_pid=0xf98/0xf9b)
[mpegts] re-using existing video stream 0 (pid=0xf98) for new pid=0xf9b
[mpegts] re-using existing audio stream 1 (pid=0xf99) for new pid=0xf9c
[mpegts] re-using existing audio stream 2 (pid=0xf9a) for new pid=0xf9d
[mpegts] detected PMT change (program=1, version=4/5, pcr_pid=0xf9b/0xfa9)
[mpegts] re-using existing video stream 0 (pid=0xf98) for new pid=0xfa9
[mpegts] re-using existing audio stream 1 (pid=0xf99) for new pid=0xfaa
[mpegts] re-using existing audio stream 2 (pid=0xf9a) for new pid=0xfab
[mpegts] detected PMT change (program=1, version=5/6, pcr_pid=0xfa9/0xfb7)
Signed-off-by: Aman Gupta <aman@tmm1.net>
Generates color bar test patterns based on EBU PAL recommendations.
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Adds tests for the hue angle and brightness filter parameters.
Renames the existing saturation parameter test for consistency.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
The artificial sample file sei-1.h264 contains five frames (IDR P B I B)
and the following SEI message types:
* Buffering period
* Picture timing
* Pan-scan rectangle (display as 4:3)
* User data registered, containing A/53 closed captions (captions match
frame content, including reordering)
* Recovery point (at the I frame)
* Display orientation (identity transformation)
* Mastering display (with arbitrary contents)
* Undefined SEI type 1234 (containing ascending bytes)
Uses the same mechanism as other codecs - conformance test files are
passed through the metadata filter (which, with no options, reads the
input and writes it back) and the output verified to match the input.
The specs says that the the first color component in the color array is
not alpha, but simply 0.
Fixes 0 alpha of fate-suite/cvid/catfight-cvid-pal8-partial.mov
Signed-off-by: Marton Balint <cus@passwd.hu>
The track's media duration from the mdhd atom takes precedence
over both the stts and elst atom for calculating and setting
the track's total duraion.
Technically, we shouldn't be using the stts atom at all for
calculating stream durations.
This fixes incorrect stream and final packet durations on files
with edit lists that are longer than the media duration.
The FATE changes are expected, and output is more correct (the
AAC frame is not 1028 samples).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Add previously omitted overlap smooting and loop filtering for
frame/field-interlace pictures. For progressive pictures switch to the
re-implemented versions of overlap smooting and loop filtering.
Signed-off-by: Jerome Borsboom <jerome.borsboom@carpalis.nl>
The existing implementation did out-of-bounds reference pixel replication for
progressive reference frames. In interlaced reference frames both the even and
odd line on the horizontal edges need to be replicated.
Fixes#3262.
Signed-off-by: Jerome Borsboom <jerome.borsboom@carpalis.nl>
- Parse schm atom to get different encryption schemes.
- Allow senc atom to appear in track fragments.
- Allow 16-byte IVs.
- Allow constant IVs (specified in tenc).
- Allow only tenc to specify encryption (i.e. no senc/saiz/saio).
- Use sample descriptor to detect clear fragments.
This doesn't support:
- Different sample descriptor holding different encryption info.
- Only first sample descriptor can be encrypted.
- Encrypted sample groups (i.e. seig).
- Non-'cenc' encryption scheme when using -decryption_key.
Signed-off-by: Jacob Trimble <modmaker@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Some ADTS streams can have multiple ID3 tags between frames. This
change parses all of them, rather than just the first one.
Signed-off-by: Mattias Amnefelt <mattiasa@avm.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
On modern x86 systems its around 2x faster. For systems without
FPUs it'll be slower, but our policy is to prefer floating point
implementations and to let users decide what's best (or just not
compile them on systems without FPUs).
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
Set relevant filter parameters such that the result can easily be
checked with a waveform editor.
In particular, it makes it clear the silence_start is not accurate in
the current code.
test extract color and alpha
with the three main kind of hap frame :
- no snappy compression
- snappy compression and one chunk
- snappy compression and several chunks (16 here)
like the bsf filter need to be used with vtag and encoder edition
also test the information of the target mov for color and alpha
This adds a way for an API user to transfer QP data and metadata without
having to keep the reference to AVFrame, and without having to
explicitly care about QP APIs. It might also provide a way to finally
remove the deprecated QP related fields. In the end, the QP table should
be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
There are two side data types, because I didn't care about having to
repack the QP data so the table and the metadata are in a single
AVBufferRef. Otherwise it would have either required a copy on decoding
(extra slowdown for something as obscure as the QP data), or would have
required making intrusive changes to the codecs which support export of
this data.
The new side data types are added under deprecation guards, because I
don't intend to change the status of the QP export as being deprecated
(as it was before this patch too).
enable dump bit stream filter and update opt fate test ref.
Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Thanks for the discussion. Here's the next version, now with /25 and removed
ff_log2().
The blocksize of the PCM decoder is hard-coded. This creates
unnecessary delay when reading low-rate (<100Hz) streams. This creates
issues when multiplexing multiple streams, since other inputs are only
opened/read after a low-rate input block was completely read.
This patch decreases the blocksize for low-rate inputs, so
approximately a block is read every 40ms. This decreases the startup
delay when multiplexing inputs with different rates.
Signed-off-by: Philipp M. Scholl <pscholl@bawue.de>
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes seek for files with empty edits and files with negative ctts
(dts_shift > 0). Added fate samples and tests.
Signed-off-by: Sasi Inguva <isasi@isasi.mtv.corp.google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
To make the best use of existing code, I generalised the wrapper
that currently does yuv420p10 to p010 to support any mixture of
input and output sizes between 10 and 16 bits. This had the side
effect of yielding a working code path for all yuv420p1x formats
to p01x.
External headers are no longer welcome in the ffmpeg codebase because they
increase the maintenance burden. However, in the NVidia case the vanilla
headers need some modifications to be usable in ffmpeg therefore we still
provide them, but in a separate repository.
The external headers can be found at
https://git.videolan.org/?p=ffmpeg/nv-codec-headers.git
Fate-source is updated because of the deleted files, and dynlink_loader.h
license headers were updated with the standard FFmpeg headers.
Signed-off-by: Marton Balint <cus@passwd.hu>
Signed-off-by: Timo Rothenpieler <timo@rothenpieler.org>
This is needed by later hwaccel code to tell which encoding process was
used for a particular frame, because hardware decoders may only support a
subset of possible methods.
These tests cover specific rounding behaviour, to ensure that I don't
introduce any regressions with the rewritten "activate" callback based
fps filter.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
In 16x8 motion compensation, for lower 16x8 region, the input to mpeg_motion() for motion_y was "motion_y + 16", which causes wrong rounding. For 4:2:0, chroma scaling for y is dividing by two and rounding toward zero. When motion_y < 0 and motion_y + 16 > 0, the rounding direction of "motion_y" and "motion_y + 16" is different and rounding "motion_y + 16" would be incorrect.
We should input "motion_y" as is to round correctly. I add "is_16x8" flag to do that.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
For B field pictures, the spec says,
> The prediction shall be made from the field of the same parity as the field being predicted.
I did it.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is done mainly in preparation for the SIMD patches.
- for the 8-bit input, decrease the blend factor precision to 7-bit.
- for the 16-bit input, increase the blend factor precision to 15-bit.
- make sure the blend functions are not called with 0 or maximum blending
factors, because we don't want the signed factor integers to overflow.
Fate test changes are due to different rounding.
Signed-off-by: Marton Balint <cus@passwd.hu>
<jamrial> durandal_1707: 8088b5d69c broke the acrossfade test
<@durandal_1707> jamrial: there was test?
<jamrial> durandal_1707: fate-filter-acrossfade
<@durandal_1707> what broke?
<jamrial> what used to be one frame is now two
<@durandal_1707> ahh, just update test
Signed-off-by: James Almer <jamrial@gmail.com>
The framerate filter was quite convoluted with some filter_frame /
request_frame logic bugs. It seemed easier to rewrite the whole filter_frame /
request_frame part and also the frame interpolation ratio calculation part in
one step.
Notable changes:
- The filter now only stores 2 frames instead of 3
- filter_frame outputs all the frames it can to be able to handle consecutive
filter_frame calls which previously caused early drops of buffered frames.
- because of this, request_frame is largely simplified and it only outputs
frames on flush. Previously consecuitve request_frame calls could cause the
filter to think it is in flush mode filling its buffer with the same frames
causing a "ghost" effect on the output.
- PTS discontinuities are handled better
- frames with unknown PTS values are now dropped
Fixes ticket #4870.
Probably fixes ticket #5493.
Signed-off-by: Marton Balint <cus@passwd.hu>
The PERSIST_RPARAM_A_RExt_Sony_1 bitstream has an out-of-range value
and has therefore been superseded.
It is otherwise identical, and decodes the same.
Signed-off-by: James Almer <jamrial@gmail.com>
It was truncated to int later on anyway. Fate test changes are due to rounding
instead of truncation.
Fixes fate test failures on x86-32 (gcc 4.8 (Ubuntu 4.8.5-2ubuntu1~14.04.1))
after 090b740680.
Signed-off-by: Marton Balint <cus@passwd.hu>
- normalize score to [0..100] instead of [0..85]
- change the default score to 8.2 to roughly keep existing behaviour
- take into account bit depth
- do not truncate to integer
Signed-off-by: Marton Balint <cus@passwd.hu>
Every bitstream filter behaves as intended now, so there's no need to
wait for the first packet of every stream.
Signed-off-by: James Almer <jamrial@gmail.com>
The current edit unit cannot be reliably determined for the last packet of a
video stream, because we can't query the start offset of the next edit unit
from the index. This caused missing timestamps for the last video packet.
Therefore from now on, we allow setting the PTS even if we are not sure of the
current edit unit if mxf_set_current_edit_unit returned a specific failure, and
the assumed current edit unit is the last.
Fixes last packet timestamp of:
ffprobe -fflags nofillin -show_packets tests/data/lavf/lavf.mxf -select_streams v
Signed-off-by: Marton Balint <cus@passwd.hu>
Writes one set of field framing information for progressive streams and
two sets for interlaced streams. Fixes ticket #6383.
Unfortunately the OpenDML v1.02 document is not very specific on what
value to use for start_line when frame data is not coming from a
capturing device, so this is just using 0/1 depending on the field order
as a best-effort guess.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
After c2a8f0fcbe this can happen on normal edit lists starting on a B-frame.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Subtract the calculated dts offset from the requested timestamp before
seeking. This fixes an error "Error while filtering: Operation not
permitted" observed with a short file which contains only one key frame
and starts with negative timestamps.
Then, av_index_search_timestamp() returns a valid negative timestamp,
but mov_seek_stream bails out with AVERROR_INVALIDDATA.
Fixes ticket #6139.
Signed-off-by: Jonas Licht <jonas.licht@fem.tu-ilmenau.de>
Signed-off-by: Peter Große <pegro@friiks.de>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Previously alac encoder was used, from a first glance I thought it is bitexact,
but it turns out it is using floating point arithmetic as well, so probably it
is not. Fixes fate failures on mingw32/64.
Signed-off-by: Marton Balint <cus@passwd.hu>
According to EBU tech 3285 supplement 3 the dwPosPeakOfPeaks field
should contain the absolute position to the maximum audio sample value,
but the current implementation writes the relative peak frame index
instead.
Fix the issue by writing the "unknown" value (-1) for now until the
feature is implemented correctly.
Previous version reviewed-by: Peter Bubestinger <p.bubestinger@av-rd.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
* commit '07a2b155949eb267cdfc7805f42c7b3375f9c7c5':
Bump major versions of all libraries
A few API deprecated ~2 years ago or more are also postponed here for
varying reasons.
FF_API_LOWRES:
Since this functionality depends on AVStream->codec, i figure the two can
be removed at the same time in the next bump or so.
FF_API_AVCTX_TIMEBASE:
Couldn't get this one to work. Not just libavcodec but apparently also
libavformat and ffmpeg.c expect AVCodecContext->time_base to be set for
decoding. Upon removal some tests report a different generic stream time
base (like 1/25), and others lose packet duration values. I guess it's
somehow tied to the AVStream->codec clusterfuck.
It can be dealt with alongside FF_API_LAVF_AVCTX in the next bump.
FF_API_OLD_FILTER_OPTS_ERROR:
This one is meant to remain after FF_API_OLD_FILTER_OPTS is removed.
Its purpose is displaying the corrected command line using the new syntax
as a suggestion as part of the error message.
Merged-by: James Almer <jamrial@gmail.com>
Sets the correct start padding value when an edit list is present.
A new fate test is added, fate-mov-440hz-10ms, to ensure this is
handled correctly.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Reviewed-by: Sasi Inguva <isasi-at-google.com@ffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Use the appropriate metadata filter for each codec - in the absence of any
options to modify the stream, the output bitstream should be identical to
the input (though the output file may differ in padding).
All tests use conformance bitstreams, the MPEG-2 streams are newly added
from the conformance test streams
<http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_13818-4_2004_Conformance_Testing/Video/>
(cherry picked from commit 3cae7f8b9b)
(cherry picked from commit fbd63170bc)
* commit '8e4d4efc67e154fdffd65964a7cfeef740320827':
fate: Add another SVQ3 test to increase coverage
Also included a fix from da8093f712.
The demuxer option "-ignore_editlist 1 " is temporarily added to the
test as well, to workaround a regression in the edit list mov parsing
code.
Merged-by: James Almer <jamrial@gmail.com>
Correctly set the interlaced_frame and top_field_first fields when pic_struct
indicates paired fields.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Metadata filter output is passed through an Awk script comparing floats
against reference values with specified "fuzz" tolerance to account for
architectural differences (e.g. x86-32 vs. x86-64).
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Use the appropriate metadata filter for each codec - in the absence of any
options to modify the stream, the output bitstream should be identical to
the input (though the output file may differ in padding).
All tests use conformance bitstreams, the MPEG-2 streams are newly added
from the conformance test streams
<http://standards.iso.org/ittf/PubliclyAvailableStandards/ISO_IEC_13818-4_2004_Conformance_Testing/Video/>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
The complex vertical low-pass filter slightly over-sharpens the picture. This becomes visible when several transcodings are cascaded and the error potentises, e.g. some generations of HD->SD SD->HD.
To prevent this behaviour the destination pixel must not exceed the source pixel when the average of the pixels above and below is less than the source pixel. And the other way around.
Tested and approved in a visual transcoding cascade test by video professionals.
SSIM/PSNR test with the first generation of an HD->SD file as a reference against the 6th generation(3 x SD->HD HD->SD):
Results without the patch:
SSIM Y:0.956508 (13.615881) U:0.991601 (20.757750) V:0.993004 (21.551382) All:0.974405 (15.918463)
PSNR y:31.838009 u:48.424280 v:48.962711 average:34.759466 min:31.699297 max:40.857847
Results with the patch:
SSIM Y:0.970051 (15.236232) U:0.991883 (20.905857) V:0.993174 (21.658049) All:0.981290 (17.279202)
PSNR y:34.412108 u:48.504454 v:48.969496 average:37.264644 min:34.310637 max:42.373392
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Adds another test for asetnsamples filter where padding of the last
frame is switched off. Renames the existing test to make the difference
obvious.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Makes the handling of unspecified/unknown color_range values on stream
level consistent to the value used on frame level.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Adds FATE tests for the previously untested allrgb, allyuv, rgbtestsrc,
smptebars, smptehdbars and yuvtestsrc filters.
Also adds a test for testsrc2 filter with rgb+alpha.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
The -map option allows for a trailing ? so that an error is not thrown if
the input stream does not exist.
This capability is extended to the map_channel option.
This allows a ffmpeg command not to break if an input channel does not
exist, which can be of use (for instance, scripts processing audio
channels with sources having unset number of audio channels).
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
When sidx box support is enabled, the code will skip reading all
trun boxes (each containing ctts entries for samples inthat box).
If seeks are attempted before all ctts values are known, the old
code would dump ctts entries into the wrong location. These are
then used to compute pts values which leads to out of order and
incorrectly timestamped packets.
This patch fixes ctts processing by always using the index returned
by av_add_index_entry() as the ctts_data index. When the index gains
new entries old values are reshuffled as appropriate.
This approach makes sense since the mov demuxer is already relying
on the mapping of AVIndex entries to samples for correct demuxing.
As a result of this all ctts entries are now 1-count. A followup
change will be submitted to remove support for > 1 count entries
which will simplify seeking.
Notes for future improvement:
Probably there are other boxes (stts, stsc, etc) that are impacted
by this issue... this patch only attempts to fix ctts since it
completely breaks packet timestamping.
This patch continues using an array for the ctts data, which is not
the most ideal given the rearrangement that needs to happen (via
memmove as new entries are read in). Ideally AVIndex and the ctts
data would be set-type structures so addition is always worst case
O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
noticeable during seeks.
Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Since there is no information about the source format, "unspecified"
is the correct value to write here.
All tests using the MPEG-2 encoder are updated, as this changes the
header on all outputs.
Fixes filter-pixfmts-scale test failing on big-endian systems due to
alpSrc not being cast to (const int32_t**).
Also fixes distortions in the output alpha channel values by copying the
alpha channel code from the rgba64 case found elsewhere in output.c.
Fixes ticket 6555.
Signed-off-by: James Cowgill <James.Cowgill@imgtec.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit switches off forced correct nesting of tags and only keeps
it for font tags. See long explanations in the code for the rationale.
This results in various FATE changes which I'll explain here:
- various swapping in font attributes, this is mostly noise due to the
old reverse stack way of printing them. The new one is more correct as
the last attribute takes over the previous ones.
- unrecognized tags disappears
- invalid tags that were previously displayed aren't anymore (instead,
we have a warning). This is better for the end user
The main benefit of this commit is to be more tolerant to error, leading
to a better handling of badly nested tags or random wrong formatting for
the end user.
This reverts commit 04aa09c4bc
and reintroduces 0ff5567a30 that
was temporarily reverted due to minor regressions.
It also reverts e5bce8b4ce that fixed FATE refs.
The fate-ffm change is caused by field_order now being set
on the output format because the first frame arrives earlier.
The fate-mxf change is assumed to be the same.
The scale2ref filter will now maintain the DAR of the main input and
not the DAR of the reference input. This previous behavior was deemed
counterintuitive for most (all?) use-cases.
Before:
scale2ref=iw/4:ow/mdar
in w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:4/3 flags:0x2
SAR: ((120 * 640) / (160 * 360)) * (1 / 1) = 4 / 3
DAR: (160 / 120) * (4 / 3) = 16 / 9
(main out now same DAR as ref)
Now:
scale2ref=iw/4:ow/mdar
in w:320 h:240 fmt:rgb24 sar:1/1
ref w:640 h:360 fmt:rgb24 sar:1/1
out w:160 h:120 fmt:rgb24 sar:1/1 flags:0x2
SAR: ((120 * 320) / (160 * 240)) * (1 / 1) = 1 / 1
DAR: (160 / 120) * (1 / 1) = 4 / 3
(main out same DAR as main in)
The scale2ref FATE test has also been updated.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This is actually internal utvideo format.
Allows to make use of SIMD for median prediction for rgb(a) formats,
thus speeding up decoding.
Simplifies code, eases further developement and maintenance.
Update FATE because of pixel format switch.
Signed-off-by: Paul B Mahol <onemda@gmail.com>
<@jamrial> durandal_1707: 04aa09c4bc broke fate-lavf-ffm and fate-lavf-mxf
<@durandal_1707> how so?
<@jamrial> one byte changes
<@durandal_1707> jamrial: just update checksums
<@jamrial> durandal_1707: but why did they change at all? the commit you reverted didn't affect them
<@jamrial> why does reverting it affect these tests?
<@jamrial> i don't think updating the checksum without knowing what changed is a good idea
<@durandal_1707> jamrial: the lavfi core is in weird state after removal of recursive code
<@durandal_1707> jamrial: the change is that older ones would get progressive flag set and new one doesnt
<@jamrial> alright
The md5 protocol has no seek support, but some tests use seeks. This changes
the fate tests to actually create the output files and calculate the md5 on the
written files, which also makes the tests independent of the size of the output
buffers and output buffering in general.
A new md5pipe fate test method is also introduced to keep the old functionality
for tests where using a non-seekable output was intentional, and matroska md5
tests are changed to use that.
Signed-off-by: Marton Balint <cus@passwd.hu>
If the videos starts with B frame, then the minimum composition time
as computed by stts + ctts will be non-zero. Hence we need to shift
the DTS, so that the first pts is zero. This was the intention of that
code-block. However it was subtracting by the wrong amount.
For example, for one of the videos in the bug nonFormatted.mp4 we have
stts:
sample_count duration
960 1001
ctts:
sample_count duration
1 3003
2 0
1 3003
....
The resulting composition times are : 3003, 1001, 2002, 6006, ...
The minimum composition time or PTS is 1001, which should be used to
offset DTS. However the code block was wrongly using ctts[0] which is
3003. Hence the PTS was negative. This change computes the minimum pts
encountered while fixing the index, and then subtracts it from all the
timestamps after the edit list fixes are applied.
Samples files available from:
https://bugs.chromium.org/p/chromium/issues/detail?id=721451https://bugs.chromium.org/p/chromium/issues/detail?id=723537
fate-suite/h264/twofields_packet.mp4 is a similar file starting with 2
B frames. Before this change the PTS of first two B-frames was -6006
and -3003, and I am guessing one of them got dropped when being decoded
and remuxed to the framecrc before, and now it is not being dropped.
Signed-off-by: Sasi Inguva <isasi@google.com>
This test the demuxer discarding non ADTS frames at the beginning and
end of the input.
As a side effect, this commit also enables fate-adts-demux, which was
accidentally disabled in 324f0fbff1.
Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This new FATE test for the scale2ref filter makes use of the recently
added scale2ref-specific variables to maintain the aspect ratio of a
test input.
Filtergraph explanation:
[main] has an AR of 4:3. [ref] has an AR of 16:9.
640 / 4 = 160. So the new width for [main] is 160.
160 / ((320 / 240) * (1 / 1)) = 160 / (4 / 3) = 120. So the new
height for [main] is 120.
160 / 120 = 4 / 3 so [main]'s aspect ratio has been maintained while
using [ref]'s width as a reference point.
[ref] is nullsink'd since it is left unchanged by scale2ref (and so
shouldn't need to be tested).
If we were to use "iw/4:-1" in place of "iw/4:ow/mdar":
640 / 4 = 160. So the new width for [main] would be 160.
360 / 4 = 90. So the new height for [main] would be 90.
160 / 90 = 16 / 9 so [main] now has the same aspect ratio as [ref]
which is probably what you do not want.
This is currently the only test for scale2ref.
Signed-off-by: Kevin Mark <kmark937@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This removes the current API violating behavior of overwritting the stream's
extradata during packet filtering, something that should not happen after the
av_bsf_init() call.
The bitstream filter generated extradata is no longer available during
write_header(), and as such not usable with non seekable output. The FATE
tests are updated to reflect this.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '019ab88a95cb31b698506d90e8ce56695a7f1cc5':
lavc: add an option for exporting cropping information to the caller
Merged-by: James Almer <jamrial@gmail.com>
This complex (-1 2 6 2 -1) filter slightly less reduces interlace 'twitter' but better retain detail and subjective sharpness impression compared to the linear (1 2 1) filter.
Signed-off-by: Thomas Mundt <tmundt75@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
the tested sample contain negative value in the red channel
need to be clip to zero, and not set to MAX_RED
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
