Tag: HTTP Dynamic Streaming

Sample Files

document_small_download LBA.zip


Late-Binding Audio

OSMF 1.6 and higher supports the inclusion of one or more alternative audio tracks with a single HTTP video stream. This practice, referred to as “late-binding audio”, allows content providers to deliver video with any number of alternate language tracks without having to duplicate and repackage the video for each audio track. Users can then switch between the audio tracks either before or during playback. OSMF detects the presence of the alternate audio from an .f4m manifest file, which has been modified to include bootstrapping information and other metadata about the alternate audio tracks.

The following article will guide you through the process of delivering an alternate language audio track to an on-demand video file (VOD) streamed over HTTP using the late-binding audio feature. You should be familiar with the HTTP Dynamic Streaming (HDS) workflow before beginning. Please refer to the following articles on HDS for more information:


Getting Started

To get the most out of this article, you will need the following:


Overview

After completing this article you should have a good understanding of what it takes to stream on-demand video with alternate audio tracks over HTTP. At a high level, this process includes:

  • Packaging your media files into segments and fragments (.f4x)
  • Creating a master (set-level) manifest file (.f4m)
  • Editing the media tags for the alternate audio tracks within the master .f4m to prepare them for late-binding audio
  • Uploading the packaged files to Adobe Media Server
  • Including a cross-domain.xml file on the server if the media player is hosted on a separate domain from Adobe Media Server
  • Playing back the video using the master .f4m as the video source, and switching between audio tracks using OSMF


Packaging the media files

When streaming media using HDS, files first need to be “packaged” into segments and fragments (.f4f), index files (.f4x), and a manifest file (.f4m). Adobe Media Server 5.0 or later can automatically package your media files for both normal on-demand and live streaming with the included Live Packager application (live), and JIT HTTP Apache module (vod). However, in order to achieve late-binding audio, the manifest for the main video file needs to be modified so that it includes information about the alternate audio tracks.

To package media that supports late-binding audio, you use the f4fpackager, a command line tool built into Adobe Media Server. The f4fpackager accepts .f4v, .flv, or other mp4-compatible files, and is located in the rootinstall/tools/f4fpackager folder within Adobe Media Server.

Next, you will use the f4fpackager to create packaged media files. You can use your own video and audio assets for this step, or you can use the “Obama.f4v” (video), and “Spanish_ALT_Audio.mp4”(alternate audio) included in the exercise files.


Running the f4fpackager

The process for packaging media files on Windows and Linux is similar:

  1. From command line target the f4fpackager executable for execution in the [Adobe Media Server Install Dir]/tools/f4fpackager (Windows), or set the LD_LIBRARY_PATH to the directory containing the File Packager libraries (Linux).

  2.  Enter the name of the tool, along with any arguments. For this example, you’ll only need to provide the following arguments for each input file:

  • The name of the input file
  • The file’s overall bitrate (Alternatively, you could add this information manually later)
  • The location where you’d like the packaged files to be output (If you omit this argument, the File Packager simply places the packaged files in the same directory as the source files)

  3.  Run the packager on the main video .f4v file. At the command prompt, enter arguments similar to: 

 

C:\Program Files\Adobe\Adobe Media Server 5\tools\f4fpackager\f4fpackager –-input-file=”C:\Obama.f4v” –-bitrate=”546” –-output-path=”E:\packaged_files”

 

   4.  Next, run the packager again, this time to package the alternate audio track:


C:\Program Files\Adobe\Adobe Media Server 5\tools\f4fpackager\f4fpackager –-input-file=”C:\Spanish_ALT_Audio.mp4” –-bitrate=”209” –-output-path=”E:\packaged_files”


   5.  Click “Enter” to run the f4fpackager


*Note: individual media files are packaged separately, meaning you run the packager once for the main video file, “Obama.f4v”, and then again for the alternate audio file, “Spanish_ALT_Audio.mp4”


running the f4fpackager

Figure 1.0: Packaging media with the f4fpackager tool


You should now see the packaged output files generated by the File Packager in the directory you supplied to the arguments in step #2. Packaging the source media included in the exercise files should output:

  • Obama.f4m
  • ObamaSeg1.f4f
  • ObamaSeg1.f4x
  • Spanish_ALT_Audio.f4m
  • Spanish_ALT_AudioSeg1.f4f
  • Spanish_ALT_AudioSeg1.f4x


Creating the “master” manifest file

Next, you will modify “Obama.f4m” to create a master (set-level) manifest file that will reference the alternate audio track.

  1. Using a text editor, open the file “Spanish_ALT_Audio.f4m”



Note: If you skipped the previous section on packaging media, you can use the manifests included with the exercise files in LBA/_START_/PackagedMediaFiles_START)



   2.  Copy everything within the bootstrapInfo and media tags in “Spanish_ALT_Audio.f4m”.

<bootstrapInfo
    profile="named"
    id="bootstrap4940">

    AAAB+2Fic3QAAAAAAAAAGQA...

</bootstrapInfo>

<media
    streamId="Spanish_ALT_Audio"
    url="Spanish_ALT_Audio"
    bitrate="209"
    bootstrapInfoId="bootstrap4940">

<metadata>

    AgAKb25NZXRhRGF0YQgAAAAA....

</metadata>

</media>

Figure 1.1: Copy the bootstrapInfo and media tags from the alternate audio manifest file



3.  Paste the bootstrapInfo and media tags into “Obama.f4m” to reference the Spanish language track.


<?xml version="1.0" encoding="UTF-8"?>

<manifest xmlns="http://ns.adobe.com/f4m/1.0">

    <id>Obama</id>
    <streamType>recorded</streamType>
    <duration>133</duration>

<bootstrapInfo
    profile="named"
    id="bootstrap4744">

    AAAAq2Fic3QAAAAAAAAABAAAAAPoAAA....

</bootstrapInfo>

<media

    streamId="Obama"
    url="Obama"
    bitrate="546"
    bootstrapInfoId="bootstrap4744">

<metadata>
    AgAKb25NZXRhRGF0YQgAAAAAAAhk....
</metadata>

</media>

<bootstrapInfo
    profile="named"
    id="bootstrap4940">

AAAB+2Fic3QAAAAAAAAAGQAAAAPo....

</bootstrapInfo>

<media
    streamId="Spanish_ALT_Audio"
    url="Spanish_ALT_Audio"
    bitrate="209"
    bootstrapInfoId="bootstrap4940">

<metadata>

AgAKb25NZXRhRGF0YQgAAAA....

</metadata>

</media>

</manifest>

Figure 1.2: Paste the bootstrapInfo and media tags from the alternate audio .f4m into the main video’s manifest file to create the master .f4m



4.  Add the following attributes to the media tag for the Spanish language track within “Obama.f4m”:

  • alternate=”true”
  • type=”audio”
  • lang=”Spanish”

<media
   streamId="Spanish_ALT_Audio"
   url="Spanish_ALT_Audio"
   bitrate="209"
   bootstrapInfoId="bootstrap4940"
   alternate="true"
   type="audio"
   lang="Spanish">

Figure 1.3: Edit the alternate audio’s media tag to prepare it for late-binding audio



In the above step, alternate=”true”, and type=”audio” allow OSMF to parse through “Obama.f4m” and see that there is alternate audio available. Logic within the included example player, which you’ll be using to play the video in a later step, uses lang=”Spanish” to populate a dropdown menu with the available alternate audio stream.

5.  Save the file “Obama.f4m”. This is now the master manifest file, and it will be what you will reference to play the video and alternate audio content with OSMF.


Upload the packaged files to the server

6.  Next, you will need to upload all of the packaged files to a folder within the webroot/vod directory of Adobe Media Server. On Windows this default location is C:\Program Files\Adobe\Adobe Media Server 5\webroot\vod. Later on you will point OSMF to the master manifest within this directory in order to play the video.

PackagedFilesOnServer

Figure 1.4: Upload all of the packaged media files to a location within the webroot/vod directory of Adobe Media Server


Verify the delivery of the .f4m file

At this point, all of the packaged files should be uploaded to a directory on the server within /webroot/vod. It’s a good idea to test whether-or-not the server is delivering the manifest file properly, and you can do that by entering the path to the .f4m file in the address bar of a browser.

To test the delivery of the manifest, open the .f4m in a browser from the webserver. On a local development machine the URL would be something like:

http://127.0.0.1/vod/Obama.f4m

If you’ve entered the URL correctly, and the server is properly serving up the .f4m, you should see the manifest’s xml. Notice the alternate audio’s media and bootstrap info tags you added earlier, as well as the additional attributes in the media tag:

*Note: Safari will not display XML by default


<manifest xmlns="http://ns.adobe.com/f4m/1.0">

<id>Obama</id>
<streamType>recorded</streamType>
<duration>133</duration>

<bootstrapInfo profile="named" id="bootstrap4744">

AAAAq2Fic3QAAAAAAAAABAAAAAPoAAAAAAACB3QAAA…

</bootstrapInfo>

<media streamId="Obama" url="Obama" bitrate="546"

bootstrapInfoId="bootstrap4744">

<metadata>

AgAKb25NZXRhRGF0YQgAAAAAAAhkd…

</metadata>

</media>

<bootstrapInfo profile="named" id="bootstrap4940">

AAAB+2Fic3QAAAAAAAAAGQAAAAPoAAAAAAACCwAAAAAA…

</bootstrapInfo>

<media 
 streamId="Spanish_ALT_Audio" 
 url="Spanish_ALT_Audio" 
 bitrate="209" 
 bootstrapInfoId="bootstrap4940" 
 alternate="true" 
 type="audio" 
 lang="Spanish">

<metadata>

AgAKb25NZXRhRGF0YQgAAAAAAAhkdXJh…

</metadata>

</media>

</manifest>

Figure 1.5: Verify that the server is delivering the .f4m properly by entering the path to the manifest in your browser’s address bar



*Note: The above example URL does not point to “/hds-vod” like it would for HDS content that needs to be packaged just-in-time as the client application requests it. This is because “/hds-vod” is a location directive for Apache that tells the server to look for content in the /webroot/vod directory, and package it for delivery. The jithttp module in Apache responsible for just-in-time packaging isn’t needed for this example, as the source files have been already packaged manually. 


Include a cross-domain policy file (Optional)

In order to access content from Adobe Media Server using a Flash-based media player that is hosted on a separate domain from the server, the player needs permission in the form of a cross-domain policy file hosted on the server. Below is an example of a cross-domain policy file that allows access from any domain. You may want to use a more restrictive cross-domain policy for security reasons. For more information on cross-domain policy files, see Setting a crossdomain.xml file for HTTP streaming.

CrossDomain

Figure 1.6: Include a crossdomain.xml file in the webroot directory of Adobe Media Server


  1. Open “crossdomain.xml” from the LBA/_START_/ folder in the included exercise files in a text editor.

  2. Examine the permissions, and edit them if you wish to limit access to include only specific domains.

  3. Save the file, and upload “crossdomain.xml” to the /webroot directory of Adobe Media Server.


Test the video using an OSMF-based media player

Now it’s time to test the video and the alternate audio streams using the included sample media player. The sample player is provided as a Flash Builder project, and is based on the LateBindingAudioSample application that comes as part of the OSMF source download(OSMF/samples/LateBindingAudioSample). You can find the included sample player in LBA/_COMPLETED_/LateBindingAudio_VOD.fxp in the exercise files folder.

  1. Import the file “LateBindingAudio_VOD.fxp” into Flash Builder and run the project.

  2. Enter the URL of the master manifest located on your server in the “.f4m source” field.

  3. If the player can see the path to the .f4m file, the Play button will be enabled, and the alternate languages dropdown menu will show a Spanish audio option.

  4. In no particular order, click “Play”, and choose “Spanish” from the alternate languages dropdown menu.

  5. The video should start to play, and you should see “Switching Audio Track” being displayed in the player under the languages menu.

  6. The audio should switch to the Spanish track, while the video continues to play normally.

The OSMF Player

Figure 1.7: Play the media within the included sample application. Enter the URL for the manifest file and click Play. Use the language selection dropdown menu to switch to the alternate audio stream.


Where to go from here

This article covered the steps necessary to attach late-binding audio to an HTTP video stream using a pre-built OSMF-based media player. You should now have a good understanding of how to package media files for delivery over HTTP, as well as what needs to be done on the server side to deliver late-binding audio. In the next article, you will learn all about the media player, and the code within it that makes late-binding audio possible.

In addition to on-demand video, OSMF supports late-binding audio for live video, multi-bitrate video, and DVR. For more information about HTTP Dynamic Streaming, late-binding audio, and OSMF, please refer to the following resources:



Contact us to learn more.

Advanced HTTP Dynamic Streaming Solutions

Posted on May 23, 2012 at 4:27 pm in Blog

RealEyes Media & Why HTTP Dynamic Streaming

RealEyes Media is a developer lead digital consultancy who focuses on on digital media delivery and software application development, consultation, & training. RealEyes builds interactive software solutions specializing in streaming media. If you need a solution on the web, desktop, mobile or connected device we have the expertise to realize your vision.

In the current technical environment it has become evident that media delivery across devices & platforms is in a state of transition and growth. This growth includes not just the devices and users that are consuming the media, but the technologies and transports that are providing the media across the board. Technologies like HTTP Dynamic Streaming (HDS) are blazing the trail that will ultimately lead the consumer to their content. Currently the capabilities provided by HDS provide developers and content providers with the broad access that is required to reach different devices and markets.

What is HTTP Dynamic Streaming?

HTTP Dynamic Streaming or HDS gives the content provider the ability to deliver packaged streaming media over the HTTP protocol to multiple platforms while saving on server infrastructure, bandwidth and administration costs. HDS can also remove the need need for expensive and or high maintenance media servers. The recorded and live content is packaged in a fragmented format allowing for the video to be delivered to the consumer in a streaming, seek-able, and multi-bitrate format. In addition to the high level of delivery options, HDS can be packaged with DRM to protect the media and can be deployed to CDNs to allow for even greater user experience while consuming media.

HTTP Dynamic Streaming Limitations

The work we have been doing with HDS packaged content and delivery has opened the doors to extend the use and integration of HDS packaged content. There are two stumbling blocks that we have encountered with the current state of HDS. Both problems center around the reliance on web server & web server extension to deliver the HDS packaged content. HDS requires an Apache web server & the HTTP Origin Module to deliver the media content to client players. The (simplified) playback sequence for HDS content is:

  1. The client requests an .f4m file that provides the location and initial data for playback.
  2. From that data the client player then determines what segment/fragment to request for the current timecode.
  3. The Apache web server hands this request off to the HTTP Origin Module to extract the needed F4V fragment data from the segment from on the web server and returns that to the web server.
  4. The Apache web server then provides the response to the client player.
  5. The client player then parses the F4V content into a playable format and plays it back.

The second stumbling block is playback of HDS content from a local file system. Currently there is no way to extract the F4V fragment data from the packaged segment files. These two use cases highlight the current deployment and usage limitations for HDS with the reliance on Apache and the Origin module. Removing the reliance on Apache and the Origin module not only allows for a greater number of and more flexible deployment options, but can simplify deployments and allow for more cost effective storage and delivery.

Removing the Limitations

The first step to extending the delivery options for HDS content is to get the packaged content into a format that doesn’t require the HTTP Origin Module. This means extracting the fragments from the segment files. RealEyes has created a tool set that can extract the fragments from an HDS packaged file set. The fragments are extracted in the exact same manner as the HTTP Origin Module meaning that the reliance on Apache and the Origin module has been removed. Once the fragments have been extracted, they can be deployed to any server that can respond to HTTP requests. This has been tested with Amazon S3, IIS and Apache (without the origin module installed) and has worked without issue.

The next step is local playback of HDS content. Once we have the fragments, we can play that content back, but for long-form media content this can mean hundreds of fragment files. A set of ActionScript3 libraries have been created to allow for the download and packaging of HDS content for local playback. The download can be accomplished from normal HDS delivery or from HDS content that has had the fragments pre-extracted. As the fragments are downloaded they are written to disk into a file format that allows for interrupted downloads as well as playback during download on windows and mac operating systems.

Local playback while downloading is accomplished through an additional ActionScript3 library created specifically for read and write operations on multiple files asynchronously and has been tuned for high performance. Playback has been tested with short-form video content as well as feature length video content. Great pains were taken to work within the file formats and specifications so things like DRM still work even with content that has had fragments extracted, downloaded and saved locally for playback.

Advanced HTTP Dynamic Flow

A visualization of the download and playback for HTTP Dynamic Streaming content.

What can you do with it?

Some of the use cases that are possible with the extended deployment and use with these tools and libraries include:

  • Local playback of HDS content
  • Simplified content deployment
  • Content deployment to cost effective services (Amazon S3)
  • Simultaneous download and playback of long-form video
  • Live HDS Streaming and download for DVR-like for local playback
  • Bandwidth and storage space savings

What is Next?

Plans for the toolset include creating web services for fragment extraction, updating the libraries and tools to make sure they work with OSMF 2.0 (currently they have been tested on OSMF 1.6). Although HDS is a powerful and flexible way to deliver content, we are continuing to embrace formats and specifications that increase the reach and availability of digital media. We are an MPEG-DASH promoter and plan to work with this format heavily. We are always looking to the next development and hope to be part of the innovators pushing media delivery to the next level.

contact-us-to-learn-more

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.

Zatim

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.

Sada

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

*Napomena*
 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.

Then

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.

Now

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:

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

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..

*Note*
 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.


Documentation

Adobe HTTP Dynamic Streaming documentation

OSMF.org

f4fpackager documentation

F4M file format specification

Downloads

HTTP origin module

f4fpackager

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

OSMF 1.6-Sprint 5 is Here!

Posted on June 06, 2011 at 2:27 pm in Development, Media Solutions

Today Adobe announced the release of the latest sprint for OSMF 1.6, and it includes some exciting new features in terms of how it can handle audio. The biggest new feature is support for multiple audio tracks for HTTP Dynamic Streaming. Known as “late-binding audio”, this methodology allows producers to present multiple audio-only tracks attached to a particular video to the end user. Consider, for example, the need to deliver videos in more than one language. Late-binding audio allows producers to include seperate audio tracks for each language, and then have the viewer choose the appropriate one based on their needs. The benefits to having multiple audio tracks associated with a single video file are savings in encoding time, as well as reduced storage requirements-much more efficient than having to encode and store several different versions of each video. OSMF also supports the ability to switch between audio tracks during playback, which allows even more flexibility in terms of what kind of user experiences are possible.

Currently late-binding audio is available for video-on-demand only, but Adobe promises live/linear support in their next drop.

Check out the original announcement here.