Commit Graph

13 Commits

Author SHA1 Message Date
Anton Khirnov 9543161800 framehash: convert to new channel layout API
Signed-off-by: James Almer <jamrial@gmail.com>
2022-03-15 09:42:32 -03:00
James Almer a42d249c91 avformat/framecrcenc: print basic side data information again
This partially reverts c6ae560a18.

Signed-off-by: James Almer <jamrial@gmail.com>
2021-05-18 10:18:49 -03:00
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
2021-05-09 11:07:20 +02:00
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.
2020-06-08 22:08:37 +02:00
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>
2020-05-27 10:22:17 +02:00
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>
2016-11-05 22:42:22 -03:00
James Almer 33aa8a6221 avformat/framecrc: enable new output
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>
2016-04-13 11:37:14 -03:00
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>
2015-06-24 02:48:37 +02:00
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>
2015-04-22 14:33:02 +02:00
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>
2015-04-20 19:50:58 +02:00
wm4 49d5c24aa1 fate: gapless: test seeking to a specific position
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2015-04-17 18:17:35 +02:00
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>
2015-04-17 13:50:37 +02:00
wm4 8297d87eec fate: add mp3 gapless test
Signed-off-by: Michael Niedermayer <michaelni@gmx.at>
2015-04-16 23:05:47 +02:00