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

[David Conrad]

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)