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

[Baptiste Coudurier]

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 ?

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org