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

[Martin Storsjö]

On Wed, 29 Dec 2010, Ronald S. Bultje wrote:

> 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!

I don't have access to any Axis camera, but I tested it with a specially 
crafted stream with RTCP packets being sent at different times in each 
stream, and with some other normal streams.

If anyone has access to such cameras, please test this patch (check that 
you get proper timestamps and get proper av sync), or send me the urls and 
I'll try it out.

I'll apply it within a few days if no problems are pointed out.

// Martin