Well, there is a problem here then..
From: [email protected]
[mailto:[email protected]] On Behalf Of Ross Finlayson
Sent: Friday, July 29, 2011 2:19 PM
To: LIVE555 Streaming Media - development & use
Subject: Re: [Live-devel] hasBeenSynchronizedUsingRTCP()
On Jul 29, 2011, at 2:49 PM, Jeff Shanab wrote:
I traced the code and I AM getting the packets....
But every rtp timestamp is 0!
Arggh, now you're talking about something completely different: RTP timestamps
- which I specifically said you don't need to care about!!!
So, are you talking about "hasBeenSynchronizedUsingRTCP()", RTP timestamps
(which you don't need to care about), or presentation times (which you do need
to care about)?
My call to "hasBeenSynchronizedUsingRTCP()" is always returning false.
But anyway, to summarize (and this will be my last posting on this thread):
1/ If you ever reach the code at line 380 of "liveMedia/RTPSource.cpp", then
- You have received a RTCP "SR" packet, and
- "hasBeenSynchronizedUsingRTCP()" will always return True from
then on, and
- the presentation times for video (and audio, if present) should
be correctly synchronized from then on.
I am hitting this line and fHasBeenSyncronized is therefore being set to true.
(at that moment in time) (Perhaps I need to protect it)
2/ If "hasBeenSynchronizedUsingRTCP()" always returns False, then that must
mean that you're not receiving any RTCP "SR" packets, which is probably because
the server does not send any. But that doesn't really matter, unless you're
receiving both a video stream and an audio stream (in which case they can never
be synchronized).
But hasBeenSynchronizedUsingRTCP() does not return fHasBeenSyncronized, it
returns fCurPacketHasBeenSynchronizedUsingRTCP which I have not yet found where
it is set. I see construted to false and I see returned and I see passed in
nextPacket->use. Now on 428 in MultiframedRtpSource I see where it would be
set as a return argument, but at that breakpoint it is 0. Not sure where that
gets reset. But when I manipulate the camera settings and it starts to have a
nonzero rtpTimestamp. It starts to work at the higher level ok. So a non-zero
or at least changing rtp timestamp does seem to make a difference.
3/ All you really care about is the presentation times, anyway.
I was depending on them being syncyed, file split boundries and names are
derived from this.
4/ You absolutely do not need to 'hack' the supplied code.
AMEN!, (and I agree)
Again, this will be my last posting on this thread.
Darn :(
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
