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

[Michael Kostukov]

Just an addon to my reply. 

Another reason why it is important to know the EXACT
duration time for the received media sample. Say you
are streaming subtitles. Each media sample is small
(just contains some text), but should be played for a
long time (for example, starts at 20s and ends at
25s). Also, durations for each such sample are
irregular. Subtitle sample can have a duration
anywhere from 0 to infinity (the time subtitle should
stay on screen). Thus, difference in presentation
times between two successive subtitle samples will in
most cases NOT be a good approximation of sample
duration, since the next sample can have (an most
likely will) have a COMPLETELY different duration
time.

Of course, I could store the duration in the media
sample data itself, but it would not be a nice Object
Oriented way, since it seems to be a responsibility of
RTCP client to ensure that the client gets correct
presentation and duration times.

What do you think?

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
>