[FFmpeg-devel] [PATCH] asf muxer: gracefully handle negative timestamps

[Alexander Strange]

On Mar 11, 2010, at 3:35 PM, Michael Niedermayer wrote:

> On Thu, Mar 11, 2010 at 11:24:11AM -0800, Baptiste Coudurier wrote:
>> On 03/11/2010 03:44 AM, Michael Niedermayer wrote:
>>> On Thu, Mar 11, 2010 at 12:37:20PM +0100, Vladimir Pantelic wrote:
>>>> Michael Niedermayer wrote:
>>>>> On Thu, Mar 11, 2010 at 12:15:16PM +0100, Vladimir Pantelic wrote:
>>>>>>  I have one asf file that when remuxed to asf with vcodec/acodec copy 
>>>>>> for
>>>>>>  some reason has negative dts.
>>>>>> 
>>>>>>  These negative dts end up in "sendtime" as a large integer, putting 
>>>>>> the
>>>>>>  send
>>>>>>  time in future of the payload presentation time. This is due to the 
>>>>>> fact
>>>>>>  that (int)asf->packet_timestamp_start is converted to (unsigned
>>>>>>  int)sendtime
>>>>>> 
>>>>>>  Attached patch make sure that we write a sendtime of 0 in this case.
>>>>>> 
>>>>>>  This fixes some complaints that M$ "Windows Media ASF View 9 Series" 
>>>>>> has
>>>>>>  with the generated file.
>>>>> 
>>>>>>   asfenc.c |    4 ++--
>>>>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>>>>  5a18e0df6769452b2874689888dfdd832cca85dc  asf_fix_send_time.patch
>>>>>>  Index: libavformat/asfenc.c
>>>>>>  ===================================================================
>>>>>>  --- libavformat/asfenc.c	(revision 22465)
>>>>>>  +++ libavformat/asfenc.c	(working copy)
>>>>>>  @@ -585,7 +624,7 @@
>>>>>> 
>>>>>>   static int put_payload_parsing_info(
>>>>>>                                   AVFormatContext *s,
>>>>>>  -                                unsigned int    sendtime,
>>>>>>  +                                int             sendtime,
>>>>>>                                   unsigned int    duration,
>>>>>>                                   int             nb_payloads,
>>>>>>                                   int             padsize
>>>>>>  @@ -626,7 +665,7 @@
>>>>>>       if (iLengthTypeFlags&   
>>>>>> ASF_PPI_FLAG_PADDING_LENGTH_FIELD_IS_BYTE)
>>>>>>           put_byte(pb, padsize - 1);
>>>>>> 
>>>>>>  -    put_le32(pb, sendtime);
>>>>>>  +    put_le32(pb, FFMAX(0, sendtime));
>>>>> 
>>>>> muxers are not supposed to store random values
>>>>> 
>>>>> id suggest
>>>>> 1. add a flag to muxers specifying the capability of negative dts 
>>>>> support
>>>> 
>>>> add AVFMT_POSITIVE_TIMESTAMPS to asfenc, or AVFMT_NEGATIVE_TIMESTAMPS
>>>> to all others?
>>> 
>>> AVFMT_POSITIVE_TIMESTAMPS, id say
>> 
>> I believe it would be more efficient the other way around, ie adding 
>> AVFMT_NEGATIVE_TIMESTAMP.
> 
> whichever people prefer ...
> 
> but this thread brought up a new aspect, dts vs pts
> if no formats support negativ pts then we dont need a flag for that
> and could just have a flag for negative dts.

MOV supports it, though it doesn't work here (issue1086). It's used to allow copy/pasting sections out of a movie without having to clip to keyframes, which is a nice enough feature.