Getting ready for showtime
MAX is now underway and to celebrate this we just released another prerelease of Flash Player 9 Update 3 code named 'Moviestar', the version is 9.0.64.0.There have been numerous changes and fixes since the last beta, especially in the area of MP4, H.264 and AAC support. I figured I should summarize the bugs we fixed. In this area only as I was not able to keep track of the other stuff. As a warning, this is highly technical stuff, but I know that some wanted this information.
- A frame ordering issue when using more than 1 reference frame has been fixed. There should be no limit anymore on how many reference frames can be used.
- One multi core systems H.264 streams using the loop filter showed artifacts along the slice boundaries. This has been fixed by switching from sliced based multi threaded decoding to picture based multi threaded decoding.
- Overlaying flash content would sometimes cause black artifacts during a seek because the underlying YUV buffer was invalid.
- AAC streams would sometimes not play back if it contained SBR information. This usually happened when switching between SBR and non-SBR streams.
- The H.264 codec would crash on octo (8) core machines.
- AAC streams with sample rates higher than 44.1Khz could crash the Flash Player.
- Corrupt or fuzzed AAC streams could crash the Flash Player.
- The H.264 codec now supports FMO decoding, PicAFF and MBAFF decoding should be improved.
- H.264 decoding should generally be about 10-15% faster because of the removal of a full frame copy. Note that this is only the case if a square pixel ratio is used, the video stream is not interlaced or cropped on the top, left or right.
- The PPC version of the H.264 codec would call kill() during certain situations which resulted in a user experience similar to a crash. The reason behind this was the incorrect behavior of assert() in release builds under CodeWarrior.
- The H.264 codec now has AltiVec versions for all the functions which are accelerated by MMX and SSE2 SIMD instructions on x86. Note that due to the extremely low available memory bandwidth of G4 and G5 PowerPC processors the overall performance will never match x86 CPUs. Refer to our system requirements page which should be up once the final version of MovieStar is released.
- The mp4 parser will now parse variable chunk sizes correctly. Usually this bug manifested itself in bad or accelerated AAC audio playback.
- The mp4 parser should now be much more robust when encountering corrupt or fuzzed files. Two new NetStream events have been added to capture invalid or unsupported files: NetStream.Play.FileStructureInvalid and NetStream.Play.NoSupportedTrackFound.
- The H.264 codec could crash when trying to decode unsupported profiles like Extended, High 4:2:2 and High 4:4:4.
- Past onImageData and onTextData events are now resent when seeking. This f.ex. allows previewing of cover art when scrubbing pod casts and will assure you will get the current timed text for any particular time. Note that also means that you will receive a lot of these events during a seek.
- supported AAC aot types are now correctly parsed and validated, meaning we allow aot types 1, 2 and 5.
- Some encoders (like Handbrake) embed aspect ratio information into the matrix of the track header box atom, which is inconsistent with ISO 14496-12. Despite this the Flash Player will now apply this matrix on the reported width and height in the onMetaData object. This does not affect the actual video stream size which can be different from what is reported in onMetaData and in this case usually points to a bug in the encoder.
- Artifacts on the right and the bottom when mixing cropping and aspect ratios in H.264 streams should be gone.
- Along with times, the seek points array will now also contain a byte offset which allows to determine if a particular seek point is reachable during a progressive download.
- There is an injection concerning scrubbing H.264 files. Currently no images are shown during scrubbing. You have to resume playback before the video is updated. There is a one line fix I have which did not make it in time for the 9.0.64.0 build.
- When playing back video using FMS you can end up in a situation where you get 1 black frame when seeking. Another minimal low risk change will address this for the final build.
- AAC streams using SBR do not play back in certain situations if the original sample rate is higher than 24Khz.
- We still do not support Extended, High 4:2:2 or High 4:4:4 profiles. Unfortunately the most commonly non-professional codec out there which is x264 does not adhere to standard terminologies when specifying encoding options. This means you will likely run into a case were you encode using options which are part of the profiles we do not support. The most common option you will want to use is 4:4:4 support to obtain screen casts without YUV artifacts. This is not a bug, although I am sure we will continue to get reports on that. I strongly suggest you stick with Adobe's AME encoder which uses standardized terminologies defined in the H.264 specifications.
- On the more controversial side we decided to postpone support for H.264 color profiles as the risk of adding tons of new SIMD code was too high at this point in time. Like MPEG-2 default H.264 streams use the color profile standardized under ITU-R BT.709 and in addition allows the selection of 6 more less frequently used color profiles. The streams will be displayed under the assumption that the content is ITU-R BT.601 meaning it will be a little brighter and slightly color shifted if the encoder did use ITU-R BT.709. Video buffs will frown upon this, but most end users will probably not notice it. We'll try to address this in one of the next versions of the Flash Players. I realize that it is important. For designers this also means that color matching with other Flash content will be more tricky for now.
- A more sophisticated way of displaying field coded streams which we had prototyped but were not able to fully test will not make it into the final release. So field coded streams will simply be frame blended.
- Corrupt AAC or H.264 streams or audio dropouts caused by the underlying OS can cause bad audio/video sync. This is due to an architectural limitation of the Flash Player which we will try to remedy for the next major version of the Flash Player, code named Astro.
posted by Tinic Uro at 12:31 AM
9 Comments:
Great work, all my HD streams are playing nicely now!
Are there any plans to enable fast start on videos that do not support it (without the file fix)? There are still a lot of old videos, especially video podcasts that have the headers at the end of the file. Would it be possible to try and do a partial request on the end of the file to try and grab the header first?
Sound for flash seems to have broken on me since upgrading to the beta of Ubuntu Gutsy. I also just grabbed this new beta and still no sound :(
Is there a way to create an FLV container for h264 video?
I haven't found any information about required mime types for progressive download playback of the different formats. When should I use audio/3gpp, audio/mp4, audio/x-m4a, audio/x-m4b, video/3gpp, video/mp4, video/quicktime, video/x-m4v?
Does anyone know when this version of the player will leave BETA?
Thank you.
Hmmm... playback of my x264 streams is very jerky. Tons of lost frames.
Playback via ffdshow or CoreAVC is super-smooth.
The post makes it sound as though you're near final here - and that worries me.
Isn't it taking ages for the appl. to come out of BETA? Hopefully, the wait ends ASAP.
Hello, i need a kind of mixer in flash that can get a list of small mp3 (4s) to generate a new one made by all of them in sequence. Anyone have any suggestion? Thank you.
"extremely low memory bandwidth" on G5s? Excuse me? The last G5s had 8.5 Gbyte/s memory, even the earliest models from 2003 had 6.4 Gbyte/s, which should both be more than adequate for any H.264 replay! In fact, H.264 should be more about the caches anyway, compared to e.g. DivX, which is probably more traffic on the bus - and which plays fine in HD on a lowly G4 Mac mini even (1.3 Gbyte/s!), thank you very much!
Adobe Flash people should better be working on un-making Flash "teh slow" on OS X (no matter if it's PPC or x86 - try flashbench on Windows and OS X!). I always considered it a fabulous idea to make your own vector- and video-system and embed it in another vector- and video-system (=Quartz), seems like some kind of sick russian doll joke to me.. But then again Adobe was never known for efficiency, as long as it saves them some work in properly supporting a platform they're always ready to blame "slow hardware"...
Post a Comment
<< Home