[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-filesystem-dev
Subject:    RE: [datatype-dev] RE: [Filesystem-dev] MP3 streaming info required
From:       <rajesh.rathinasamy () nokia ! com>
Date:       2005-11-18 23:39:58
Message-ID: AADDB69D47B8C5498F30600FDC3CD90401378D40 () daebe102 ! NOE ! Nokia ! com
[Download RAW message or body]

 Hi Jamie,
   Thank u very much for your time. 

Here are my observation on windows version splay.exe. (Profile I used in
helix-client-all-defines, sys id: win32-i386-vc6 )

* The response header is added to the bitstream. Since the bit stream
has the headers, the m_bLive in mp3ff.cpp is set. If this response is
added to bitstream, then the metedata calculation on the httpfilesys
will have to skip it. And also I did not see any hit on code
CHTTPFileObject::_SetMetaData even though the stream had some meta data
information.

* I looked at the CRnMp3Fmt::SetFileSize. The check for magic number
never succeeds on that function. Also I don't see any code in
httpfilesys which could possibly set the magic number to content size
variable. It is the m_bShoutcast flag in httpfilesys returning true for
IsLive() call.

If the intended design is to use magic number for shoutcast stream
identification, then it is not happening that way. It is always picking
up the fallback option of response headers in the bit stream.

Thanks,
Rajesh.


>-----Original Message-----
>From: ext Jamie Gordon [mailto:jgordon@real.com] 
>Sent: Friday, November 18, 2005 3:59 PM
>To: Rathinasamy Rajesh (Nokia-TP-MSW/Dallas)
>Cc: ehyche@real.com; acolwell@real.com; 
>datatype-dev@helixcommunity.org; filesystem-dev@helixcommunity.org
>Subject: Re: [datatype-dev] RE: [Filesystem-dev] MP3 streaming 
>info required ( Shoutcast )
>
>Rajesh -
>What I meant is that the existence of ICY headers (checked in
>CheckForHeaders) is not the primary or only means of 
>determining whether a "file" is actually a live/Shoutcast 
>stream, it's more a fallback - if it didn't think it was live 
>but it found a shoutcast header, it goes ahead and assumes 
>it's live. It should not need the Shoutcast headers to know 
>that the stream is live - it should know that it's live based 
>on the file size from the Stat call. (Ignore what I said about 
>ADVISE_LINEAR, that was not correct, at all).
>
>You probably will want to look at what happens in the call to 
>StatDone. What *should* happen is that it will call 
>SetFileSize, which will set to live if it matches one of the 
>live file size magic numbers. I would guess that maybe either 
>the size is not an expected magic number, the file system is 
>failing on Stat, or maybe StatDone is screwing up when you do 
>not have progressive download support defined, which I'm 
>guessing you don't with an HTTP lite build (I mention this 
>because I looked at it and noticed a lot of code in StatDone 
>ifdef'd for prog download only).
>
>That said, if there *are* Shoutcast headers you may want to 
>pass them on to the ff plugin. The only really critical one 
>should be the icy-metaint, which you will only need to worry 
>about if the file system plugin is requesting meta-data. (If 
>there *is* meta data and the ff plugin does not receive and 
>parse the interval, it will screw up playback since the meta 
>data will be in the way of the audio data, in the middle of 
>frames, etc.). I think the only other one it uses is the title.
>
>Jamie
>
>
>rajesh.rathinasamy@nokia.com wrote:
>
>>>That's not true unless something has been broken recently. 
>>>Shoutcast streams will not always have an icy-metaint property (they 
>>>do not always contain metadata) and live streams do not have to be 
>>>shoutcast.
>> 
>> 
>> <<Rajesh>> May be I'm missing something.
>> I understand that only if client requests for Metadata, the server 
>> will send it.
>> I was trying to make changes to HTTPLite for supporting shoutcast.
>> Initially I just added the media data to the Bitstram, the 
>play out of 
>> data started, but the fileformat did not recognize the stream to be 
>> shoutcast. Later looking at the code in CMp3Misc::CheckForHeaders, I 
>> added string 'icy-metaint:" string to the start of the 
>bitstream (Just 
>> for the heck of testing..) and the fileformat detected the stream as 
>> shoutcast. That's the one made me to assume that headers are part of 
>> bit stream.
>> 
>> Maybe you could have a look at api CMp3Misc::CheckForHeaders and 
>> correct me if I'm wrong.
>> 
>> I'm trying to setup windows splay build. May be that will solve some 
>> puzzles for me.
>> 
>> -Rajesh.
>> 
>> 
>>>The ff plugin does sets to live if it finds a shoutcast header but 
>>>this is not the only way a "file" will be seen as live. It 
>determines 
>>>live based on the length (some magic number lengths that have been 
>>>used in the past for Shoutcast) or if the file system returns 
>>>PREFER_LINEAR to the request for random access.
>>>
>>>Jamie
>>>
>


[prev in list] [next in list] [prev in thread] [next in thread]