| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We have test to make sure that certain configurations do print
warnings. However, the normal operation of the muxer within this
test always printed a warning, so those tests to check for
extra warnings didn't essentially guard anything.
The warning that always was printed, "track 1: codec frame size is
not set" was not present in the libav fork where this testcase
originated, it was removed in f234e8a32e6c69d7b63f8627f278be7c2c987f43.
Set the frame size for the audio stream to silence the warning,
and use this frame size in a couple later calculations, and check
that one test configuration doesn't print warnings.
Setting the frame size apparently changes the rounding of a timestamp
in the ismv muxing testcase.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is based on a spec at https://aomediacodec.github.io/id3-emsg/,
further based on ISO/IEC 23009-1:2019.
Within libavformat, timed ID3 metadata (already supported by the
mpegts demuxer and muxer) is handled as a separate data AVStream
with codec type AV_CODEC_ID_TIMED_ID3. However, it doesn't
have a corresponding track in the mov file - instead, these events
are written as separate toplevel 'emsg' boxes.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
| |
Fix #8334
Signed-off-by: Zhao Zhili <zhilizhao@tencent.com>
|
|
|
|
|
|
|
| |
mvhd and tkhd present the post-editlist duration, while mdhd should
have the pre-editlist duration. Regression since c2424b1f3.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch will make audio and subtitle packets be marked as AV_PKT_FLAG_KEY.
For audio, it'll caused the audio sample to be sync sample.
To verify ref/fate/movenc results:
1. Get the movenc test data
[lmwang@vpn ffmpeg]$ libavformat/tests/movenc -w && mkdir -p audio_old && mv *.mp4 audio_old_
After applied the patch:
[lmwang@vpn ffmpeg]$ make fate-movenc SAMPLES=../fate-suite
[lmwang@vpn ffmpeg]$ libavformat/tests/movenc -w && mkdir -p audio_key && mv *.mp4 audio_key
2. Get l-smash and build boxdumper
https://github.com/l-smash/l-smash.git
3. dump the box of crc change mp4 and diff -u
[lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box audio_key/non-empty-moov-no-elst.mp4 > audio_key/non-empty-moov-no-elst.log
[lmwang@vpn ffmpeg]$ ../l-smash/cli/boxdumper --box audio_old/non-empty-moov-no-elst.mp4 > audio_old/non-empty-moov-no-elst.log
[lmwang@vpn ffmpeg]$ diff -u audio_key/non-empty-moov-no-elst.log audio_old/non-empty-moov-no-elst.log
- default_sample_flags = 0x02000000
- independent
- sync sample
+ default_sample_flags = 0x01010000
+ dependent
+ non-sync sample
4. have checked the change of crc are caused by default_sample_flags
non-empty-moov.mp4, non-empty-moov-elst.mp4,
non-empty-moov-no-elst.mp4, empty-moov.mp4, delay-moov-content.mp4,
empty-moov-second-frag.mp4, empty-moov-second-frag-discont.mp4,
delay-moov-second-frag-discont.mp4, delay-moov-elst-second-frag.mp4
etc
5 For subtitle, it'll effect for tests/ref/fate/binsub-movtextenc and
tests/ref/fate/sub2video, that's expecting result for the subtitle is
marked as keyframe. Below is the checking result of binsub-movtextenc:
[lmwang@vpn ffmpeg]$ ./ffmpeg -i ../fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov audio_key/binsub-movtextenc.mp4
[lmwang@vpn ffmpeg]$ ./ffmpeg -i ../fate-suite/sub/MovText_capability_tester.mp4 -map 0 -scodec mov_text -f mp4 -flags +bitexact -fflags +bitexact -movflags frag_keyframe+empty_moov audio_old/binsub-movtextenc.mp4
[lmwang@vpn ffmpeg]$../l-smash/cli/boxdumper audio_key/binsub-movtextenc.mp4 > audio_key/binsub-movtextenc.log
[lmwang@vpn ffmpeg]$../l-smash/cli/boxdumper audio_old/binsub-movtextenc.mp4 > audio_old/binsub-movtextenc.log
[lmwang@vpn ffmpeg]$ diff -u audio_key/binsub-movtextenc.log audio_old/binsub-movtextenc.log
.... // the key difference is the flag for sync sample
- flags = 0x000701
+ flags = 0x000301
data-offset-present
sample-duration-present
sample-size-present
- sample-flags-present
sample_count = 6
- data_offset = 188
+ data_offset = 164
sample[0]
sample_duration = 1570000
sample_size = 21
- sample_flags = 0x02000000
- independent
- sync sample
- degradation_priority = 0
sample[1]
sample_duration = 510000
sample_size = 2
- sample_flags = 0x01010000
- dependent
- non-sync sample
- degradation_priority = 0
sample[2]
sample_duration = 1690000
sample_size = 9
- sample_flags = 0x02000000
- independent
- sync sample
- degradation_priority = 0
Suggested-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
Suggested-by: Nicolas George <george@nsup.org>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>
|
|
|
|
|
|
|
| |
Sets some required constrains and reports compatability with the relevant
compatible brand.
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
| |
trun boxes
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
| |
more than once
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
| |
Signed-off-by: James Almer <jamrial@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Signed-off-by: Martin Storsjö <martin@martin.st>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
|
|
|
|
| |
According to https://developer.apple.com/library/content/documentation/QuickTime/QTFF/QTFFAppenG/QTFFAppenG.html and ISO-IEC-14496-12 Section 10.1.1.1 and 10.1.1.3
Signed-off-by: Sasi Inguva <isasi@google.com>
Reviewed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|
|
|
| |
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|\
| |
| |
| |
| |
| |
| | |
* commit 'a79aafd0b4d37eda6f15dc68e6509d4e815290c9':
movenc: Add a test for VFR with b-frames, with a duration change at a fragment end
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
|
| |
| |
| |
| |
| |
| | |
fragment end
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit 'fd4957d9c67996e7d218fd36b4168c9cb85f9ea7':
movenc-test: Test write_data_type
Merged-by: Matthieu Bouron <matthieu.bouron@stupeflix.com>
|
| |
| |
| |
| | |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|\|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
* commit '9200514ad8717c63f82101dc394f4378854325bf':
lavf: replace AVStream.codec with AVStream.codecpar
This has been a HUGE effort from:
- Derek Buitenhuis <derek.buitenhuis@gmail.com>
- Hendrik Leppkes <h.leppkes@gmail.com>
- wm4 <nfxjfg@googlemail.com>
- Clément Bœsch <clement@stupeflix.com>
- James Almer <jamrial@gmail.com>
- Michael Niedermayer <michael@niedermayer.cc>
- Rostislav Pehlivanov <atomnuker@gmail.com>
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, AVStream contains an embedded AVCodecContext instance, which
is used by demuxers to export stream parameters to the caller and by
muxers to receive stream parameters from the caller. It is also used
internally as the codec context that is passed to parsers.
In addition, it is also widely used by the callers as the decoding (when
demuxer) or encoding (when muxing) context, though this has been
officially discouraged since Libav 11.
There are multiple important problems with this approach:
- the fields in AVCodecContext are in general one of
* stream parameters
* codec options
* codec state
However, it's not clear which ones are which. It is consequently
unclear which fields are a demuxer allowed to set or a muxer allowed to
read. This leads to erratic behaviour depending on whether decoding or
encoding is being performed or not (and whether it uses the AVStream
embedded codec context).
- various synchronization issues arising from the fact that the same
context is used by several different APIs (muxers/demuxers,
parsers, bitstream filters and encoders/decoders) simultaneously, with
there being no clear rules for who can modify what and the different
processes being typically delayed with respect to each other.
- avformat_find_stream_info() making it necessary to support opening
and closing a single codec context multiple times, thus
complicating the semantics of freeing various allocated objects in the
codec context.
Those problems are resolved by replacing the AVStream embedded codec
context with a newly added AVCodecParameters instance, which stores only
the stream parameters exported by the demuxers or read by the muxers.
|
| |
| |
| |
| | |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
| |
| |
| | |
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '1d62ee38894afb696674db78cee8f8d89204a8fe':
movenc: Add a unit test for signaling of the track start times
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
| |
| |
| | |
Signed-off-by: Martin Storsjö <martin@martin.st>
|
| |
| |
| |
| |
| |
| |
| | |
This way, it never starts with 0xFFF0, and never trips the
ADTS "Detection" code in movenc.c.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|\|
| |
| |
| |
| |
| |
| | |
* commit '3eeb7edfc2a1157b7b0e0ce21ac2cd44d55d405b':
movenc: Add a unit test for frag_discont with edit lists
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
| |
| |
| |
| |
| |
| |
| | |
This tests the case where the muxer correctly guesses that a stream
starts at pts=0.
Signed-off-by: Martin Storsjö <martin@martin.st>
|
|/
|
|
|
|
|
|
|
| |
All diferences in unit tests have been acounted for.
* commit '59e8ec0aa8ab174701d01a3bfe96fedd0b7fcead':
movenc: Add an API unit test for fragmenting options/calls
Merged-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
|
|
Contrary to the normal fate tests that run via avconv, this tests
nontrivial call sequences that are only doable via the API
(mainly for different corner cases when using the muxer for
segmenting).
The test muxes fake packet data (with extradata that looks
enough like proper data to make the file be viewable with e.g.
boxdumper) and checks the hash of the produced files. The test also
verifies that fragments produced via different call sequences remain
identical (to avoid e.g. updating the output hashes and suddenly
having fragments that used to be identical suddenly diverging), for
fragments written with frag_discont and/or delay_moov.
Signed-off-by: Martin Storsjö <martin@martin.st>
|