joowtv

News

17 Aprile 2013 In Blog 0 comment
tradotto da "How to Encode Video for Multiple Devices "By Jan Ozer

Molti produttori del settore dello streaming stanno aumentando il numero di piattaforme mobili ed over-the-top (OTT) supportate, allo stesso tempo implementano l’adaptive streaming per migliorare l'esperienza di visualizzazione su ogni dispositivo per ogni tipologia di target. Ci sono due modi per ottenere questo risultato: produrre un unico insieme di flussi per ogni target, oppure partire da uno piccolo gruppo di file che servirà efficacemente tutte le piattaforme. In questo articolo, esploreremo  il secondo approccio.

Il primo passo è quello di identificare le piattaforme su cui si vuole distribuire il contenuto. Per la stragrande maggioranza dei produttori, di solito questo significa sia desktop , mobile e piattaforme OTT. Mentre l'aggiunta di piattaforme può sembrare scoraggiante in un primo momento, considerate che i n primo luogo, tutte le piattaforme rilevanti di destinazione riproducono video H.264, inoltre tutte  usano una delle tre tecnologie di streaming adattivo; Flash streaming dinamico (sia RTMP o HTTP), Smooth Streaming o HTTP Live Streaming (HLS). (vedere  tabella 1). Nella tabella sono indicate le specifiche massime consentite per ogni piattaforma. Non sono  inclusi i PC poiché  non vi è alcuna limitazione hardware, e la maggior parte dei PC è in grado di riprodurre almeno 720p video. La capacità di riproduzione di video sulle piattaforme mobili è invece dipendente dal dispositivo. In termini di streaming adattivo, HLS di Apple è il chiaro vincitore nel segmento OTT, con solo Xbox 360 di Microsoft non supportata (nessuna sorpresa). Questo significa che se si sta distribuendo i file singoli per ogni dispositivo, c’è solo bisogno di trovare e utilizzare parametri ottimali di codifica per ogni piattaforma. Se si sta distribuendo con streaming adattivo  è necessario supportare Flash o Smooth Streaming sul desktop ed HLS per la maggior parte dei dispositivi  mobili ed OTT. Mettere tutto  in un media server o un servizio CDN che può fare la transcodifica da un formato ad un altro sembra rendere le cose molto più semplici.

Il Mobile detta il passo

Fare la codifica per dispositivi mobile è una faccenda  cosa piuttosto complicate, sia perché hanno una capacità di riproduzione limitata, sia perchè possono contare su connessioni meno affidabili, elementi che si devono necessariamente considerare.

Al contrario, la maggior parte dei computer e dei dispositivi OTT supportano  H.264 e solitamente utilizzano connessioni ad alta velocità o connessioni a banda larga, sia in modalità cablata che  tramite Wi-Fi. Tuttavia quando si distribuiscono contenuti video per PC e dispositivi OTT, bisogna  bilanciare i costi di banda con una buona qualità di riproduzione. Quando configura la distribuzione per  il mobile, è centrale con siderare la distribuzione sui dispositivi meno performanti e con capacità di connettività limitate.

Questo significa che verranno prodotti alcuni stream appositamente per il mobile che non potranno essere distribuiti su  computer o OTT. Significa anche che si dovrebbe prendere in considerazione le piattaforme mobili in prima istanza. Nel  2012, NetMarketShare ha rilevato  che Apple deteneva il 61.1% nel mercato dei sistemi operative per mobile/tablet , Android il  28.02%, Java ME il 6.65%, BlackBerry il 1.42%, Symbian il 1.24% e Windows Phone il 0.9%. In questo articoloconsidereremo Apple, Android e Microsoft ed ignoreremo il resto.

APPLE MOBILE DEVICES

I produttori di contenuti video, ovviamente danno priorità alla distribuzione su iOS in quanto ha la maggiore quota di mercato, ma anche perché ha semplificato la distribuzione presso i propri dispositivi. Per esempio, Apple ha definito nello specifico le capacità di riproduzione H.264 su ogni dispositivo, tra cui la risoluzione, velocità di trasmissione dati, e profilo, un'azione apparentemente ovvia che però è  sfuggita alla maggior parte degli sviluppatori di hardware con piattaforma Android. In secondo luogo hanno definito in modo personalizzato HLS per rendere più semplice la distribuzione sui dispositivi iOS. Un esempio significativo è evidenziato nella tabella 2, che evidenzia le configurazioni raccomandate per stream  16:9 distribuiti in  HLS. Questi dati sono presi da Apple Technical Note TN2224, intitolato “Best Practices for Creating and Deploying HTTP Live Streaming Media for the iPhone and iPad.” Come si può vedere, ci sono  raccomandazioni specifiche rispetto alla configurazione degli stream per ogni singolo dispositivo. Per i produttori di video che intendono  distribuire su dispositivi iOS, TN2224 è il punto di partenza.

 

ANDROID MOBILE DEVICES

La distribuzione sui dispositivi Android è molto più complicata per diversi motivi. In primo luogo, ci sono più produttori di hardware con più dispositivi con vaghi o senza riferimenti alla riproduzione  H.264. Per esempio, la scheda tecnica dell’ HTC Rhyme, non ha alcun riferimento all’ h.264. Il numero e la diversità dei dispositivi, insieme con la mancanza di informazioni sulla riproduzione H.264, rende la creazione di una tabella che racchiuda le specifiche per ogni dispositivo,  un compito impossibile. Invece, sulla pagina dei formati supportati da android , Google dettaglia le capacità software di riproduzione del sistema operativo Android e fornisce le scarse raccomandazioni indicate nella tabella 3.

Si potrebbe immaginare che le capacità di riproduzione hardware dei più recenti tablet e smartphone Android superino di gran lunga queste raccomandazioni. Per esempio, con un  Toshiba Thrive tablet, è possibile riprodurre un  video 720p codificato utilizzando il High profile senza problemi (anche se sul sito Toshiba simile non sono presenti informazioni sulla riproduzione H.264). Durante la codifica per i dispositivi Android, tuttavia, si deve andare un po’ a tentativi. Mentre con Apple, è tutto noto.  Un ulteriore fattore di complicazione per Android è che il supporto HLS è arrivata in ritardo, a partire dalla versione Android 3.1. come evidenziato in “penetration of Android versions “; Come riportato nel seguente articolo:“Jeroen Wijering Talks HLS, DASH, and the JW Player 6.”, la soluzione migliore è spesso costruirsi la propria applicazione per la riproduzione dei video.

 

MICROSOFT WINDOWS PHONE

Sebbene la quota attuale di Microsoft sia trascurabile nel settore mobile / tablet, ci sono grandi aspettative per Windows 8 , RT e la piattaforma Windows Phone.

Come Apple, Microsoft offre un numero limitato di telefoni cellulari e documenta le loro caratteristiche in modo esaustivo. Si noti che mentre Windows RT supporterà Flash (e AIR dalla secondà metà del 2013), i telefoni Windows non supportano attualmente Flash. Il supporto dei dispositivi mobili windows d’altronde non è nella road map di adobe. Come si può vedere nella tabella 1, l'unica tecnologia di distribuzione adattiva supportata dalla piattaforma Windows Phone è lo Smooth Streaming. Come osservato nei Media Codec supportati in  Windows Phone, non tutti i telefoni Windows supportano il cambio di risoluzione dinamico. Per questi telefoni, tutte le risoluzioni del gruppo adattivo devono condividere la stessa risoluzione . La fonte migliore per i ottenere i parametri di codifica consigliati per lo Smooth Streaming sono i preset di codifica presenti in Microsoft Expression Encoder 4.  In questo google doc sono riportati  i parametri di configurazione consigliati per il video 1080p in un foglio. Come vedrete, il preset utilizza molteplici risoluzioni che non funzionerebbero  per alcune versionei di Windows Phone.

Over-the-Top Devices

Again, OTT devices are easier than mobile because they all live on at least relatively high-speed connections and can all decode virtually any H.264 stream you throw their way. You have links to the playback and adaptive streaming specs, so here I’ll just point out any highlights therefrom.

 

I dispositivi OTT sono più facili da gestire rispetto ai dispositivi mobili, in quanto hanno connessioni ad alta velocità e possono decodificare praticamente qualsiasi flusso H.264. Nella tabella successiva le raccomandazioni di codifica per OTT. Anche se Roku supporta più specifiche rispetto allo streaming adattivo , la sua guida chiarisce che HLS è la modalità distributiva  preferita. La guida individua anche in  Wowza Media Server la tecnologia migliore nel campo HLS; con una guida utile per configurare il Roku Streaming Player. Apple TV è stato considerato precedentemente nella sezione di iOS. Si noti che secondo Boxee support boards, HLS funziona solo all'interno di un'applicazione, non nel browser. È interessante notare che, come si può vedere nella tabella 4, come GoogleTV abbia adattato le sue “stream recommendations “ a quelle di Apple TN2224, anche se ha ha raccomandato l'alto profilo per tutti i flussi. Finally, for Smooth Streaming to the Xbox, see the earlier discussion about Microsoft Windows Phone. Note that I checked Expression Encoder, and there were no Xbox presets. Infine, lo Smooth Streaming per la Xbox, vedere la precedente discussione su Microsoft Windows Phone. In Expression Encoder  non sono presenti  preset Xbox.

Sintesi

Dopo queste premesse, prendiamo qualceh decisione operativa, a cominciare dal numero di stream.

Quanti stream?

Come indicato nella tabella 2, Apple consiglia 10 stream fino a  1080p, tra cui un solo stream unicamente  audio. Tuttavia, prima di seguire questi consigli, bisogna considerare il costo di distribuzione. Consideriamo che con un bitrate di 8564 Kbps per il video 1080p, un'ora di video dovrebbe consumare circa 4 GB.  Secondo quanto riportato da Dan Rayburn nel suo blog in materia pricing CDN , per i clienti che acquistano da 100.000$ fino ad 1 milione $ all’ anno in banda , il costo del singolo GB varia da un minimo di 1 centesimo ad  un massimo di 12 centesimi.

A questi prezzi, costerebbe tra i 4 centesimi e 48 centesimi per lo streaming di un'ora di video 1080p  come suggerito in tabella 2 da Apple. Bisogna inoltre considerare che il costo del singolo GB è generalmente considerevolmente più alto per chi non utilizza grandi quantitativi di banda , si arriva fino ad  1.10 $/GB, in quest’ultimo caso il costo per uno streaming di un ora di un video 1080p sale 4,40 dollari.   Quando si configura  la qualità a cui fare lo streaming , bisogna considerare i costi di banda che si possono sostenere e che sono  coerenti con la propria  strategia di monetizzazione e la struttura dei costi.

Per esempio, se ci si può permettere solo 3 Mbps di banda , conviene  codificare a 720p, non 1080p, sarebbe inutile. Così come è importante capire quale qualità massima si può supportare è altrettanto importante identificare la qualità minima che si vuole garantire. Per Apple, è 200Kbps , 416 × 234 a 10-12 fotogrammi al secondo è un punto di partenza ragionevole. Individuate le qualità dei picchi del flusso (high and low) è necessario identificare il numero di flussi per ogni risoluzione. In linea generale e astratta dobbiamo garantire almeno un flusso per ogni risoluzione stabilita. Ad esempio, YouTube riproduce video 16:09 con due risoluzioni, 640 × 360 e 854 × 480, più il full screen.  Se si carica un video 720p o più grande, YouTube farà una codifica per entrambe le risoluzioni. Quindi, se si riproduce un video a  640 × 360, è necessario avere almeno un flusso codificato in quella risoluzione. Volete anche un numero sufficiente di corsi d'acqua per servire come trampolini di lancio ragionevole tra i flussi più alti e più bassi di qualità. Per YouTube, questo significava quattro 16:09 flussi fra loro flusso cellulare configurato a 176 × 141 e il loro flusso 1080p (o, flussi a 426 × 240, 640 × 360, 854 × 480 e 720p). E’ possible configurare anche tutte le risluzioni intermedie che si vogliono garantire. Quanto suggerisce la codifica in YouTube, è ideale avere 4 flussi 16:9 tra la codifica mobile a 176×141 ed il  1080p (426×240, 640×360, 854×480 e 720p).

Altre opzioni di configurazione

Una volta che sai quanti flussi produrre, è necessario configurarli. Per gli stream a bassa qualità può essere preferibile ridurre il frame rate piuttosto che la risoluzione, interessanti opinioni in merito su “Configuring Low Data Rate Adaptive Streams”.

In termini di bitrate per ogni stream si può partire dai 200Kbps (suggeriti da Apple )e salire a bitrate più elevati, come ad esempio i 2Mbps. Probabilmente il più grande problema di configurazione si riferisce al profilo H.264 applicato a ogni file. Ad esempio, se si seguono le raccomandazioni di Apple, si userà il base line profile per i primi quattro stream (con video, ovvero audio escluso) ed il Main profile per i successivi quattro. Per Android l'approccio più sicuro sarebbe quello di utilizzare il base profile per tutti i flussi. Tuttavia, tutte le piattaforme OTT ed i computer possono riprodurre flussi codificati utilizzando High profile, ma può essere controproducente in termini di costi operativi e di stroage/banda produrre così tante varianti di codifica. Alcune considerazioni a riguardo , “H.264 in a Mobile World: Adios to the Main and High Profiles?” relative ad un test di utilizzo dei 3 profili h264 con gli altri  parametri trasversalmente identici.

In uno solo di questi casi di test, quello in cui il video è stato codificato a 640 × 360 @ 240Kbps, era la visibile una sostanziale differenza. Con impostazioni più ragionevoli, ad esempio 720p @ 800Kbps e 640 × 480 @ 468Kbps, i file erano praticamente indistinguibili.
E’ importante prestare particolare attenzione alla differenza di qualità tra gli stream Main ed High profile profilo. Se si sceglie high profile per OTT e computer, piuttosto che il main, sarà poi necessario creare uno stream con parametri equivalenti utilizzando il Main profile per avere piena compatibilità iOS / Android.

Poiché i dispositivi Android hanno grosso modo le stesse caratteristiche HW dei dispositivi Apple non è necessario creare tutti gli stream con il Base-line profile appositamente per Android. Lo schema mostrato nella tabella 2 è sicuramente valido anche per Android. Lo schema in tabella 2 è probabilmente lo schema ottimale i computer, mobile, ed i dispositivi OTT. Prese  tutte le decisioni difficili, è il momento di considerare gli aspetti “meccanici” di codifica per lo streaming adattivo. Per prima cosa l'intervallo dei fotogramma chiave deve essere identico per tutti i flussi con differenti codifiche. La maggior parte dei produttori utilizzano un intervallo di 2 o 3 secondi, e disabilitano l'inserimento di fotogrammi chiave nei cambi di scena.   In secondo luogo, decidere se codificare utilizzando la codifica bitrate costante (CBR) o la codifica bit rate variabile (VBR).  Infine, per quanto riguarda l'audio, considera che è più sicuro utilizzare gli stessi parametri audio per tutti gli stream, questo riduce al minimo il rischio di popping. Questo è il motivo per cui Apple consiglia audio  44,1 kHz a 64 Kbps per tutti i flussi (ved tabella 2).  D'altra parte, se nei contenuti la qualità audio è una componente significativa questo approccio può risultare troppo restrittivo. 

Per minimizzare potenziali problemi, conviene usare la stessa frequenza per tutti i flussi e cambiare il numero di canali, il bitrate, o entrambi. Ad esempio, considerare un audio  44,1 kHz mono a 32Kbps per il flusso a più bassa qualità,  44,1 kHz, mono a 64Kbps per i flussi di media qualità, e 44,1 kHz stereo a 128Kbps per i flussi di altissima qualità.

 

04 Febbraio 2013 In Blog 0 comment

Amazon ha annunciato un nuovo servizio di trnascoding in cloud, denominato Amazon Elastic Transcoder.

26 Novembre 2012 In Blog 0 comment

E-thatre, web tv dedicata al teatro e realizzata con la piattaforma Joow , è candidata nella sezione "entertainement" ai Teletopi 2012, gli oscar delle web tv italiane

18 Settembre 2012 In Blog 0 comment

Pico srl , presenterà Joow Tv al Integrated Systems Europe Show (ISE), che si terrà ad Amsterdam dal 29 gennaio al 31 gennaio 2013, presso lo stand Pico Srl (Stand: 8-R225).

Pagina 1 di 2