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

[Martin Storsjö]

On Thu, 30 Dec 2010, Martin Storsj? wrote:

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

Applied, let me know if there are any problems.

// Martin