> -----Original Message-----
> From: Henry Ping [mailto:ping real.com]
> Sent: Tuesday, September 19, 2006 2:51 PM
> To: 'Jamie Gordon'; ehychereal.com
> Cc: filesystem-devlists.helixcommunity.org
> Subject: RE: [Filesystem-dev] CR-Client: handle live
mp3 case
>
> I put in a fix a few weeks ago that assumes we have
read all
> the content
> when the socket was closed by the server and
"Content-Length" is not
> included in HTTP response. So the data will still be
sent over to the
> corresponding fileformat/renderer for parsing. If the
data is
> incomplete,
> then the error will be reported from the
fileformat/renderer.
>
> On the other hand, (!m_bKnowHTTPResponseContentSize
&& !m_bEncoded) != live.
But the problem is that there *is* no definition from
the headers of "live" other than Shoutcast. We
know that
Shoutcast is gonna be live, but this stream is live but not
Shoutcast.
The only way I can tell to detect these types of stream is
that we don't have a Content-Length in the header.
Is there another way you can think of? John: any other
ways you know of to detect that this stream is live?
Eric
> I think the name of the function where this changes
resides
> is misleading,
> maybe we should rename it to
"IsRandomAccessSupported()" etc.
> instead of
> "IsLiveStream()", changing bLive to
bRandomAccessSupported.
>
> -->Henry
>
>
> > -----Original Message-----
> > From: filesystem-dev-bounceshelixcommunity.org
> > [mailto:filesystem-dev-bounceshelixcommunity.org] On Behalf
> > Of Jamie Gordon
> > Sent: Tuesday, September 19, 2006 11:18 AM Ping
> > To: ehychereal.com
> > Cc: filesystem-devlists.helixcommunity.org
> > Subject: Re: [Filesystem-dev] CR-Client: handle
live mp3 case
> >
> > Eric Hyche wrote:
> > > The net result of this change is that when
there is no
> > Content-Length
> > > in the response, that the http filesystem
answers the
> > > ::Advise(RANDOM_ACCESSS) query with
PREFER_LINEAR.
> > PREFER_LINEAR will
> > > cause the file format not to try to seek to
the end of
> the file to
> > > read the ID3 tags (which makes sense, since
it doesn't know
> > the file
> > > length to seek to).
> > >
> > > The stream still plays just fine. It just
won't try to
> read the ID3
> > > tags.
> > >
> >
> > Ah, as far as playback goes, that's always been
sort of the
> > expected response anyway. 
> >
> > But I am actually thinking more of other types of
files. What
> > is the consequence of this change for small files
(e.g. ram,
> > smil, x-wap-profile, etc.) fetched from servers
that don't
> > send a Content-Length header, which we expect to
have fetched
> > the entire file before attempting to parse?
> >
> > Thanks,
> > Jamie
> >
> > > Eric
> > >
> > >
==============================================
> > > Eric Hyche (ehychereal.com)
> > > Technical Lead
> > > Embedded Player and Technologies
> > > RealNetworks, Inc.
> > >
> > >
> > >
> > >>-----Original Message-----
> > >>From: Jamie Gordon [mailto:jgordonreal.com]
> > >>Sent: Tuesday, September 19, 2006 2:03 PM
> > >>To: ehychereal.com
> > >>Cc: filesystem-devlists.helixcommunity.org
> > >>Subject: Re: [Filesystem-dev] CR-Client:
handle live mp3 case
> > >>
> > >>But won't this potentially break standard
HTTP compatibility with
> > >>HTTP/1.0 servers?
> > >>
> > >>Content-Length is not required in a
response - the content
> > length if
> > >>the header is not present in a response is
defined to be
> > the length of
> > >>data sent until the server closes the
connection.
> > >>
> > >>Jamie
> > >>
> > >>Eric Hyche wrote:
> > >>
> > >>>Description
> >
>>>------------------------------------------------
--
> > >>>The current http filesystem detects a
"live" http stream
> > when either
> > >>>it's a Shoutcast stream (has
"ICY" headers") or it has a
> > Content-Type
> > >>>of "audio/mpeg" and has a
specific Content-Size
> > >>>(99999999 or 54000000). However, the
following stream:
> > >>>
> > >>>
> > >>
> > >>http://streamer2.last.fm/last.mp3?Session=cc941db0
d6d21d9b60b5
> > >>ddd65602bbe2
> > >>
> > >>>is a live mp3 stream but simply does
not have a
> > Content-Size in the
> > >>>HTTP response. However, since we were
not detecting that
> > this was a
> > >>>live stream, then we tried to seek to
the end of the
> > "file" to read
> > >>>the ID3 tags and this seek failed. So
the fix is to
> > consider a stream
> > >>>live if there is no
"Content-Size" in the HTTP response.
> > >>>
> > >>>Files Modified
> >
>>>------------------------------------------------
--
> > >>>filesystem/http/httpfsys.cpp
> > >>>
> > >>>Branches
> >
>>>------------------------------------------------
--
> > >>>HEAD and 150Cay
> > >>>
> > >>>Testing
> >
>>>------------------------------------------------
--
> > >>>John Stirling of Reciva tested this on
the above stream
> > and verified
> > >>>that it fixed the problem.
> > >>>
> > >>>Index: httpfsys.cpp
> >
>
>>>================================================
===================
> > >>>RCS file:
/cvsroot/filesystem/http/httpfsys.cpp,v
> > >>>retrieving revision 1.102
> > >>>diff -u -w -u -w -r1.102 httpfsys.cpp
> > >>>--- httpfsys.cpp 15 Sep 2006
04:08:59 -0000 1.102
> > >>>+++ httpfsys.cpp 19 Sep 2006
15:54:23 -0000
> > >>> -5388,6 +5388,10
> > >>> bLive = TRUE;
> > >>> }
> > >>> }
> > >>>+ else if
(!m_bKnowHTTPResponseContentSize && !m_bEncoded)
> > >>>+ {
> > >>>+ bLive = TRUE;
> > >>>+ }
> > >>>
> > >>> return bLive;
> > >>> }
> > >>>
> >
>>>==============================================
> > >>>Eric Hyche (ehychereal.com)
> > >>>Technical Lead
> > >>>Embedded Player and Technologies
> > >>>RealNetworks, Inc.
> > >>>
> > >>>
> >
>>>_______________________________________________
> > >>>Filesystem-dev mailing list
> > >>>Filesystem-devhelixcommunity.org
> > >>>http://lists.helixcommunity.org/mailman/listinfo/
filesystem-dev
> > >>
> > >
> >
> > _______________________________________________
> > Filesystem-dev mailing list
> > Filesystem-devhelixcommunity.org
> > http://lists.helixcommunity.org/mailman/listinfo/
filesystem-dev
>
_______________________________________________
Filesystem-dev mailing list
Filesystem-devhelixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/
filesystem-dev
|