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

Baptiste Coudurier baptiste.coudurier
Fri Mar 12 02:30:52 CET 2010


On 03/11/2010 05:21 PM, Alexander Strange wrote:
>
> 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.

No it doesn't. DTS always start at 0 according to specs.

The issue here is related to edit lists and the way it is handled.

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



More information about the ffmpeg-devel mailing list