On Wed, 2003-09-03 at 21:58, Erlend Simonsen wrote:> Hirendra Hindocha <hiren_hindocha@comcast.net> writes:> >> > >> > >> No. icecast2 is a streaming server, so it... streams. > >> > > > > Good point. I wonder how the other servers (Real Server ,Quicktime etc) do it. > > Any inputs on any other streaming servers that lets a client > > seek/fast forward /rewind ? > > They probably do it client side by buffring the stream.No, they do it using RTSP methods, which inherantly contain the correct "time" for the frame. By requesting a specific "time", you get a the frames that correspong, thus you can seek without relying on client side buffering. Note that not all QuickTime or RealMedia files are served by proper streaming servers. You need two things for server side seeking.... a seekable source, and a seek-aware protocol. If all you want to do is get the file to the client, HTTP works just fine. And while the file, when it arrives, will be seekable, HTTP doesn't understand seeking, so downloading quicktime files off an HREF from a web page doesn't get you all the cool goodies that RealServer or the Darwin Streaming Server get you. Which is why they invented the "embed" tag. Make sense? ------------------------------------------------------------------ Thanks to Linux Toys, I'm listening to Oak Cliff Bra by Edie Brickell & New Bohemians --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
You know winamp does support seeking on HTTP connections via the Range: header, of course it relies on the client figuring out how the byte offset corresponds to the time offset, which is easy for CBR files, but not for VBR files. And winamp sometimes gets confused with some streaming servers and keeps trying to seek when it doesn't need to. <p>>> No, they do it using RTSP methods, which inherantly contain the correct > "time" for the frame. By requesting a specific "time", you get a the > frames that correspong, thus you can seek without relying on client side > buffering. Note that not all QuickTime or RealMedia files are served by > proper streaming servers. You need two things for server side > seeking.... a seekable source, and a seek-aware protocol. If all you > want to do is get the file to the client, HTTP works just fine. And > while the file, when it arrives, will be seekable, HTTP doesn't > understand seeking, so downloading quicktime files off an HREF from a > web page doesn't get you all the cool goodies that RealServer or the > Darwin Streaming Server get you. Which is why they invented the "embed" > tag. > > Make sense? >--- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Wed, 2003-09-03 at 22:43, Scott Manley wrote:> You know winamp does support seeking on HTTP connections via the Range: > header, of course it relies on the client figuring out how the byte > offset corresponds to the time offset, which is easy for CBR files, but > not for VBR files. And winamp sometimes gets confused with some > streaming servers and keeps trying to seek when it doesn't need to.Yes, of course there are fringe cases, and you make a good point. I was just trying to get the basic idea across without saying things like "RFC 2616 Section 14.35 in contrast to the format described in RFC 2326 Section 3.7" and may have oversimplified there... Oh the shame..... <p>------------------------------------------------------------------ Thanks to Linux Toys, I'm listening to Still Can't... by The Cranberries --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.
On Thursday 04 September 2003 08:20, W. Kevin Pedigo wrote:> On Wed, 2003-09-03 at 21:58, Erlend Simonsen wrote: > > Hirendra Hindocha <hiren_hindocha@comcast.net> writes: > > >> No. icecast2 is a streaming server, so it... streams. > > > > > > Good point. I wonder how the other servers (Real Server ,Quicktime etc) > > > do it. Any inputs on any other streaming servers that lets a client > > > seek/fast forward /rewind ? > > > > They probably do it client side by buffring the stream. > > No, they do it using RTSP methods, which inherantly contain the correct > "time" for the frame. By requesting a specific "time", you get a the > frames that correspong, thus you can seek without relying on client side > buffering. Note that not all QuickTime or RealMedia files are served by > proper streaming servers. You need two things for server side > seeking.... a seekable source, and a seek-aware protocol. If all you > want to do is get the file to the client, HTTP works just fine. And > while the file, when it arrives, will be seekable, HTTP doesn't > understand seeking, so downloading quicktime files off an HREF from a > web page doesn't get you all the cool goodies that RealServer or the > Darwin Streaming Server get you. Which is why they invented the "embed" > tag. >Well, this is mostly right... but seeking with HTTP is entirely possible However, you have to build it up from byte-range 'seek' requests, not using a time-offset. This makes doing it efficiently quite difficult. That's what the Range header is for. See also http://www.annodex.net/TR/uri_fragments.html for an internet-draft attempting to specify a media-and-transport-neutral way of specifying this sort of thing. I think they have an apache module implementing it as a proof-of-concept. Mike --- >8 ---- List archives: http://www.xiph.org/archives/ icecast project homepage: http://www.icecast.org/ To unsubscribe from this list, send a message to 'icecast-request@xiph.org' containing only the word 'unsubscribe' in the body. No subject is needed. Unsubscribe messages sent to the list will be ignored/filtered.