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 

non-standard ogg-stream, new format

 
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Dev Branches
View previous topic :: View next topic  
Author Message
mml



Joined: 11 Feb 2009
Posts: 6

PostPosted: Wed Feb 11, 2009 3:58 pm    Post subject: non-standard ogg-stream, new format Reply with quote

We're trying to get IceCast running with multiple logical ogg-streams. One of them is a non-standard stream-type (OggSpots), the other one a basic Vorbis stream.

When sending the multiplexed stream to the server, we get disconnected with the following error:
"format-ogg/format_ogg.c Seen BOS page with unknown type".

We assume, that we have to implement a new format (format_oggspots.c). What would be the minimal implementation for that? We know, that we have to check the packet-headers in (like in initial_vorbis_page), but we don't know the exact content of ogg_codec_t. Is there any documentation available? What about other functions?

Best regards

mml


Details on the OggSpots format:
http://wiki.xiph.org/index.php/OggSpots
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Wed Feb 11, 2009 4:09 pm    Post subject: Reply with quote

The format_ogg.c:process_initial_page detects the first page and will allow calling your own specific function. I would say look at speex as a minimal one to follow, which is to detect the headers so that they can be identified for listeners connecting some time later. How much processing you want to do is up to you, in the case of vorbis, it can rebuild pages so is probably not the most simplest to look at. the ogg_codec_t is just to maintain state for a particular codec in the stream, so in the simplest case it could keep a header count.

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



Joined: 11 Feb 2009
Posts: 6

PostPosted: Thu Feb 12, 2009 3:17 pm    Post subject: Reply with quote

Thanks for your fast response.

We managed to compile Icecast with a format_spots, which is similar to format_speex. It detects the Spots-stream, but we're having difficulties connecting with a client, as long as we include this type of stream. Plain Vorbis stream works fine.
As far as we can tell, there are no related messages in the logfile. We're trying to figure out more details on our problem, any ideas what we should be looking for?

Thanks in advance

mml
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 Feb 12, 2009 7:14 pm    Post subject: Reply with quote

depends on what you mean by difficulties. If you mean that no stream content appears at all then you may have the sync marker setup for your specific codec and not setting it. use DEBUG messages to see what functions are being called.

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



Joined: 11 Feb 2009
Posts: 6

PostPosted: Tue Feb 24, 2009 3:25 pm    Post subject: Reply with quote

We're still trying to figure out the exact nature of our difficulties.
But we can try to explain some effects: Our Spots stream is recognized and shown as "subtype=Spots", but vlc can't play even the vorbis substream. It is able to play such ogg-files from harddisk.
Network traffic looks much less smooth on a mixed stream than on plain vorbis (even when we only send the header of our Spots-stream), i.e. IceCast seems to send less, yet larger packets in larger intervals.
In addition to that, total_bytes_read and total_bytes_sent seem to be way off as well, with read bytes being a lot larger than sent.

Is anyone else using Visual Studio 2008 to compile the sources? We thought, that this could also cause problems. Indeed, we encountered some minor problems with the correct display of the server uptime. In line 626 in Icecast2winDlg.cpp, we had to change the "%d" to "%ld" respectively "%lld" to fix it.
Code:
sprintf(timespan, "%lld Days, %ld Hours, %ld Minutes, %ld Seconds", runningFor.GetDays(), runningFor.GetHours(), runningFor.GetMinutes(), runningFor.GetSeconds());


Last edited by mml on Tue Feb 24, 2009 8:20 pm; edited 1 time in total
Back to top
View user's profile Send private message
mml



Joined: 11 Feb 2009
Posts: 6

PostPosted: Tue Feb 24, 2009 6:52 pm    Post subject: Reply with quote

Actually this seems to be even weirder than before. I compiled and ran everything on a different computer and streaming works fine. Well everything but an exception in Icecast after disconnecting the source-client.

Code:
Invalid Address specified to RtlValidateHeap( 00EB0000, 01B04020 )
Back to top
View user's profile Send private message
mml



Joined: 11 Feb 2009
Posts: 6

PostPosted: Wed Feb 25, 2009 1:08 pm    Post subject: Reply with quote

We found a problem with our source client, Icecast seems to be running fine now.
Even if OggSpots is not and probably will never be a standard format, is there a chance/interest to include the new format to the main release?

Thanks again for your help.
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Wed Feb 25, 2009 10:50 pm    Post subject: Reply with quote

if it becomes part of the standard ogg codec group then it can be, failing that you can have it as a third party patch to the codebase.

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



Joined: 11 Feb 2009
Posts: 6

PostPosted: Mon Aug 10, 2009 1:16 pm    Post subject: Reply with quote

Hello Karl,

our codec has been running smoothly for some months now, yet we're still willing to do some modifications:

Assuming that a stream consists of individual parts (like a packet):
Is it possible to send previously delivered pages of the current part (ogg-packet) to a client, which connects in the "middle" of a part (packet)? Or send the last part, if there isn't a new one (-> everything since the last start of a part)?
For example speaking in terms of a video stream: Is there a way to buffer the last keyframe and send it to newly connecting clients? Or a triggered event that allows to send specific information to newly connected clients per codec (after headers)?

We tried to do work with "refbuf", yet were not able to solve the above problem.

Any help or hints would be appreciated
Back to top
View user's profile Send private message
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Mon Aug 10, 2009 1:51 pm    Post subject: Reply with quote

It will depend on the context of the data in question, but you will either store it on the queue or within/off the ogg_codec_t. In the case of the theora keyframe, the theora specific structure held a reference to the starting refbuf.

karl.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Display posts from previous:   
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Dev Branches All times are GMT
Page 1 of 1

 
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