[Live-devel] Re: live-devel Digest, Vol 25, Issue 9

[Michael Kostukov]

The trouble is, in my situation presentation time that
I retrieve on client side IS NOT the same as the one
specified on the server side: 

- presentation time on the server side is 0 based
(starts from 0 sec and up)
- presentation time retrieved on the client side is
based on some other number (around 1131582207).

Am I missing some step that it supposed to re-base the
presentation time when it arrives on the client side?
Is it possibly a type conversion error somewhere?

My client code is virtually identical to that of
openRTSP sample application...

Regarding the media sample duration- would it be a
problem to simply add an extra WORD variable to the
packet that will contain the media sample duration?
Would it break generality, or some ISO standard or
something?

Thanks,

Michael

--- live-devel-request at ns.live555.com wrote:

> Send live-devel mailing list submissions to
> 	live-devel at lists.live555.com
> 
> To subscribe or unsubscribe via the World Wide Web,
> visit
> 
> http://lists.live555.com/mailman/listinfo/live-devel
> or, via email, send a message with subject or body
> 'help' to
> 	live-devel-request at lists.live555.com
> 
> You can reach the person managing the list at
> 	live-devel-owner at lists.live555.com
> 
> When replying, please edit your Subject line so it
> is more specific
> than "Re: Contents of live-devel digest..."
> > Today's Topics:
> 
>    1. Restoring ORIGINAL presentation time and
> duration on	client
>       side (Michael Kostukov)
>    2. Re: Restoring ORIGINAL presentation time and
> duration on
>       client side (Ross Finlayson)
> > From: Michael Kostukov <the-bishop at rogers.com>
> CC: 
> To: live-devel at ns.live555.com
> Date: Wed, 9 Nov 2005 13:30:10 -0500 (EST)
> Subject: [Live-devel] Restoring ORIGINAL
> presentation time and duration on
> 	client side
> 
> Is it possible to retrieve ORIGINAL presentation
> time
> and sample duration on the client side? As I
> understand it, the current implementation of RTP
> source uses RTP timestamp as presentation time for
> received samples and does not set sample duration to
> any meaningful value. Please correct me if I'm
> wrong.
> 
> The reason why this is important is that exact
> original timestamps and diration make is MUCH easier
> to synchronize multiple streams in DirectShow on
> Windows. If there was a way to pass the original
> DirectShow samples' presentation time and duration
> to
> the client side- DirectShow would do all the work
> required to synchronize the streams.
> 
> Any comment on this would be appreciated.
> 
> Regards,
> 
> Michael
> > From: Ross Finlayson <finlayson at live555.com>
> CC: 
> To: LIVE555 Streaming Media - development & use
> <live-devel at ns.live555.com>
> Date: Wed, 09 Nov 2005 10:59:55 -0800
> Subject: Re: [Live-devel] Restoring ORIGINAL
> presentation time and
> 	duration on client side
> 
> At 10:30 AM 11/9/2005, you wrote:
> >Is it possible to retrieve ORIGINAL presentation
> time
> >and sample duration on the client side?
> 
> As I've explained several times already, the
> "presentationTime" 
> passed to a receiver (that reads derives from
> "RTPSource") *is* the 
> 'original' presentation time (i.e., the presentation
> time that was 
> specified by the server).  See 
>
<http://www.live555.com/liveMedia/faq.html#separate-rtp-streams>
> 
> As for 'sample duration' - i.e., the
> "durationInMicroseconds" 
> parameter.  Unfortunately "RTPSource" and its
> subclasses don't set 
> this parameter (so it gets the default value of
> zero).  In general, 
> there's no good way for the receiving RTP
> implementation to compute 
> the duration of received data - other than just
> using the difference 
> between successive presentation times.
> 
> >The reason why this is important is that exact
> >original timestamps and diration make is MUCH
> easier
> >to synchronize multiple streams in DirectShow on
> >Windows. If there was a way to pass the original
> >DirectShow samples' presentation time and duration
> to
> >the client side- DirectShow would do all the work
> >required to synchronize the streams.
> 
> As I noted above, the RTPSource's "presentationTime"
> value will be 
> accurate (provided, of course, that you're also
> implementing 
> RTCP).  So, you can (in fact, should) use this for
> synchronization.
> 
> 
> 	Ross Finlayson
> 	Live Networks, Inc. (LIVE555.COM)
> 	<http://www.live555.com/>
> 
> > _______________________________________________
> live-devel mailing list
> live-devel at lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>