FFmpeg

Commit Graph

Author	SHA1	Message	Date
James Almer	a42d249c91	avformat/framecrcenc: print basic side data information again This partially reverts `c6ae560a18`. Signed-off-by: James Almer <jamrial@gmail.com>	4 years ago
Anton Khirnov	c6ae560a18	lavf/framecrcenc: do not hash side data There are no guarantees that all side data types have the same representation on all platforms. Tests that change output due to this: id3v2-priv-remux, cover-art-mp3-id3v2-remux, gapless-mp3: SKIP_SAMPLES, which is tested by fate-gapless-mp3-side-data matroska-vp8-alpha-remux: MATROSKA_BLOCKADDITIONAL, which is tested by remux itself (side data is written into output) matroska-mastering-display-metadata: MASTERING_DISPLAY_METADATA and CONTENT_LIGHT_LEVEL, which are tested by ffprobe invocation in the same test matroska-spherical-mono-remux: STEREO3D and SPHERICAL, which are tested by ffprobe invocation in the same test segment-mp4-to-ts: MPEGTS_STREAM_ID, which is tested by ts remuxing tests webm-webvtt-remux: WEBVTT_IDENTIFIER/SETTINGS, which is tested by the ffprobe invocation in the same test mxf-d10-user-comments: CPB_PROPERTIES, which is tested by mxf-probe-d10 mov-cover-image: SKIP_SAMPLES, which is tested for mov by mov-aac-2048-priming copy-trac3074: AUDIO_SERVICE_TYPE, which is tested by fate-hls-fmp4_ac3	4 years ago
Michael Niedermayer	49e766aa4c	Revert "lavf/mp3dec: don't adjust start time; packets are not adjusted." 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 `460132c998`.	5 years ago
Dale Curtis	460132c998	lavf/mp3dec: don't adjust start time; packets are not adjusted. `7546ac2fee` 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>	5 years ago
James Almer	e8a39f584a	avformat/framehash: also print channel layout as a string 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>	8 years ago
James Almer	33aa8a6221	avformat/framecrc: enable new output Reviewed-by: Michael Niedermayer <michael@niedermayer.cc> Signed-off-by: James Almer <jamrial@gmail.com>	9 years ago
Michael Niedermayer	89a420b71b	avcodec/mpegaudio_parser: Discard ID3v1 tag at the end Ideally this should be discarded by the demuxer but this is not possible without fully parsing which would be then very similar to this. The current ID3v1 discard code in the demuxer does not work and will be removed in a subsequent commit The discard code could be adjusted if needed to also discard tags at other locations than the end or to limit this possibly to input from the mp3 demuxer or even to move the discarding to the decoder. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>	10 years ago
wm4	c3a73666ad	avformat/mp3dec: allow enabling generic seek mode "-usetoc 2" now invokes the generic seek and indexing mode. This mode skips data until the seek target is reached, and this is exact. It also makes gapless audio actually work if a seek past the start of the file is involved. Change the fate-gapless-mp3 test to use the new mode, and move the old one to fate-gapless-mp3-toc (since the test forces use of the Xing TOC). The new mode has a different result for the seek - this result is actually correct. Signed-off-by: Michael Niedermayer <michaelni@gmx.at>	10 years ago
wm4	1e2e22ec61	fate: gapless: fix mp3 tests Seeking to a negative time did not have the desired effect of seeking to the next valid position (the file start). On the other hand, just "-ss 0" will normally seek to a position higher than 0, because it adds the start time of the file. (The start time is not 0 because the gapless code skips a few samples from the start.) Fix this by using the "-seek_timestamp 1" option, which makes "-ss 0" do what you'd expect it would do. Also put the -ss option at the right place, before -i. This actually makes it seek, instead of something completely else. The ".out-3" test is no different in the -usetoc 0/1 cases, because the seeking is inaccurate (in both cases). Signed-off-by: Michael Niedermayer <michaelni@gmx.at>	10 years ago
wm4	49d5c24aa1	fate: gapless: test seeking to a specific position Signed-off-by: Michael Niedermayer <michaelni@gmx.at>	10 years ago
Michael Niedermayer	8768f8f4b9	avcodec/mpegaudiodec_template: use double to build csa tables Fixes rounding difference between 32bit x86 and 64bit Fixes fate failure with gapless mp3 Signed-off-by: Michael Niedermayer <michaelni@gmx.at>	10 years ago
wm4	8297d87eec	fate: add mp3 gapless test Signed-off-by: Michael Niedermayer <michaelni@gmx.at>	10 years ago

12 Commits (4b54818981d2783af161c2ff670b658afbdda503)