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

[David Conrad]

On Mar 11, 2010, at 3:10 PM, Baptiste Coudurier wrote:

> On 03/11/2010 11:41 AM, David Conrad wrote:
>> On Mar 11, 2010, at 2:24 PM, 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.
>>> Which format does support negative timestamps ?
>> 
>> Matroska does directly, although I believe it was unintentional.
>> More commonly, any format that stores only pts will often imply negative dts (e.g. nut)
> 
> I believe the question is more: does matroska support negative pts ?

It's syntactically possible to store negative pts in matroska, and I can't find anything in the spec that disallows it. But negative pts can't be indexed (the timestamp there is unsigned), the minimum negative timestamp is limited, and other demuxers don't expect it, so I'd say stick with only allowing negative dts in matroska.