Missed in 487b49d8.

Signed-off-by: James Almer <jamrial@gmail.com>
(cherry picked from commit aa0829d8)

Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit fb4da90f)

This disallows the usage of ? and # in libavformat specific scheme options
(e.g. subfile,,start,32815239,end,0,,:video.ts) but this change was considered
acceptable.

Signed-off-by: ruiquan.crq <caihaoning83@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>
(cherry picked from commit ae9a1a96)

Also add and update some tests.

Change the semantic a little, because for filesytem paths
symlinks complicate things.
See the comments in the code for detail.

Fix trac tickets #8813 and 8814.

(cherry picked from commit 1201687d)

(cherry picked from commit d8532936)

This causes regressions in end to end timestamps with mp3s and ffmpeg.
The revert is to avoid this regression in the 4.3 release

See: [FFmpeg-devel] [PATCH] Don't adjust start time for MP3 files; packets are not adjusted.

This reverts commit 460132c9.

Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

7546ac2f made it so that the start_time for mp3 files is
adjusted for skip_samples. However, this appears incorrect because
subsequent packet timestamps are not adjusted and skip_samples are
applied by deleting data from a packet without changing the timestamp.

E.g., we are told the start_time is ~25ms and we get a packet with a
timestamp of 0 that has had the skip_samples discarded from it. As such
rendering engines may incorrectly discard everything prior to the
25ms thinking that is where playback should officially start. Since the
samples were deleted without adjusting timestamps though, the true
start_time is still 0.

Other formats like MP4 with edit lists will adjust both the start
time and the timestamps of subsequent packets to avoid this issue.

Signed-off-by: Dale Curtis <dalecurtis@chromium.org>
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

single:               Single-track
track{0,1}:           Dual-track
trunc-t1:             Truncated track 1
trunc-t2-track{0,1}:  Fully-truncated track 2
trunc-t2a-track{0,1}: Partially-truncated track 2
trunc-h2:             Truncated track 2 header

Signed-off-by: Zane van Iperen <zane@zanevaniperen.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

changes since v1
- default behavior, no longer hidden behind decoder parameter
- updated tests to reflect change

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Also fixes colorhold filtering.

The Matroska muxer writes the Chapters early when chapters were already
available when writing the header; in this case any tags pertaining to
these chapters get written, too.

Yet if no chapters had been supplied before writing the header, Chapters
can also be written when writing the trailer if any are supplied. Tags
belonging to these chapters were up until now completely ignored.

This commit changes this: Writing the tags belonging to chapters has
been moved to mkv_write_chapters(). If mkv_write_tags() has not been
called yet (i.e. when chapters are written when writing the header),
the AVIOContext for writing the ordinary Tags element is used, but not
output, as this is left to mkv_write_tags() in order to only write one
Tags element. Yet if mkv_write_tags() has already been called,
mkv_write_chapters() will output a Tags element of its own which only
contains the tags for chapters.

When chapters are available initially, the corresponding tags will now
be the first tags in the Tags element; but the ordering of tags in Tags
is irrelevant anyway.

This commit also makes chapter_id_offset local to mkv_write_chapters()
as it is used only there and not reused at all.

Potentially writing a second Tags element means that the maximum number
of SeekHead entries had to be incremented. All the changes to FATE
result from the ensuing increase in the amount of space reserved for the
SeekHead (21 bytes more).

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

We won't be able to seek back to write the actual duration anyway.

FATE-tests using the md5pipe command had to be updated due to this change.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

have tested on linux x86_32/64, mingw32/64 arm & mips qemu

Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Tested on x86-32/64, mingw32/64, arm & mips qemu

Tested-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

Signed-off-by: Limin Wang <lance.lmwang@gmail.com>

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>

fix ticket: 8625
and add testcase into url for double dot corner case

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: vectronic <hello.vectronic@gmail.com>
Signed-off-by: Marton Balint <cus@passwd.hu>

Failure was due to the extra comment printed by libavcodec/utils.c since
side data is used to signal the skipped samples.

Up until now, the Matroska muxer would mark a track as default if it had
the disposition AV_DISPOSITION_DEFAULT or if there was no track with
AV_DISPOSITION_DEFAULT set; in the latter case even more than one track
of a kind (audio, video, subtitles) was marked as default which is not
sensible.

This commit changes the logic used to mark tracks as default. There are
now three modes for this:
a) In the "infer" mode the first track of every type (audio, video,
subtitles) with default disposition set will be marked as default; if
there is no such track (for a given type), then the first track of this
type (if existing) will be marked as default. This behaviour is inspired
by mkvmerge. It ensures that the default flags will be set in a sensible
way even if the input comes from containers that lack the concept of
default flags. This mode is the default mode.
b) The "infer_no_subs" mode is similar to the "infer" mode; the
difference is that if no subtitle track with default disposition exists,
no subtitle track will be marked as default at all.
c) The "passthrough" mode: Here the track will be marked as default if
and only the corresponding input stream had disposition default.

This fixes ticket #8173 (the passthrough mode is ideal for this) as
well as ticket #8416 (the "infer_no_subs" mode leads to the desired
output).

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Several EBML Master elements for which a good upper bound of the final
length was available were nevertheless written without giving an
upper bound of the final length to start_ebml_master(), so that their
length fields were eight bytes long. This has been changed.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

The Matroska muxer currently only adds CuePoints in three cases:
a) For video keyframes. b) For the first audio frame in a new Cluster if
in DASH-mode. c) For subtitles. This means that ordinary Matroska audio
files won't have any Cues which impedes seeking.

This commit changes this. For every track in a file without video track
it is checked and tracked whether a Cue entry has already been added
for said track for the current Cluster. This is used to add a Cue entry
for each first packet of each track in each Cluster.

Implements #3149.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Moreover, putting the Cues in front of the Clusters by reserving space
in advance is also tested.

The new capability of using ffprobe during a remux/transcode test are
used here for information about the chapters.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Michael Bradshaw <mjbshaw@google.com>

Commit 9842fd3a stopped guessing colr
values.

Signed-off-by: Michael Bradshaw <mjbshaw@google.com>

Using random values for TrackUID and FileUID (as happens when the
AVFMT_FLAG_BITEXACT flag is not set) has the obvious downside of making
the output indeterministic. This commit mitigates this by writing the
potentially random values with a fixed size of eight byte, even if their
actual values would fit into less than eight bytes. This ensures that
even in non-bitexact mode, the differences between two files generated
with the same settings are restricted to a few bytes in the header.
(Namely the SegmentUID, the TrackUIDs (in Tracks as well as when
referencing them via TagTrackUID), the FileUIDs (in Attachments as
well as in TagAttachmentUID) as well as the CRC-32 checksums of the
Info, Tracks, Attachments and Tags level-1-elements.) Without this
patch, there might be an offset/a size difference between two such
files.

The FATE-tests had to be updated because the fixed-sized UIDs are also
used in bitexact mode.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

If there are Attachments to write, the Matroska muxer currently
allocates two objects: An array that contains an entry for each
AttachedFile containing just the stream index of the corresponding
stream and the FileUID used for this AttachedFile; and a structure with
a pointer to said array and a counter for said array. These uids are
generated via code special to Attachments: It uses an AVLFG in the
normal and a sha of the attachment data in the bitexact case. (Said sha
requires an allocation, too.)

But now that an uid is generated for each stream in mkv_init(), there is
no need any more to use special code for generating the FileUIDs of
AttachedFiles: One can simply use the uid already generated for the
corresponding stream. And this makes the whole allocations of the
structures for AttachedFiles as well as the structures itself superfluous.
They have been removed.

In case AVFMT_FLAG_BITEXACT is set, the uids will be different from the
old ones which is the reason why the FATE-test lavf-mkv_attachment
needed to be updated. The old method had the drawback that two
AttachedFiles with the same data would have the same FileUID.
The new one doesn't.

Also notice that the dynamic buffer used to write the Attachments leaks
if an error happens when writing the buffer. By removing the
allocations potential sources of errors have been removed.

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Tags in the Matroska file format can be summarized as follows: There is
a level 1-element called Tags containing one or many Tag elements each
of which in turn contain a Targets element and one or many SimpleTags.
Each SimpleTag roughly corresponds to a single key-value pair similar to
an AVDictionaryEntry. The Targets meanwhile contains information to what
the metadata contained in the SimpleTags contained in the containing Tag
applies (i.e. to the file as a whole or to an individual track).

The Matroska muxer writes such metadata. It puts the metadata of every
stream into a Tag whose Targets makes it point to the corresponding
track. And if the output is seekable, then it also adds another Tag for
each track whose Targets corresponds to the track and where it reserves
space in a SimpleTag to write the duration at the end of the muxing
process into.

Yet there is no reason to write two Tag elements for a track and a few
bytes (typically 24 bytes per track) can be saved by adding the duration
SimpleTag to the other Tag of the same track (if it exists).

FATE has been updated because the output files changed. (Tests that
write to unseekable output (pipes) needn't be updated (no duration tag
has ever been written for them) and the same applies to tests without
further metadata.)

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@gmail.com>

Signed-off-by: Philip Langdale <philipl@overt.org>

It represents the relationship between them more naturally and will be
useful in the following commits.

Allows significantly more frames in fate-h264-attachment-631 to be
decoded.