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

[Mike Scheutzow]

Sam Creasey wrote:
> On Fri, Sep 24, 2010 at 1:37 PM, Michael Niedermayer <michaelni at gmx.at> wrote:
>   
>> 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.
>>>       
>>> [...]
>
> I can give you a little more information on this.  The problem
> basically seems to be around the following calculation in
> output_frame():
>
> if (pkt->dts == AV_NOPTS_VALUE)
>     opkt.dts = av_rescale_q(ist->pts, AV_TIME_BASE_Q, ost->st->time_base);
>
> When ist->pts has incremented to the point that av_rescale_q returns 1
> for two consecutive frames, ffmpeg bombs out on the monotonic
> timestamp check.  Often, this is avoided because dts == 0 is special
> cased in the test, and the input frames will start having a valid dts
> before its->pts has incremented sufficiently to cause a problem

The high level issue here is that the FFmpeg h264_parser does not know 
how to generate timestamps for an h264 elementary stream. That means 
that the ffmpeg app has to make a guess at proper values. By the way, if 
you are attempting to do a "-vcodec copy", that is known not to work 
with h264 elementary stream input (there are multiple bug reports on 
roundup.)

How much do you know about the input stream you are processing? If the 
input stream is very simple (e.g. no B frames, fixed frame rate) then a 
tiny hack to ffmpeg.c could customize it to work for your specific 
situation.

Mike Scheutzow