We're a webcasting and slides sharing services company. Flash 11.4 is not working for our Live Webcast Flash player for Mac+Safari, Mac+FireFox, or PC+FireFox.
The problem is limited to a specific player used for live audio-only webcasts, and not the players used for replays or audio+slides events, which use different players.
Any ideas on how we can fix this?
@Joel_IT - Do you have a URL I can try? Does this reproduce with Firefox 15 on Windows?
@biggyspender - Thanks for adding the bug. If possible, I'd recommend noting the browsers and operating systems you've seen this occur on. I saw you mention Windows 2008, does it also happen with Win7?
Chris: We use a couple of different players, one works and one does not. These are live-streaming events, so posting links for the next several hours.
Live until 12:30PM to 4:30PM Pacific:
4:35 PM to 8:50 PM Pacific:
8:55 PM to 1:10 AM Aug 30 Pacific:
@joel_IT - Thanks, I was able to reproduce this. I'd recommend, opening a new bug at bugbase.adobe.com and including a stream that will be available in the future for testing against. You're bug might be the same as biggyspender, but having two open can't hurt. I've been able to reproduce the problem with your stream so I'd like to follow up internally. Once you get the bug report entered, please let me know the bug number.
I took a look at @Joel_IT's swf's with a decompiler. The failure case (singlemp3player.swf) is an AVM1 swf using Sound object, just as I describe in my bug report. The working player is AVM2 (SlidesPro.swf).
With regards to platforms that I can reproduce on, we only use server2008 r2 x64 in our office, so I cannot confirm other platforms.
I did find this thread on the web that suggests that this is not isolated to Windows platforms:
@Joel_IT, in answer to your question on the bugbase, you can't "tell" Flash to use AVM2. The choice of virtual machine that FlashPlayer uses is determined by the SWF being played. Old style swf files authored with the ActionScript1/2 language use AVM1, new swf files written using ActionScript 3 will cause AVM2 to be used. The two types of SWF (AVM1/AVM2) are completely incompatible with one another.
As an aside, the behaviour of mp3 streaming in AVM1 and AVM2 is subtly different. The AVM1 sound object is considerably more resilient to switching of bitrate (something we see on radio streams with a "banner" at the start, something like "you're listening to radio xxx" that plays before the music). Sometimes after the banner, AVM2 sound stutters and plays back incorrectly. AVM1 does not display this behaviour which makes it considerably better suited to radio stream playback. This is why we continue to use AVM1 on radiotuna.com for mp3 stream playback (other than if we detect broken FP11.4, in which case we switch to an AVM2 swf). If this issue remains, I think I'll open a bug on this issue too.
The following stream switches from 320kbps to 128 kbps (yes, this is bad practice by the broadcasters, but mainly they're non-techie so they don't have much of a clue anyway) :
plays fine in AVM1 (pre FP11.4 of course). Stops working in AVM2.
I talked with the dev manager for audio and video and while we are trying to slowly phase out AS2/AVM1, this change was un-intentional. I'm creating an internal bug and we'll start investigating.
Good to know. Would be great to get this fixed asap. We serve ~a million widgets a month to 3rd party web pages that rely directly on this API. Rewriting in AVM2 would be a lengthy and unscheduled diversion from current work. I think I'll definitely file a report about the difference in behaviour between AVM1/2 if AVM1 is going away. Is there any kind of statement on the phasing out? Time schedule? When would we need to consider upgrading to AVM2?
Good to know, if you can add a comment to your bug report with the buisness impact, it'll help us prioritize this issue.
I don't know of any official announcement for AVM1, and I wouldn't worry about any changes happening without a long announcement lead. You can find out about our roadmap and any future changes here: http://www.adobe.com/devnet/flashplatform/whitepapers/roadmap.html
Chris: Here's a page that clearly demonstrates the problem with both working and non-working versions:
The event on the above page refers to a specially modified web server
that I am running on my machine at home, which we only intend to leave a
web server running long enough for Adobe to examine the problem.
We would prefer to hear back from you guys when they have adequately used
the above to isolate the problem, but if we haven't heard anything by
the middle of next week, anticipate disabling this web server unless
you specifically re-contact us to re-enable the demonstration case.
We have tested this with two Windows/7 configurations:
1) Firefox 14.0.01 on Windows/7 with flash 11.1 -- that combination
WORKS for both cases on the above page.
2) Firefox 15.0 on Windows/7 with flash 11.4 -- that combination
FAILS for the second case.
In the case where it works, the audio will start playing within the
first few seconds. In the case where it doesn't work, the progress bar
zips along, and eventually the flash player resets the TCP connection
on data coming from the server. Occasionally, I would see the browser
lock-up, requiring a restart when experiencing the error case.
Supplemental Info from my developer:
Regarding any correspondence you may have with Adobe about our flash
11.4 problem, I spent all evening doing packet captures and changing
experimental server code in an attempt to find a way to avoid
triggering the flash 11.4 problem.
Fortunately, I did discover something interesting/useful.
Whenever live audio is streamed from an HTTP server, it is standard
practice (in widespread use) for the server to NOT include a
Content-Length field in the HTTP response header, because if it is a
live stream, there is no way to know how long the stream will be at the
point that the stream starts.
After exhaustive testing this evening, the only way I could get a live
stream to play with Firefox on Windows/7 directly with flash 11.4 was
to include a Content-Length: header field with a bogus somewhat-large
value. In that case it works, at least testing with the flash player
that I experimented with last night.
I don't plan to make a change to our server if we have any other
solution available to us, because such a change is known to be wrong
for other cases. For example, no matter what I set the Content-Length
value to, if the webcast ever reaches that size, the stream would stop
playing right there. If we make the Content-Length super-huge, then the
navigation slider won't work, but at least the live streaming audio
plays with at least Windows Firefox 15 and flash 11.4.
It may be of help for Adobe to know that if a Content-Length: header is
supplied, that it materially effects the occurrence of the problem, so
please feel free to pass this along to Adobe.
Europe, Middle East and Africa