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 

REQ: Icecast - built-in stream transcoding

 
Post new topic   Reply to topic    Icecast Streaming Media Server Forum Index -> Feature Requests
View previous topic :: View next topic  

Would you like to see stream transcoding in Icecast server?
yes
65%
 65%  [ 17 ]
no
34%
 34%  [ 9 ]
Total Votes : 26

Author Message
Anonymous
Guest





PostPosted: Sat Jul 02, 2005 12:38 am    Post subject: REQ: Icecast - built-in stream transcoding Reply with quote

this feature would by far make icecast the top dog of streaming servers.

it would be nice to see stream transcoder functionality built into icecast, say as a library?

getting streamtranscoder to work outside of icecast/shoutcast is very cumbersome.

Any thoughts on this? would this be very difficult? could stream transcoder functions be built into a library?

for those that dont know: stream transcoding is a process that listens to one stream, transcodes (converts) it to a lower bitrate and sends it to another server/mountpoint

most practical/common example:
with stream transcoding in icecast, I could have one source broadcasting a single hi quality stream (128kbps) to my server. The server could transcode the hi quality stream into a lower quality stream (i.e., 32kbps) and then serve up both the high bandwidth and low bandwidth streams from the same server, from only a single high quality stream.
Back to top
Anonymous
Guest





PostPosted: Sat Jul 02, 2005 10:52 am    Post subject: Re: REQ: Icecast - built-in stream transcoding Reply with quote

jens wrote:
this feature would by far make icecast the top dog of streaming servers.

it would be nice to see stream transcoder functionality built into icecast, say as a library?

getting streamtranscoder to work outside of icecast/shoutcast is very cumbersome.

Any thoughts on this? would this be very difficult? could stream transcoder functions be built into a library?

for those that dont know: stream transcoding is a process that listens to one stream, transcodes (converts) it to a lower bitrate and sends it to another server/mountpoint

most practical/common example:
with stream transcoding in icecast, I could have one source broadcasting a single hi quality stream (128kbps) to my server. The server could transcode the hi quality stream into a lower quality stream (i.e., 32kbps) and then serve up both the high bandwidth and low bandwidth streams from the same server, from only a single high quality stream.
The server should not transcode, the source should.
Lower bitrate = smaller amount of data to send to the icecast server. And lower system load times on the server end.
Back to top
Anonymous
Guest





PostPosted: Sat Jul 02, 2005 11:09 pm    Post subject: Re: REQ: Icecast - built-in stream transcoding Reply with quote

Quote:
The server should not transcode, the source should.
Lower bitrate = smaller amount of data to send to the icecast server. And lower system load times on the server end.


i have to disagree with you jason on the part about a lower bandwidth.

considering the (imho VERY)common scenario of needing a lo bw "simulcast" of a high bandwidth stream (For modems, isdn, mobile devices, etc)----

your method (stream transcoding done within the source):
at the source: 160kbps (128+32) needed for outgoing stream
at the server: 160kbps needed for incoming stream

my method (stream transcoding done within the server):
at the client: 128kbps needed for outgoing stream
at the server: 128kbps needed for incoming stream
-----
I do understand and agree with you, that stream transcoding takes up significant cpu time (as does any ogg/mp3/etc coding), but if this was simply a xml config option, users who dont need it would never use it
also, most of the people using or considering server side transcoding would have enough cpu power to handle it. (it took about 4-5% cpuload for a 128k to 32k mp3 transcode using streamtranscoder 1.28 on my celeron 1.Cool

again, im not asking for it to be a mandatory option. in fact, some things should be build-time option-only, not default, as is the video options that cause dependancy/library hell for alot of newbies when trying to install icecast.

as the slightly higher cpu loads is the only drawback that i can see to having builtin transcoding, and it doesnt seem like a big showstopper to me, if there is another reason for keeping the transcoder separate from icecast, i would love to hear about it.

i can tell you from experience that there are some severe logistical problems with streamtranscoder, mainly due to the fact without some complicated scripting, you cannot have it dynamically load and work ONLY when the source stream is present on the high bw stream. If it was part of the icecast server, this would, ostensibly, be easy to "trigger" the transcoder only when a source stream is present on the desired mountpoints

------
most people will probably do their transcoding at the source, which is fine and dandy, but there are plent of folks who could really use the added feature of having the OPTION of transcoding functionality at the server

my whole point is that, why would somebody choose icecast over say shoutcast ?
i think the answer is: because of the advantages that icecast has over shoutcast, i.e., 1. open source, 2. multiple streams in one server instance, 3. other codec support (ogg, etc), 4. (hopefully, one day) optional server-side stream transcoding
Back to top
karlH
Code Warrior
Code Warrior


Joined: 13 Jun 2005
Posts: 5476
Location: UK

PostPosted: Sun Jul 03, 2005 2:09 am    Post subject: Post subject: Re: REQ: Icecast - built-in stream transcoding Reply with quote

It's not the job of icecast to do transcoding, but that does not stop someone running a transcoding application on the same machine. That decision is up to the administrator of that system not the developers of icecast.

The trunk code (for 2.3) does allow for invoking scripts at stream start and end. This can be used to handle a transcoding application like streamtranscoder.
Back to top
View user's profile Send private message Send e-mail Visit poster's website
Anonymous
Guest





PostPosted: Sun Jul 03, 2005 6:38 am    Post subject: Reply with quote

thanks karl!

script triggers is exactly what i need to make ST work right..

well, i'll abandon the idea for now then
Back to top
morpheus



Joined: 23 Sep 2009
Posts: 2

PostPosted: Wed Sep 23, 2009 10:45 am    Post subject: Prevent auto fallback? Reply with quote

I'm bringing up this old thread to ask whether it is possible to prevent the automatic moving of specific listeners because of the fallback-override setting?

What I want to achieve is have 2 main streams, auto and live, and for each one have a .ogg and a .mp3 version. auto.ogg is generated by a local mpd, while live.ogg is provided by a remote shoutcast source. I have streamtranscoder connect to both .ogg streams and create the .mp3 streams (using the script triggers of icecast).
I have also set each live.xxx stream to fallback on auto.xxx and fallback-override too, so that when the remote source starts playing, the listeners of auto.xxx are moved to live.xxx
The problem is that streamtranscoder (auto.ogg-->auto.mp3) is moved to live.ogg too, so auto.mp3 is actually playing the live stream.

So, what I want is:
Code:
auto.ogg-->ST--auto.mp3

live.ogg-->ST-->live.mp3


but after the live.ogg source connects, I get:
Code:

auto.ogg

        |-->ST--live.mp3
live.ogg|
        |-->ST--auto.mp3


I have though and tried some workarounds:

    Use the httpd output of mpd, and have icecast relay this to auto.ogg. ST connects directly to the httpd output of mpd to provide auto.mp3.Sadly with this setup I cannot set the stream name, description, etc, and I dont know if fallback works for relays

    Have mpd connect (via shout output) to an extra mount auto-int.ogg (for internal use only). ST connects to auto-int.ogg and icecast relays auto-int.ogg to auto.ogg, which is used by listeners. Thus live.ogg uses auto.ogg as fallback, and ST should not get moved as it listens to auto-int.ogg. In this case all metadata work ok, except the stream URL, which is not a big deal. I have not yet tested with a remote source, to check if it works as I describe above though.


My server is http://amorgos.csl.mech.ntua.gr:8000 , in case you want to take a look yourselves. Right now I am testing the second method described above
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 Sep 23, 2009 1:01 pm    Post subject: Reply with quote

There's no selection criteria for prevention of listener movement. I suppose the listener could issue a header to exclude them but it sounds like you want to have a local relay to act as a holding point. eg

live.ogg fallas back to /fallback.ogg
/fallback.ogg is a local relay of /auto.ogg (on-demand is allowed).
ST sits on /auto.ogg and is not overridden, but always has 2 listeners (ST and the local relay).
Ogg players are either on /live.ogg or /fallback.ogg
The mp3 streams would stay as they are.

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



Joined: 23 Sep 2009
Posts: 2

PostPosted: Mon Feb 08, 2010 2:30 pm    Post subject: Reply with quote

karlH wrote:
There's no selection criteria for prevention of listener movement. I suppose the listener could issue a header to exclude them but it sounds like you want to have a local relay to act as a holding point. eg

live.ogg fallas back to /fallback.ogg
/fallback.ogg is a local relay of /auto.ogg (on-demand is allowed).
ST sits on /auto.ogg and is not overridden, but always has 2 listeners (ST and the local relay).
Ogg players are either on /live.ogg or /fallback.ogg
The mp3 streams would stay as they are.

karl.


Thanks karl, I have implemented something like this:

added auto-int.ogg as an internal, hidden stream, to which one off the ogg sources connects. ST uses this to create auto.mp3 and never gets overriden.
converted auto.ogg to a relay of auto-int.ogg. Ogg clients connect to this, either intentionally, or when falling back from live.ogg.

Thus actual listeners use auto.ogg as fallback, while ST is using auto-int.ogg and does not get moved around when the live.ogg source connects.

Thanks again, hope this helps others too.

I am posting below 2 simple start and stop scripts for ST I am using. They use /etc/StreamTranscoder/mountname (eg /etc/StreamTranscoder/auto.ogg/) directories to run ST, so ST config files must be placed there. Icecast calls these scripts with the on-connect and on-disconnect options, when the respective source connects, to start and stop the transcoding:

start.sh:
Code:

#!/bin/sh


if [ -d /etc/streamTranscoder$1 ]

then

        cd /etc/streamTranscoder$1
        echo `date` ": Starting transcoding $1" > run.log
        nice -n 19 streamTranscoderv3 -b $1
        echo `date` ": Started succesfully $1" >> run.log
fi


stop.sh :
Code:

#!/bin/sh

if [ -d /etc/streamTranscoder$1 ]
then
PID=`ps xa | grep -v grep | grep "streamTranscoderv3 -b $1" | awk '{print $1}'`
cd /etc/streamTranscoder$1
echo `date` ": Stopping transcoding of $1 ..." >> run.log
kill -9 $PID
echo `date` ": Stopped succesfully!" >> run.log
fi
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 -> Feature Requests 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