Thanks guys, you helped me a great deal. Should we decide to implement this feature, I'll keep you informed on our progress.

Peter

-----Ursprüngliche Nachricht-----
Von: Milko Boic [mailto:milko at real.com] 
Gesendet: Samstag, 18. November 2006 19:40
An: Rahul Agarwal; ehyche at real.com; Niederwieser, Peter; common-dev at helixcommunity.org
Betreff: RE: RE: [Common-dev] Streaming/Seeking within Incomplete File


1.) While we already support HTT1.1 behavior as you describe below and have 
the LRU cache in HTTP1.1 file system (a.k.a. chunkyres) since the file is 
not fully written (.rm for example) there is no index table.  Since there 
is no index table, the RealMedia file format parser in the client will be 
building the index table on the fly but it will require a linear 
download.  Thus you will not be allowed to seek into parts of the file that 
have not been downloaded yet.

2.) There is the issue of presenting proper control GUI to the user and 
proper duration to the player.  The two problems are related as currently 
the player seek bar is tied to the content duration and player will stop 
playback once the duration expires.  Knowing content duration helps but it 
is still necessary to give an indication to the user of where the currently 
live position is or allow the seek bar to snap back to the live location if 
positioned beyond it.

Solution that does not solve above two issues will be clonky.

Since you are not modifying the GUI of the player, it is possible to 
accomplish the following behavior by writing client and server plugins:
- Once you connect to the live stream player seek bar will show span of 
0...<duration currently recorded>.
- starting position on connect can either be 0 or <duration currently 
recorded>.  Supporting start at <duration currently recorded> requires a 
bit more complexity.
- <duration currently recorded> will keep updating as content continues to 
be recorded on the server
- user will be allowed to seek between 0 and <duration currently connected> 
and get fast access to the content

To accomplish this, you will need to provide your own datatype.  There will 
be a file format component for it on the server and a renderer component in 
the client.  The file format would generate and audio and video stream and 
a time-code stream indicating duration recorded thus far.  The audio and 
video streams would be handled in the client via already provided renderers 
(e.g. RealAudio and RealVideo) while the time-code renderer would be simply 
modifying the duration of the presentation based on the time-code feed from 
the server.

Thus presentation would start as follows from the client:
rtsp://<server_url>/server_recoded_live_feed.srf

Server would invoke the plugin knowing how to handle .srf extension.  There 
would an actual .srf file on the server produced by the encoding tool 
containing path to the recorded file and information needed to obtain or 
compute file duration (e.g. file bitrate and overhead % needed to convert 
file size to duration).  It could load and proxy the file format plugin 
that knows how to parse the recorded stream (e.g.: rmffplin) or parse the 
recorded format itself to produce streaming payload packets.  It would also 
generate the duration update stream.

In order to support stating at <duration currently recorded> on connect, 
the renderer plugin in the client would need to act as a persistent 
renderer (like SMIL renderer) and AddTrack to the presentation based on the 
rtsp:// link supplied.  Thus, the .srf server file-format would no longer 
be responsible for generating A/V streams but only the header with the link 
to the A/V stream and the duration update stream.  When track is added, 
start time can be indicated which could be anything between 0 and initially 
provided <duration currently recorded> thus allowing the user to start at 
(or nearly at) live time.  The drawback is a bit more complex system and 
additional communication between client and server to separately setup 
another stream.

Milko

At 10:53 AM 11/17/2006, Rahul Agarwal wrote:
>Isn't this a slight enhancement to the progressive download feature that is
>already built into the client. The only difference is that instead of
>progressively downloading down the whole file from the start, you want to
>pull down only the portions where the data is requested from and fill holes
>as you go along the way (as the user seeks back and forth). So all you
>should need is a custom local file syste+http downloader that can do byte
>range requests. In the backend since the live stream is already archived to
>a file, you can always make chunk requests from this file and not ever
>connect to the live stream directly.
>
>Perhaps I am missing something.
>
>- Rahul
>
>-----Original Message-----
>From: common-dev-bounces at helixcommunity.org
>[mailto:common-dev-bounces at helixcommunity.org]On Behalf Of Eric Hyche
>Sent: Friday, November 17, 2006 8:22 AM
>To: 'Niederwieser, Peter'; common-dev at helixcommunity.org
>Subject: RE: RE: [Common-dev] Streaming/Seeking within Incomplete File
>
>
>
>In the scenario you describe, here's what the current
>RealServer/RealPlayer can do: once you connect to
>the live TV show stream, the LivePause feature of
>RealPlayer will be saving the most recent X minutes,
>where X is configurable. But you would only be able to
>seek back to the time that you connected to the stream,
>and not before. I don't know of ANY streaming system
>(QT, WM, Real) which somehow allows you do get the
>part of the show you missed.
>
>However, the advantage that Helix has is that I
>can easily see how you could write a plugin for Helix
>(and therefore RealPlayer which uses Helix) to accomplish
>this. It might be possible with the other streaming
>systems, but I kinda doubt it.
>
>What you would need is a custom fileformat plugin that
>you would write. This fileformat plugin would proxy
>the live stream as well as establish a special connection
>to the server to retrieve the previous 10 minutes of the show
>(perhaps via http?). There would also have to be
>some archiving taking place on the server (perhaps the
>server is always archiving the last Y minutes of a live stream).
>I believe RealServer currently has that capability,
>but you would have to look more into the RealServer admin
>docs to find out for sure.
>
>Let's take your example. The user connects 10 minutes into
>a show. Initially your custom fileformat simply proxies the
>live stream. The packets coming from the live stream are
>automatically written into the player's LivePause buffer
>and as previously mentioned, the user would be able to
>seek back to the point he connected with no modifications.
>However, your custom fileformat, at the time the player connects,
>would need to contact some sort of programming guide server
>to find out what is the "current show" and how far into
>this current show the user was when he connected. Then,
>once your custom fileformat knew that, it could make a request
>to the server to deliver a certain range from the
>archived stream. The custom fileformat would stitch together
>the packets from the archived stream with the live packets
>so that the rest of the system would not know the
>difference.
>
>All of the above assumes that you are using RealPlayer for
>your display app. If you have the option to write your
>own top-level-client, then you could implement IHXRecordSource
>yourself and put this retrieval of archived packets into
>the IHXRecordSource implementation itself. The live stream
>would start writing packets to the record source (from
>the time the user connected) while the IHXRecordSource went
>and retrieved the archived packets.
>
>Hope this helps!
>
>Eric
>
>=============================================
>Eric Hyche (ehyche at real.com)
>Technical Lead
>RealNetworks, Inc.
>
> > -----Original Message-----
> > From: Niederwieser, Peter [mailto:Peter.Niederwieser at siemens.com]
> > Sent: Friday, November 17, 2006 10:49 AM
> > To: ehyche at real.com; common-dev at helixcommunity.org
> > Subject: AW: RE: [Common-dev] Streaming/Seeking within Incomplete File
> >
> > > My understanding from your description was that the
> > > content was live, which means that only the first option
> > > makes sense. Is this not the case?
> >
> > Thanks for your patience. Yes, the content IS live. Let me
> > provide an analogy that (hopefully) explains what we are
> > looking for: Imagine a VCR that can record multiple TV shows
> > simultaneously. Multiple TV screens are connected to the VCR,
> > each of which has its own remote control to choose which of
> > the shows to watch and to freely navigate within a show, no
> > matter if the show is already over or still on-air (with the
> > only restriction that you can't jump into a show's future :-)).
> > The recording part of the VCR is already realized by our
> > custom encoder, which currently produces one .asf file for
> > each audio/video recording from a live source in real time.
> > What's still missing is a way to deliver and playback
> > recordings in an on-demand fashion, without having to wait
> > until they are complete. Coming back to the VCR analogy: If
> > I'm 10 minutes late for a one-hour long live TV show, I might
> > first want to watch it from start with a time-shift of 10
> > minutes, later skip over 5 minutes of boring TV commercials,
> > watch a funny scene twice, and finally jump to the live
> > position for the rest of the show.
> > Do you think the delivery/playback part can be somehow
> > realized with Real Server/Player? If necessary, we are
> > willing to adapt our encoder (stream recordings to Real
> > Server over http, write .rm instead of .asf files, split one
> > recording into multiple files, etc.) and/or write plugins for
> > Real Server/Player, but we rather don't want to hack existing
> > sources or, even worse, implement a server/player from scratch.
> >
> > Peter
> >
> > -----Ursprüngliche Nachricht-----
> > Von: Eric Hyche [mailto:ehyche at real.com]
> > Gesendet: Donnerstag, 16. November 2006 21:24
> > An: Niederwieser, Peter; common-dev at helixcommunity.org
> > Betreff: RE: RE: [Common-dev] Streaming/Seeking within Incomplete File
> >
> >
> >
> > > -----Original Message-----
> > > From: Niederwieser, Peter [mailto:Peter.Niederwieser at SIEMENS.com]
> > > Sent: Thursday, November 16, 2006 12:50 PM
> > > To: ehyche at real.com; common-dev at helixcommunity.org
> > > Subject: AW: RE: [Common-dev] Streaming/Seeking within
> > Incomplete File
> > >
> > > >If you want to use RealPlayer, then you'll have
> > > >to live with the limit of X minutes prior to the current
> > > >live time.
> > > Setting X to a high value might be good enough for us.
> > > After searching through the player settings, I suppose you
> > > are referring to the LivePause feature. Does this really
> > > allow me to go back further than the live position at the
> > > time I opened the clip?
> > >
> >
> > No - you can only go back X minutes before the current live time.
> > I don't know of any application that would let you go back
> > further than the time you opened the clip. That was data that
> > was sent over the wire and is now "gone".
> >
> > > In your proposed solution, which Helix Server delivery mode
> > > should I use?
> > > - live (unicast) broadcast (encoder sends content directly to
> > > Helix Server)
> > > - on-demand streaming (encoder writes content to a file,
> > > Helix Server reads from file)
> > > - http download (encoder writes content to a file, Helix
> > > Server reads from file)
> > >
> >
> > My understanding from your description was that the
> > content was live, which means that only the first option
> > makes sense. Is this not the case?
> >
> > Eric
> >
> > =============================================
> > Eric Hyche (ehyche at real.com)
> > Technical Lead
> > RealNetworks, Inc.
> >
> > > At the moment, my only goal is to figure out if Helix/Real
> > > Server and Real Player meet our requirements for playing back
> > > live content, either out-of-the-box or after writing our own
> > > plugin(s). Would you advise me to ask somewhere else, maybe
> > > contact Real directly?
> > >
> > > Peter
> > >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Eric Hyche [mailto:ehyche at real.com]
> > > Gesendet: Donnerstag, 16. November 2006 16:35
> > > An: Niederwieser, Peter; common-dev at helixcommunity.org
> > > Betreff: RE: RE: [Common-dev] Streaming/Seeking within
> > Incomplete File
> > >
> > >
> > > > Thanks for your response. In your proposed solution, can the
> > > > user seek within everything the source has produced up to
> > > > that moment, no matter at what point in time he connected?
> > >
> > > You can certainly implement IHXRecordSource that way. In
> > > RealPlayer's implementation of IHXRecordSource, I believe
> > > it has a user-configurable limit of X minutes saved prior
> > > to the current "live" time.
> > >
> > > All of this is assuming you write your own TLC (top-level
> > > client). If you want to use RealPlayer, then you'll have
> > > to live with the limit of X minutes prior to the current
> > > live time. There might be some way to override RealPlayer's
> > > implementation of IHXRecordSource and force it to use your
> > > own implementation, but I'm pretty sure that has never
> > > been tried.
> > >
> > > Eric
> > >
> > > =============================================
> > > Eric Hyche (ehyche at real.com)
> > > Technical Lead
> > > RealNetworks, Inc.
> > >
> > > > -----Original Message-----
> > > > From: Niederwieser, Peter [mailto:Peter.Niederwieser at SIEMENS.com]
> > > > Sent: Thursday, November 16, 2006 10:16 AM
> > > > To: ehyche at real.com; common-dev at helixcommunity.org
> > > > Subject: RE: RE: [Common-dev] Streaming/Seeking within
> > > Incomplete File
> > > >
> > > > Eric
> > > >
> > > > Thanks for your response. In your proposed solution, can the
> > > > user seek within everything the source has produced up to
> > > > that moment, no matter at what point in time he connected? To
> > > > our users, playing back "live" files should feel exactly the
> > > > same as playing back pre-recorded files, except that for live
> > > > files, the file end isn't fixed but advances as new data is
> > > > produced by the source. Ideally, seeking would be done on the
> > > > server with just the requested parts being streamed to
> > > > clients over rt(s)p. As a compromise, progressive download of
> > > > the whole file with seeking on the client might be acceptable
> > > > too, as long as the client would still continue to receive
> > > live data.
> > > >
> > > > Regards
> > > > Peter
> > > >
> > > > -----Ursprüngliche Nachricht-----
> > > > Von: Eric Hyche [mailto:ehyche at real.com]
> > > > Gesendet: Donnerstag, 16. November 2006 14:46
> > > > An: Niederwieser, Peter; common-dev at helixcommunity.org
> > > > Betreff: RE: [Common-dev] Streaming/Seeking within Incomplete File
> > > >
> > > >
> > > > What you are describing sounds more or less like the
> > > > IHXRecordSource interface which is already integrated into
> > > > the Helix client. If IHXRecordSource is implemented by
> > > > the TLC, then the client will pass all packets it receives
> > > > from the live source as it receives them from the transport
> > > > buffer, and it also reads all of its packets from this record
> > > > source. When it seeks, it seeks within the record source.
> > > >
> > > > RealPlayer currently implements IHXRecordSource as a
> > > > non-persistent cache (i.e. - it goes away when you close
> > > > the player). But there's nothing that would prevent you
> > > > from implementing it however you wanted.
> > > >
> > > > Take a look at client/core/hxntsrc.cpp and client/core/hxflsrc.cpp
> > > > and note places where m_bPlayFromRecordControl == TRUE. That's
> > > > where the HXNetSource will either be writing packets to
> > > > or reading packets from the record source.
> > > >
> > > > Eric
> > > >
> > > > =============================================
> > > > Eric Hyche (ehyche at real.com)
> > > > Technical Lead
> > > > RealNetworks, Inc.
> > > >
> > > > > -----Original Message-----
> > > > > From: common-dev-bounces at helixcommunity.org
> > > > > [mailto:common-dev-bounces at helixcommunity.org] On Behalf Of
> > > > > Niederwieser, Peter
> > > > > Sent: Tuesday, November 14, 2006 11:14 AM
> > > > > To: common-dev at helixcommunity.org
> > > > > Subject: [Common-dev] Streaming/Seeking within Incomplete File
> > > > >
> > > > > Is there ANY possibility to make the following scenario work
> > > > > (e.g. by writing a plugin for Helix Server and/or Real Player):
> > > > >
> > > > > - Produce an audio file (.rm or .asf) from a live source
> > > > > (done by our custom application)
> > > > > - Even before the file is complete, allow clients to
> > > > > 1) View the file from start
> > > > > 2) Seek within the file (jump back and forth up to the
> > > > > current file end)
> > > > >
> > > > > In essence, users should not experience any difference when
> > > > > viewing an incomplete (instead of a complete) file, except
> > > > > that jumping to the file end now means jumping to the live
> > > > > position, as the file is still growing.
> > > > >
> > > > > I assume a file index cannot be written before the file is
> > > > > complete. In that case, a "best effort" seek feature (e.g.
> > > > > seek to estimation for position hh:mm:ss, then display and
> > > > > continue from where you actually landed) would suffice - we
> > > > > just need to give our users some means to jump back and forth.
> > > > >
> > > > > Thanks for your help!
> > > > > Regards
> > > > > Peter
> > > > >
> > > > >
> > > >
> > >
> >
>
>
>_______________________________________________
>Common-dev mailing list
>Common-dev at helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/common-dev
>
>
>
>
>
>_______________________________________________
>Common-dev mailing list
>Common-dev at helixcommunity.org
>http://lists.helixcommunity.org/mailman/listinfo/common-dev