Looks good... :-) Did you submit an announce at Audiocoding.com already, or should I do it? Anyway, I just added the info about the new aacPlus support on the SomaFM forum:
Well, making a gmerlin release is hard enough, so it's good
to know, that some other guys spread the news.
I announce it in freshmeat and (starting with this release)
on gnomefiles.org.
A lot of my code in libquicktime was already successfully ported to Max OS X, so I think for gmerlin, there should be
no major problem. AFAIK, the only linux specific stuff in
the whole code is VCD support (should be disabled by
the configure script on non linux systems) and
Soundcard support.
If some Mac OS X guru would like to look into these, I would
happily give advice converning the internal APIs etc.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
OK, I've submitted the Freshmeat announce to Audiocoding.com's news section, and Menno has published it this morning. Furthermore I posted the same on the Linux forum at Doom9.org.
I asked about a Mac OS X port, because VLC is the only player for that platform yet which can decode aacPlus streams.
Greg Ogonowski replied this to my email concerning small vs. capital letters for content-type:
I'm glad you pointed this out, because I just took a look at several different MP3 and AAC streams currently on the Net and I do see it both ways. Currently we are using content-type for SHOUTcast and Content-Type for Icecast2, only because that's what we saw others using, but I don't think it really matters. After a closer look, I see it both ways. We are going to test content-type with Icecast2, and if that works, we will change to that so both SHOUTcast and Icecast2 will be the same from us."
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
At least some versions of shoutcast violate the http
standard by answering with something linke
"ICY 200 OK" instead of "HTTP/1.1 200 OK".
Then comes a header line saying that winamp is required to
play this stream :-D
This is definitely an attempt to prevent non winamp
software from playing this stream, but a very weak one
since all opensource players I know handle the ICY lines correctly.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
ok, gmerlin-0.3.1 is on the wire now.
Please check the homepage for news and details
Looks good... :-) Did you submit an announce at Audiocoding.com already, or should I do it? Anyway, I just added the info about the new aacPlus support on the SomaFM forum:
http://somafm.com/aac/index.html
I'll write an email to Greg Ogonowski, too, because he's always interested in new apps supporting his software (Orban Opticodec-PC). ;-)
Last question: is it possible to port gmerlin to Mac OS X easily?
Well, making a gmerlin release is hard enough, so it's good
to know, that some other guys spread the news.
I announce it in freshmeat and (starting with this release)
on gnomefiles.org.
A lot of my code in libquicktime was already successfully ported to Max OS X, so I think for gmerlin, there should be
no major problem. AFAIK, the only linux specific stuff in
the whole code is VCD support (should be disabled by
the configure script on non linux systems) and
Soundcard support.
If some Mac OS X guru would like to look into these, I would
happily give advice converning the internal APIs etc.
OK, I've submitted the Freshmeat announce to Audiocoding.com's news section, and Menno has published it this morning. Furthermore I posted the same on the Linux forum at Doom9.org.
I asked about a Mac OS X port, because VLC is the only player for that platform yet which can decode aacPlus streams.
Greg Ogonowski replied this to my email concerning small vs. capital letters for content-type:
"Technically, content types are case-insensitive.
http://www.w3.org/TR/REC-html40/types.html#h-6.7
I'm glad you pointed this out, because I just took a look at several different MP3 and AAC streams currently on the Net and I do see it both ways. Currently we are using content-type for SHOUTcast and Content-Type for Icecast2, only because that's what we saw others using, but I don't think it really matters. After a closer look, I see it both ways. We are going to test content-type with Icecast2, and if that works, we will change to that so both SHOUTcast and Icecast2 will be the same from us."
Oops, you are right and gmerlin already uses strcasecmp, so
it's also ok. But this one is the right link:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2
(We're talking about http not html :-)
At least some versions of shoutcast violate the http
standard by answering with something linke
"ICY 200 OK" instead of "HTTP/1.1 200 OK".
Then comes a header line saying that winamp is required to
play this stream :-D
This is definitely an attempt to prevent non winamp
software from playing this stream, but a very weak one
since all opensource players I know handle the ICY lines correctly.