Hey, sorry for the slow reply. Use this sample file. Its a CBR file with a corrupt TOC. http://happyworm.com/jPlayerLab/halite/jumptest/testcount.mp3
Before applying my patch: ./ffplay -ss 00:33:20 testcount.mp3 -usetoc 0 plays out "1395", which is the correct audio for the given seek time ./ffplay -ss 00:33:20 testcount.mp3 -usetoc 1 plays out "...378, 1379", way off because it used the bad TOC After applying my patch these commands both play out the correct time of "1395" because usetoc=1 is ignored/overridden by virtue of this file being CBR. However, I've *just* thought of another (better) approach. My goal is really to improve the behavior of AVFMT_FLAG_FAST_SEEK <https://github.com/FFmpeg/FFmpeg/blob/b9cd3e1add3a3db86aaeba8680ad5a4ee57d519b/libavformat/mp3dec.c#L348>, which defaults to using the TOC whenever its available. Standby for a second patch that will only change TOC behavior when the AVFMT_FLAG_FAST_SEEK is being used. Chris On Mon, Nov 9, 2015 at 3:34 PM, Michael Niedermayer <mich...@niedermayer.cc> wrote: > On Wed, Nov 04, 2015 at 05:21:57PM -0800, Chris Cunningham wrote: > > "Fast seek" uses linear interpolation to find the position of the > > requested seek time. For CBR this is more direct than using the > > mp3 TOC and bypassing the TOC avoids problems when the TOC is > > corrupted (e.g. https://crbug.com/545914). > > > > For VBR, fast seek is not precise, so continue to prefer the TOC > > when available. > > --- > > libavformat/mp3dec.c | 6 ++++-- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > how can this be reproduced with FFmpeg ? > do you have a sample which you can share ? > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > I have often repented speaking, but never of holding my tongue. > -- Xenocrates > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
