View previous topic :: View next topic |
Would you like to see stream transcoding in Icecast server? |
yes |
|
65% |
[ 17 ] |
no |
|
34% |
[ 9 ] |
|
Total Votes : 26 |
|
Author |
Message |
Anonymous Guest
|
Posted: Sat Jul 02, 2005 12:38 am Post subject: REQ: Icecast - built-in stream transcoding |
|
|
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
|
Posted: Sat Jul 02, 2005 10:52 am Post subject: Re: REQ: Icecast - built-in stream transcoding |
|
|
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
|
Posted: Sat Jul 02, 2005 11:09 pm Post subject: Re: REQ: Icecast - built-in stream transcoding |
|
|
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.
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
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sun Jul 03, 2005 2:09 am Post subject: Post subject: Re: REQ: Icecast - built-in stream transcoding |
|
|
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 |
|
|
Anonymous Guest
|
Posted: Sun Jul 03, 2005 6:38 am Post subject: |
|
|
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
|
Posted: Wed Sep 23, 2009 10:45 am Post subject: Prevent auto fallback? |
|
|
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 |
|
|
karlH Code Warrior
Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Wed Sep 23, 2009 1:01 pm Post subject: |
|
|
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 |
|
|
morpheus
Joined: 23 Sep 2009 Posts: 2
|
Posted: Mon Feb 08, 2010 2:30 pm Post subject: |
|
|
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 |
|
|
|
|
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
|