On 9/4/15, Tsung-Hung Wu <tsungh...@chromium.org> wrote: > Hi FFmpeg developers, > > Sorry for the spam. I know you are busy. Please take your time to review > the patch. I don't mean to rush at all. > Since the is my first patch, I just want to make sure I was doing the right > thing. Please kindly let me know if I posted to a wrong mail group or made > the patch wrong. Thank you so much for all your great contributions. > > Best Regards, > Andy >
First do not top post, second you already received review. > > On Tue, Sep 1, 2015 at 11:35 AM, Tsung-Hung Wu <tsungh...@chromium.org> > wrote: > >> Hi FFmpeg developers, >> >> I am trying to solve an issue: seeking a large MP3 file is slow. This >> happens when play Podcast audio, for example >> >> http://podcastdownload.npr.org/anon.npr-podcasts/podcast/344098539/430765119/npr_430765119.mp3 >> It works not so good in less computing power mobile devices, especially >> under slow network environment. >> My goal is to improve the usability, although it may sacrifice the >> accuracy. >> >> I noticed that FFmpeg has AVFMT_FLAG_FAST_SEEK flag. That's exactly what I >> need, sacrifices the accuracy of playback time in exchange for >> responsiveness. However, it does not work as my expectation. I made some >> changes to fulfill my needs. Please find the attachment for the patch. >> Just to be clear, I put some comments below for discussions, which are not >> in the patch. >> >> Could you please kindly review the attached patch? Let me know if you have >> any comments. Thank you so much for your help. >> >> Best Regards, >> Andy >> >> --- >> libavformat/mp3dec.c | 14 ++++++++------ >> 1 file changed, 8 insertions(+), 6 deletions(-) >> >> diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c >> index 007c6ea..7f675ab 100644 >> --- a/libavformat/mp3dec.c >> +++ b/libavformat/mp3dec.c >> @@ -342,7 +342,7 @@ static int mp3_read_header(AVFormatContext *s) >> int i; >> >> if (mp3->usetoc < 0) >> - mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 0 : 2; >> + mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2; >> >> /* >> Should usetoc be 0 when AVFMT_FLAG_FAST_SEEK is enabled? When usetoc is 0, >> seeking a VBR mp3 is slow, even if it contains a TOC. >> Thus, I think 1 is a more proper selection. >> */ >> >> st = avformat_new_stream(s, NULL); >> if (!st) >> @@ -489,19 +489,21 @@ static int mp3_seek(AVFormatContext *s, int >> stream_index, int64_t timestamp, >> AVStream *st = s->streams[0]; >> int64_t ret = av_index_search_timestamp(st, timestamp, flags); >> int64_t best_pos; >> + int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0; >> + int64_t filesize = mp3->header_filesize > 0 ? mp3->header_filesize >> + : avio_size(s->pb) - >> s->internal->data_offset; >> >> /* >> Many MP3 files in Podcast does not have VBRI, LAME, or XING tag, so >> header_filesize is not always available. (file size - data offset) could >> be >> a good estimation. >> */ >> >> >> if (mp3->usetoc == 2) >> return -1; // generic index code >> >> - if ( mp3->is_cbr >> + if ( (mp3->is_cbr || fast_seek) >> && (mp3->usetoc == 0 || !mp3->xing_toc) >> && st->duration > 0 >> - && mp3->header_filesize > s->internal->data_offset >> - && mp3->frames) { >> + && filesize > 0) { >> /* >> Not sure why (mp3->header_filesize > s->internal->data_offset) has to be >> true. What if a MP3 file contains a short audio and a large picture? >> Again, mp3->frames is not always available. Do we really need it here? I >> move the check to below. >> */ >> ie = &ie1; >> timestamp = av_clip64(timestamp, 0, st->duration); >> ie->timestamp = timestamp; >> - ie->pos = av_rescale(timestamp, mp3->header_filesize, >> st->duration) + s->internal->data_offset; >> + ie->pos = av_rescale(timestamp, filesize, st->duration) + >> s->internal->data_offset; >> } else if (mp3->xing_toc) { >> if (ret < 0) >> return ret; >> @@ -515,7 +517,7 @@ static int mp3_seek(AVFormatContext *s, int >> stream_index, int64_t timestamp, >> if (best_pos < 0) >> return best_pos; >> >> - if (mp3->is_cbr && ie == &ie1) { >> + if (mp3->is_cbr && ie == &ie1 && mp3->frames) { >> 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); >> } >> -- >> 2.5.0.457.gab17608 >> >> > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel