Playing AAC stream

[ganeshjay]

I am trying to play an AAC stream using exoplayer demo. I have only changed the url and not been successful so far. Any help would be appreciated. It always get stuck in the MediaExtractor setDatasource method

1) URL 1 - http://streamcdn.atc-labs.com/AtcStream128.aac This throws an error could not at detect media content at the setDatasource method. 2) URL 2 - http://sc.powergroup.com.tr:80/PowerFM/aac/128/tunein This is not exiting the setDatasource method and keeps reading the stream.

It works for other types of streams.

[ojw28]

• We'll shortly be adding the ability to play AAC without having to rely on the MediaExtractor.
• One question: You don't expect to be able to seek within AAC, right? I don't think it normally exposes any kind of index to help you to do that.

[ojw28]

Correction - It looks like it should be possible to support seeking (since the platform extractor does it).

[ojw28]

Heh. It actually looks like the platform extractor scans through the entire stream to construct an index for seeking. Which is perhaps why it appears to get stuck (this is conjecture). In any case, it appears seeking should not be supported after all.

[ganeshjay]

Seeking is not required, since it is a internet radio broadcast. I suspect it is trying to scan the entire thing to get some media information and since it is continuous stream it gets stuck. Any fix for this will be greatly appreciated.

[ojw28]

I have this more or less working, but it seems like this is fundamentally a bad way to stream audio, particularly to mobile devices.

The client opens a network connection, starts streaming audio, and everything is fine. But what's the client supposed to do when it encounters a network error (which is highly likely over a long period of time on a mobile device, since it may well be switching between WiFi/mobile, or just on a flaky mobile connection etc). It seems like it's impossible for the client to request data starting from exactly where it encountered the error, meaning it's impossible to seamlessly recover from any network error.

Furthermore, it appears to be impossible to distinguish between a live AAC stream such as the PowerFM example, and a non-live AAC file. Desired retry behavior is different in each case, because for the non-live AAC file you want to make a range request starting where you left off, where-as for the live case you want to request starting from a 0 byte offset.

Is that correct? Am I missing something? If I am correct, how exactly is this ever supposed to work nicely on a mobile device, unless it's stationary with a solid WiFi connection?

[mingfai]

just a note that my use case in #389 is, as same as @ganeshjay, for Internet radio broadcast. for this use case, I would argue freshness is more important than seamless recovery. The host may run a live event such as phone-in, or making comment on a live event, a prolonged delay is odd. If the connection is interrupted for 10s or any long enough duration, I actually wish the player just skip the 10s rather than attempting any recovery.

there are other cases that a seamless recovery is preferred, say, for playing movie or TV series. Could ExoPlayer give an option for developer to choose between the two kinds of usage?

[ganeshjay]

Since this is an internet radio broadcast there is no need and now way to resume from where the error occurred nor any way to seek etc. You can only listen from when you tune in. It should resume from where the broadcast is currently streaming like you said from 0 byte offset. It is different from on demand music or video.

[ojw28]

• It's not true to say that there's no way to seamlessly recover for live broadcasts. In all live streaming systems the client player will maintain a small buffer. For this particular case the rate at which the server serves the audio effectively controls the client's buffer size to between 5 and 10 seconds of audio. So if an error occurs, you have between 5 and 10 seconds to recover in a completely seamless way by requesting more data before the buffer fully plays out. HLS and DASH both allow for this type of seamless recovery, and fast recovery is often possible in cases like switching from one network to another, which is why I'm saying that the approach here is inferior (it is).
• Having said that, your points are otherwise valid. It is true that seamless recovery is less important in this case, and that if you can't recover in within the buffer period then seamless recovery isn't possible anyway (and you want to jump forward rather than falling behind the live broadcast).
• We can probably come up with a way of supporting what's required here. Basically, we'd need to disable the existing retry logic (because it doesn't work), wait for the buffer to fully drain, and then retry non-seamlessly.

[ganeshjay]

Thanks for really analyzing the problem in detail and coming up with a solution. This would be of really useful for us.

[ojw28]

This should all work nicely now. For URL (2) in the original report, use TYPE_MP3 in the demo app. It should play nicely, and resume properly when errors occur (unless the outage is extended, in which case the application will be notified of the error). URL (1) doesn't seem to be up any more.

Separately, we're aware that it might be a bit painful to have to know the type of the media prior to playback. We'll be looking at sniffing the format automatically at some point (possibly not particularly soon though).