| View previous topic :: View next topic |
| Author |
Message |
jaddle
Joined: 14 Jan 2010 Posts: 5
|
Posted: Sat Jan 16, 2010 1:39 am Post subject: fallback streams and truncated frames and flash |
|
|
WARNING - I *might* not know what I'm talking about here. This is all very new to me, but I've been reading a lot of docs online, and I think I've got an idea of what's happening. Apologies if I'm totally wrong!
I have a server set up with fallback streams. it works wonderfully when I play the streams with mplayer, or just about any other client. But with flash, I get all sorts of audio glitches as soon as the fallback happens.
After digging around with a hex editor, I found that icecast seems to switch over in the middle of a frame, instead of finishing it off. That's reasonable, since I know icecast doesn't actually pay any attention to the stream that it's sending out, but just passes on the data. Unfortunately, it seems that flash DOES mind, and get rather confused and plays poorly as soon as the switchover happens - either it stops entirely, or else keeps playing but with regular little glitches every second or two, where it just pauses the playback. (different flash mp3 players seem to pause for different amounts of time - flowplayer often seems to pause for about half a second!)
So, do I have any options at this point? Is there any way that icecast could be made to at least listen for a frame boundary before switching over to/from the fallback? |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat Jan 16, 2010 2:32 am Post subject: |
|
|
You have the basic issue already. Obviously code can be inserted into icecast to parse these non-free formats like mp3 and aac but there's also nsv. While you could organise the internal blocks to contain whole frames, you would still need to deal with the case of short writes at the point of the move (you could copy it to a per-listener specific block as it should not be that common).
karl. |
|
| Back to top |
|
 |
jaddle
Joined: 14 Jan 2010 Posts: 5
|
Posted: Sat Jan 16, 2010 6:46 pm Post subject: |
|
|
Hmm. Any idea how much work might be involved in getting icecast to do that? Would it be a worthwhile endeavour? And by 'nsv' do you mean the container format?
Oddly enough, I could have sworn that this actually worked fine a year or so ago - I wonder if previous versions of flash handled shortened mp3 frames better? |
|
| Back to top |
|
 |
karlH Code Warrior

Joined: 13 Jun 2005 Posts: 5476 Location: UK
|
Posted: Sat Jan 16, 2010 7:09 pm Post subject: |
|
|
The non-ogg handler just reads into blocks of a little over 1k, what you want is to process those blocks a little further by locating those markers and sizing the block accordingly. I could see a function handler being called (from a complete read) based on the content type and within that function match for what you need. A default setting could be to do the current behaviour but then you would setup functions for aac, mp3 and nsv.
players have to do this sort of stuff because they will be decoding and I think most will actually do the resync at the beginning, but obviously Flash does not do that midstream.
karl. |
|
| Back to top |
|
 |
|