[Live-devel] Timestamp gap in RTCP Report for MPEG1or2VideoStreamFramer

Guy Bonneau gbonneau at matrox.com
Tue Feb 5 11:01:12 PST 2008


Ross,

Give me a few days. I have to double check a few things and I will getting
back to you about that. Then I will provide you with some feedback about the
AAC support in Mpeg2 Transport Stream if it work for me.

Thanks for you great support.

Best Regards
Guy 

> -----Original Message-----
> From: live-devel-bounces at ns.live555.com 
> [mailto:live-devel-bounces at ns.live555.com] On Behalf Of Ross Finlayson
> Sent: Tuesday, February 05, 2008 1:32 PM
> To: LIVE555 Streaming Media - development & use
> Subject: Re: [Live-devel] Timestamp gap in RTCP Report for 
> MPEG1or2VideoStreamFramer
> 
> You need to stop thinking about RTP timestamps.  Instead, 
> think about presentation times.
> 
> At the RTP sender end, you provide - for each frame of media 
> data - a presentation time.
> 
> At the RTP receiver end, you get - for each frame of media 
> data - a presentation time.  This presentation time is used 
> for decoding (and a/v sync).
> 
> If you also implement RTCP, then (after the initial RTCP "SR" is
> received) the presentation times that you get at the RTP 
> receiver end will be *exactly the same* as the presentation 
> times that you provided at the RTP sender end.  You can 
> verify this for youself.
> 
> In other words, you can - and should - think of the RTP/RTCP 
> implementation, at the sender and receiver ends, as being a 
> 'black box' that takes presentation times as input at one 
> end, and produces *the same* presentation times as output at 
> the other end.  This 'black box' happens to work by using RTP 
> timestamps and RTCP reports. 
> But you shouldn't concern yourself with this.  This code works. 
> Trust me.
> 
> Thus, the thing that you need to worry about is presentation times. 
> Look at the *presentation times* that are coming out of 
> "MPEG1or2VideoStreamFramer".  Are they correct?  Because your 
> stream is I-frame only, then it's not inconceivable that 
> there is a problem with the way that 
> "MPEG1or2VideoStreamFramer" generates presentation times for 
> your streams.  You should be able to easily check this for 
> yourself.  But don't concern yourself with RTP timestamps; 
> that's a total red herring.
> 
> Note also that if your input data consists of discrete MPEG 
> video frames, rather than a byte stream, then you could 
> instead use "MPEG1or2VideoStreamDiscreteFramer", which is 
> simpler and more efficient than "MPEG1or2VideoStreamFramer".
> -- 
> 
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
> _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel



More information about the live-devel mailing list