One that is fine enough to represent all DV audio sample rates. Audio
packet durations are now sample-accurate.
This largely undoes commit 76fbb0052df471075858c1cb82b04c8be7adba8d. To
avoid breaking the issue fixed by that commit, resync audio timestamps
against video if they get more than one frame apart. The sample from
issue #8762 still works correctly after this commit.
Slightly changes the results of the lavf-dv seektest, due to the audio
timebase being more granular.
Current code will call avpriv_set_pts_info() for each video frame,
possibly setting a different timebase if the stream framerate changes.
This violates API conventions, as the timebase is supposed to stay
constant after stream creation.
Change the demuxer to set a single timebase that is fine enough to
handle all supported DV framerates.
The seek tests change slightly because the new timebase is more
granular.
This was a bug/mistake in dae3679a9bfa421829ef9049ae2167089a2fdef7.
use_mfra_for by defintion only has an effect on fragmented MP4 files,
making the check not only redundant, but also broken if a user used
the option globally (i.e. set on non-fragmented MP4s).
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Also make duration check for mvhd more consistent with the others, write
version 1 of mvhd if duration is at least INT32_MAX instead of UINT32_MAX.
Signed-off-by: Marton Balint <cus@passwd.hu>
Commit 23eeffcd48a15e73fb2649b712870b6d101c5471 added a hack to support invalid
files where the creation date was encoded as a classic unix timestamp. Let's
reduce the scope of the hack by only applying it to version 0 mdhd/mvhd atoms.
Also warn the user of such possibly broken files.
Signed-off-by: Marton Balint <cus@passwd.hu>
When write multi-trun box, the MOV_TRUN_FIRST_SAMPLE_FLAGS flag
need judge by first param, not 0.
If the original video contains consecutive I frames,
this will cause the packets of fmp4 have error sample_flags ,
and then incorrect keyframes were generated,
and then error packet will be seeked.
Signed-off-by: Wang Yaqiang <wangyaqiang03@kuaishou.com>
Signed-off-by: Steven Liu <liuqi05@chinaffmpeg.org>
Changes the result of the h264_redundant_pps-mov test, where the output
timebase is now 1001/24000 instead of 1/24. This is more correct, as the
source file actually is 23.98fps.
Timestamps in two FATE H.264 conformance tests now start at 1 instead
of 0, which also happens in some other H.264 tests before this commit
and so is not a big issue.
Conversely, timestamps in some HEVC conformance tests start from a
smaller value now.
Ideally this should be addressed later in a more general way.
h264-conformance-frext-frext2_panasonic_b no longer requires -vsync
passthrough.
Partially reverts a change from 88de01d878167cbff9af32c0b7366e0aae3db2bd, and
2133cadfcf9a613cf2c0060f9896bba49dabfba4.
Signed-off-by: James Almer <jamrial@gmail.com>
The Matroska spec requires it to be equal to the highest BlockAddID value in a
BlockAdditions, but being purely an informative element, only abort if strict
compliance is requested, as demuxing is otherwise unaffected.
Signed-off-by: James Almer <jamrial@gmail.com>
RIP, if exists is the last KLV item in the MXF files therefore we can stop
parsing the file if it is encountered. This allows us to support files created by
broken muxers such as OpenCube MXFTk Advanced 2.8.0.0.1. which dumps some extra
garbage after the RIP.
Signed-off-by: Marton Balint <cus@passwd.hu>
Current log messages talk about 'suitable' output formats. This is
confusing, because it suggests that some formats are suitable, while
others are not, which is not the case.
Also, suggest possible user actions when format cannot be guessed from a
filename.
An uninitialized AVFormatContext instance with neither iformat nor
oformat set will currently log as 'NULL', which is confusing and
unhelpful. Print 'AVFormatContext' instead, which provides more
information.
This happens e.g. if choosing an output format fails in
avformat_alloc_output_context2().
E.g. with the following commandline:
ffmpeg -i <input> -f foobar -y /dev/null
before: [NULL @ 0x5580377834c0] Requested output format 'foobar' is not a suitable output format
after: [AVFormatContext @ 0x55fa15bb34c0] Requested output format 'foobar' is not a suitable output format
3GPP TS 26.244 Table 8.10 specifies that longitude is written before
latitude. The MOV demuxer already expects the correct order. So, write
them in that order.
However, the user supplied string may also be used in MOV mode which
requires ISO 6709 format which specifies latitude first. The demuxer
also exports the loci value in that format. So parser adjusted as well.
When writing a subtitle SSA/ASS subtitle file, the AVCodecParameters::extradata
buffer is written directly to the output. In the case where the buffer is
filled from a matroska source file produced by some older versions of
Handbrake, this buffer ends with a null terminating character, which is then
erroneously copied into the middle of the output file. The change here avoids
this problem by treating it as a string rather than a raw buffer. This way it
is agnostic as to whether the source buffer was null terminated or not.
Fixes ticket #10203.
Reported-by: Tim Angus <tim at ngus.net>
Signed-off-by: Marton Balint <cus@passwd.hu>
Previously, the ff_configure_buffers_for_index function had
upper sanity limits of 16 MB (1<<24) for buffer_size and
8 MB (1<<23) for short_seek_threshold.
However, if the index contained entries with a much larger
delta, setting pos_delta to a value larger than the sanity
limit, we would end up not increasing the buffer size at all.
Instead, ignore the individual deltas that are excessive, but
increase the buffer size based on the deltas that are below the
sanity limit.
Only count deltas that are below 1<<23, 8 MB; pos_delta gets doubled
before setting the buffer size - this matches the previous maximum
buffer size of 1<<24, 16 MB.
This can happen e.g. with a mov file with some tracks containing
some samples that belong in the start of the file, at the end of
the mdat, while the rest of the file is mostly reasonably interleaved;
previously those samples caused the maximum pos_delta to skyrocket,
skipping any buffer size enlargement.
Signed-off-by: Martin Storsjö <martin@martin.st>
When scanning through the index, account for the fact that the
compared samples may be located in an unexpected order in the file;
this function is mainly interested in the absolute difference between
file locations.
Signed-off-by: Martin Storsjö <martin@martin.st>
Some additional properties are set for ARIB caption.
* need_parsing = 0
ARIB caption doesn't require any parser.
This avoids "parser not found" warning message.
* need_context_update = 1
When any profiles are changed, set this flag to notify.
Signed-off-by: rcombs <rcombs@rcombs.me>
According to MXF specs the Stored Rectangle corresponds to the data which is
passed to the compressor and received from the decompressor, so they should
contain the width / height extended to the macroblock boundary.
In practice however width and height values rounded to the upper 16 multiples
are only seen when muxing MPEG formats. Therefore this patch changes stored
width and height values to unrounded for all non-MPEG formats, even macroblock
based ones.
For DNXHD the specs (ST 2019-4) explicitly indicates to use 1080 for 1088p.
For ProRes the specs (RDD 44) only refer to to ST 377-1 without precision but
no known commercial implementations are using rounded values.
DV is not using 16x16 macroblocks, so 16 rounding makes no sense.
The patch also fixes Sampled Width / Display Width to use unrounded values.
Signed-off-by: Marton Balint <cus@passwd.hu>
Add the appropriate descriptors to the MPEG-TS demux and mux to
ensure that SMPTE 2038 VANC streams are properly preserved
when using codec copy (including adding the appropriate PMT
descriptors).
The focus of this patch is TS input to TS output. A separate
patch adds support for output of 2038 VANC over decklink SDI.
Thanks to Marton Balint for feedback to preserve ABI compatibility.
Signed-off-by: Devin Heitmueller <dheitmueller@ltnglobal.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
