On Mon, 20 Apr 2015 21:25:44 +0200
Michael Niedermayer <michae...@gmx.at> wrote:
> With this the returned timestamp should match the packet instead of
> the requested timestamp, which may lay between packets
>
> Signed-off-by: Michael Niedermayer <michae...@gmx.at>
> ---
> libavformat/mp3dec.c | 6 ++++++
> tests/ref/fate/gapless-mp3-notoc | 2 +-
> 2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> index 06bc1d0..89990ec 100644
> --- a/libavformat/mp3dec.c
> +++ b/libavformat/mp3dec.c
> @@ -489,6 +489,12 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> ret = avio_seek(s->pb, best_pos, SEEK_SET);
> if (ret < 0)
> return ret;
> +
> + if (mp3->is_cbr && ie == &ie1) {
> + int frame_duration = av_rescale(st->duration, 1, mp3->frames);
> + ie1.timestamp = frame_duration * (av_rescale(best_pos -
> s->internal->data_offset, mp3->frames, mp3->header_filesize));
> + }
> +
> ff_update_cur_dts(s, st, ie->timestamp);
> st->skip_samples = ie->timestamp <= 0 ? mp3->start_pad + 528 + 1 : 0;
> return 0;
> diff --git a/tests/ref/fate/gapless-mp3-notoc
> b/tests/ref/fate/gapless-mp3-notoc
> index f52efff..936d0ba 100644
> --- a/tests/ref/fate/gapless-mp3-notoc
> +++ b/tests/ref/fate/gapless-mp3-notoc
> @@ -2,4 +2,4 @@ d5c88cf38416329a052a9b0cb140fb4c
> *tests/data/fate/gapless-mp3-notoc.out-1
> c96c3ae7bd3300fd2f4debac222de5b7
> 3386bc2009b31b7ef39247918cbb02a5 *tests/data/fate/gapless-mp3-notoc.out-2
> c96c3ae7bd3300fd2f4debac222de5b7
> -e82eaed507ce3f7f6199918159e1ddd7 *tests/data/fate/gapless-mp3-notoc.out-3
> +92e37f050ad4fc817730c8af17ee6d1b *tests/data/fate/gapless-mp3-notoc.out-3
I checked myself, and the output looks and sounds potentially good.
(But I'm rather bad at spotting the "gap".) So I'd suggest applying
this.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
