[FFmpeg-devel] [PATCH] rtpdec: Emit timestamps for packets before the first RTCP packet, too

[Ronald S. Bultje]

Hi,

On Tue, Dec 28, 2010 at 5:22 PM, Martin Storsj? <martin at martin.st> wrote:
> Verbally, here's what the code does, after my patch:
>
> Prior to the first RTCP packet, the timestamp returned is [RTP timestamp]
> - [RTP timestamp of first packet], so regardless of at what value they
> start, the ones we emit start at 0. The RTP timestamp of the first packet
> is named base_timestamp in the code.
>
> Once the other patchset for modifying the header parsing is applied, we
> could parse the RTP-Info header, too, and use the timestamp specified
> there instead of the RTP timestamp of the first packet.
>
> When we get the first RTCP packet, we calculate the offset from the first
> RTCP packet to the base RTP timestamp, and store this in rtcp_ts_offset.
> At this point, timestamps emitted are: [RTP timestamp] - [RTP timestamp of
> last RTCP] + [diff between latest RTCP packet and first RTCP packet] +
> [rtcp_ts_offset]. Proper rescaling between values expressed in different
> units is done, of course.
>
> Thus, all streams are synced together via the NTP timestamps once an RTCP
> packet has been received in that stream, before that, the timestamps are
> simple diffs against the first packet.
>
> Actually, on top of all this, we add a variable named range_start_offset.
> This is used for emitting sensible timestamps after seeking. If we seek to
> e.g. 42.0, and the response to the PLAY header had a Range: 42.0- header,
> we add this on top of all timestamps, so that the emitted timestamps start
> at 42.

This helped a lot, and sounds like the sanest approach we could take
here, and assuming this works with a variety of RTP/RTSP sources (try
sth. like an Axis camera if you have access to it), it sounds great to
me!

Thanks,
Ronald