- 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>
Add an option to webm_dash_manifest demuxer to specify a value for
"bandwidth" field in the DASH manifest. The value is then used by
the muxer. Fixes an existing FIXME in the code.
Signed-off-by: Vignesh Venkatasubramanian <vigneshv@google.com>
Signed-off-by: James Zern <jzern@google.com>
As it gives excellent encoding gains at an insignificant speed increase
and passes fate without problems, it should now be safe to enable by
default.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>
This merges commits 8e2ea69135 and
096a8effa3 by Anton Khirnov, with the
following change:
- extract_extradata_check() is added to know if the codec is supported
by the bsf before trying to initialize it. This behaviour is similar to
the old AVCodecParser.split checks.
The FATE reference changes are due to the filtered out NAL units that
the old AVCodecParser.split implementation left alone.
Decoding is unchanged as the functions that parse extradata simply
ignored said unnecessary NAL units.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '481ff3cf018811ba3235f1c236e970f32a6300b9':
fate: Add h264 and hevc extradata reload tests
Only the HEVC part is merged, see 00c8079816
Merged-by: Clément Bœsch <u@pkh.me>
* commit 'b90c8a3d08e3f9ad4de1253376d2d1d93abb8b8c':
fate: Add tests for mov display matrix
Adapted to use ffprobe -show_entries
Merged-by: James Almer <jamrial@gmail.com>
This field is of little value, and interferes with testing side data,
since sizes can be different on multiple architectures.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.
Adds an internal helper function for bitrate guessing.
Signed-off-by: Tobias Rapp <t.rapp@noa-archive.com>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Preparation for potentially disabling merged side data by default in the
libs. Do this in particular because it affects fate tests.
The changed tests either reflect added packet side data, or the changed
packet size due to merged side data removal reducing the packet size.
The Chen-Shapiro(CS) test was used to test normality for
Lagged Fibonacci PRNG.
Normality Hypothesis Test:
The null hypothesis formally tests if the population
the sample represents is normally-distributed. For
CS, when the normality hypothesis is True, the
distribution of QH will have a mean close to 1.
Information on CS can be found here:
http://www.stata-journal.com/sjpdf.html?articlenum=st0264http://www.originlab.com/doc/Origin-Help/NormalityTest-Algorithm
Signed-off-by: Thomas Turner <thomastdt@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
The constants used in the decoder used floating point precision,
and this caused different values to be generated on different
architectures. Additionally on big endian machines, the fate test
would output bytes in native order, which is different from the one
hardcoded in the test.
So, eradicate floating point numbers and use fixed point (32.32)
arithmetics everywhere, replacing constants with precomputed integer
values, and force the pixel format output to be the same in the fate
test.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
This makes sure the actual stream parameters are used, which is
important mainly for hardware decoding+filtering cases, which would
previously require various weird workarounds to handle the fact that a
fake software graph has to be constructed, but never used.
This should also improve behaviour in rare cases where
avformat_find_stream_info() does not provide accurate information.
This merges Libav commit a3a0230. It was previously skipped.
The code in flush_encoders() which sets up a "fake" format wasn't in
Libav. I'm not sure if it's a good idea, but it tends to give
behavior closer to the old one in certain corner cases.
The vp8-size-change gives different result, because now the size of
the first frame is used. libavformat reported the size of the largest
frame for some reason.
The exr tests now use the sample aspect ratio of the first frame. For
some reason libavformat determines 0/1 as aspect ratio, while the
decoder returns the correct one.
The ffm and mxf tests change the field_order values. I'm assuming
another libavformat/decoding mismatch.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This will be useful in the following commit, after which the muxer
timebase is not always available when encoding.
This merges Libav commit 3e265ca. It was previously skipped.
There are some changes with how/when the mux_timebase field is set,
because the Libav approach often causes a too imprecise time base
to be set. This is hard, because the muxer's write_header function
can readjust the timebase, at which point we might already have
encoded packets buffered. (It might be better to buffer them after
the encoder, instead of after all the timestamp handling logic
before muxing.)
The two FATE tests change because the output time base is raised
for subtitles. (Needed to avoid certain rounding issues in other
cases.)
Includes a minor merge fix by Mark Thompson, and
avconv: Move rescale to stream timebase before monotonisation
also by Mark Thompson <sw@jkqxz.net>.
Signed-off-by: wm4 <nfxjfg@googlemail.com>
This should fix the fate failure due to a truncated last frame.
Alternatively the frame could be dropped.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes: 664/clusterfuzz-testcase-4917047475568640
The change to fate is due to a truncated last frames which is now detected as damaged.
Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
According to the spec[1], a value of 0 means the footer is present and a value
of 1 means it's absent, the exact opposite of header presence flag where 1
means present and 0 absent.
The reason for this is compatibility with APEv1 tags, where there's no header,
footer presence was mandatory for all files, and the flags field was a zeroed
reserved field.
[1] http://wiki.hydrogenaud.io/index.php?title=Ape_Tags_Flags
Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Current code returned the number of channels as channel layout in that case,
and if nret is not set then unknown layouts are typically not supported.
Also use the common parsing code. Use a temporary workaround to parse an
unknown channel layout such as '13c', after a 1 year grace period only '13C'
will work.
Signed-off-by: Marton Balint <cus@passwd.hu>
* commit '38efff92f1ef81f3de20ff0460ec7b70c253d714':
FATE: add a test for H.264 with two fields per packet
h264: fix decoding multiple fields per packet with slice threads
This merge includes two commits because the FATE test was useful in
order to make proper testing.
The merge gets rid of the now unused:
- SLICE_SINGLETHREAD and SLICE_SKIPED macros
- max_contexts
- "again" label in decode_nal_units()
This commit also includes the fix from d3e4d406b.
Thanks to wm4 and Michael Niedermayer for their testing.
Merged-by: Clément Bœsch <u@pkh.me>
Merged-by: Matthieu Bouron <matthieu.bouron@gmail.com>
This would be simpler if codecpar supported AVOptions
modern ffserver should be unaffected by this, older ffserver which required the
muxer to directly access the encoder could have issues with this, but this
direct access is just wrong and unsafe
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This accesses the private encoder context, it should not be used by
the current ffserver it may affect old ffserver versions but i believe
there is consens that accessing the private encoder context from the muxer
is completely wrong.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This reverts commit e0c6b32046.
Said commit changed the behavior of the demuxer and decoder in a non
backwards compatible way.
Demuxers should make extradata available at init if possible, and send
new extradata as side data within a packet if needed.
A better fix for the remuxing crash will follow.
Signed-off-by: James Almer <jamrial@gmail.com>
* commit '8d07e941b04d63fc4443dd986e3dc7b69cdcca43':
FATE: add a test of H.264 SEI recovery in an intra refresh stream
Our H264 decoder drops 3 frames from the beginning of the stream, but
all frames after those match, hence the difference in the fate test.
Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>
The test is not supposed to cover audio.
Also, using -vframes along with an audio stream depends on
the exact order the frames are processed by filters, it is
too much constraint to guarantee.
Add keyframe index metadata
Used to facilitate seeking; particularly for HTTP pseudo streaming.
1. read live streaming or file by sequence
2. if use add_keyframe_index option, add a mark flag at the position,
use to insert new context at the last step.
3. add the keyframes *offset* and *timestamp* into a list
4. if use add_keyframe_index option, shift the metadata data from
mark flag offset
5. insert the keyframes *offset* and *timestamp* from the list by
sequence
6. free the list
7. end.
Add FATE test case;
Reviewed-by: Lou Logan <lou@lrcd.com>
Signed-off-by: Steven Liu <liuqi@gosun.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This should be more useful for users since numerical values for channel
layout can be confusing and unintuitive.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This matrix needs to be applied after all others have (currently only
display matrix from trak), but cannot be handled in movie box, since
streams are not allocated yet. So store it in main context, and apply
it when appropriate, that is after parsing the tkhd one.
Fate tests are updated accordingly.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>
Also test the fallback to png creation for a single frame.
Reviewed-by: James Almer <jamrial@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
The dynamic buffer does not contain the CRC32 element so calls to avio_tell()
don't take it into account. This resulted in CueRelativePosition values being
six bytes short.
This is a regression since 6724525a15
Instead of adding yet another custom check for CRC32 to fix a size or an offset,
remove the existing ones and reserve the six bytes in the dynamic buffer.
Signed-off-by: James Almer <jamrial@gmail.com>
Current code doesn't initialize AVPacket::pos. Made it point to FLVTAG so flv_read_packet can decode from pos
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This also fixes a minor bug introduced in the codecpar conversion, where
the termination condition for extracting the extradata does not match
the actual extradata setting code. As a result, the packet durations
made up by lavf go back to their values before the codecpar conversion.
That is of little consequence since that code should eventually be
dropped completely.
We don't currently support values 1 (centimeters), 2 (inches) or 3 (DAR),
only the default value 0 (pixels) which doesn't need to be written.
The fate refs are updated as unknown SAR is now signaled in the output
files with the addition of the new element.
Reviewed-by: Carl Eugen Hoyos <ceffmpeg@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>
Attachment tags were being written targeting non-existent streams in the
output file.
Also filter filename and mimetype entries, as they are standard elements
in the Attachment master.
Signed-off-by: James Almer <jamrial@gmail.com>
Using the stream timebase simply overflows
Fix integer overflow in psp framerate computation
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
Implements part of ticket #4347
Tested-by: Dave Rice <dave@dericed.com>
Tested-by: Jerome Martinez <jerome@mediaarea.net>
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
The durations are never written in that situation.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
This is a bit messy, mainly due to timestamp handling.
decode_video() relied on the fact that it could set dts on a flush/drain
packet. This is not possible with the old API, and won't be. (I think
doing this was very questionable with the old API. Flush packets should
not contain any information; they just cause a FIFO to be emptied.) This
is replaced with checking the best_effort_timestamp for AV_NOPTS_VALUE,
and using the suggested DTS in the drain case.
The modified tests (fate-cavs and others) still fails due to dropping
the last frame. This happens because the timestamp of the last frame
goes backwards (ffprobe -show_frames shows the same thing). I suspect
that this "worked" due to the best effort timestamp logic picking the
DTS over the decreasing PTS. Since this logic is in libavcodec (where
it probably shouldn't be), this can't be easily fixed. The timestamps
of the cavs samples are weird anyway, so I chose not to fix it.
Another strange thing is the timestamp handling in the video path of
process_input_packet (after the decode_video() call). It looks like
the code to increase next_dts and next_pts should be run every time
a frame is decoded - but it's needed even if output is skipped.
Fixes gapless decoding. Adjust skip_samples field correctly in case of DISCARDed audio frames.
Signed-off-by: Sasi Inguva <isasi@google.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
This commit is initially largely based on commit 4426540 from Anton
Khirnov <anton@khirnov.net> and two following fixes (80fb19b and
fe7b21c) which were previously skipped respectively in 98e3153, c9ee36e,
and 7fe7cdc.
mpeg4-bsf-unpack-bframes FATE reference is updated because the bsf
filter now actually fixes the extradata (mpeg4_unpack_bframes_init()
changing one byte is now honored on the output extradata).
The FATE references for remove_extra change because the packet flags
were wrong and the keyframes weren't marked, causing the bsf relying on
these proprieties to not actually work as intended.
The following was fixed by James Almer:
The filter option arguments are now also parsed correctly.
A hack to propagate extradata changed by bitstream filters after the
first av_bsf_receive_packet() call is added to maintain the current
behavior. This was previously done by av_bitstream_filter_filter() and
is needed for the aac_adtstoasc bsf.
The exit_on_error was not being checked anymore, and led to an exit
error in the last frame of h264_mp4toannexb test. Restoring this
behaviour prevents erroring out. The test is still changed as a result
due to the badly filtered frame now not being written after the failure.
Signed-off-by: Clément Bœsch <u@pkh.me>
Signed-off-by: James Almer <jamrial@gmail.com>
This commit is largely based on commit 15e84ed3 from Anton Khirnov
<anton@khirnov.net> which was previously skipped in bbf5ef9d.
There are still a bunch of things raising codecpar related warnings that
need fixing, such as:
- the use of codec->debug in the interactive debug mode
- read_ffserver_streams(): it's probably broken now but there is no test
- lowres stuff
- codec copy apparently required by bitstream filters
The matroska references are updated because they now properly forward
the field_order (previously unknown, now progressive).
Thanks to James Almer for fixing a bunch of FATE issues in this commit.
Signed-off-by: Clément Bœsch <clement@stupeflix.com>
Signed-off-by: James Almer <jamrial@gmail.com>
add tests/ref/fate/filter-hls-append for FATE
add hls-list-append fate use filter make audio data and test hls_flags
append options
Signed-off-by: Steven Liu <lingjiujianke@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Fixes regressions with stream copy and output timebase/fps being twice as fine as needed
Makes the timebase and ticks per frame handled identical which should make the
code easier to understand and work with. It does not solve the problem without
st->codec access
Suggested-by: Hendrik Leppkes
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
Allows testing simple_idct12 correctness/bitexactness, as the sample
was generated using faani as idct.
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
As Nvidia has put the most recent Video Codec SDK behind a double
registration wall, of which one needs manual approval of a lenghty
application, bundling this header saves everyone trying to use NVENC
from that headache.
The header is still MIT licensed and thus fine to bundle with ffmpeg.
Not bundling this header would get ffmpeg stuck at SDK v6, which is
still freely available, holding back future development of the NVENC
encoder.
If this still doesnt give the same results on all platforms then this should be
disabled
Found-by: James Almer <jamrial@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
