[FFmpeg-devel] [PATCH] Add libavformat option to ignore non monotime dts timestamps

[Michael Niedermayer]

On Fri, Sep 24, 2010 at 01:14:09PM -0400, Sam Creasey wrote:
> On Fri, Sep 24, 2010 at 12:10 PM, Mike Scheutzow
> <mike.scheutzow at alcatel-lucent.com> wrote:
> > Sam Creasey wrote:
> >>
> >> This patch adds an option which disables an error check for dts
> >> ordering in compute_pkt_fields2(). ?This was needed to store the RTP
> >> stream from a particular model camera usefully (using the existing
> >> igndts flag resulted in rather jumpy playback of the final stream).
> >> Should have no effect if the new option is not specified.
> >
> > I am wondering if this is a reasonable way to solve the problem. It seems
> > like this feature could lead to the creation of an even more badly-formed
> > output file.
> >
> > Please give us more info:
> >
> > 1. what is the format of the RTP payload? Is it a well-known container type?
> 
> The RTP payload is H264 video, using payload type 96 (through rtpmap
> in the SDP).  AFAICT, the camera in question is using a standard H.264
> container, as most tools/players seem to be able to record/play the
> stream.  I haven't done the RFC diving to actually hand-decode the
> incoming packets.
> 
> > 2. what container type are you writing the output to?
> 
> ASF, though this particular patch is also needed for AVI output to
> work.  I haven't tried any other containers.
> 
> > 3. is the failing timestamp equal to the preceeding one, or is the pkt->dts
> > value actually smaller?
> 
> Equal.
> 
> > 4. do you know if the container already has these "bad" DTS timestamps, or
> > are they being created by FFmpeg itself?
> 
> Well, that led me down a much more complicated road of investigation
> than "this error seems to be causing me problems, I'll just turn it
> off..."
> 
> They appear to be generated by FFmpeg itself, particularly in
> ffmpeg.c:output_packet(), on line 1748 during the call to
> av_rescale_q() in the case that the input packet's dts was equal to
> AV_NOPTS_VALUE.  In the most reproducable case, av_rescale_q returns 1
> for two packets in a row, which eventually causes the check in
> compute_pkt_fields2() to fail.
> 
> I've seen other cases where the failure was of a repeated dts of other
> larger numbers (50, in one case), though that occured before I'd
> instrumented to code sufficiently to see where the dts was coming
> from.
> 
> As an additonal note, the case of the duplicated timestamp appears to
> only occur when both the dts and pts values of the pkt argument to
> output_frame() are AV_NOPTS_VALUE.   In the alternate case, whatever
> is generating the input to output_frame() begins assigning values to
> pts, and the case I kludged around by ignorning the later error is
> avoided.
> 
> I have a strong suspicion that having found something slightly closer
> to a root cause, my odds of getting a patch accepted which simply
> papers over it are quite low, and the odds of my having to spend many
> more hours in this code have increased dramatically...
> 
> I'll continue digging and see if there's a more "proper" way to
> resolve this issue.

do the packets have a duration set?
if yes why is it not used to extrapolate dts?
if no, why not?

also make sure the timestamps are not rounded down to lower precission that
too can make 2 equal

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100924/dab2c5d9/attachment.pgp>