[Ffmpeg-devel] "error, non monotone timestamps" when extracting audio from 3gp

[Michael Niedermayer]

Hi

On Sat, Dec 10, 2005 at 05:33:26PM +0100, Julian Scheid wrote:
> Julian Scheid wrote:
> >But using today's ffmpeg from CVS (same configuration options, same gcc
> >version, same mp3lame and AMR codec versions), or when using Debian
> >unstable's latest ffmpeg package, I get the following errors (the full
> >log files are attached):
> >
> >error, non monotone timestamps 1355254 >= 1355254 (CVS)
> >error, non monotone timestamps 1353600 >= 1353600 (Debian/unstable)
> >
> >And in both cases I end up with only 762 bytes of bogus audio data.
> 
> Since nobody cared to answer to my post, I decided to track down this
> issue myself and managed to come up with a fix.  Being unfamiliar with
> the code base, I'm not entirely sure that it is the right solution but
> it seems to do the trick.  Following are the details of my findings.
> 
> The immediate cause seems to be that the following test in
> libavformat/mov.c line 2005 fails for all but the first couple of audio
> samples:
> 
> >if (sc && sc->sample_to_time_index < sc->stts_count && pkt) {	 
> 
> stts_count is 1 which I verified to be correct for my input file, so
> I took a look at the value of sample_to_index_time. Further digging
> showed that it is increased when the following test in line 2011
> evaluates to true:
> 
> >if ((sc->sample_to_time_sample + count) < sc->current_sample) {	 
> 
> Looking at the value of sc->current_sample, I noticed that it didn't
> increase by 1 for each sample, but instead by 27 which is the sample
> size.
> 
> I could be wrong, but as far as I can see the current_sample field is
> meant to be the sample number, not an offset into the sample data.
> Unfortunately there is no comment explaining the purpose of the field,
> but its name and usage seems to indicate so.
> 
> Now, I found one place in line 1951 in which the current_sample field
> value is incremented by multiples of sc->sample_size:
> 
> >sc->current_sample += sc->sample_size * sc->sample_to_chunk[idx].count;
> 
> I suppose this is the cause of the problem, as changing this line to the
> following makes my issue go away:
> 
> 	sc->current_sample += sc->sample_to_chunk[idx].count;
> 
> A corresponding patch against CVS HEAD is attached.
> 
> Please let me know if this is the correct fix.

i think your fix is correct, can someone who knows mov.c & the QT spec
check and apply this? 
failing that, can someone test this against a few mov files (if it fixes
more then 0 and breaks 0 then it should be applied)

[...]

-- 
Michael