Patch to support Real Audio / Windows Media streaming on Linux

[Peter Heslin]

I have got a new version of alienstream, the plugin for the old version
of the server that enabled listening to Real Audio and Windows Media
streams under Linux. It works by calling external players (mplayer for
Windows media, which can also play ogg streams, etc., and trplayer for
Real Audio). This is not a plugin, as it was for the old server, but is
a standalone Perl app that is named in convert.conf, and is then called
to stream the URL passed and convert the result to mp3 (or wav, for
Squeezebox) whenever the relevant contentType is encountered by the Slim
server.

In order for the new alienstream to work, however, it was necessary to
make a few changes to the server code. I suggested the idea for these
changes in an earlier email, but had little response, so I don't know if
they will be acceptable.

The smaller change is to add the setting of two environment variables
before launching the transcoder; these allow the external transcoder app
to manipulate the client display via the CLI.

The larger change is the addition of another configuration file,
transport.conf, which is a simple list of contentTypes that the Slim
Server should not attempt to do anything with, but rather leave entirely
for a helper app to deal with the network transport. These
configuration details are accessible via a function called
queryTransport, and I have changed all places in the server where
openRemoteStream is called so that they respect this setting, in order
that the Slim server does not attempt to stream the content if the
contentType is listed in transport.conf. This is necessary, because
otherwise the server hangs when it attempts to contact http: URLs with
Real audio, etc at the other end, even if it is just scanning a playlist
with such a URL included.

I am aware that it is undesirable to add configuration files
indiscriminately, but in this case, it seemed to me that the
functionality was orthogonal to that of convert.conf (where behavior
depends on client type as well as content type) and types.conf (which
defines the nature of types, rather than what to do with them). I am
open to suggestions that I am wrong here. I note that types.conf has
just had another column added to it by Dan Sully, and one possibility
would be to add yet another column to indicate whether the Slim server
should handle network transport for that particular contentType or not.

For non-Linux users and those without alienstream there should be no
impact: if the file transport.conf is absent, the server's behavior
should not change in any way. In fact, it would be better if the
transport.conf file had no entries at all as normally distributed.
Users who install alienstream could then add the ram, asx, etc.
contentTypes as required.

I have not tried to integrate this with Dan Sully's new support for WMA
files (not streams) -- I'm not sure whether the metadata is available
in like manner for Windows Media streams.

I'll attach the new code for alienstream itself (which is not quite
finished) and its config file (to go in /etc/alienstreamrc) along with
the patch for application to the server code. The recursive diff is
against the nightly build of 2003-12-06. If I need to change it in
order to get it applied, just let me know.

Peter

[dean]

Thanks Peter, sorry for the lack of feedback. We've been, um, busy.

Can you work with Dan and Tapani to reconcile all the WMA efforts so
that we have a single simple solution that works cross-platform?

On Dec 6, 2003, at 4:31 PM, Peter Heslin wrote:

> I have got a new version of alienstream, the plugin for the old version
> of the server that enabled listening to Real Audio and Windows Media
> streams under Linux. It works by calling external players (mplayer for
> Windows media, which can also play ogg streams, etc., and trplayer for
> Real Audio). This is not a plugin, as it was for the old server, but
> is
> a standalone Perl app that is named in convert.conf, and is then called
> to stream the URL passed and convert the result to mp3 (or wav, for
> Squeezebox) whenever the relevant contentType is encountered by the
> Slim
> server.
>
> In order for the new alienstream to work, however, it was necessary to
> make a few changes to the server code. I suggested the idea for these
> changes in an earlier email, but had little response, so I don't know
> if
> they will be acceptable.
>
> The smaller change is to add the setting of two environment variables
> before launching the transcoder; these allow the external transcoder
> app
> to manipulate the client display via the CLI.
>
> The larger change is the addition of another configuration file,
> transport.conf, which is a simple list of contentTypes that the Slim
> Server should not attempt to do anything with, but rather leave
> entirely
> for a helper app to deal with the network transport. These
> configuration details are accessible via a function called
> queryTransport, and I have changed all places in the server where
> openRemoteStream is called so that they respect this setting, in order
> that the Slim server does not attempt to stream the content if the
> contentType is listed in transport.conf. This is necessary, because
> otherwise the server hangs when it attempts to contact http: URLs with
> Real audio, etc at the other end, even if it is just scanning a
> playlist
> with such a URL included.
>
> I am aware that it is undesirable to add configuration files
> indiscriminately, but in this case, it seemed to me that the
> functionality was orthogonal to that of convert.conf (where behavior
> depends on client type as well as content type) and types.conf (which
> defines the nature of types, rather than what to do with them). I am
> open to suggestions that I am wrong here. I note that types.conf has
> just had another column added to it by Dan Sully, and one possibility
> would be to add yet another column to indicate whether the Slim server
> should handle network transport for that particular contentType or not.
>
> For non-Linux users and those without alienstream there should be no
> impact: if the file transport.conf is absent, the server's behavior
> should not change in any way. In fact, it would be better if the
> transport.conf file had no entries at all as normally distributed.
> Users who install alienstream could then add the ram, asx, etc.
> contentTypes as required.
>
> I have not tried to integrate this with Dan Sully's new support for WMA
> files (not streams) -- I'm not sure whether the metadata is available
> in like manner for Windows Media streams.
>
> I'll attach the new code for alienstream itself (which is not quite
> finished) and its config file (to go in /etc/alienstreamrc) along with
> the patch for application to the server code. The recursive diff is
> against the nightly build of 2003-12-06. If I need to change it in
> order to get it applied, just let me know.
>
> Peter
>
> <alienstream.diff><alienstream><alienstreamrc>____ _____________________
> ______________________
> Developers mailing list
> Developers (AT) lists (DOT) slimdevices.com
> http://lists.slimdevices.com/lists/listinfo/developers

[Peter Heslin]

On Sat, Dec 06, 2003 at 05:00:47PM -0800, dean blackketter wrote:
> Thanks Peter, sorry for the lack of feedback. We've been, um, busy.
>
> Can you work with Dan and Tapani to reconcile all the WMA efforts so
> that we have a single simple solution that works cross-platform?

I have just taken a look at Tapani's WmaStream.pm, and it looks like, if
my patch were applied to the server source, it would become possible to
rewrite it so that a plugin is no longer necessary, in much the same way
that I have rewritten Alienstream.pm so that it is now a command-line
tool.

Then, it would simply be a matter of adding a line to convert.conf like
this:

asx mp3 * *
wmatool $URL$

With a single line reading "asx" in transport.conf

(this imagines a slightly different version of wmatool that writes mp3
output to STDOUT rather than to a tcp/ip port).

The advantage would be that you would no longer have to edit the plugin
or a plugin configutation file in order to add new streams. The Slim
server would now just know how to handle Windows Media streams whereever
it found them. For example, someone could write a plugin much like my
ShoutcastBrowser.pm which would provide a browser for the WMA streams at
http://windowsmedia.com/mediaguide/radio/

The problem, in other words, with providing new music capabilities via a
plugin is that other plugins cannot easily build on that capability.
For example, I have had an e-mail from someone who would like to write
an app that puts together playlists of the Real Audio archives of BBC
radio; this becomes much simpler if all that app has to do is put the
playlists together, rather than also decoding the proprietary audio.

I wonder if Tapani would be interested in this approach? If he is not
interested, I could hack the new version of alienstream so that it uses
his wmatool when running under Windows, instead of mplayer -- but I
don't use Windows much, so I would be reluctant to maintain it myself.

I don't think an intergrated cross-platform solution to the streaming of
proprietary audio formats is going to be easy to achieve, since this
hypothetical solution will be calling platform-dependent binaries and
libraries. On the other hand, my patch makes it very easy to call
platform-dependent code from the server: just add the relevant lines to
convert.conf, which points to your platform-dependent player/transcoder.
In any case, I doubt that many of us hobbyists have access to all of the
platforms the Slim server runs on in order to test and maintain this
hypothetical cross-platform solution.

As far as coordination with Dan, I believe that our work is orthogonal.
He has been working on adding knowledge of WMA metadata to the server
(for files only, not streams), whereas I have been implementing a
solution for situations where the server cannot know anything about the
stream it is playing, since it is a proprietary format. I'm not sure if
that is the case with Windows Media streams, but I'm pretty sure it's
the case with Real Audio. I'd be interested to hear from Dan what the
situation is like with metadata for Windows Media streams, as opposed to
files.

Another way to look at this situation is that the patch I provided
removes a false assumption implicit in the server code. The server
currently assumes that it will be able to handle the content of any
stream that begins with http://. This is clearly not the case today,
since the server hangs on HTTP URLs that point to Real Audio streams,
and will not be the case so long as proprietary streaming formats exist.
So long as they exist, there will be a need for external applications to
handle the URL, the network transport, and the transcoding into an open
audio format. Therefore, the server will need a way to identify those
streams that it should not attempt to play.

IMO, the only way that my patch, or something like it, would not be
required eventiually is if you want to add those audio capabilities to
the Slim server itself, which would require making it dependent on
third-party codecs and binary libraries with very restrictive licenses.
That's my impression of having looked at the gory details of the
licensing for Real Audio stuff at https://www.helixcommunity.org/, which
requires payment for commericial products that include the RealAudio
codec.

Peter

[Tapani Jarvinen]

----- Original Message -----
From: "Peter Heslin" <slimp3 (AT) heslin (DOT) eclipse.co.uk>
To: "SlimDevices Developers" <developers (AT) lists (DOT) slimdevices.com>
Sent: Sunday, December 07, 2003 3:44 PM
Subject: Re: [Developers] Patch to support Real Audio / Windows
Mediastreaming on Linux


> I have just taken a look at Tapani's WmaStream.pm, and it looks like, if
> my patch were applied to the server source, it would become possible to
> rewrite it so that a plugin is no longer necessary, in much the same way
> that I have rewritten Alienstream.pm so that it is now a command-line
> tool.
>
> Then, it would simply be a matter of adding a line to convert.conf like
> this:
>
> asx mp3 * *
> wmatool $URL$
>
> With a single line reading "asx" in transport.conf
>
> (this imagines a slightly different version of wmatool that writes mp3
> output to STDOUT rather than to a tcp/ip port).
>

This is almost exactly what I have done with my experiments with the server.
I have updated wmatool so that it can write to stdout. (it can be found in
wmatool.zip at http://www.kolumbus.fi/jewel.tapsta/...WmaStream.html)

The lines I have added to types.conf are:

wma wma audio/wma
mms mms: audio/wma

and to convert.conf:

wma mp3 * *
wmatool -q -e "lame --alt-preset standard - -" $FILE$ -
mms mp3 * *
wmatool -q -e "lame --alt-preset standard - -" $URL$ -

(wmatool needs the mms:// -type URL instead of .asx file.)
This combined with the sligh modifications to the server code so that
it can recognise wma files and mms streams makes it possible to play
those. I believe these modifications are roughly what your patch does.

> I wonder if Tapani would be interested in this approach? If he is not
> interested, I could hack the new version of alienstream so that it uses
> his wmatool when running under Windows, instead of mplayer -- but I
> don't use Windows much, so I would be reluctant to maintain it myself.
>
Sounds reasonable. I believe the updated wmatool (see above) now does
what is required for it to work the way you described.

I can maintain wmatool.

Tapani

[dean]

Thanks, Peter, for looking at this.

My feeling is that we should add the necessary hooks to the server to
support arbitrarary formats in files, via http and other streaming
protocols, using external helpers applications when necessary. It
would be great if we could keep the number of external apps to a
minimum using popular ones (such as LAME and ffmpeg). If they can send
audio to stdout, then we should be able stream it. The mov123 binary
that we include for Mac and Windows does this for AAC/m4a and QuickTime
files, ffmpeg can do it for many others.

Since folks will likely add support for new formats faster than we can
integrate them into the main tree, this should also be supported via
plugins.

The nice thing about the plugin mechanism is that it's just Perl, so
you can add new modules ( for the Slim::Formats::FileType ) that add
meta information extraction if necessary.

Then the issue is about adding content via the plugin mechanism. There
are two ways to achieve this. One is to create a new navigable mode
that lets you select an item via the remote. This is using the
original plugin mechanism and should be easy to achieve.

The second is to allow plugins to register new URL schemes (like http
for new streaming formats. These can be added to playlists, etc. I
started thinking about this (and even added an example line to the
convert.conf file that didn't do anything.) Using this mechanism, one
plugin could create playlists using the new URL scheme and the second
one could provide the intelligence to get them played.

Thoughts?



On Dec 7, 2003, at 5:44 AM, Peter Heslin wrote:

> On Sat, Dec 06, 2003 at 05:00:47PM -0800, dean blackketter wrote:
>> Thanks Peter, sorry for the lack of feedback. We've been, um, busy.
>>
>> Can you work with Dan and Tapani to reconcile all the WMA efforts so
>> that we have a single simple solution that works cross-platform?
>
> I have just taken a look at Tapani's WmaStream.pm, and it looks like,
> if
> my patch were applied to the server source, it would become possible to
> rewrite it so that a plugin is no longer necessary, in much the same
> way
> that I have rewritten Alienstream.pm so that it is now a command-line
> tool.
>
> Then, it would simply be a matter of adding a line to convert.conf like
> this:
>
> asx mp3 * *
> wmatool $URL$
>
> With a single line reading "asx" in transport.conf
>
> (this imagines a slightly different version of wmatool that writes mp3
> output to STDOUT rather than to a tcp/ip port).
>
> The advantage would be that you would no longer have to edit the plugin
> or a plugin configutation file in order to add new streams. The Slim
> server would now just know how to handle Windows Media streams
> whereever
> it found them. For example, someone could write a plugin much like my
> ShoutcastBrowser.pm which would provide a browser for the WMA streams
> at
> http://windowsmedia.com/mediaguide/radio/
>
> The problem, in other words, with providing new music capabilities via
> a
> plugin is that other plugins cannot easily build on that capability.
> For example, I have had an e-mail from someone who would like to write
> an app that puts together playlists of the Real Audio archives of BBC
> radio; this becomes much simpler if all that app has to do is put the
> playlists together, rather than also decoding the proprietary audio.
>
> I wonder if Tapani would be interested in this approach? If he is not
> interested, I could hack the new version of alienstream so that it uses
> his wmatool when running under Windows, instead of mplayer -- but I
> don't use Windows much, so I would be reluctant to maintain it myself.
>
> I don't think an intergrated cross-platform solution to the streaming
> of
> proprietary audio formats is going to be easy to achieve, since this
> hypothetical solution will be calling platform-dependent binaries and
> libraries. On the other hand, my patch makes it very easy to call
> platform-dependent code from the server: just add the relevant lines to
> convert.conf, which points to your platform-dependent
> player/transcoder.
> In any case, I doubt that many of us hobbyists have access to all of
> the
> platforms the Slim server runs on in order to test and maintain this
> hypothetical cross-platform solution.
>
> As far as coordination with Dan, I believe that our work is orthogonal.
> He has been working on adding knowledge of WMA metadata to the server
> (for files only, not streams), whereas I have been implementing a
> solution for situations where the server cannot know anything about the
> stream it is playing, since it is a proprietary format. I'm not sure
> if
> that is the case with Windows Media streams, but I'm pretty sure it's
> the case with Real Audio. I'd be interested to hear from Dan what the
> situation is like with metadata for Windows Media streams, as opposed
> to
> files.
>
> Another way to look at this situation is that the patch I provided
> removes a false assumption implicit in the server code. The server
> currently assumes that it will be able to handle the content of any
> stream that begins with http://. This is clearly not the case today,
> since the server hangs on HTTP URLs that point to Real Audio streams,
> and will not be the case so long as proprietary streaming formats
> exist.
> So long as they exist, there will be a need for external applications
> to
> handle the URL, the network transport, and the transcoding into an open
> audio format. Therefore, the server will need a way to identify those
> streams that it should not attempt to play.
>
> IMO, the only way that my patch, or something like it, would not be
> required eventiually is if you want to add those audio capabilities to
> the Slim server itself, which would require making it dependent on
> third-party codecs and binary libraries with very restrictive licenses.
> That's my impression of having looked at the gory details of the
> licensing for Real Audio stuff at https://www.helixcommunity.org/,
> which
> requires payment for commericial products that include the RealAudio
> codec.
>
> Peter
>
>
>

[Peter Heslin]

On Sun, Dec 07, 2003 at 07:45:41AM -0800, dean blackketter wrote:
> Thanks, Peter, for looking at this.
>
> My feeling is that we should add the necessary hooks to the server to
> support arbitrarary formats in files, via http and other streaming
> protocols, using external helpers applications when necessary.

No need to add any hooks -- the functionality is already there. The
only thing that prevents external apps from accessing and transcoding
remote streams for the Slim server is the assumption that the Slim
server should try to access all http:// URLs itself. All that is needed
is a way to tell the server not to do this. That's all my patch does.

> It
> would be great if we could keep the number of external apps to a
> minimum using popular ones (such as LAME and ffmpeg).

Wouldn't it be better if we could support all external apps, both
popular and unpopular?

> If they can send
> audio to stdout, then we should be able stream it.

Yes, and the server can already do this, except for the fact that
whenever the server currently sees an http:// URL, it *always* tries to
access that stream itself, instead of sometimes leaving it to an
external app, which will provide audio to stdout.

> The mov123 binary
> that we include for Mac and Windows does this for AAC/m4a and QuickTime
> files, ffmpeg can do it for many others.

These are for files, not streams, so your examples avoid the whole issue
of network transport, which is the problem I have been bumping up
against. If you want to have the Slim server handle transport for Real
Audio and Windows Media, etc., and have ffmpeg handle the audio
conversion, then you will have to build enough intelligence into server
so that it can handle the proprietary transport protocols and the
various types of indirection that these formats use.

Take a Real Audio example. The Slim server would have to first download
a file called http://blah.example.com/stream.ram. Then it parses
stream.ram, and discovers the rtsp:// address(es) embedded within it,
and initiates an rtsp session with one of those servers, and only then
would it be able to call ffmpeg or whatever to decode the audio. Who
will write this code? The .ram and .asx file formats seem fairly
simple, but are they always so? Are they documented? What about the
proprietary transport protocols? Is rtsp documented?


> Since folks will likely add support for new formats faster than we can
> integrate them into the main tree, this should also be supported via
> plugins.

Or via external binaries called from convert.conf. Why not?

> The nice thing about the plugin mechanism is that it's just Perl, so
> you can add new modules ( for the Slim::Formats::FileType ) that add
> meta information extraction if necessary.

And the nasty thing about plugins is that they force you to implement a
complex and inflexible solution to what may be a fairly simple problem.

> Then the issue is about adding content via the plugin mechanism. There
> are two ways to achieve this. One is to create a new navigable mode
> that lets you select an item via the remote. This is using the
> original plugin mechanism and should be easy to achieve.

Is this different from what my old AlienStream.pm did or what Tapani's
WmaStream.pm does?

> The second is to allow plugins to register new URL schemes (like http
> for new streaming formats. These can be added to playlists, etc. I
> started thinking about this (and even added an example line to the
> convert.conf file that didn't do anything.) Using this mechanism, one
> plugin could create playlists using the new URL scheme and the second
> one could provide the intelligence to get them played.

Is this different in function from what my patch does? It's not a
plugin; that's the only difference. It's just one line in
transport.conf to tell the server not to touch a particulat contentType,
and then another line in convert.conf, which tells the server what app
to launch in order to stream that contentType.

Then you could write a plugin that "creates playlists using the new URL
scheme". In fact, that's just what I suggested in my last e-mail as one
of the benefits of this approach.

The fact that both Tapani and I started out by writing transcoding
plugins and have been moving towards trying to integrate this
functionality more closely with the server's handling of URLs, I think
may indicate that we both found the plugin approach a bit inflexible --
well, I did anyway.

It was your example line in convert.conf that inspired the approach I
have taken. Or did I misunderstand what you meant by this?

rts mp3 * *
rtsp_player $URL$ -


Essentially, what I discovered was that your hypothetical code won't
work as the server is currently written, since rtsp_player will never be
launched and will never see the $URL$. What will happen is that the
server will wrongly try to access $URL$ using openRemoteStream(), and it
will hang forever, since the server doesn't actually speak rtsp.

With my patch, your hypothetical example would actually work (assuming
that you really had a program named rtsp_player and that you defined rts
correctly in types.conf and included it in transport.conf).

Peter

[Peter Heslin]

On Sun, Dec 07, 2003 at 05:38:52PM +0200, Tapani Jarvinen wrote:
> > (this imagines a slightly different version of wmatool that writes mp3
> > output to STDOUT rather than to a tcp/ip port).
> >
>
> This is almost exactly what I have done with my experiments with the server.
> I have updated wmatool so that it can write to stdout. (it can be found in
> wmatool.zip at http://www.kolumbus.fi/jewel.tapsta/...WmaStream.html)

Great minds think alike!

> ...

> This combined with the sligh modifications to the server code so that
> it can recognise wma files and mms streams makes it possible to play
> those. I believe these modifications are roughly what your patch does.

If you have any suggestions, based on your experience of implementing
similar functionality, on how my patch might be improved, please say so.

Peter

[dean]

On Dec 7, 2003, at 1:41 PM, Peter Heslin wrote:

> On Sun, Dec 07, 2003 at 07:45:41AM -0800, dean blackketter wrote:
>> Thanks, Peter, for looking at this.
>>
>> My feeling is that we should add the necessary hooks to the server to
>> support arbitrarary formats in files, via http and other streaming
>> protocols, using external helpers applications when necessary.
>
> No need to add any hooks -- the functionality is already there. The
> only thing that prevents external apps from accessing and transcoding
> remote streams for the Slim server is the assumption that the Slim
> server should try to access all http:// URLs itself. All that is
> needed
> is a way to tell the server not to do this. That's all my patch does.
Right, but some streams don't use HTTP but should be able to be
referenced by URLs.

>> would be great if we could keep the number of external apps to a
>> minimum using popular ones (such as LAME and ffmpeg).
>
> Wouldn't it be better if we could support all external apps, both
> popular and unpopular?
Absolutely! But the default settings should be to use the popular
tools to support the popular formats.

>> If they can send
>> audio to stdout, then we should be able stream it.
>
> Yes, and the server can already do this, except for the fact that
> whenever the server currently sees an http:// URL, it *always* tries to
> access that stream itself, instead of sometimes leaving it to an
> external app, which will provide audio to stdout.
Right, and we should fix that.

>> The mov123 binary
>> that we include for Mac and Windows does this for AAC/m4a and
>> QuickTime
>> files, ffmpeg can do it for many others.
>
> These are for files, not streams, so your examples avoid the whole
> issue
> of network transport, which is the problem I have been bumping up
> against. If you want to have the Slim server handle transport for Real
> Audio and Windows Media, etc., and have ffmpeg handle the audio
> conversion, then you will have to build enough intelligence into server
> so that it can handle the proprietary transport protocols and the
> various types of indirection that these formats use.
Right. Use URLs to represent the streams, then be able to pass the
necessary information to the helper apps when one of those streams is
selected to play.

> Take a Real Audio example. The Slim server would have to first
> download
> a file called http://blah.example.com/stream.ram. Then it parses
> stream.ram, and discovers the rtsp:// address(es) embedded within it,
> and initiates an rtsp session with one of those servers, and only then
> would it be able to call ffmpeg or whatever to decode the audio. Who
> will write this code? The .ram and .asx file formats seem fairly
> simple, but are they always so? Are they documented? What about the
> proprietary transport protocols? Is rtsp documented?
Yes, it is. This is the perfect example. The server knows about HTTP.
But it doesn't know about RTSP. So, if it sees a RTSP URL, then it
knows (through some new extension to the content type/convert mechanism
to open a specific helper app.

>> Since folks will likely add support for new formats faster than we can
>> integrate them into the main tree, this should also be supported via
>> plugins.
>
> Or via external binaries called from convert.conf. Why not?
Both.

>> The nice thing about the plugin mechanism is that it's just Perl, so
>> you can add new modules ( for the Slim::Formats::FileType ) that add
>> meta information extraction if necessary.
>
> And the nasty thing about plugins is that they force you to implement a
> complex and inflexible solution to what may be a fairly simple problem.
Not always. They can provide a simple and elegant solution for
implementing a SlimServer specific feature in a way that works
cross-platform and is easy to install.

>> Then the issue is about adding content via the plugin mechanism.
>> There
>> are two ways to achieve this. One is to create a new navigable mode
>> that lets you select an item via the remote. This is using the
>> original plugin mechanism and should be easy to achieve.
>
> Is this different from what my old AlienStream.pm did or what Tapani's
> WmaStream.pm does?
Not at all, I just want to make a standard and flexible API to make it
easier for both of them.

>> The second is to allow plugins to register new URL schemes (like
>> http
>> for new streaming formats. These can be added to playlists, etc. I
>> started thinking about this (and even added an example line to the
>> convert.conf file that didn't do anything.) Using this mechanism, one
>> plugin could create playlists using the new URL scheme and the second
>> one could provide the intelligence to get them played.
>
> Is this different in function from what my patch does? It's not a
> plugin; that's the only difference. It's just one line in
> transport.conf to tell the server not to touch a particulat
> contentType,
> and then another line in convert.conf, which tells the server what app
> to launch in order to stream that contentType.
Great!

> Then you could write a plugin that "creates playlists using the new URL
> scheme". In fact, that's just what I suggested in my last e-mail as
> one
> of the benefits of this approach.
Great!

> The fact that both Tapani and I started out by writing transcoding
> plugins and have been moving towards trying to integrate this
> functionality more closely with the server's handling of URLs, I think
> may indicate that we both found the plugin approach a bit inflexible --
> well, I did anyway.
>
> It was your example line in convert.conf that inspired the approach I
> have taken. Or did I misunderstand what you meant by this?
>
> rts mp3 * *
> rtsp_player $URL$ -
Nope, you got it right.

> Essentially, what I discovered was that your hypothetical code won't
> work as the server is currently written, since rtsp_player will never
> be
> launched and will never see the $URL$. What will happen is that the
> server will wrongly try to access $URL$ using openRemoteStream(), and
> it
> will hang forever, since the server doesn't actually speak rtsp.
Right. I never finished it.

> With my patch, your hypothetical example would actually work (assuming
> that you really had a program named rtsp_player and that you defined
> rts
> correctly in types.conf and included it in transport.conf).
Excellent.

I just want to make sure that we're all working in the same direction.

Some specific questions about your patch:

Will it work cross platform? (i.e. Linux/BSD/Mac/Windows)
Do you think the contents of transports.conf should be rolled into
types.conf and/or convert.conf?

[Peter Heslin]

On Mon, Dec 08, 2003 at 09:20:23AM -0800, dean blackketter wrote:
> Right, but some streams don't use HTTP but should be able to be
> referenced by URLs.

That's easy -- just define the protocol appropriately in types.conf,
such as in your example:

rts rtsp: - -

Then put rts in transport.conf, and the server will also refrain from
attempting to contact all rtsp:// URLs

[snip]

>> Yes, it is. This is the perfect example. The server knows about HTTP.
> But it doesn't know about RTSP. So, if it sees a RTSP URL, then it
> knows (through some new extension to the content type/convert mechanism
> to open a specific helper app.

The problem is that many RTSP streams are not found on the internet as
RTSP URLs, but are embedded in HTTP URLs of filetype .ram, .rm and so
on. So unless the Slim server knows how to parse .ram files, it needs
to know that it should ignore not only rtsp://example.com/stream.rm, but
also http://example.com/stream.ram, which contains a reference to the
RTSP stream.

Otherwise you force Slim users to view and parse manually the .ram files
for the streams they like and then enter in the playlist the RTSP URL,
instead of just entering in the http://...stream.ram URL, which is much,
much handier.

[snip]

>
> I just want to make sure that we're all working in the same direction.

I hope so, since I took my cue from the incomplete rtsp_player example
you supplied in convert.conf. I have just been trying to get that
example working.

>
> Some specific questions about your patch:
>
> Will it work cross platform? (i.e. Linux/BSD/Mac/Windows)

Yes, it should be completely cross-platform. The only thing that is
platform dependent is the line in convert.conf which specifies the
external app to call. This player/transcoder is quite likely to be a
different program on different platforms. For example, a Linux user
might have:

mms mp3 * *
alienstream -wms $URL$ -

Where a Windows user has:

mms mp3 * *
wmatool -q -e "lame --alt-preset standard - -" $URL$ -


This flexibility is probably a good thing, since Tapani's wmatool and my
alienstream are quite different programs and work in somewhat different
ways. I don't want to maintain his Windows tool and I would guess that he
doesn't want to maintain my Linux tool.

If, on the other hand, you want to remove even this platform dependency,
then we could write

wma mp3 * *
$wmaplayer$ $URL$ -

and then hack Slim::Utils::Misc:findbin to substitute for $wmaplayer$
the appropriate command for the current platform.

But convert.conf is already platfom-dependent in exactly this way, since
it includes an entry like this:

mov mp3 * *
$mov123$ $FILE$ | $lame$ --silent -b $BITRATE$ -r $-x$ - -

Well, there's no mov123 binary on my Linux box, so convert.conf is
already platform-dependent in that this entry doesn't work on my
platform; I think a certain amount of that is inevitable, though I take
your point that it would be nice to have the exact same command-line
work on every platform. But that seems a fairly remote dream right now.

> Do you think the contents of transports.conf should be rolled into
> types.conf and/or convert.conf?

I asked this very question on the list when I first started working on a
solution, and then I asked it again when I posted my patch. Here is
what I wrote in my previous e-mails:

[...]

At first, I added an extra column to convert.conf, but that is wrong,
since this has to be a general preference, not specific to a
particular destination device or output format. That didn't work
well, so I just added a new config file, called transport.conf.

[snip description of file]

The other place I considered putting this info is in types.conf,
where there could be a fourth, optional column, where a * (for
example) would indicate that this particular content-type should have
all transport handled by an external program.

[...and from the next e-mail...]

I am aware that it is undesirable to add configuration files
indiscriminately, but in this case, it seemed to me that the
functionality was orthogonal to that of convert.conf (where behavior
depends on client type as well as content type) and types.conf (which
defines the nature of types, rather than what to do with them). I am
open to suggestions that I am wrong here. I note that types.conf has
just had another column added to it by Dan Sully, and one possibility
would be to add yet another column to indicate whether the Slim server
should handle network transport for that particular contentType or
not.

My feeling is that, if you don't want top add another config file, the
"don't do network transport flag" would go much more smoothly into
types.conf than into convert.conf, since it specifies a property of the
contentType, but types.conf has gotten a bit more crowded lately, so it
might make the file too nasty. It's your call.

Peter

[Dan Sully]

* Peter Heslin <slimp3 (AT) heslin (DOT) eclipse.co.uk> shaped the electrons to say...

> Yes, it should be completely cross-platform. The only thing that is
> platform dependent is the line in convert.conf which specifies the
> external app to call. This player/transcoder is quite likely to be a
> different program on different platforms. For example, a Linux user
> might have:
>
> mms mp3 * *
> alienstream -wms $URL$ -
>
> Where a Windows user has:
>
> mms mp3 * *
> wmatool -q -e "lame --alt-preset standard - -" $URL$ -

I don't have much time right now, and will respond more to this thread later,
but I'm trying to make it so that the same tool can be used on all platforms.

ffmpeg is already cross platform, and I'm working on mods to mmsclient to make it work everywhere.

Also - if it can be done in perl, that's much better anyways. Most cleaner C
(and some C++ code) can be converted to perl relatively easily. Then cross platform problems are solved.

-D
--
C program run, C program crash, C programmer cry.