- Apr 08, 2022
-
-
James Almer authored
Missed in 487b49d8. Signed-off-by:
James Almer <jamrial@gmail.com> (cherry picked from commit aa0829d8)
-
- Apr 08, 2021
-
-
Marton Balint authored
Signed-off-by:
Marton Balint <cus@passwd.hu> (cherry picked from commit fb4da90f)
-
- Oct 28, 2020
-
-
ruiquan.crq authored
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)
-
- Sep 08, 2020
-
-
Nicolas George authored
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)
-
Nicolas George authored
(cherry picked from commit d8532936)
-
- Jun 08, 2020
-
-
Michael Niedermayer authored
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.
-
- Jun 01, 2020
-
-
Zane van Iperen authored
Signed-off-by:
Zane van Iperen <zane@zanevaniperen.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- May 27, 2020
-
-
Dale Curtis authored
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>
-
- May 25, 2020
-
-
Anton Khirnov authored
-
- May 23, 2020
-
-
Nicolas George authored
-
- May 22, 2020
-
-
Oneric authored
Reviewed-by:
Paul B Mahol <onemda@gmail.com> Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- May 20, 2020
-
-
Zane van Iperen authored
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>
-
Mark Reid authored
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>
-
- May 19, 2020
-
-
Paul B Mahol authored
Also fixes colorhold filtering.
-
Andreas Rheinhardt authored
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>
-
- May 18, 2020
-
-
Andreas Rheinhardt authored
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>
-
- May 14, 2020
-
-
Limin Wang authored
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>
-
Limin Wang authored
Reviewed-by:
Paul B Mahol <onemda@gmail.com> Signed-off-by:
Limin Wang <lance.lmwang@gmail.com>
-
Limin Wang authored
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>
-
- May 11, 2020
-
-
Michael Niedermayer authored
-
Michael Niedermayer authored
-
- May 10, 2020
-
-
Limin Wang authored
Signed-off-by:
Limin Wang <lance.lmwang@gmail.com>
-
- May 06, 2020
-
-
Limin Wang authored
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>
-
Steven Liu authored
fix ticket: 8625 and add testcase into url for double dot corner case Signed-off-by:
Steven Liu <lq@chinaffmpeg.org>
-
- May 05, 2020
-
-
Mark Reid authored
Signed-off-by:
Michael Niedermayer <michael@niedermayer.cc>
-
- May 02, 2020
-
-
vectronic authored
Signed-off-by:
vectronic <hello.vectronic@gmail.com> Signed-off-by:
Marton Balint <cus@passwd.hu>
-
- May 01, 2020
-
-
Lynne authored
Failure was due to the extra comment printed by libavcodec/utils.c since side data is used to signal the skipped samples.
-
- Apr 21, 2020
-
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
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>
-
- Apr 20, 2020
-
-
Andreas Rheinhardt authored
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>
-
James Almer authored
Signed-off-by:
James Almer <jamrial@gmail.com>
-
- Apr 18, 2020
-
-
Andreas Rheinhardt authored
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>
-
- Apr 13, 2020
-
-
Michael Bradshaw authored
Signed-off-by:
Michael Bradshaw <mjbshaw@google.com>
-
Michael Bradshaw authored
Commit 9842fd3a stopped guessing colr values. Signed-off-by:
Michael Bradshaw <mjbshaw@google.com>
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
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>
-
Andreas Rheinhardt authored
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>
-
- Apr 10, 2020
-
-
John Stebbins authored
Signed-off-by:
Philip Langdale <philipl@overt.org>
-
Anton Khirnov authored
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.
-
- Apr 04, 2020
-
-
Stephen Hutchinson authored
-