[FFmpeg-devel] [PATCH] flv 32 bit signed timestamps

[Baptiste Coudurier]

Michael Niedermayer wrote:
> On Mon, Jul 28, 2008 at 10:17:13AM -0700, Baptiste Coudurier wrote:
>> Michael Niedermayer wrote:
>>> On Sun, Jul 27, 2008 at 10:19:17PM -0700, Baptiste Coudurier wrote:
>>>> Hi,
>>>>
>>>> Like figured out, flv uses 32 bit signed timestamps, meaning that
>>>> pts_wrap_bits must be set to 31.
>>> What fails, why does it fail and how is it fixed by this change?
>> Don't remember ? 
> 
> i remember signed timestamps, flv, weird dts and pts, but i do not remember
> how they where connected and how that leads to this patch or what exactly
> this is supposed to change.
> 
> 
>> Let me restate, FLV specs say timestamps are unsigned,
>> while flash player use _signed_ 32 bits, this means that max timestamp
>> value is INT_MAX, if you go > INT_MAX, flash player just interpret
>> timestamps as 0, which is broken.
> 
> timestamps are in ms, to reach INT_MAX needs 3.5 weeks, thats not what you
> mean i assume ...

Depends, timestamps are not meant to start at 0, for example, when using
FFserver, timestamps reflect current time, so timestamps can be >
INT_MAX, and this is what happens. I guess flash player range value for
timestamps is 0 - INT_MAX, and for that pts_wrap_bits needs to be set to
31 due to truncate_ts.

> so what do you mean? a few initial timestamps that a negative, no that cant
> be because they should be > (unsigned)INT_MAX.
> So iam confused ...

Well, I was too, I think 31 bits is correct, 32 isn't and produce
problems I encounter.

>>> [...]
>>>> @@ -362,7 +366,7 @@
>>>>          put_byte(pb,1); // AAC raw
>>>>      else if (enc->codec_id == CODEC_ID_H264) {
>>>>          put_byte(pb,1); // AVC NALU
>>>> -        put_be24(pb,pkt->pts - (int32_t)pkt->dts);
>>>> +        put_be24(pb,pkt->pts - pkt->dts);
>>>>      }
>>> Why was that int32_t cast there?
>>>
>> To get the really painful first negative dts which gets wrapped during
>> truncate_ts.
> 
> Which values did pkt->pts and pkt->dts had, which value was stored
> with and which without the cast in the file?

pts 0 dts 2147483608

> As far as i can see this cast should not make any difference.

Indeed, it seems there is no difference, must be a leftover, I'll remove it.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Smartjog USA Inc.                                http://www.smartjog.com
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA