View previous topic :: View next topic |
Author |
Message |
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Thu Nov 19, 2009 6:31 pm Post subject: Clear-up Misconception |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Thu Nov 19, 2009 8:23 pm Post subject: |
|
|
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 |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Thu Nov 19, 2009 10:44 pm Post subject: |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Fri Nov 20, 2009 1:33 am Post subject: |
|
|
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 |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Sat Dec 05, 2009 3:46 pm Post subject: |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat Dec 05, 2009 8:33 pm Post subject: |
|
|
icecast will keep a copy of the header pages for sending to newly connected listeners.
karl. |
|
Back to top |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Sun Dec 06, 2009 4:43 pm Post subject: |
|
|
Then can you explain an out of sync condition in terms of stream<=>player?
Vince, |
|
Back to top |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sun Dec 06, 2009 4:49 pm Post subject: |
|
|
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 |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Sun Dec 06, 2009 5:06 pm Post subject: |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sun Dec 06, 2009 8:32 pm Post subject: |
|
|
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 |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Tue Dec 29, 2009 1:27 pm Post subject: |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Tue Dec 29, 2009 7:44 pm Post subject: |
|
|
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 |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Thu Dec 31, 2009 5:05 pm Post subject: |
|
|
Thank you! There will be more question as I read on.
THKS
Vince, |
|
Back to top |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Sat Mar 20, 2010 1:04 pm Post subject: |
|
|
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 |
|
|
lifestream
Joined: 19 Nov 2009 Posts: 19
|
Posted: Sat Mar 20, 2010 1:38 pm Post subject: |
|
|
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 |
|
|
|