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

Diego Biurrun diego
Sun Feb 19 13:49:19 CET 2006


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





More information about the ffmpeg-devel mailing list