I've been experimenting with the <a rel="nofollow" target="

Julian Bond - 2015-02-01 12:44:40+0000 - Updated: 2015-02-01 12:44:40+0000

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?

googlecast/CastHelloVideo-chrome

Leon Nicholls - 2015-02-01 16:05:18+0000

Provide logs and a sample stream for your bug:
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.

Julian Bond - 2015-02-01 17:15:31+0000

Sample stream: http://ice.somafm.com/groovesalad

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.

Ali Naddaf - 2015-02-01 18:35:02+0000

On your second issue, the default receiver doesn't attempt to grab any info from the ID3 tags, if you need such a thing, you need to write your own custom receiver.

Alessandro Martellucci - 2015-02-02 07:06:12+0000

Custom Receiver! The MediaPlayer JavaScript object is just a wrapper of Video/Audio HTML5 tag. Further, the guidelines suggests to listen to that tag's events in order to make custom receiver web app decoupled from Google Cast technology. So custom receiver, I mean.

Julian Bond - 2015-02-02 07:29:05+0000

I've been digging into the SDK docs and I can see this is going to require considerable yak shaving and is probably beyond me!

I think both issues and the associated issues with html5 <audio> support in Chrome are sufficiently wide to justify feature requests for the defaults.

Ali Naddaf - 2015-02-02 16:21:20+0000

If you have suggestion or feature requests for Chrome in general, please use their forums and issue tracker to file those. If you have a specific feature request for Google Cast, use our issue tracker to file one.

Julian Bond - 2015-02-05 08:18:11+0000

Let's say for the moment that the problem here is the html5 implementation of audio mp3 stream decoding. This problem is common to all examples of implementations of html5 audio. That is Chromecast, Chrome and actually non-Chrome browsers as well. All the implementations follow the HTML5 spec for the <audio> tag and quite possibly all use the same ffmpeg libraries.

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.