I've been experimenting with the https://github.com/googlecast/CastHelloVideo-chrome example application to cast mp3 audio shoutcast streams. I've tried this with the default media receiver and the hosted reference app.
Two things I've noticed so far.
1) The buffer is much too large. If I make a change on the server side of the stream such as next track it takes 70s for the change to happen on the Chromecast output. This is a very similar problem to the default html5 <audio> tag in Chrome making me think it's similar code.
2) The default media receiver (and html5 <audio> tag) doesn't seem to understand embedded ID3 tags in the MP3 stream. Shoutcast streams typically have metadata embedded such as artist, album, track title, track number and so on. But these never get picked up and displayed.
Since the stream is being decoded on the receiver side, I'm not sure if it's going to be possible to do anything about either issue.
Any ideas?
https://code.google.com/p/google-cast-sdk/issues/detail?id=499
There is no need to cross-post the same issue to this community.
When you say logs, you mean the contents of the log window from the Chrome Cast extension settings?
How about the second issue though? That's separate from the one logged in issues. I wanted to try and understand a bit more about what was happening before logging an issue.
The issue tracker isn't a good place for discussion although clearly it works for logging an issue and formally placing it with Google. I kind of assumed this community would be the place for more open discussion about the nature of problems and possible solutions.
I think both issues and the associated issues with html5 <audio> support in Chrome are sufficiently wide to justify feature requests for the defaults.
If that's the case then where do I post the feature request? I guess what's needed is to post feature requests everywhere the problem turns up! ;)
So let's narrow the scope back down to just the Chromecast for this forum. If I use the SDK to tell the Chromecast to load a URL located mp3 stream, the default and styleable media receivers buffer too much and fail to decode the embedded mp3 ID3 tags. So the feature request is to (optionally) be able to reduce the buffer size to <5s, to throw an event when embedded metadata changes and to display the metadata while allowing it too be over-ridden.
If that's not really feasible in the default players, then add some features to the custom receiver player SDK and/or the implementation of the web audio API specifically for decoding audio streams.
The justification for this is the success in the outside world of Shoutcast/Icecast mp3 radio stations. There's 100s of thousands of them. And so better direct support for them would seem to be desirable, especially with Cast for Audio coming up.