Icecast Streaming Media Server Forum Index Icecast Streaming Media Server
Icecast is a Xiph Foundation Project
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Clear-up Misconception
Goto page 1, 2, 3  Next
 
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Dev Branches
View previous topic :: View next topic  
Author Message
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Thu Nov 19, 2009 6:31 pm    Post subject: Clear-up Misconception Reply with quote

Greetings,

I was under the impression that an icecast server was a transparent server. By transparent, I mean no processing whatsoever. While observing the error log I notice an message that stated "INFO format-vorbis/initial_vorbis_page seen initial vorbis header". Are the packets being evaluated to do some kind of processing? Why can not the packets be sent straigth through??? Is there an developmental documentation manual for an icecast server? I have only seen user operational docs.

THKS,
Vince
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Thu Nov 19, 2009 8:23 pm    Post subject: Reply with quote

no re-encoding is done, but vorbis only streams are re-packaged to make sure there is a regular stream of data sent. What you are seeing is the identification of the headers packets that are identified so that those can be sent to the player at connection time, they will need those to start decoding.

karl.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Thu Nov 19, 2009 10:44 pm    Post subject: Reply with quote

Shouldn't that responsibility be for the source stream to make sure the encoded stream is correct. It seems like alot of over-head for the stream server to bare the burden. Are there any Developmental Docs?


THKS,
Vince
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Fri Nov 20, 2009 1:33 am    Post subject: Reply with quote

Your initial query of the headers need to be identified whether you re-package at the ogg level or not as those headers need to be sent for any decoding to occur.

As for whether the source client should be responsible for ensuring that there are no large gaps between pages is debatable. Initially re-packaging was not done but there were some source clients in certain situations that did not flush pages out frequently enough, this becomes apparent on low bandwidth or silent audio streams. The re-packaging overhead is minimal as you are taking the ogg packets and re-packing them so we are just operating at the ogg level and we only do this once per stream, not per listener.

There aren't any real development docs but the codebase is not that difficult to get to grips with but then I'm biased in that regard. I have no problem in going through some of the detail if you want to get something down but I do try out various changes in the kh tree to see how it would pan out in trunk. Even the threading setup is different to as it was, not vastly between 2.3.2 and trunk, but more so with kh currently.

karl.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Sat Dec 05, 2009 3:46 pm    Post subject: Reply with quote

Karl,


While reading the docs for OGG and VORBIS on the xiph.org web site, it said that you needed three header pages before any data is send. If a client connect to a server while it is in the mddle of a song, how and where will it get these three header pages? It seems like I and missing the concept/s.

Vince
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sat Dec 05, 2009 8:33 pm    Post subject: Reply with quote

icecast will keep a copy of the header pages for sending to newly connected listeners.

karl.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Sun Dec 06, 2009 4:43 pm    Post subject: Reply with quote

Then can you explain an out of sync condition in terms of stream<=>player?


Vince,
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sun Dec 06, 2009 4:49 pm    Post subject: Reply with quote

The term is vague. A lack of headers would not really be a sync issue, maybe data starvation but it really does depend on what is actually being experienced.

karl.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Sun Dec 06, 2009 5:06 pm    Post subject: Reply with quote

Well here's what I am getting at, I thought the pages were in chronological order. So if you send the header pages then send the data(song) in the middle of it playback, I thought the pages would be out of sync. I tried to following the thread paths in icecast but got lost. An outline of the thread paths and small detail would help!!!


Vince,
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sun Dec 06, 2009 8:32 pm    Post subject: Reply with quote

The pages are in chronological order but the pages containing the header packets are isolated and can be used to initiate playback from some later part in the queue.

There is obviously a tie in between the header pages and the data associated with them because it is possible for an ogg stream to have various encoded versions of files think a non-encoded source stream froma series of ogg files where they were encoded at different times and by different encoders.

You may be finding complexity because of the page rebuilding logic in vorbis which is there to make sure that the pages have a certain number of samples. That rebuilding is done at the source client reading end, doing that at the listener send end would mean a lot of processing work. Having a queue of packets instead of pages would be ideal but the zero-copy ogg2 work was important for that

karl.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Tue Dec 29, 2009 1:27 pm    Post subject: Reply with quote

KarlH,

I have been looking over the source code and I have a question. I see where the source_client_callback() function is initialized to the pending_list object by
calling the fserve_add_client_callback() function in the _handle_soure_request() function. And I do see where the pendig_list object's file descriptor is put in to a poll event object through fserve_thead_function()=>wait_for_fds()=>fserve_client_wating() functions.

In what Function is the source_client_callback() function actually being called, I do not see it? There are a lot of threads running, maybe I over look it.


Vince,
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Tue Dec 29, 2009 7:44 pm    Post subject: Reply with quote

Assuming we are talking about trunk. look in fserve.c fserve_client_destroy. There is only 1 fserve thread (in trunk it is dynamically started) and after the response header is sent the fserve_t is deleted but client_t is passed to the callback to resume initialisation. The fserve thread runs with that until the source thread is created.

karl.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Thu Dec 31, 2009 5:05 pm    Post subject: Reply with quote

Thank you! There will be more question as I read on.

THKS
Vince,
Back to top
View user's profile Send private message
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Sat Mar 20, 2010 1:04 pm    Post subject: Reply with quote

KarlH,

After looking through the source code(the trunk), I decided to try and write code for a very very small one client sever to get a better understanding. It seems when I connect with OGG123 I get a message "Error opening http://127.0.0.1:8888/radio.ogg using the oggvorbis module. The file may be corrupted". If you could tell me how far I actually got, it would be appreciated!

Vince.
Back to top
View user's profile Send private message
lifestream



Joined: 19 Nov 2009
Posts: 19

PostPosted: Sat Mar 20, 2010 1:38 pm    Post subject: Reply with quote

KarlH,

Here is a even better question. At the point were the headers are ressemble to from a new bitstream for streaming using the function ogg_stream_packetin(), how do you check if the headers are not corrupt when the function ogg_stream_packetin() return OK? I am trying to find out at what point in the ressembling of the bitstream is being corrupted.

Vince,
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Dev Branches All times are GMT
Goto page 1, 2, 3  Next
Page 1 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2002 phpBB Group
subRebel style by ktauber