[FFmpeg-devel] [PATCH] Extracting NTP timestamp from RTCP

Fred Rothganger frothga at sandia.gov
Mon Dec 2 23:44:16 CET 2013


On 11/26/2013 06:51 PM, Michael Niedermayer wrote:
> On Mon, Nov 25, 2013 at 01:11:04PM -0700, Fred Rothganger wrote:
>> On 11/14/2013 01:14 PM, Reimar Döffinger wrote:
>>> I believe that _someone_ at _some point_ will have to make that
>>> assumption though. Unless they want to have some ugly
>>> user-interface mess like every stream initially showing as
>>> "created 1970" to the suddenly jump to the correct value. Either
>>> way, the short of it is that I can't see that 0 as an
>>> initialization value will cause anything but annoyance long-term.
>>> INT64_MAX hopefully only long beyond the time we would care about.
>>> And UINT64_MAX means you have to be careful to not involve
>>> anything signed at any point, unless there's a good reason I'd
>>> prefer sticking with INT64_MAX (and ideally some error handling if
>>> the received timestamps should be >= than that).
>> INT64_MAX will work. Attached is another patch which creates
>> AV_NO_REALTIME and uses it instead of 0.
> why isnt AV_NOPTS_VALUE used ?
>
>

Here's a version that uses AV_NOPTS_VALUE instead.

AV_NOPTS_VALUE works because it is outside the useful range of date 
values, given the scaling of the field.

The following observation is not directly related to this patch. A few 
lines above in rtsp.c it says:

             if (rtpctx->first_rtcp_ntp_time != AV_NOPTS_VALUE) {
             ...

NTP time is defined in the standard as an unsigned 64-bit value. 
However, the field first_rtcp_ntp_time is signed. AV_NOPTS_VALUE falls 
in the middle of its range, so there is latent bug when NTP time crosses 
through this value. We aren't in any danger of this happening soon, 
unless one works with historic footage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rtsp.patch
Type: text/x-patch
Size: 4167 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20131202/aad14d3c/attachment.bin>


More information about the ffmpeg-devel mailing list