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

[Diego Biurrun]

On Mon, Jan 30, 2006 at 10:35:01PM +0100, Michael Niedermayer wrote:
> 
> 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)

Tried on all my MOV samples, it fixes one 3GP sample and breaks none
that were not already broken (lots are, btw).

Patch applied.

Diego