Tag: Flash Player

The past week has brought a series of announcements from Adobe that has elicited myriad speculation and concern from the Flash Platform and Adobe community.  As a leading Adobe Solutions provider for Flash Platform solutions, RealEyes wants to address these announcements and how we see their impacting our focus in the technological ecosystem.

Before we begin this analysis, from our vantage point, the largest issue with these announcements is the way in which they were communicated—to the public, to partners, everyone.  There was much good news in what Adobe announced; unfortunately, their public relations team chose to focus largely on what was being deprecated, which colored the resulting dialog.

We’d like to take a moment to refocus this conversation for our customers and community.  Contrary to popular debate, Flash is NOT dead.  And here’s why:

Adobe Focus on Mobile Applications

Adobe announced that it would be more aggressively contributing to HTML5, with future Flash Platform development to focus on personal computer and mobile applications.  Great!  Our clients who are developing mobile experiences are universally doing so with the intention of making installable applications.  More Adobe focus in this area will only enhance the experiences that we are able to work with them to deliver.

The Flash Platform is still the best way to develop mobile application experiences intended to be deployed across the major application marketplaces: Apple, Android, and Blackberry.

However, what got the most attention in this announcement was that Adobe is discontinuing development of Flash Player for the mobile browser.  While this got many people up in arms, declaring the general demise of the Flash Player, we at RealEyes can respect this decision and see the validity of it.  For Adobe, the return on investment for this runtime simply wasn’t there, and with the fragmented nature of Android (and a few other issues that contribute to delivering an application to all browser, OS, and mobile hardware configurations) the continued development of the mobile Flash Player would be exponentially complex.

For application developers, the mobile Flash Player was never as good a runtime as the desktop one.

So, how is the discontinuation of mobile Flash Player affecting our clients? Really, it isn’t.

Because mobile device users are more likely to look exclusively toward installable applications for rich media content—and RealEyes’ Flash Platform applications largely deliver rich media content—our customers have been developing applications built using the Flash Platform and relying less on the mobile web.  Mike Chambers does a nice job of discussing the differences in how users consume rich content on mobile devices compared to the desktop, and we agree wholeheartedly that this is the way to go.

Because Flash Player doesn’t have the same ubiquity on mobile devices as it does for desktop browsers RealEyes was already advising our clients to create fallback experiences for their Flash content for mobile browsers.  For most of them we could achieve the same functionality in HTML as in Flash (video being the exception as you’ll see below).  Why not forgo Flash entirely and have a single HTML codebase to support?  Seems like a decision that makes good business sense.

Not that we aren’t sad to see mobile Flash Player go: we are.

If only because we don’t want the web to have missing plugin alerts. Having the Flash Player plugin available to Android and Blackberry mobile browsers was a convenience that offered a great marketing pitch, but, truthfully, delivered very little.  This is due, in large part, to the fact that the majority of the web was design for the desktop and was not meant for (nor is it very functional for) mobile phones – period, full stop.

In truth, we’ve seen just a very few Flash applications developed specifically for the mobile browser.  We at RealEyes have developed just one of these for commercial release. And this application was built before AIR for Android and was always intended to be a stop-gap until this runtime was available.

Now, tablets make a better use case for Flash’s place in the mobile ecosystem; however, the number of tablets that support Flash is under 30% of market share.  Given this and Apple’s seemingly prohibition on Flash, the Flash Player was just never going to achieve the same ubiquity as it has on the desktop for tablets, or for mobile phones for that matter.

Adobe Supports HTML5 Development

As Adobe is a multimedia creation company it will want to be at the forefront of whatever technology is defining exceptional user experiences for multimedia delivery.  And, for a few years now, Adobe’s been looking toward HTML5.  Unfortunately, the announcement from Adobe that contains the information about the discontinuation of the mobile Flash Player makes it sound like Adobe’s just jumping on HTML as a development platform.  That’s just not true.

Even more unfortunate in the present debate is a perception that Steve Job’s thoughts on Flash have somehow won and that this was just fallout from an Apple v. Adobe war.  Not so fast.  Apple and, to some degree Microsoft, have done much to market HTML5 development to the point that its perception overpromises what it can deliver.  Although Adobe has been working to educate its community about the benefits of the Flash Player over HTML5 and was backed by legions of developers, animators, designers, and content creators, they couldn’t overcome the tactics of a such powerful and cunning marketing machines.  While standing its ground on the mobile Flash Player, Adobe was, in many ways, able to achieve what critics said was not possible with Flash Player on mobile devices.

So, if Steve didn’t win, who did?

Well, Adobe is still poised to win and … more importantly so is its community of developers and customers.  Look at tools like Adobe Edge and the new mobile enhancements to Dreamweaver.  Also, with Adobe’s acquisition of PhoneGap, Adobe developers are poised to deliver the best HTML5 experiences out there.  Yeah, it’s not Flash … but that’s OK. While it seems like Adobe’s making a sharp turn toward HTML5, from where we sit, they are more fully committing to a direction that Macromedia, and then Adobe, started in some time ago.  Remember the HTML and Flash being friends video from Adobe MAX last year?

And, with other recent innovations for mobile AIR such as the availability of native extensions, the future of mobile development is exhilarating for any Flash Platform developer.  We’re hopeful that Adobe will use this opportunity to sharpen their focus on native mobile functionality and continue the path of making the Flash Platform the best choice for developing multi-platform mobile applications with a single code base.

However, the perception that Adobe’s making a rash decision is very damaging and something that we’re working with our clients to help them understand.  The reality of the situation is that not much has changed; however, poor communication, horrible messaging, and virtually no community outreach from Adobe regarding this messaging has made the perception the accepted reality in the short term.

And, if that weren’t enough news for one week …

Adobe Really Open Sources Flex

In clarifying its future plans for the Flex SDK, Adobe announced that the Flex SDK will be contributed to an open source foundation.  The good news in this move is that the Flex community is mature enough to take on the governance of this robust framework moving forward.  This wasn’t the case in February of 2008 when Adobe released Flex 3 as open source (Adobe had been planning to open source it since April of 2007).

For several years now, Adobe has been moving towards a more open standard with their development and this decision to contribute the Flex SDK to an open source foundation isn’t something that’s Adobe has done in isolation, and not just to the Flash Platform.  Some other projects that are on this path are:

  • PhoneGap
  • BlazeDS
  • Flex SDK

And, in reading Adobe’s clarification to this open source announcement, we see even more reason to be excited.  They are also open sourcing tools that support Flex including an experimental one (Falcon JS) that cross-compiles MXML and ActionScript to HTML and JavaScript.  Now, that’s exciting!  And, we’re sure that more is on the horizon.  Maybe HTML and Flash can be friends after all.

And, let’s be honest, the original model that Adobe used to open source Flex didn’t go as planned.  While Adobe always said they welcomed contributions from the community to grow and improve the Flex SDK, the process for getting a change accepted was unclear and many community contributions were rejected for any number of reasons (valid or invalid).  Adobe simply did not have the process or the resources to handle the influx of developers who wanted to contribute.  It was a frustrating situation for the Flex development community (and arguably Adobe as well).

So, the vibrant Flex community answered back earlier this year by creating the Spoon Project to better organize and test Flex SDK modifications submitted by the Flex community.  It proved to be an excellent model, drove innovation of the Framework, and was an initial step toward the full open source move that Adobe just announced.

Who’s governing the future of Flex? We are!

In case the nuance in what’s different now versus Adobe’s 2007 decision to open source Flex isn’t apparent, the major difference is that the Flex community will extend the Flex code base without needing Adobe’s permission to do so.  A new governance, following Apache’s well-established community rules, will be formed to determine the future direction of the codebase.

Since our inception RealEyes has been in close contact with Adobe’s Flash Platform team, we’re excited for this change in governance. RealEyes has always been super excited about the Spoon Project, and our Development Manager (Jun Heider) is very active in this community as the Infrastructure Chairman.  We’ve seen that this is truly a community-driven initiative that is supported by Adobe to increase the volume, speed (and maybe even the quality) in which the Flex framework can grow.

We are excited to contribute further to the future of Flex and confident that, like other successful open source communities, the language will continue to evolve.

Also … Flex isn’t all of the Flash Platform

Sadly, many of the announcements that we’ve been talking about, including the open sourcing of Flex, led many to say that Flash is dead. That simply isn’t true.  Let’s talk about what the Flex framework actually is: a particular framework used to structure Flash Platform development.  Do you have to use it to develop Flash Platform applications? No. And, to be honest, RealEyes doesn’t use Flex in every Flash Platform project because sometimes that framework can make applications to “heavy”.  If performance is of paramount concern for a Flash Platform application, Flex often cannot replace pure ActionScript.

Flash and Flex are not going away.  Adobe is still committed to developing tooling to support development for the Flash Platform. Further, Adobe hasn’t open sourced the Flash Player, the most installed piece of software in the history of the internet.  Adobe plans on steadily contributing to the Flex SDK in its open sourced project and we are working with the Flex community to make us contributors as well.

Adobe and Enterprise Applications

In a week of poorly handled communication, probably RealEyes’ largest concern was Adobe’s statement that “In the long-term, we believe HTML5 will be the best technology for enterprise application development.” Ouch.  Big enterprises have invested millions upon millions of dollars in the development and maintenance of Flash Platform applications.  At the very least that statement can erode the confidence that large companies (or companies of any size, really) have when building systems based upon Adobe technology.  Something that we feel is probably a bit of an over-reaction.

Also, without context this statement is very misleading.  Currently, HTML5 does not have full functional parity with the Flash Platform.  A few days after making this statement, Adobe clarified it by indicating what it intended as a timeframe for HTML5 to be able to truly complete with Flash Platform development: three to five years. That timeframe could be heavily extended when considering corporate browser adoption timelines.

There’s no enterprise that can wait three to five years for functionality.

As Adobe stated, “Flex has now, and for many years will continue to have, advantages over HTML5 for enterprise application development – in particular:

  • Flex offers complete feature-level consistency across multiple platforms
  • The Flex component set and programming model makes it extremely productive when building complex application user interfaces
  • ActionScript is a mature language, suitable for large application development
  • Supporting tools (both Adobe’s and third-party) offer a productive environment with respect to code editing, debugging and profiling and automation.

We see all that as being the case and some more:

  • Enterprise clients tend to have slower adoption rates for software, meaning that not all enterprises support the advanced HTML5 features that exist.
  • In particular, the video capabilities in HTML5 are not as robust as what is available in the Flash Platform including multicasting with integrated hardware acceleration and advanced security models.
  • The testing issues for supporting browser fragmentation can be daunting to enterprises, compared with supporting a Flash Platform application that can be deployed across desktop browsers with consistent display and functionality.

RealEyes will continue to recommend Flex and Flash Platform development to our clients where it makes real business sense to do so.  That said, there are reasons to use HTML over (or alongside) the Flash Platform, and we have plenty of clients we support who do that as well.

The Impact to RealEyes

So, what does all of this mean to RealEyes?  In the short term, it has meant a challenge to bring context to Adobe’s announcements and dispel rumors and misinformation to our clients. In the long run, it probably doesn’t mean a lot.

We have already been on a path of technology diversification with continued focus and adoption of HTML5, its supporting technologies, and native mobile development. Many of us are in the technology space because we enjoy the challenge of evolving our skills as the industry grows.  However, for the next few years, we anticipate that the Flash Platform will continue to be our predominant focus.

Our development specialty has been in delivering industry-leading streaming media solutions and multiscreen development. Flash and AIR are still the best solutions for this and will be for a while.  The timeline for that largely depends on Adobe and, as a valued Adobe Solutions Partner, we will continue to support them in as educated and balanced way as possible.

We are actively involved in the future of the Flex framework through the Spoon Project and excited about the potential for future growth for that project.  We are now even more apt to contribute to the betterment of this already robust framework for the benefit of the Flex community.

Finally, RealEyes has always helped our clients to choose the best technology to power a given project and we will continue to do this.  And, as HTML5 becomes a more comprehensive solution, we will likely recommend it more frequently. It is truly about what is right for the current and future on a case by case basis. Our clients and projects will continue to be industry leaders, no matter the technology behind them.


Now, we can’t see all of the news in a positive light.  And not all of it is positive – certainly not for the 750 Adobe employees who were laid off and their families. However, this degree of restructuring in the fourth quarter isn’t unprecedented for Adobe.  We’ve seen this over the past couple of years.  This year, as in years past, we lost meaningful relationships with Adobe employees that we’ve been happy to collaborate with on community and development projects.  We at RealEyes have close contact with Adobe and tend to focus on how individuals shape the platforms, products, and communities that we work with instead of quarterly earnings and fiscal projections.  While adjusting to this restructuring, we wish all of the affected employees only the best in their next moves and hope that they will continue to make positive contributions to the technical community they have helped to shape.

Additional Links:

Part 1 of this series discussed HTTP Dynamic Streaming (HDS) at a fairly high level. The next few editions in the series will explore some of the more powerful features that make using this protocol advantageous. Multi-bitrate stream switching and file encryption are two important features that we’ll cover in the very near future, as they’re very big reasons to stream over any protocol. However, in this article I’d like to discuss a brand new feature of the Open Source Media Framework (OSMF) known as “late-binding audio”.

Late Binding Audio Defined

Late-binding audio refers to the ability to stream videos with multiple associated audio tracks. This makes it possible to play an alternative audio track on the client-side using the same video file. There’s no need to encode, store, and deliver separate video + audio assets for each version you would like to provide. Say for example that you would like to provide video content with audio translated into multiple languages. Instead of  creating separate video + audio files for each language, you instead encode the video only once, and include the alternate audio-only tracks along with the it. This represents a huge savings in time, storage, and bandwith that anyone making the switch to HTTP Dynamic Streaming can take advantage of.

Updates to OSMF that came in version 1.6, Sprint 5 make streaming late-binding audio files over HTTP possible. Specifically, the MediaPlayer class now contains the read-only public property hasAlternativeAudio : Boolean. By using the LateBindingAudio example application included in the latest OSMF release, I’ll demonstrate step-by-step how to get this new feature to work.

Many of the steps we’ll be taking are the same steps we took when packaging our files for simple streaming over HTTP, so if you’d like to review, please check out HTTP Dynamic Streaming – Part 1: An Introduction to Streaming Media.

Late-Binding Audio, Step-by-Step

1. Gather your media assets

In this example, we’ll be working with a video that has one alternate audio track. (President Barack Obama’s speech from July 25th, and an alternate audio track of the transcription translated into Spanish) You can include as many alternate audio tracks as you’d like, however there are some recommendations from the OSMF team in regards to how you prepare your media. One suggestion is that you should use audio tracks that are at least as long as the main video + audio track to ensure smooth stream switching. Other guidelines relate to encoding best practices for streaming over HTTP in general. You can read the white paper on encoding standards here. A list of known issues with OSMF 1.6 Sprint 5 can be found in the release notes.

The creation of the media assets prior to packaging them for HTTP streaming is beyond the scope of this article, but for your information:

  • I used Adobe Premiere Pro 5.5 to edit the original video file down to something shorter (~2 min).
  • I used Adobe Audition CS 5.5 to edit the audio, and to create the alternate audio track.
  • I encoded the video and audio files to .f4v using Adobe Media Encoder (see part 1 of the series for file type requirements).
  • I happily found a transcription of the speech online.
  • Google Translate helped me with the translation (it’s been awhile since I’ve spoken Spanish).
  • At&t Natural Voices text-to-speech demo provided me with the .wav files of the Spanish audio.
So, to start you’ll need a minimum of 3 separate files:
  • The original video + audio file encoded into an .flv or Mp4-compatible format
  • The audio track from the original video + audio encoded the same as above
  • An alternate audio track, hopefully of the same duration as the original audio, encoded the same as above
2. Package your media using the f4fpackager tool

This step is the same as it is for packaging files for simple streaming over HTTP, covered in part 1.

using the f4fpackager to package the media files

At this point, if you’d like to send additional arguments to the packager, you can enter them here and they’ll show up in the XML of the .f4m file, otherwise use the minimum arguments. We’ll be editing the XML of the main video’s .f4m file in the next step. After you’ve packaged all of the files, it’s time to create a “master” .f4m file. I’m using 3 source files, so I have 3 sets of 3 packaged files:

  • Obama.f4m
  • ObamaSeg1.f4x
  • ObamaSeg1.f4f
  • Obama_Audio.f4m
  • Obama_AudioSeg1.f4x
  • Obama_AudioSeg1.f4f
  • Obama_altAudio.f4m
  • Obama_altAudioSeg1.f4x
  • Obama_altAudioSeg1.f4f
3. Create master .f4m file

Next, we’ll be adding some information from the two audio tracks’ .f4m files (the separated audio from the original video, and our alternate Spanish track) to the .f4m of the packaged main video file. Copy the “bootstrapInfo” and “media” tags from inside the .f4m files of the two audio tracks, and paste them into the main video’s .f4m file.

Add media and bootstrapInfo tags to main .f4m file

Add media and bootstrapInfo tags to main .f4m file

4. Add attributes to media tags in master .f4m

In order for late-binding audio to work, we’ll need to add a few attributes to the media tags inside the main .f4m file. In the media tag of your alternate audio, add:

  • alternate=”true”
  • type=”audio”
In order to get the example application that I’m using to behave the way I’d like it to, I added another attribute to the alternate audio’s media tag:
  • lang=”Spanish”
The player is using that attribute to populate a dropdown menu of available alternate audio tracks, and by including this attribute, I get a nicely-named menu item in the player.
*Note*I’ve noticed that when using packaged .f4v’s, the example player can’t load the files unless I add yet another attribute to (every) media tag:
  • bitrate=””
Apparently, the player doesn’t care what the bitrate value is, even if it’s an empty String, but it does seem to require that you include that attribute when streaming packaged .f4v’s.
Updated master .f4m file

Updated master .f4m file

5. Place all packaged files into vod folder in the webroot of your Apache server

When done, it should look something like this: (“readme.htm” and “sample2_1000kbps.f4v” are files that come with Flash Media Server, and can be ignored)

Packaged files in the vod folder on the server

Packaged files in the vod folder on the server

Setting Up Flash Builder

6. Make sure you’re using the latest versions of Flash Builder, Flash Player, and OSMF

In order for this example to work, you’ll need to ensure that you’re using Flash Builder 4.5.1 and the latest OSMF .swc. You’ll need to replace the OSMF .swc that comes with the latest Flex SDK with the one from OSMF 1.6 Sprint 5, and deploy your project to the latest version of the Flash Player. (At least 10.2)

Use Flex 4.5.1, and Flash Player 10.2 and up

Use Flex 4.5.1, and Flash Player 10.2 and up

Use the latest OSMF .swc-OSMF 1.6, Sprint 5

Use the latest OSMF .swc-OSMF 1.6, Sprint 5

As mentioned earlier, this example uses the LateBindingAudioSample application that comes bundled with the latest OSMF release. It can be found in OSMF/apps/samples/framework/LateBindingAudioSample. Modify this application to point to your main video’s .f4m file on the server.

That’s it! Ensure that your Apache web server is running, and if you’re using the same example application, run the application in debug mode to get valuable information about the stream in the Console. Select your video asset from the dropdown menu up top, and hit “Play”. Choose the alternate audio stream at any time from the dropdown in the lower left of the application.

Where to go from here

For a more in-depth look into HDS, including discussions on file encryption, and live streaming, please refer to John Crosby’s series on HTTP Dynamic Streaming

For an informative look into the world of OSMF, including deep-dives into such things as building custom media players and plugin integration and development, please see David Hassoun and John Crosby’s article series “Mastering OSMF“on the Adobe Developer Connection site .

For information on how Realeyes Media can help you make the switch to HTTP Dynamic Streaming, please feel free to contact us today.


Adobe HTTP Dynamic Streaming documentation


f4fpackager documentation

F4M file format specification


HTTP origin module


Flash Media Development Server (free)

Apache web server

Scott Sheridan writes about, and messes around with, the latest technologies in digital motion media at Realeyes. He also does triathlons. Really big triathlons.

Feel free to reach out with any questions-we’re glad to help!

scott AT realeyes DOT com

Kao tehnologija koje se odnosi na proizvodnju i isporuku digitalnih pokreta medija nastavlja da napreduje, tako da su zahtevi potrošača za sve raznovrsniji i bogatiji mediji iskustveniji.. Video visoke definicije se sada isporučuje na više korisnika, na razlicitim vrstama uređaja, i kroz više kompleksnih mreža nego ikada pre. Za provajdere sadržaja, to naravno znači više raspoloživih mogućnosti za medijsku distribuciju i monetizaciju.


Tradicionalno, video je dostavljen klijentu na jedan od dva načina:bilo progresivnim preuzimanjem korišćenjem široko podržanog HTTP protokola, ili strimovanjem, korišćenjem protokola RTP, RTMP, UDP, ili TCP, u saradnji sa specijalizovanim serverom softvera za rukovanje tokom (npr. Flash Media Server ili Windows Media Services). Ove dve metode dostave imaju i prednosti i mane. Streaming medija protokoli nude gledaocu bolje iskustvo omogućavajuci videu da reprodukuje odmah, bez potrebe da prvo sačekamo da su potpunosti uploaduje. Oni su takođe omogućili takve karakteristike kao adaptivne bitrate strimovanja da nadoknadi za fluktuacije u korisničkom protok, uživo gledanje, sadržaj enkripciju, i pametne ribanje. Ove karakteristike su često vrlo skupe, međutim, i kao takve nije su održiva opcija za mnoge sadržaje. Isporuka preko HTTP, s druge strane, traži kompletan file download pre nego se moze poceti gledanje. Pored toga, sadržaj prebačen na ovaj način je uskladištena na hard disku krajnjeg korisnika, i zbog toga često nije najbolje rešenje za prikazivanje zaštićenog sadržaja autorskih prava. Međutim, podrška za HTTP protokol bio je i ostao, veoma rasprostranjen. Specijalizovani server tehnologije se ne zahteva da bi se dostavio sadržaj preko HTTP- jednostavno (i besplatano) ce to uraditi web server. Biti podrzan postojećim i rasprostranjenim serverom hardvera i caching infrastruktura nastavlja da bude jedan od glavnih prednosti pri korišćenju HTTP protokola.


U prošlosti, provajderi sadržaja su često bili suočeni sa teškom dilemom. Da li bi oni trebali da naprave velike finansijske investicije u cilju pružanja najboljeg streaming videa iskustva svojim krajnjim korisnicima? Ili bi njihov ROI bio bolji ako isporuci robustano iskustvo gledanja, iako ima potencijalno veću publiku, preko HTTPa? Kompanije kao što su Move Networks, Microsoft, Adobe i Apple su došli sa svojim jedinstvenim rešenjima ovog problema – dinamičan problem streaming medija preko HTTP protokola. Svako rešenje podrazumeva razbijanje kodiranih medijskih datoteka u manje komade, koji su zatim ponovo okupljeni od strane medija playera klijenta.

Nekoliko adaptivnih bitrate streaming rešenja:

HTTP Dynamic Streaming – Adobe

Od puštanja Adobe Flash Playera 10.1, i Open Source Media Framework 1.0 (OSMF), sadržaj isporuke usluga, stvaraoci i izdavači imali su opciju usklađivanje HTTP Dynamic Streaming da znatno povećaju svoj domet kada je u pitanju pružanje kvalitetnih video iskustva klijentu. HTTP Dinamic Streaming (HDS) je prava streaming tehnologija, ali ne zavisi od specijalizovanih streaming servera ili vlasničkih transfer protokola. . Pored toga, potreban alat da biste gledali svoj video preko HTTP dobija se besplatno sa Adobe.

Da biste pripremili svoje medije za HDS, uradite sledeće:

Spakujte vaš FLV, F4V ili druge MP4-kompatibilne datoteke pomoću slobodanog f4fpackager alata.

Preuzmite f4fpackager. f4fpackager je komandna linija alat dostupan za Windows i Linux koji koristite za pretvaranje svoje izvorne medijske datoteke u nužno-fragmentiranedatoteke potrebne za strimovanje. Možete skinuti packager  besplatno sami, ili koristite verziju koja se isporučuje u okviru Flash Media Server 4.0 i dalje. Proces je prilično jednostavan i brz, mnogo brži nego kodiranje izvornog fajla za početak! Za pokretanje Packager u operativnom sistemu Windows, na komandnoj liniji, “cd” u svoj Flash Media Server ili Apache web server instalaciom ““tools\f4fpackager” foldera. Odavde se lako pokrene Packager jednostavnim kucanjem “F4” (tada Tab), i pustiti komandni prozor da auto kompletira pokretanje f4fpackager.exe. Dajte Packageru najmanje sledeće argumente:

01 --input-file=<em>theFullPathToYour/Media
01 --output-path=theFullPathToTheOutputLocationOfYourChoice

Alternativno, možete izostaviti argument izlaz, a Packager će staviti upakovane fajlove u izvornom direktorijumu. Više Packager argumenta za stvari kao sto su trazenje bitrate nekog datoteke, kriptovanje, itd mogu se naći ovde.

f4fPackager at the command line
Korišćenje f4fPackager na komandnoj liniji

Ako sve ide dobro, trebalo bi da imate 3 nova fajlova za svaku izvornu datoteku koju ste poslali Packager-u:

  1. .F4M (manifest) file
  2. .F4F (fragment) file
  3. .F4x (index) file

Manifest fajl (F4M.). je XML fajl koji sadrži bitne informacije o vašim medijima koje medija plejer analizira kako bi se reprodukovao pravilno datoteku. Da biste saznali više o F4M, i. F4F tipovima datoteka., Pogledajte Džona Krozbi serija na HTTP Dinamic Streamingu

The 3 packaged files: .F4M, .F4F, and .F4X

Uverite se da imate HTTP Poreklo modula spreman zarad

Instalirajte i konfigurišite HTTP Module Porijekla u postojeću instalaciju Apache web servera. HTTP Modul porekla je proširenje na Apache web serveru koji je neophodan za striming medija preko HTTP-a za Flash Player. Možete preuzeti modul ovde.  Alternativno.,I HTTP modul porekla i Apache web server dolaze u paketu i konfigurisani sa Flash Media Server om verzije 4.0 i gore. *Napomena* Uvjerite se da se vas server Apache koristi operativni sistem Windows, podrazumevan, Apache web servis počinje konfiguraciju unutar Flash Media Servera 4 koji je postavljen na “Manual”. Možda ćete želeti da se prebaci ovo na “automatski”.

Postavi vase spakovane media server datoteke u vod direktorijum vašeg Apache web servera (webroot / vod/)

Kada imate sve datoteke pravilno upakovane, i vi ste instalirali i konfigurisali Apache web server, kao i HTTP Modul porijekla (kao samostalan ili u paketu u okviru Flash Media Server), sve sto treba da uradite na strani servera je postaviti 3 upakovana fajla u vod fasciklu unutar vašeg Apache servera, i zgrabite URL (e) medijske datoteke (e) koje želite da pustite. *napomena* Apache je postavljen za slušanje na port 80 kao podrazumevano, i prelaze na port 8134 ako port 80 je u upotrebi. Međutim, možete konfigurisati Apache server da sluša bilo koji dostupan port.

Make sure Apache service is running

Konfigurisanje media player da ukaže na URL medi unutar vašeg vod fajla

Dobrodošli ste da izgradite sopstveni prilagođeni player na potoku preko HTTP-a, međutim, fini ljudi na Adobe i Realeyes mediji su već uradili dosta posla za vas. Dajte nekima ili svima od sledećih playera sansu:

REOPS Player   Moćan, OSMF-baziran media player iz Realeyes medija The Realeyes OSMF player primer (REOPS) nudi odličnu bazu za stvaranje snažnog video playera koristeći Open Source Media Framework (OSMF) iz Adobe. REOPS je trebalo da bude kamen temeljac za programere, kao i vizuelni prikaz da ilustruje mogućnosti i kako da se od OSMF framework. The REOPS projekat uključuje veoma proširu i robustnu kontrolnu traku i šablone da pomogne da prilagodite traku kontrole, kao i Full-screen podršku, zatvoren Captioning iz eksternog fajla, kao i OSMF dinamički plugin podršku. The REOPS projekat može da se koristi za primenu lako prilagođenog player videa koji podržavaju progresivnu video reprodukciju, video na zahtev, striming live streaming i dinamičkih striming. Šta više, sve ove funkcije se mogu konfigurisati iz spoljnog XML fajla.

Flash Media Playback Besplatan, standardni medija player za Adobe Flash platformu Flash Media Playback može koristiti bilo koji sajt sa samo nekoliko linija HTMLa, omogućavajući video i druge medije u nekoliko minuta. Njegova prošira plug-in arhitektura omogućava jednostavnu integraciju sa mrežama sadržaja isporuke (CDNs) i oglašavanja platformi, kao i podršku za analitiku i dodatne nezavisne usluge. Sa podrškom za najnovije metode isporuke, Flash Media Playback omogućava web programerima svih nivoa da u potpunosti iskoriste mocne karakteristike videa na Flash Platformi.

Strobe Media Playback Besplatni, OSMF bazirani media player iz Adobe. Strobe Media Playback je Open Source Media Framework (OSMF) baziran media player koji možete brzo i lako integrisati u vaš sajt. Sastavni SVF i njegov izvorni kod su dostupni za besplatno preuzimanje ovde.

… ili napravi svoj pomocu sledeceg tutorijala!  Ovladavanje OSMF-Adobe Developer Connection serije. John Crosby i David Hassoun iz Realeyes medija napisali su odličan niz članaka i tutorijalekoji nas vode kroz ucenje rada sa OSMF. Oni počinju sa izgradnjom jednostavnog medija playera, a onda zarone dublje u složenije teme, kao što su odvajanje kontrole, uključujući media prekrivače, kao i integraciju i razvoj custom plugin-a.

Bilo da odlučite da izgradite sopstveni ili da koristite medija player koji je vec napravljen, moraćete da istaknete svoju aplikaciju na F4M fajlu. vod direktorijumu vašeg Apache servera. Opet, ovo je media manifest datoteka, XML datoteka koju media player koristi da analizira ažne informacije o medijima, kao što su bitrate, trajanje, itd

 HTTP Dinamic Streaming zahteva Flash Player 10.1 i gore. Bilo koja verzija OSMF, počevši od 1.0 bice kompatabilna sa HDSom.

Streaming Demo

Ispod je primer ugrađenog Flash Media Playback medija playerakoji dostavlja video preko HTTP-a. Ako želite,možete podesiti svoj player ovde. Ukoliko želite da koristite iste upakovane fajlove koji se koriste u demo, možete ih preuzeti ovde.

Naravno, ova demonstracija samo pokazuje video snimak preko HTTP-a to nije primjer moćnih funkcije dostupnih preko HDSa, kao što su promenljive bitrate prebacivanje, enkripcija, ili kasno vezivanje audio. Ostanite uz nas za vise informacija i o tome..

Where to go from here

Za dublji pogled na HDS, uključujući rasprave o File Encriptionu, Live streamingu, pogledajte John Crosby seriju na HTTP Dinamic Streamingu

Za informativni pogled na svet OSMF, uključujući i duboko zaranjanje u takvim stvarima kao građenje prilagođenih medija playera i dodatke integracije i razvoja, pogledajte David Hassoun i John Crosby’s clanak serijeMastering OSMF na Adobe Developer Connection sajtu .

Za informacije o tome kako Realeyes Mediji vam mogu pomoći da se prebacite na HTTP Dinamic Streaming, budite slobodni da nas kontaktirate danas.

This article is translated to “http://science.webhostinggeeks.com/http-dinamic-streaming” Serbo-Croatian language by Vera Djuraskovic from “http://webhostinggeeks.com/” Webhostinggeeks.com

As technologies related to the production and delivery of digital motion media continue to advance, so do consumer demands for an increasingly varied and rich media viewing experience. High-definition video is now being delivered to more users, on a wider variety of devices, and through more complex networks than ever before. For content providers, this of course means more available avenues for media distribution and monetization.


Traditionally, video has been delivered to the client in one of two ways: either by progressive download using the widely-supported HTTP protocol, or by streaming, using protocols such as RTP, RTMP, UDP, or TCP, in conjunction with specialized server-side software to handle the stream (e.g., Flash Media Server or Windows Media Services). These two delivery methods had both advantages and disadvantages. Streaming media protocols offered the viewer a better experience by allowing the video to play back right away, without having to first wait for it to completely download. They also made possible such features as adaptive bitrate streaming to compensate for fluctuations in user bandwith, live viewing, content encryption, and smart scrubbing. These features often came at a significant cost, however, and as such weren’t a viable option for many content providers. Delivery over HTTP on the other hand, required a complete file download before viewing could start. In addition, content transferred in this way was stored on the end user’s hard drive, and was therefore often not the best solution for displaying copyright-protected content. However, support for the HTTP protocol was, and remains to be, very widespread. Specialized server technology isn’t required to deliver content over HTTP-a simple (and free) web server will do. Being supported by existing and widespread server hardware and caching infrastructures continues to be one of the major advantages of using the HTTP protocol.


In the past, content providers often faced a difficult dilemma. Should they make the relatively large financial investment in order to provide the best streaming video experiences to their end-users? Or would their ROI be better served by delivering a less-robust viewing experience, albeit to a potentially larger audience, over HTTP? Companies such as Move Networks, Microsoft, Adobe, and Apple have come up with their own unique solutions to this problem-the problem of dynamically streaming media over the HTTP protocol. Each solution involves breaking up the encoded media files into smaller chunks, which are then re-assembled by the media player on the client end.

A few adaptive bitrate streaming solutions:

HTTP Dynamic Streaming – Adobe

Since the release of Adobe Flash Player 10.1, and the Open Source Media Framework 1.0 (OSMF), content delivery providers, creators, and publishers have had the option of leveraging HTTP Dynamic Streaming to vastly increase their reach when it comes to delivering quality video experiences to the client. HTTP Dynamic Streaming (HDS) is a true streaming technology, but not dependent on specialized streaming servers or proprietary transfer protocols. In addition, the tools required to make your media files streamable over HTTP are provided free from Adobe.

To prepare your media for HDS, you do the following:

Package your FLV, F4V, or other MP4-compatible files using the free f4fpackager tool.

Download f4fpackager The f4fpackager is a command line tool available for Windows and Linux that you use to convert your source media files into the necessarily-fragmented files required for streaming. You can get the packager for free on its own, or use the version that ships within Flash Media Server 4.0 and up. The process is fairly simple and quick-much faster than encoding the source files to begin with! To run the packager in Windows, at the command line, “cd” into your Flash Media Server or Apache web server installation’s “tools\f4fpackager” folder. From here, easily run the packager by simply typing “f4” (then Tab), and let the command window auto-complete your prompt to launch f4fpackager.exe. Give the packager at least the following arguments:


Alternatively, you can omit the output argument, and the packager will place the packaged files into the source directory. More packager arguments for doing things like declaring a file’s bitrate, encrypting, etc. can be found here.

f4fPackager at the command line
Using the f4fPackager at the command line

If everything goes well, you should have 3 new files for every source file you sent to the packager:

  1. .F4M (manifest) file
  2. .F4F (fragment) file
  3. .F4x (index) file

The manifest file (.F4M) is an XML file that contains pertinent information about your media that the media player parses in order to play back the file appropriately. To learn more about the .F4M, and .F4F file types, please check out John Crosby’s series on HTTP Dynamic Streaming.

The 3 packaged files: .F4M, .F4F, and .F4X

Ensure that you have the HTTP Origin Module ready to go.

Install and configure the HTTP Origin Module into an existing Apache web server installation. The HTTP Origin Module is an extension to the Apache web server that is necessary for streaming media via HTTP to the Flash Player. You can download the module here. Alternatively, both the HTTP Origin Module and the Apache web server come bundled and configured with Flash Media Server versions 4.0 and up. *Note* Make sure your Apache server is running. On Windows, by default, the Apache web service start configuration within Flash Media Server 4 is set to “manual”. You may want to switch this to “automatic”.

Place your packaged media files into the vod folder of your Apache web server. (webroot/vod/).

Once you have your files properly packaged, and you’ve installed and configured your Apache web server, as well as the HTTP Origin Module (as a standalone or bundled within Flash Media Server), all you need to do on the server side is place the 3 packaged files into the vod folder within your Apache server, and grab the URL(s) of the media file(s) you wish to stream. *note* Apache is set to listen to port 80 by default, and to switch over to port 8134 if port 80 is in use. However, you may configure your Apache server to listen to any available port.

Make sure Apache service is running

Configure your media player to point to the URL of the media within your vod directory.

You’re welcome to build your own custom player to stream via HTTP, however, the fine people at Adobe and Realeyes Media have already done a lot of the work for you. Give any or all of the following example players a try:

REOPS Player  A powerful, OSMF-based media player from Realeyes Media The Realeyes OSMF Player Sample (REOPS) offers an excellent base for creating a robust video player utilizing the Open Source Media Framework (OSMF) from Adobe. REOPS is meant to be a building block for developers as well as a visual representation to illustrate the capabilities and how to of the OSMF framework. The REOPS project includes a very extensible and robust control bar skinning solution and templates to help customize the control bar, as well as Full-screen support, Closed Captioning from an external file, and OSMF dynamic plugin support. The REOPS project can be used to deploy easily customized video players that support progressive video playback, video on demand streaming, live streaming and dynamic streaming. What is more, all of these features are configurable from an external XML file.

Flash Media Playback A free, standard media player for the Adobe Flash Platform Flash Media Playback can be used by any website with only a few lines of HTML, enabling playback of video and other media in minutes. Its extensible plug-in architecture enables easy integration with content delivery networks (CDNs) and advertising platforms, as well as support for analytics and additional third-party services. With support for the latest delivery methods, Flash Media Playback enables web developers of all levels to fully utilize the powerful video features of the Flash Platform.

Strobe Media Playback A free, OSMF-based media player from Adobe Strobe Media Playback is an Open Source Media Framework (OSMF) based media player that you can quickly and easily integrate into your website. The compiled SWF and its source code are available for free download here.

…Or Build Your Own With These Tutorials! Mastering OSMF-Adobe Developer Connection Series John Crosby and David Hassoun of Realeyes Media have written an excellent series of articles and walkthrough tutorials for teaching us how to work with OSMF. They start with building a simple media player, and then dive deeper into more complex topics such as separating control, incorporating media overlays, as well as integrating and developing custom plugins. 

Whether you decide to build your own, or use a media player that’s been provided, you’ll need to point your application to the .F4M file within your Apache server’s vod directory. Again, this is the media manifest file, an XML file that the media player uses to parse important information about the media, such as bitrate, duration, etc..

 HTTP Dynamic Streaming requires Flash Player 10.1 and above. Any version of OSMF, starting with 1.0, will be capable of HDS.

Streaming Demo

Below is an example of the embedded Flash Media Playback media player delivering a video over HTTP. If you’d like, you can configure your own player here. If you would like to use the same packaged files playing in the demo, you can download them here. Of course, this demonstration is merely showing a video stream via HTTP-it’s not an example of the more powerful features available with HDS, such as variable bitrate switching, encryption, or late-binding audio. Stay tuned for coverage of those topics and more.

Where to go from here

For a more in-depth look into HDS, including discussions on file encryption, and live streaming, please refer to John Crosby’s series on HTTP Dynamic Streaming

For an informative look into the world of OSMF, including deep-dives into such things as building custom media players and plugin integration and development, please see David Hassoun and John Crosby’s article series “Mastering OSMF“on the Adobe Developer Connection site .

For information on how Realeyes Media can help you make the switch to HTTP Dynamic Streaming, please feel free to contact us today.


Adobe HTTP Dynamic Streaming documentation


f4fpackager documentation

F4M file format specification


HTTP origin module


Flash Media Development Server (free)

Apache web server

Scott Sheridan writes about, and messes around with, the latest technologies in digital motion media at Realeyes. He also does triathlons. Really big triathlons.

Feel free to reach out with any questions-we’re glad to help!

scott AT realeyes DOT com

Digital-Tutors is a recognized leader in on-demand training for the motion graphics industry, partnering with leading design studios, software manufacturers, and educational institutions.  To extend their platform of web and mobile video applications, Digital-Tutors worked with RealEyes Media to create a new version of their online training library that would allow users to download lessons and courses for offline viewing, while continuing to advance the features in their training platform: Digital-Tutors Vault.

Today, Digital-Tutors is releasing the second major release of Vault, coupled with a new Web application that brings Vault’s advanced user interface and much of its functionality to the browser. Curious about what all the fuss is about? Vault 1.6 includes enhanced group functionality and updates to Digital-Tutors’ streaming technology.

Digital-Tutors Vault provides digital visual artists at all experience levels the opportunity to stream training content while online and use a credits system to download and lease DRM protected content for offline viewing. All users are welcomed to the application with an HTML experience that is seamlessly integrated into the application.  Through an API, the HTML pages can execute actions in the parent AIR application, allowing Digital-Tutors to highlight important content easily. To keep content fresh, Vault has an integrated asset and data update system that ensures users have the most up-to-date local catalog assets. In fact, the AIR application is bundled with catalog assets (local database, images, HTML, and JavaScript) so users experience a robust application right from the start – even when offline.

With the ability to move category tabs such as Browse and Playlists as well as create and organize custom tags, notes and video clips, Vault provides an extremely customizable digital learning environment.  The Vault application also automatically syncs custom user data across Digital-Tutors suite of applications, including web and iPhone, so that items like view progress and clips are consistent across all of a user’s devices.

Want to experience Vault for yourself:

On March 18, 2011, Adobe announced the General Availability release of Flash Player 10.2 in the Android Market for various Android devices (Android mobile – 2.2 Froyo, and 2.3 Gingerbread, and for Android tablets – 3.x Honeycomb).

From Adobe:

“Flash Player 10.2 is now available for download on Android Market.  This is a production GA (General Availability) release for Android 2.2 (Froyo) and 2.3 (Gingerbread) devices and an initial beta release for Android 3.x (Honeycomb) tablets that include at least Google’s 3.0.1 system update.*  To see if your device is certified for Flash Player 10.2, visit: http://www.adobe.com/go/cd1.

The beta of Flash Player 10.2 for Android 3.x is an exciting release that brings a full web browsing experience, including video, games and other interactive content, to the latest Android tablets. We have been working very closely with Google through the development of this beta to ensure tight integration and optimization between Flash Player 10.2 and new OS and browser capabilities.

Improvements include:

  • Performance enhancements to take advantage of new hardware in both Android 3.x tablets, as well as existing hardware in many Android 2.2 and 2.3 devices
  • Tight integration with the new Android 3.x browser to treat Flash content as part of the web page instead of as a separate “overlay.”  This results in improved scrolling of web pages and the ability to display pages in the way intended by the page designer, including new support for compositing HTML and other web content over Flash Player rendered content.
  • Automatic soft keyboard support to simplify text entry for rich mobile and multi-screen experiences”

Continue reading the full article on the Adobe Flash Player Team Blog

Challenges of the Mobile Platform

  • Delivering a multimedia experience
  • Performance & Memory
  • Usability and User Experience


  • Flash Player 10.1
  • Open Source Media Framework (OSMF) based media playback
  • Custom, light-weight framework for visual presentation and data management
  • CSG Systems’ Content Direct


Realeyes Media, together with CSG Systems, built the Content Direct Mobile media streaming application. CSG Systems (NASDAQ: CSGS) provides software and services-based solutions that help clients improve commerce by better engaging and transacting with their customers. CSG provides enabling applications and a monetization platform to engage customers wherever they consume content.

Content Direct, a business unit of CSG, is focused on providing a complete ecosystem of online, mobile and OTT content and merchandising solutions.  Its solution empowers service providers, content creators, aggregators and distributors to easily and effectively market, monetize and manage their members and build engaging relationships by leveraging rich content.

Content Direct was created  to manage live events, content for video, music, games, other digital wares and physical merchandise and provide a flexible “browse, buy and belong” membership experience.  Content Direct provides consumer the ultimate flexibility in how they find, pay and manage their content choices and how they interact with their entertainment brands.

Content Direct is architected as a set of application modules (Member, Content, Commerce and Advertising) that expose its functionality through a set of well defined web services to applications such as the Online Storefront for Devices, , a Customer Care  Portal, Reporting Portal and the Invision Portal, a metadata manager.

Some of CSG’s  clients include:

  • Ultimate Fighting Championship
  • NBC Universal Sports
  • Onlive (Gaming)

CSG chose RealEyes as their partner to extend Content Direct’s online experience to mobile, enabling customers to market their premium video pay-per-view or subscription content on mobile devices.  Content Direct enables consumers to be able to watch, buy and manage their content from any device at anytime, anywhere.  Having established online, OTT and connected device solutions, Content Direct Mobile provides another way for customers to view and manage their content.   Content Direct Mobile allows users to search for content, buy video, manage their account and watch videos from their Flash enabled phones.

CSG partnered with RealEyes and Adobe to create Content Direct Mobile.  RealEyes and Adobe were obvious partners to extend Content Direct Mobile’s strategy.   RealEyes’ deep experience with Flash, Flash Mobile, OSMF combined with their relationship with Adobe were invaluable, and Adobe’s Flash penetration and the planned rollout to the mobile devices worldwide made Adobe a natural partner in deploying the Content Direct Mobile solution.

The Application

The Content Direct Mobile application uses the Content Direct’s existing data services and streaming media built for existing browser based clients and leverages the Flash Player 10.1 mobile player to create a rich and engaging mobile client experience to search, manage and view personalized media selections and libraries. Using a custom and light-weight visual presentation framework, the Content Direct Mobile application manages visuals and content in such a way as to conserve as much memory and resources as possible.

The Framework

Taking into account the Flash Player 10.1 improvements and optimizations already provided by the Flash Player team, the Content Direct Mobile application framework was built for speed and light weight. RealEyes built a powerful lightweight layout management system and UI controls that were optimized for mobile application development. This provided the application a versatile and sturdy foundation to build upon. Some of the challenges that we looked to address early on were screen rotation, and resolution independent layout. One of the benefits to both of the above challenges was there was no need of new ActionScript API’s or Flash runtime to build and manage such issues. This allowed us to utilize our past experience and apply it to the mobile application arena without losing a step.

Another area of focus for the framework and optimization was screen transitions and dynamic media asset management. Utilizing the robust ActionScript 3 bitmap management and caching appropriately for both content and motion played a major part in this. The custom bitmap management allowed us to maintain high quality motion and frame-rate while still keeping power and file weight low.

We enabled full branding and UI skinning via the clients data services and an Adobe Flash Professional source file created and managed in Flash CS5. Currently this media asset package creates a library file (SWC) that is utilized by the pure ActionScript 3 application developed in FlashBuilder 4.

The Media Player

The Content Direct Media player was built using Adobe’s Open Source Media Framework (OSMF). A testament to the quality of the OSMF and Flash Player 10.1, is the ability of the player to perform on a mobile platform without modification. In the future the media player could be an area of modification for optimization and performance enhancement, but right out of the box OSMF filled our needs and exceeded our expectations.

The extensibility of the OSMF allowed us to build in a custom control bar that is highly customizable for any client of Content Direct. In addition the OSMF plugin extensibility capabilities are a major benefit to the project and offer a high level of extensibility with ease.

The Bonus of AIR for Android

Having built the Content Direct Mobile application as an ActionScript 3 application, the transition from a browser based application to a natively installed Android application was accomplished with minimal effort. The following is a basic overview of all we needed to do to create a the AIR for Android application package:

  • We began by extending the main ActionScript class from the browser based application in our AIR for Android application.
  • Integrate features built into to the Android Operating System, such as keyboard functionality and navigational features using the updated APIs from the AIR for Android SDKs.
  • Listen for and respond to events associated specifically with the mobile application to handle screen orientation and sizing efficiently.
  • Package an AIR file by use the Andoird SDK adt commands to create the Android package (apk).


As the Flash Platform matures and grows on mobile we are looking forward to the ability to collaborate with Adobe and other companies allowing us to use our existing, skills, content and code on an ever increasing number of devices. Another exciting facet of the improvements and optimizations for Flash Player on mobile is how it will affect other device platforms – from laptops and netbooks, to set-top boxes and consumer devices – the possibilities are expanding and very exciting for us.

Overall we at RealEyes have been incredibly impressed with the capabilities and the development process for Flash applications on the Android devices. Some challenges were encountered with integration into the browser when it comes to rotation and form inputs, but Adobe has recently released an excellent article which addresses many of those issues. Performance and battery life have been nothing less than astonishing, and even the video playback without hardware acceleration (a temporarily missing feature) has been very promising.

The biggest changes in development are solely around form factor for UI, and optimization for devices with lower power capabilities than the desktop. For those who are more reliant upon a full framework like Flex it may be a little more of a challenge, but with reasonable ActionScript skills and consideration for complexity and optimization it is amazing how easy it is to make robust applications for a Flash enabled mobile device.

On Sunday, February 27, Adobe announced the launching of a new AIR and Flash Player incubator site on Adobe Labs. The purpose of this site is to share with developers some of the new features in the Adobe AIR runtime, and Adobe Flash Player that are currently under development or consideration.

From Adobe:

The Adobe Flash Platform runtimes team is launching the Adobe AIR and Flash Player Incubator program next week (live at 10am on Sunday, Feb 27th). The Incubator is a new place on Adobe Labs for us to share with developers features that are under development or under consideration for inclusion in future versions of the runtimes. It is different from the existing runtimes beta program. The Incubator program allows us to involve and engage earlier with our community of developers and customers. For developers and companies who are interested in testing cutting-edge capabilities of runtimes, the Incubator program allows them to contribute to the future of the Flash Platform. Keep in mind that the new features and functionalities in the Incubator builds may or may not be supported in future releases of the runtimes. The program will go live on Adobe Labs at www.adobe.com/go/runtimes_incubator .

“Molehill” 3D APIs and Cubic Bezier Curves will be the first two new features available in the first Incubator builds, which will be announced at the keynote of the Gaming Summit on Sunday, February 27th. For more information on the “Molehill” 3D APIs, visit Adobe Labs at www.adobe.com/go/molehill

The runtimes product management team has also set up a new AIR and Flash Player Releases blog (http://blogs.adobe.com/flashruntimereleases/), where developers can get real-time updates on new AIR and Flash Player releases.  Be sure to subscribe to the RSS feed and be notified whenever a new runtime build is posted.

FAQ: Adobe® AIR® and Flash® Player Incubator

1. What is the Adobe AIR and Flash Player Incubator?
The Adobe AIR and Flash Player Incubator is a place for our runtimes product teams to share new features that are either under development or under consideration for inclusion in future versions of the runtimes. Unlike our beta releases, capabilities that you see in the Incubator builds may or may not be supported in future releases of the runtimes.

2. Who is this Incubator program for?
This program is especially suitable for more adventurous developers who are willing to experiment with software features in early development stages and may or may not be included in future product releases.

3. Why does Adobe have an Incubator program?
Adobe’s product development philosophy is to engage in an open exchange and involve our community of passionate developers in early stages of the development cycle. Your feedback is critical to our on-going innovation efforts for the Flash Platform.

4. What’s the difference between the Incubator program and the beta program?
While the goals of both programs are similar — get early feedback from the developer community, the key differences include:
– The Incubator program allows us to get a community of developers involved in a much earlier development stage than what we do in the beta program.
– The Incubator program will be focused on a collection of new features that may or may not make into any future releases, where as the beta program allows developers to experience and evaluate an upcoming release that has reached the feature-complete stage.

5. What should I expect from the Incubator program?
We plan to release new Flash Player or AIR Incubator builds on a regular basis. To get updates on new builds and features, please subscribe to the RSS feed on Adobe runtimes release blog.  These are early builds of AIR or Flash Player and may not be as stable as a final release. However, the current released features should still work as expected. Please file bugs for new features highlighted in the Incubator and new bugs for current released features. The availability of AIR and Flash Player and supported OS and platforms may vary on the downloads page between updates to this program.

6. Why should I participate in the Incubator program?
The Incubator program provides you the opportunity to get an early look at what our engineers are developing for two of the most ubiquitous runtime technologies in the world. By being an active participant in the program, you’ll be able to influence the future of the leading runtime technologies with the Adobe engineering team.

7. Who will read my comments and answer my questions?
Your feedback is very important to us. Your comments and questions will be read and answered by Adobe engineers who are responsible for these features.

8. What will happen to these features?
These features are under development or under consideration for future releases. Depending on the feedback we get from the community, some of these features will be incorporated into future releases of the runtimes.

9. I have ideas for new features, who do I talk to?
We welcome new ideas from the community. Please submit your ideas to us at http://bugs.adobe.com/flashplayer/

HD video rendered on the GPU is here!

Last November we reported on the incredible performance enhancements that Flash Player 10.2 Beta provides us in the form of GPU-accelerated  HD video playback. By utilizing the new Stage Video API, developers can now enjoy the benefit of  having their H.264 video being completely decoded and rendered on the GPU, drastically reducing the load on the CPU. Of course, what this translates into is the ability to playback higher quality video on less powerful devices, such as mobile phones and set-top players.

From Adobe:

“Today, we’re launching Flash Player 10.2 for Windows, Mac, and Linux. We’re especially excited that this release introduces Stage Video, a full hardware accelerated video pipeline for best-in-class, beautiful video across platforms and browsers. Additionally, this version of Flash Player offers all the new capabilities previewed in our beta release, like custom native mouse cursors, multiple monitor full-screen support, Internet Explorer 9 hardware accelerated rendering support, and enhanced sub-pixel rendering for superior text readability.”

Higher-quality video delivered to more devices = better user experiences

The release of Flash Player 10.2 is exciting news for those who wish to deliver their high-definition video to an even wider audience than what was possible before. Companies such as Brightcove, Google, YouTube, and Vimeo have already been enjoying the powerful new performance enhancements found in this version of the Flash Player. Indeed, considering that the usage of relatively low-powered devices such as mobile phones, set-top video players, and Flash-enabled televisions seems to be on an upward trajectory, the arrival of Flash Player 10.2 couldn’t have come at a better time. You can see the performance enhancements yourself by viewing examples of Stage Video in action here. (Must update to Flash Player 10.2)

Contact us today to find out how you can take advantage of this new release, and how your viewers can experience beautiful, high-performance video playback like never before.

Adobe Developer Connection – Stage Video

Getting Started With Stage Video

More Flash Player 10.2 New Features (Native Mouse Cursors, Anyone?)

Yesterday (11/30/2010) Adobe announced the beta release of Flash Player 10.2 for Windows, Mac, and Linux.  This update introduces some key enhancements in the area of video playback, including a new API known as Stage Video, that dramatically improves performance for HD content delivery, as well as an API that enables the use of native custom mouse cursors, and support for full screen playback while using multiple displays.

Stage Video

Perhaps the biggest change comes with the introduction of the Stage Video API, which provides an alternative method of rendering video in Flash besides using the Video object in the display list.  Instead, video can now be rendered onto a flash.media.StageVideo object, which gets created by Flash Player and composited through the GPU instead.  When playing video that has been encoded to the H.264 specification, and thus optimized for GPU acceleration, Flash Player 10.2 can decode and render video entirely on the GPU without sending that data to the CPU for processing, dramatically decreasing CPU load.

This reduction in processing demand means that higher quality video (read: higher bitrates/framerates) can now be rendered successfully by less powerful machines.  This is a huge plus for mobile devices, set-top boxes, and TVs that, while typically have powerful video rendering capabilities, usually lack the CPU power that a desktop computer may have.  Indeed, sites like YouTube are already preparing to support Stage Video, and Google TV currently supports Stage Video on their set-top devices.

Content providers can still use their existing content with Stage Video.  There’s no need to re-encode their video assets after implementing the Stage Video API into their applications.  More information on how developers can incorporate Stage Video into their sites here.

Demo For Flash Player 10.2 Beta From Adobe Labs

Here’s a quick demo taken from Adobe Labs:

Install Flash Player 10.2 beta to preview Stage Video hardware acceleration in the demos below. We’ve found the beta to be stable and ready for broad testing, but keep in mind this a sneak peak, and not everything will be fully baked just yet.

Click on the thumbnail below for a simple example of Stage Video using the example code described in Thibault Imbert’s Stage Video developer article Getting Started with the StageVideo API.

(c) copyright 2008, Blender Foundation / www.bigbuckbunny.org

The Stage Video API for advanced GPU Acceleration, the ability for developers to implement custom, native mouse cursors in their applications, Internet Explorer 9 GPU support, enhanced text rendering capabilities, and full screen support while using multiple displays all add up to a nice amount of improvements being offered with Flash Player 10.2 Beta.