VERKETTUNG VON VIDEOS MIT HLS-MANIFESTEN

Dieser Artikel konzentriert sich auf HTTP Live Streaming (HLS), aber die grundlegenden Konzepte sind auch für andere HTTP-basierte Streaming-Protokolle gültig. Ein tieferes Eintauchen in das HLS-Protokoll würde den Rahmen dieses Artikels sprengen, aber eine Fülle von Informationen ist online verfügbar, einschließlich des veröffentlichten Standards: HTTP Live Streaming.

Verkettung und der alte Weg

Inhalte sind gleichbedeutend mit Wert. In der Videowelt besteht eine Möglichkeit, mehr Wert zu schaffen, darin, ein einzelnes Video mit anderen Videos zu mischen, um einen neuen Inhalt zu erstellen. In vielen Fällen geschieht dies durch Verkettung oder die Möglichkeit, mehrere Videos zusammenzufügen, was eine grundlegende Form der Bearbeitung darstellt. Hinzu kommt die Erstellung von Clips durch Bearbeitungslisten, und schon haben Sie zwei der grundlegendsten Funktionen eines nichtlinearen Editors.

So vielversprechend die Verkettung auch erscheint, sie kann auch eine Belastung für die Infrastruktur und den Betrieb darstellen. Stellen Sie sich ein soziales Videoportal vor. Abhängig von den Zielgeräten kann es zwischen einer Handvoll und mehreren Dutzend Ausgabeformaten pro Video geben. Sollten sie sich dazu entschließen, mehrere Videos miteinander zu verknüpfen, um den Wert ihrer Bibliothek zu erhöhen, steigen auch die Speicherkosten und die Komplexität der Verwaltung von Assets massiv an. Jedes Mal, wenn eine neue Kombination von Videos erstellt wird, wird eine Reihe von festen Beständen erzeugt, die gespeichert werden müssen.

HTTP-Live-Streaming und die Manifestdatei

Die Einführung von manifestgesteuerten HTTP-basierten Streaming-Protokollen hat ein völlig neues Paradigma für die Erstellung dynamischer Seherlebnisse geschaffen. Bisher bestand die einzige Möglichkeit, mehrere Kombinationen von Clips aus einem einzigen Inhalt zu liefern, in der Bearbeitung, d. h. in der Erstellung von festen Inhalten. Mit Technologien wie HLS - da das abspielbare Element nicht mehr eine Videodatei, sondern eine einfache Textdatei ist - ist die Bearbeitung eines Videos dasselbe wie die Bearbeitung eines Dokuments in einem Textverarbeitungsprogramm.

Für eine Videoplattform gibt es zwei Möglichkeiten, die HLS m3u8-Manifestdatei zu behandeln. Am einfachsten ist es, die m3u8-Datei als separates, abspielbares Asset zu behandeln. Bei diesem Modell wird die m3u8-Datei auf dem Ursprungsserver zusammen mit den segmentierten TS-Dateien gespeichert und an die Geräte geliefert. Das Ergebnis ist einfach und schnell zu implementieren, aber die m3u8-Datei kann nur durch einen manuellen Prozess geändert werden.

Indem das Manifest als etwas behandelt wird, das dynamisch generiert wird, ist es möglich, den Zuschauern eine praktisch unbegrenzte Kombination von Clips zu liefern. Bei diesem Modell wird die m3u8-Datei "on the fly" generiert, d. h. sie liegt nicht auf dem Server, sondern wird jedes Mal erstellt und bereitgestellt, wenn sie angefordert wird

Dynamische Manifest-Erstellung

Was ist eine Manifestdatei? Im Wesentlichen handelt es sich um eine Kombination aus einigen Metadaten und Links zu Videosegmenten.

  • Beispielhaftes Video A
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Exemplarisch_A_segment-01.ts
  • #EXTINF:10,
  • Exemplarisches_A_segment-02.ts

Das obige m3u8 hat zwei Videosegmente von je 10 Sekunden, so dass die Gesamtlänge des Videos 20 Sekunden beträgt. Das Beispielvideo A, das übrigens ein wirklich tolles Video ist, ist 20 Sekunden lang. Stellen wir uns nun vor, wir hätten auch eines:

  • Beispielhaftes Video B
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Exemplarisch_B_segment-01.ts
  • #EXTINF:10,
  • Exemplarisch_B_segment-02.ts

Und nehmen wir an, wir wissen, dass ein bestimmter Betrachter begeistert wäre, wenn er eine Kombination aus beiden Videos sehen würde, wobei Video B zuerst und Video A an zweiter Stelle läuft:

  • Hervorragendes Video
  • #EXTM3U
  • #EXT-X-MEDIA-SEQUENCE:0
  • #EXT-X-TARGETDURATION:10
  • #EXTINF:10,
  • Exemplarisch_B_segment-01.ts
  • #EXTINF:10,
  • Exemplarisch_B_segment-02.ts
  • #EXT-X-DISCONTINUITY
  • #EXTINF:10,
  • Exemplarisch_A_segment-01.ts
  • #EXTINF:10,
  • Exemplarisches_A_segment-02.ts

Jetzt haben wir im Handumdrehen ein neues Video für den Benutzer generiert, das mit Video B beginnt, gefolgt von Video A. Als ob das nicht schon cool genug wäre, wird das Video nahtlos abgespielt, als ob es ein einziges Video wäre.

Vielleicht haben Sie eine kleine Ergänzung zum m3u8 bemerkt:

EXT-X-DISCONTINUITY

Durch das Einfügen dieses Tags in den m3u8 wird dem Player mitgeteilt, dass das nächste Videosegment eine andere Auflösung oder ein anderes Audioprofil als das letzte hat. Wenn die Videos alle mit derselben Auflösung, denselben Codecs und Profilen kodiert sind, kann dieses Tag weggelassen werden.

Ausweitung des neuen Modells

Um eine Videoplattform zu schaffen, die in der Lage ist, benutzerdefinierte Wiedergabeerlebnisse "on-the-fly" zu liefern, muss das m3u8-Manifest nicht als festes Asset behandelt werden, sondern als etwas, das bei jeder Anfrage generiert werden muss. Das bedeutet, dass das Backend den Speicherort jedes Videosegments, die Gesamtzahl der Segmente pro Element und die Länge jedes Segments kennen muss.

Es gibt Möglichkeiten, dies einfacher zu gestalten. Wenn die Dateien beispielsweise einheitlich benannt werden, muss nur der Basisdateiname für alle Segmente bekannt sein, und die Iteration der Segmente kann programmatisch gehandhabt werden. Es kann davon ausgegangen werden, dass alle Segmente mit Ausnahme des letzten Segments die gleiche Zieldauer haben, so dass nur die Dauer des letzten Segments gespeichert werden muss. Bei einer einzelnen Videodatei mit vielen Videosegmenten müssen also nur der Basispfad, der Basisdateiname, die Anzahl der Segmente, die durchschnittliche Segmentlänge und die Länge des letzten Segments gespeichert werden.

Wenn man selbst lange Titel als eine Kombination von Szenen betrachtet, oder noch weitergehend, wenn man Szenen als eine Kombination von Aufnahmen betrachtet, gibt es eine unglaubliche Menge an Möglichkeiten, die durch dynamische Manifestgenerierung erschlossen werden können. Bei frühzeitiger Planung und Entwicklung kann die Architektur der Bereitstellungsplattform ein hohes Maß an Flexibilität bieten, ohne dass die Betriebs- oder Infrastrukturkosten steigen.

WIE AVID-TECHNOLOGIE MASSGESCHNEIDERTE BILDUNGSFUNKTIONEN GESCHAFFEN HAT

Es ist immer interessant zu erfahren, wie Brightcove-Kunden unsere Technologie nutzen und messbare Vorteile aus ihren Implementierungen ziehen. Besonders interessant war es, mehr darüber zu erfahren, wie Avid Technology Brightcove einsetzt, da unsere Welt eng mit der ihren verbunden ist. Während wir unsere Kunden bei der Bereitstellung und Verwaltung von Online-Videocontent unterstützen, ist Avid häufig das kreative Tool, das im Videoentwicklungsprozess eingesetzt wird.

Avid, ein weiteres in Massachusetts ansässiges Unternehmen, ist auf Technologien für die Video- und Audioproduktion spezialisiert, insbesondere auf digitale nichtlineare Bearbeitungssysteme, Management- und Vertriebsdienste. Kreativprofis von Hollywood bis zur Madison Avenue verlassen sich auf die Produktpalette von Avid, um ihre Anforderungen an die visuelle Gestaltung von Geschichten zu erfüllen. Seit der Markteinführung im Jahr 1987 hat Avid für seine technologischen Innovationen Hunderte von Auszeichnungen erhalten, darunter zwei Oscars, einen Grammy und 14 Emmys. Das Unternehmen verfügt zweifellos über "Video Cred".

Was also führte Avid zu Brightcove? Avid ist zwar ein Experte auf dem Gebiet der Videoentwicklung, suchte jedoch nach externem Fachwissen für die besten Verfahren zur Videodistribution. In unserer Kundenfallstudie wird die Beziehung zwischen Avid und Brightcove ausführlicher beschrieben, aber wir möchten diesen Beitrag nutzen, um einen kurzen Überblick zu geben.

Der Weg von Avid zum Online-Video geht im Wesentlichen auf das Frühjahr 2010 zurück, als das Unternehmen begann, Optionen für Live-Webcasting, einschließlich Video, zu untersuchen. Schließlich stellte Avid eine Flash-basierte DIY-Webcasting-Lösung zusammen, die sowohl Chat als auch Video für ein interaktives Erlebnis beinhaltete. Mit diesem Wissen begann das Unternehmen, Online-Videoplattformen zu erforschen, die zusätzliche On-Demand-Anzeigefunktionen bieten und dem Unternehmen dabei helfen würden, weitere Funktionen für Bildungsvideos zu entwickeln.

Im März 2012 wählte Avid Brightcove als Online-Videoplattform aus. Seitdem hat das Unternehmen Videos in seine Website-Hilfsangebote integriert, so dass Benutzer, die mit Avid-Software arbeiten und eine Frage haben, zu Lernvideocontent weitergeleitet werden. Derzeit arbeitet das Avid-Team an der Migration seiner Video-Content-Marketing-Assets auf Video Cloud , damit diese einfach organisiert und verwaltet sowie für mobile Geräte optimiert werden können. Für die Zukunft plant Avid, Brightcove zu nutzen, um die videobasierte Suchmaschinenoptimierung zu verbessern und benutzergenerierten Content auf seiner Website hinzuzufügen.

PUMA FÖRDERT DIE KUNDENBINDUNG MIT ONLINE-VIDEO

Wir haben ausführlich über die Rolle geschrieben, die Online-Videos im Content-Marketing-Ökosystem spielen und Marken dabei helfen, dauerhafte Beziehungen zu ihren Kunden aufzubauen. PUMA, eine der bekanntesten Schuh- und Bekleidungsmarken der Welt, ist ein großartiges Beispiel für einen Vermarkter, der die Macht von Videos verstanden hat und weiß, wie sie dazu beitragen, die Kundenbindung zu erhöhen.

PUMA produziert und veröffentlicht weltweit eine breite Palette von Videoinhalten, um seine Produkte zu unterstützen, aber auch um die Kunden auf eine Reise mitzunehmen. PUMA ist zwar für seine innovativen Produkte bekannt, aber die Marke wird erst durch den Kontext, in den das Unternehmen die Produkte stellt, und den Lebensstil, den die Marke vermittelt, wirklich lebendig. PUMA sieht in Videos eine Möglichkeit, Kunden zu binden und ihnen ein kadenzspezifisches, bildschirmübergreifendes Erlebnis zu bieten.

Diese Strategie kam bei den Olympischen Spielen 2012 in London zum Einsatz, wo PUMA eine komplette Markenumgebung für seine Kunden schuf, mit der sie sowohl persönlich als auch über Live-Videoinhalte interagieren konnten. Die Veranstaltungen und Inhalte waren zeitlich auf den von PUMA gesponserten jamaikanischen Sprinter Usain Bolt und seine epischen Leistungen über 100 und 200 Meter abgestimmt.

Wir haben uns kürzlich mit Jay Basnight, Leiter der digitalen Strategie bei PUMA, zusammengesetzt, um mehr über die Videostrategie des Unternehmens und die Bedeutung von Videos für die Kundenbindung zu erfahren. Jay spricht ausführlich über die Bedeutung von Videos und darüber, wie PUMA den Erfolg misst, sowie darüber, wie das Unternehmen die Brightcove-Videoplattform zur Unterstützung seiner Videobemühungen auf der ganzen Welt einsetzt.

VERWENDUNG VON SALESFORCE-MASSEN-API UND APEX-CODES MIT BRIGHTCOVE

Bei Brightcove verwenden wir Salesforce zur Verwaltung unserer Kundendaten. Unsere Vertriebs-, Account-Management-, Support- und Finanzteams verwenden es auch für verschiedene Aktivitäten wie die Kontaktaufnahme mit Vertriebsleads, die Verfolgung von Supportfällen und die Erstellung von Nutzungsberichten. Für unser Unternehmen ist es wichtig, die Kundendaten zeitnah und zuverlässig in Salesforce zu übertragen.

Das Datenmodell für unsere Produkte unterstützt eine Many-to-many-Beziehung zwischen Benutzern und Konten. Ein Account-Objekt stellt eine Organisation oder eine Abteilung innerhalb einer großen Organisation dar, und ein Benutzerobjekt stellt eine Person dar, die für eine oder mehrere Organisationen arbeitet. In Salesforce passen wir das integrierte Kontaktobjekt an, um jeden Benutzer von Brightcove-Services darzustellen, und wir definieren ein benutzerdefiniertes Objekt namens BCAccount, um ein Konto darzustellen (siehe Abbildung 1).

Abbildung 1

Abbildung 1. Datenmodell in Brightcove-Service und Salesforce

Vor einigen Jahren haben wir die Funktion zur Datensynchronisierung mithilfe der SOAP-API von Salesforce und Quarz entwickelt, und wir haben einige Probleme mit dieser Implementierung festgestellt. Es gibt zwei Hauptschwierigkeiten:

  • Es ist zu geschwätzig, was es langsam macht. Pro Stunde können nur 700 Objekte mit Salesforce synchronisiert werden.
  • Es ist sehr aufwändig, Änderungen am Datenmodell vorzunehmen. Um ein neues Feld zu einem Objekt hinzuzufügen, müssen wir eine neue WSDL-Datei aus Salesforce exportieren und Java-Klassen aus der WSDL-Datei generieren.

Angesichts dieser Schwierigkeiten haben wir uns entschlossen, ein neues Synchronisierungssystem zu entwickeln, das die Salesforce Massen-API und den Apex-Code verwendet. Die neue Implementierung besteht aus einer Daten-Pushing-Engine namens RedLine und einer Reihe von Salesforce-Apex-Klassen zur Verarbeitung von Massendaten, die von RedLine gepusht werden.

Abbildung 2

Abbildung 2. Neue Datensynchronisation

RedLine wurde mit Sinatra, einem leichtgewichtigen Ruby-Webserver, als eigenständiger Service unabhängig von den anderen Brightcove-Services entwickelt. RedLine verwendet den Rufus-Scheduler, um in regelmäßigen Abständen die Erstellung, Aktualisierung und Löschung von Objekten von Brightcove über RESTful-APIs abzufragen. Anschließend wandelt RedLine die JSON-Antwort in eine CSV-Datei um und sendet sie als Massenanforderung an Salesforce. Salesforce hat einen Grenzwert von 10.000 Objekten pro Sammelanforderung, was für unsere Zwecke ausreichend ist. Da die Sammelanforderung in Salesforce asynchron verarbeitet wird, müssen weder die Brightcove-Services noch RedLine nach dem Senden der Daten an Salesforce warten.

Wir haben einige Apex-Klassen zur Verarbeitung von Massenanforderungen geschrieben, einschließlich der Anpassung der Benutzer- und Kontenobjekte an die Salesforce-Objekte, und haben dann die Apex-Klassen in Salesforce bereitgestellt und Apex-Batch-Aufträge geplant, um diese Klassen auszuführen, sobald die Daten als Massenanforderung eintreffen. Auf diese Weise ist in den Brightcove-Services kein Code für das Salesforce-Datenmodell vorhanden, und nur der Salesforce-Apex-Code muss sich mit dem Salesforce-Datenmodell befassen. Salesforce bietet eine Reihe von Überwachungstools sowohl für Massenanforderungen als auch für Apex-Batch-Aufträge.

Wenn bei der Verarbeitung einer Massenanfrage Fehler auftreten, können wir diese leicht in der Salesforce-Web-UI sehen. Außerdem haben wir eine Apex-Klasse implementiert, die in regelmäßigen Abständen prüft, ob eine Massenanfrage in der erwarteten Häufigkeit eintrifft, und die eine Warnung ausgibt, wenn eine Anfrage eine Zeit lang nicht eingetroffen ist.

Im neuen Synchronisierungssystem müssen wir zur Freigabe einer Änderung neuer Felder des Benutzer- oder Kontoobjekts lediglich die neuen Felder im benutzerdefinierten Salesforce-Objekt hinzufügen und dann die neuen Felder in der JSON-Antwort der Brightcove-Service-API bereitstellen. Wir müssen RedLine nicht ändern oder neu starten, um das Objektformat zu ändern, da RedLine in der Lage ist, die neuen Felder in JSON als neue Spalten in CSV in Massenanforderungen zu konvertieren.

Es gab vier Änderungen an Kontenobjekten und eine Änderung an Benutzerobjekten, und wir mussten für diese Änderungen nicht eine Zeile RedLine-Code ändern. Bei dem alten, auf SOAP-API basierenden Synchronisierungssystem brauchten wir ein bis zwei Wochen, um ein neues Feld für Benutzer- oder Kontenobjekte zu synchronisieren.

Nachdem wir diese neue Synchronisierungsanwendung 8 Monate lang in der Produktion eingesetzt haben, konnten wir feststellen, dass sie einige umfangreiche Datenänderungen problemlos bewältigt. Kürzlich wurde während einer Bereitstellung eine Batch-Änderung von 900 Konten vorgenommen, und alle wurden in weniger als einer Minute mit Salesforce synchronisiert (die meiste Zeit wurde von Apex-Klassen verbraucht, die in Salesforce laufen). Mit dem alten Synchronisierungssystem dauerte die Synchronisierung der gleichen Anzahl von Objekten mehr als eine Stunde.

VERWENDUNG DER GOOGLE COMPUTE ENGINE FÜR DIE VIDEOTRANSKODIERUNG

Für diejenigen unter uns, die in der Welt des Cloud-Computing tätig sind, war das Aufregendste an der Google I/O 2012 nicht, dass Fallschirmspringer Glass trugen, und auch nicht, dass es ein neues Tablet gab. Die große Neuigkeit war, dass Google in den Bereich der Cloud-Infrastruktur-as-a-Service einsteigt, der derzeit von Amazon Web Services (AWS) dominiert wird. Konkret hat Google einen neuen Dienst namens Google Compute Engine eingeführt, der mit Amazon EC2 konkurrieren soll.

Das ist aufregend. Die Welt braucht einen weiteren robusten, leistungsfähigen und gut durchdachten Cloud-Service für virtuelle Maschinen. Mit Verlaub, Rackspace und andere haben hier lange Zeit nur einen einzigen Anbieter gehabt - EC2 ist mit Abstand der Marktführer. Google hat offensichtlich das Know-how und die Größe, um ein ernstzunehmender Konkurrent zu sein, wenn sie dabei bleiben.

Wie sieht es aus? Die ersten Berichte sind positiv. Google Compute Engine (GCE) ist gut konzipiert, gut ausgeführt und basiert auf einer Infrastruktur, die Google schon seit Jahren nutzt. Die Leistung ist gut, vor allem bei der Festplatten-E/A, den Boot-Zeiten und der Konsistenz, die in der Vergangenheit nicht gerade zu den Stärken von EC2 gehörten. Aber wie gut eignet sich GCE für die Cloud-Videotranscodierung? Wir haben einige vorläufige Ergebnisse, wobei wir zugeben, dass noch mehr Tests durchgeführt werden müssen. Im Folgenden finden Sie einige grundlegende Tests zur Videotranskodierung und Dateiübertragung mit der Zencoder-Software sowohl auf GCE als auch auf EC2.

Geschwindigkeit der Rohtranscodierung

Leistung hat für uns oberste Priorität, daher verwendet Zencoder die schnellsten Server, die wir finden können. Auf EC2 verwenden wir Cluster Compute-Instanzen, schnelle Dual-CPU-Maschinen in zwei Größen: 4XL und 8XL. Wir haben diese mit dem schnellsten GCE-Instanztyp verglichen, der derzeit ein Single-CPU-8-Core-Server ist.

ServerCPU
GCE 8-KernIntel Xeon (Sandy Bridge - wahrscheinlich E5-2670) - 8 Kerne @ 2.60GHz
EC2 cc1.4xgroßZwei Intel Xeon X5570 - 8 Kerne bei 2,93 GHz/Kern
EC2 cc2.8xlargeZwei Intel Xeon E5-2670 - 16 Kerne bei 2,60 GHz/Kern

Diese Tests wurden mit einem H.264-Quellvideo mit den Auflösungen 640×360 und 1280×720 durchgeführt und von Zencoder mit denselben Einstellungen für die Transkodierung in einem Durchgang (H.264 Baseline-Profil, AAC, Transkodierung in einem Durchgang mit konstanter Qualität usw.) kodiert.

Google Compute Engine vs. Amazon EC2

ServerAuflösungGleichzeitige KodierungZeit (Sekunden)Kosten pro Tausend
EC2 cc1.4xgroß640×360615.87$0.96
EC2 cc2.8xlarge640×36069.93$1.10
GCE 8-Kern640×360621.05$1.13
GCE 8-Kern640×36016.01$1.94
EC2 cc1.4xgroß640×36015.96$2.15
EC2 cc1.4xgroß1280×720648.58$2.92
EC2 cc2.8xlarge640×36014.99$3.33
EC2 cc2.8xlarge1280×720630.74$3.42
GCE 8-Kern1280×720668.15$3.66
EC2 cc1.4xgroß1280×720112.89$4.65
GCE 8-Kern1280×720116.01$5.16
EC2 cc2.8xlarge1280×720110.92$7.28

Mit den Standardeinstellungen von Zencoder sind beide EC2-Instanztypen schneller als GCE. Die Wirtschaftlichkeit liegt etwas näher beieinander, und es gibt keinen klaren Gewinner zwischen 4XL EC2-Instances und GCE. GCE ist also eine praktikable Option für die Transcodierung, bei der die Kosten eine höhere Priorität haben als die reine Geschwindigkeit, obwohl AWS-Kunden Reserved Instances und Spot Instances für weitere Kostensenkungen nutzen können. Wir haben festgestellt, dass die EC2-Instances mit 16 Kernen unter Last mit 6 gleichzeitigen Transcodierungen etwa doppelt so schnell waren wie die GCE-Instances mit 8 Kernen.

Angesichts der ähnlichen Taktraten, aber der halben Anzahl von Kernen, ist dies das, was man erwarten würde. Wenn Google jedoch ähnliche 16-Kern-Maschinen hinzufügt, könnten sie vergleichbare Transcodierungsgeschwindigkeiten haben.

Übertragungsgeschwindigkeiten

Bei der Transkodierung von Videos in der Cloud ist die Netzwerk-E/A fast so wichtig wie die CPU. Dies gilt insbesondere für Kunden, die mit hochbitratigen Inhalten arbeiten (Rundfunkanstalten, Studios und Kreative). Wie sind also die Übertragungsgeschwindigkeiten von GCE im Vergleich zu EC2? Um dies zu testen, haben wir vier Benchmark-Sets durchgeführt:

  • Amazon S3 zu Amazon EC2
  • Amazon S3 zu Google Compute Engine
  • Google Cloud-Speicher für Amazon EC2
  • Google Cloud Storage zu Google Compute Engine

Dazu haben wir dieselbe 1 GB große Videodatei getestet, die auf Google Cloud Storage (GCS) und auf Amazon S3 gespeichert war. Die Übertragung wurde über 10 HTTP-Verbindungen durchgeführt (Zencoder tut dies standardmäßig, um die Übertragungsgeschwindigkeiten zu optimieren, und es kann die Übertragung großer Dateien über HTTP erheblich beschleunigen).

GCE vs. EC2 Übertragungsgeschwindigkeiten

 Übertragungsgeschwindigkeit (Mbps)Server-Bandbreite
S3 bis GCE470.961 Gbit/s
S3 zu EC2 c1.xlarge644.291 Gbit/s
S3 zu EC2 cc2.8xlarge1458.3210 Gbit/s
GCS zu GCE202.601 Gbit/s
GCS zu EC2 c1.xlarge378.281 Gbit/s
GCS zu EC2 cc2.8xlarge641.3410 Gbit/s

Das ist interessant. Wir haben erwartet, dass die Übertragung von Amazon zu Amazon schnell ist, und das war sie auch. Aber wir haben auch erwartet, dass die Google-zu-Google-Übertragung schnell ist, was nicht der Fall war. Tatsächlich scheint es so zu sein, dass GCS langsamer ist als S3 und die GCE-Übertragung langsamer als EC2, so dass man, selbst wenn man Google für Berechnungen nutzt, besser dran ist, wenn man S3 für die Speicherung nutzt. Die Übertragung war 2,3 Mal schneller von S3 zu GCE als von GCS zu GCE.

Weitere Tests erforderlich

Betrachten Sie diese Ergebnisse als vorläufig. Es müssen weitere Tests durchgeführt werden, um mehr Variablen zu berücksichtigen.

  • Unterschiede von Instanz zu Instanz. Dies gilt insbesondere für die Dateiübertragung, die je nach Netzwerkbedingungen und Instanzvariabilität stark variieren kann.
  • Zusätzliche Anwendungen. Diese Benchmarks decken nur die Transkodierung ab, die ein CPU-gebundener Benchmark ist. Andere Anwendungen sind durch Festplatte, Speicher usw. begrenzt, und diese Tests sagen nichts anderes aus als Transcoding.
  • Skalierbarkeit. Skalierbarkeit ist für jeden, der die Cloud für die Videotranskodierung nutzt, extrem wichtig. Es sind weitere Tests erforderlich, um herauszufinden, wie GCE im Vergleich zu EC2 bei einer enormen Skalierung - Zehntausende von Servern (oder mehr) - abschneidet. An welchem Punkt stoßen die Benutzer auf Kapazitätsprobleme? Leistungsprobleme? Design-Einschränkungen? Instabilität?

Zukunft der Cloud-Infrastruktur

Auch wenn EC2 in diesen ersten Tests gewinnt, sind wir von Google Compute Engine begeistert. Um ein ernsthafter Konkurrent für Hochleistungs-Transcoding zu sein, muss Google größere Instanzen mit schnelleren CPUs hinzufügen. Das Hinzufügen neuer Instanztypen ist jedoch einfach. Nichts hindert Google daran, dies zu tun. Die Schwierigkeit besteht darin, eine robuste, leistungsfähige, mit allen Funktionen ausgestattete und skalierbare Cloud-Plattform zu entwickeln, und das scheint Google gelungen zu sein. Wenn Google diesem Produkt und den Entwicklern langfristig verpflichtet ist, könnte die Welt der Cloud-Virtualisierung gerade einen zweiten legitimen Akteur bekommen haben.

UNTERTITEL FÜR WEB, HANDY UND ANGESCHLOSSENES FERNSEHEN

Untertitel sind eine gute Sache für die Zugänglichkeit und Benutzerfreundlichkeit und ein weiterer Meilenstein auf dem Weg zur Reife von Internet-Videos. Leider handelt es sich bei Untertiteln nicht um eine einzelne Technologie oder "Funktion" von Videos, die man "einschalten" kann. Es gibt eine Reihe von Formaten, Standards und Ansätzen.

Untertitel sind ein ziemliches Durcheinander, genau wie der Rest des digitalen Videos, und eine besondere Herausforderung für Multiscreen-Publisher. Was müssen Sie also über Untertitel wissen, wenn Sie heute Videos für Web, Mobilgeräte und Connected TV veröffentlichen wollen?

In diesem Beitrag werden die Grundlagen erläutert: wie Untertitel funktionieren, welche Formate Sie kennen sollten und wie Sie Untertitel für jeden Bildschirm aktivieren können.

Wie Untertitel funktionieren

Als erstes muss man verstehen, wie Untertitel bereitgestellt, gespeichert und gelesen werden. Heute gibt es zwei Hauptansätze.

  • Eingebettet in ein Video. CEA-608, CEA-708, DVB-T, DVB-S, WST. Diese Untertitelformate werden direkt in eine Videodatei geschrieben, entweder als Datenspur oder eingebettet in den Videostrom selbst. Das Fernsehen verwendet diesen Ansatz, ebenso wie iOS.
  • Wird als separate Datei gespeichert. DFXP, SAMI, SMPTE-TT, TTML, EBU-TT (XML), WebVTT, SRT (Text), SCC, EBU-STL (binär). Bei diesen Formaten werden die Untertitelinformationen nicht in das Video selbst eingebettet, sondern neben dem Video an den Player übermittelt. Dieser Ansatz wird normalerweise bei der browserbasierten Videowiedergabe verwendet.

Unterschiede zwischen Untertiteln und Untertiteln

Was ist mit Untertiteln? Sind sie dasselbe wie geschlossene Untertitel? Hier gibt es drei wesentliche Unterschiede.

  • Ziele. Geschlossene Untertitel sind eine Zugänglichkeitsfunktion, die das Video für Hörgeschädigte zugänglich macht und Hinweise darauf enthalten kann, wer spricht oder welche Geräusche auftreten: z. B. "Es klopft an der Tür". Untertitel sind eine Internationalisierungsfunktion, die das Video auch für Menschen zugänglich macht, die die gesprochene Sprache nicht verstehen. Mit anderen Worten: Sie würden Untertitel verwenden, um ein Video auf stumm zu schalten, und Sie würden Untertitel verwenden, um ein Video in einer Sprache zu sehen, die Sie nicht verstehen. Hinweis: Diese Unterscheidung gilt in Nordamerika, aber in weiten Teilen der Welt wird nicht zwischen Untertiteln und Untertiteln unterschieden.

  • Speicherung. In der Vergangenheit wurden Untertitel in das Video eingebettet und Untertitel extern gespeichert (siehe CEA-608 unten). Dies ist konzeptionell sinnvoll, da Untertitel immer zusammen mit einem Video bereitgestellt werden sollten; eine 100%ige Zugänglichkeit für Hörgeschädigte ist gesetzlich vorgeschrieben. Untertitel hingegen werden nur manchmal benötigt; ein in Deutschland ausgestrahltes deutschsprachiges Video muss nicht mit deutschen Untertiteln versehen werden, ein in Frankreich ausgestrahltes Video hingegen schon.

  • Wiedergabe. Da die Untertitel zusammen mit dem Video übertragen und von einem Fernsehgerät oder einem anderen Verbrauchergerät gedolmetscht/angezeigt werden, können die Zuschauer sie jederzeit selbst über das Fernsehgerät ein- und ausschalten, haben aber nur selten die Möglichkeit, eine Sprache auszuwählen. Wenn in diesen Situationen Untertitel zu Übersetzungszwecken hinzugefügt werden, handelt es sich in der Regel um harte Untertitel (siehe unten), die nicht deaktiviert werden können. Bei der Wiedergabe von DVD/Blue-Ray/VOD-Videos steuert das Abspielgerät jedoch, ob und in welcher Sprache Untertitel angezeigt werden.

Formate und Normen

Es gibt Dutzende von Formaten und Standards für Untertitel und Closed Captioning. Hier ist eine Übersicht über die wichtigsten für Internetvideos.

  • CEA-608. CEA-608-Untertitel werden auch als Zeile 21 bezeichnet und sind der NTSC-Standard, der vom analogen Fernsehen in den Vereinigten Staaten und Kanada verwendet wird. Untertitel nach Zeile 21 werden von den Wiedergabegeräten direkt in einen versteckten Bereich des Videostroms kodiert. Wenn Sie jemals weiße Balken und Punkte am Anfang eines Programms gesehen haben, handelt es sich dabei um Untertitel der Zeile 21.
  • SCC. Diese Datei enthält Untertitel im Scenarist Closed Caption-Format. Sie enthält SMTPE-Timecodes mit den entsprechenden kodierten Untertiteldaten als Darstellung von CEA-608-Daten.
  • CEA-708. Dies ist der Standard für Untertitel für digitale ATSC-Fernsehübertragungen (DTV) in den Vereinigten Staaten und Kanada. Derzeit gibt es kein Standarddateiformat für die Speicherung von CEA-708-Untertiteln außerhalb eines Videostreams.
  • TTML. Timed Text Markup Language beschreibt die Synchronisation von Text und anderen Medien wie Audio oder Video. Weitere Informationen finden Sie in der W3C TTML-Empfehlung.
  • DFXP. Dies ist ein vom W3C definiertes Profil von TTML. DFXP-Dateien enthalten TTML, das definiert, wann und wie Beschriftungsdaten angezeigt werden sollen. DFXP steht für Distribution Format Exchange Profile. DFXP und TTML werden oft synonym verwendet.
  • SMPTE-TT. Die Society of Motion Picture and Television Engineers - Timed Text ist eine Erweiterung des DFXP-Profils, die drei Erweiterungen unterstützt, die in anderen Untertitelformaten und Informationselementen vorkommen, aber nicht in DFXP enthalten sind: #Daten, #Bild und #Information. SMPTE-TT ist auch das FCC-Safe-Harbor-Format. Wenn ein Produzent von Videoinhalten einem Verleiher Untertitel in diesem Format zur Verfügung stellt, hat er seine Verpflichtung zur Bereitstellung von Untertiteln in einem zugänglichen Format erfüllt. Es steht den Produzenten und Vertreibern von Videoinhalten jedoch frei, ein anderes Format zu vereinbaren.
  • SAMI. Synchronized Accessible Media Interchange basiert auf HTML und wurde von Microsoft für Produkte wie Microsoft Encarta Encyclopedia und Windows Media Player entwickelt. SAMI wird von einer Reihe von Desktop-Videoplayern unterstützt.
  • EBU-STL. Dies ist ein von der EBU-Norm verwendetes Binärformat, das in separaten STL-Dateien gespeichert wird.
  • EBU-TT. Dies ist ein neueres, von der EBU unterstütztes Format, das auf TTML basiert. EBU-TT ist eine strenge Untermenge von TTML, was bedeutet, dass EBU-TT-Dokumente gültige TTML-Dokumente sind, aber einige TTML-Dokumente sind keine gültigen EBU-TT-Dokumente, weil sie Funktionen enthalten, die von EBU-TT nicht unterstützt werden.
  • SRT. Dieses Format wurde von SubRip entwickelt, einem Windows-basierten Open-Source-Tool zum Extrahieren von Untertiteln aus einem Video. SRT wird von vielen Desktop-Videoplayern unterstützt.
  • WebVTT. Dabei handelt es sich um ein Textformat, das der SRT ähnlich ist. Die Web Hypertext Application Technology Working Group (WHATWG) hat WebVTT als Standard für die Untertitelung von HTML5-Videos vorgeschlagen.
  • Harte Untertitel. Harte Untertitel sind per Definition keine geschlossenen Untertitel. Harte Untertitel sind eingeblendeter Text, der in das Video selbst kodiert ist, so dass sie im Gegensatz zu geschlossenen Untertiteln oder weichen Untertiteln nicht ein- oder ausgeschaltet werden können. Wann immer es möglich ist, sind weiche Untertitel oder geschlossene Untertitel zu bevorzugen, aber harte Untertitel können nützlich sein, wenn sie für ein Gerät oder einen Player bestimmt sind, das/der keine geschlossenen Untertitel unterstützt.

Untertitelung für jedes Gerät

Welche Formate werden von welchen Geräten und Playern verwendet?

  • HTML5. Untertitel werden noch nicht von allen Browsern unterstützt, aber das wird sich mit der Zeit ändern. Es gibt zwei konkurrierende Standards: TTML, vorgeschlagen vom W3C, und WebVTT, vorgeschlagen von der WHATWG. Derzeit bietet Chrome eine begrenzte Unterstützung für WebVTT; Safari, Firefox und Opera arbeiten alle an der Unterstützung von WebVTT; und Internet Explorer 10 unterstützt sowohl WebVTT als auch TTML. Bis die Browser ein Format nativ unterstützen, kann ein HTML5-Player-Framework wie Video.js Untertitel über Javascript unterstützen, indem es eine externe Datei analysiert (Video.js unterstützt derzeit WebVTT-Untertitel).
  • iOS. Apple verfolgt einen anderen Ansatz und verwendet CEA-608 Untertitel mit einer modifizierten Version der CEA-708/ATSC-Legacy-Kodierung. Das bedeutet, dass Untertitel im Gegensatz zu HTML5 zum Zeitpunkt der Transcodierung hinzugefügt werden müssen. Brightcove Zencoder kann Untertitel zu HTTP-Live-Streaming-Videos für iOS hinzufügen.
  • Android. Die Unterstützung für Videoplayer ist immer noch fragmentiert und problematisch. Die Unterstützung von Untertiteln hängt natürlich von der Betriebssystemversion und dem verwendeten Player ab.
  • Andere mobile Geräte. Einige haben keine Unterstützung für Untertitel, und Untertitel können die einzige Option sein.
  • Roku. Unterstützt Untertitel durch externe SRT-Dateien.
  • Andere Connected-TV-Plattformen. Einige unterstützen die Untertitelung noch nicht. Aber das wird schon bald der Fall sein. Jeder Fernseher, jede Konsole, jede Kabelbox und jeder Blu-Ray-Player, der heute auf dem Markt ist, will Internetinhalte streamen, und in den nächsten anderthalb Jahren wird die Unterstützung von Untertiteln zur Pflicht werden. Sony, Samsung, Vizio, Google TV und andere werden die Unterstützung von Untertiteln zu einem Bestandteil ihrer Anwendungsentwicklungssysteme machen. Leider ist noch nicht klar, welche Formate dabei zum Einsatz kommen werden. Höchstwahrscheinlich werden die verschiedenen Plattformen noch viele Jahre lang eine Vielzahl von inkompatiblen Formaten unterstützen.

Anforderungen für die Untertitelung

Die Landschaft für Untertitel wird sich im Laufe der Zeit verändern und weiterentwickeln, aber ab 2012 sind hier die häufigsten Anforderungen für die Unterstützung von Untertiteln auf gängigen Geräten aufgeführt.

  • Ein Webplayer mit spielerseitigen Steuerelementen zum Aktivieren und Deaktivieren von Untertiteln.
  • Eine externe Datei mit Untertiteldaten, wahrscheinlich in einem Format wie WebVTT, TTML oder SRT. Es kann mehr als eine Datei erforderlich sein (z. B. SRT für Roku und WebVTT für HTML5).
  • Ein Transcoder, der eingebettete Untertitel für HTTP-Live-Streaming für die iPad/iPhone-Ausgabe unterstützt, wie Zencoder. Zencoder kann Untertitelinformationen in einer Vielzahl von Formaten akzeptieren, darunter auch TTML, sodass Verlage eine einzige TTML-Datei sowohl für die Webwiedergabe als auch als Eingabe für Zencoder für iOS-Videos verwenden können.

Danach wird es schwierig. Für andere Geräte sind möglicherweise andere Eingabeformate erforderlich, und für eine 100-prozentige Kompatibilität mit älteren Geräten sind wahrscheinlich feste Untertitel notwendig.

Brightcove Zencoder und Untertitel

Brightcove Zencoder unterstützt Closed Captioning für zwei Formate: Untertitel im CEA-608-Stil für iOS-Geräte, die HLS verwenden, und MP4-Dateien mit CEA-608-Untertitelspuren. Auf der Eingabeseite unterstützen wir SCC-, SAMI-, DFXP/TTML/SMPTE-TT- und CEA-608-Untertitelspuren in MP4-Dateien.

Bislang haben wir uns auf eingebettete Untertitel konzentriert, weil diese Formate den Videodateien zum Zeitpunkt der Transkodierung hinzugefügt werden. Wenn wir also keine Untertitel für iPad oder iPhone unterstützen würden, könnten unsere Kunden, die auf diesen Geräten veröffentlichen, keine Untertitel verwenden. In Zukunft werden wir die Palette der von uns akzeptierten Untertitelformate erweitern und möglicherweise Dienste wie die Formatkonvertierung für externe Untertiteldateien (z. B. TTML zu WebVTT) anbieten.

In der Zwischenzeit haben Brightcove-Kunden mit einer einzigen Untertiteldatei und dem richtigen HTML5-Player alles, was sie zum Erstellen von Videos mit Untertiteln für Web-, Mobil- und Connected TV-Geräte benötigen.

APP CLOUD: ERFAHRUNGSBERICHT EINES WEBENTWICKLERS

In meinen 13 Jahren als Webentwickler und -designer habe ich mich mühelos an neue Technologien angepasst - zunächst an Java, dann an PHP und später an Ruby. Lange Zeit war ich in den "Flash-Dampfer" eingetaucht und habe wichtige UI-Bibliotheken wie Prototype und jQuery erforscht, während ich mit den sich schnell entwickelnden Webstandards auf dem Laufenden blieb.

Wie viele Webentwickler habe ich jedoch den Sprung zu mobilen Anwendungen verpasst. Mir fehlte die Erfahrung mit Low-Level-Sprachen wie C++ oder Objective-C und ich hatte keine Zeit, sie zu lernen. Der Gedanke, "kleine" Anwendungen in Java zu entwickeln - einer Sprache, die ich als sperrig und umfangreich empfand - war ebenso wenig reizvoll.

Ich habe mehrere plattformübergreifende Entwicklungstools ausprobiert, aber sie blieben stets hinter den Erwartungen zurück:

  • App-"Fabriken", die RSS-Feeds in vorgefertigte Vorlagen verpacken, haben generische, uninspirierte Anwendungen geschaffen.
  • Frameworks, die JavaScript oder ActionScript in nativen Code umwandeln, erfordern komplexe Toolchains für die Erstellung und Kompilierung von Anwendungen.
  • Frameworks, die Webseiten in native Shells verpackten, boten nur wenig Infrastruktur für die Bereitstellung von datengesteuerten Anwendungen in Produktionsumgebungen.

Als ich App Cloud entdeckte, ein Framework zur Erstellung nativer mobiler Anwendungen mit HTML, CSS und JavaScript, war ich skeptisch. Würde es anders sein als die anderen? Würde es halten, was es verspricht? Nach der Entwicklung meiner ersten App kann ich getrost sagen: "Ja!" Hier ist der Grund dafür.

APP CLOUD SPRICHT DIE SPRACHE DER ENTWICKLER

App Cloud stützt sich auf die Kernkompetenzen von Webentwicklern: HTML zum Strukturieren von Inhalten, CSS zum Gestalten und JavaScript zum Bearbeiten der Inhalte. Sie brauchen keine neuen Sprachen zu lernen, um inhaltsorientierte, reichhaltige Anwendungen zu erstellen. Webtechnologien haben sich schon immer durch ihre Einfachheit ausgezeichnet. Vergleichen Sie die Komplexität der Erstellung einer Tabellenansicht in iOS mit der Einfachheit der Erstellung einer einfachen HTML-Liste - es ist kein Wettbewerb!

Das App Cloud SDK unterstützt außerdem fast jede JavaScript-Bibliothek, so dass ich Tricks anwenden kann, die ich mir in jahrelanger Webentwicklung angeeignet habe.

MIT APP CLOUD AUF DER ÜBERHOLSPUR

Ich wechsele beim Programmieren häufig zwischen BBEdit und vim, da dies meine bequemsten Werkzeuge sind. App Cloud ermöglicht es mir, diese vertrauten Editoren weiterhin zu verwenden. Da sie auf Standard-Webtechnologien basiert, kann ich meinen Code auch mit den Chrome Developer Tools debuggen und testen. Im Gegensatz zu schwerfälligen Systemen, die an XCode oder Eclipse gebunden sind, bietet App Cloud Flexibilität und Freiheit.

SCHNELLE ITERATION MIT DER WORKSHOP-APP

Die App Cloud Workshop-App für iOS und Android ermöglicht Echtzeittests während der Entwicklung. Nachdem ich Codeänderungen vorgenommen habe, klicke ich einfach auf "Aktualisieren", um die Aktualisierungen sofort zu sehen. Für Webentwickler, die an iterative Prozesse - kodieren, aktualisieren, wiederholen - gewöhnt sind, ist diese Funktion von unschätzbarem Wert.

Zwar können viele Tests auf Desktop-Browsern durchgeführt werden, aber nichts ist besser als zu sehen, wie eine App auf tatsächlichen Geräten funktioniert. Mit der Workshop-App ist dies einfach und nahtlos möglich.

NUTZUNG GERÄTESPEZIFISCHER FUNKTIONEN

App Cloud bietet eine unkomplizierte JavaScript-API für den Zugriff auf gerätespezifische Funktionen, wie die Kamera oder die Fotobibliothek. Zum Beispiel ist das Scannen eines QR-Codes so einfach wie:

bc.device.getQRCode(
function (data) { /* handle success */ },
function (error) { bc.device.alert("Oops! " + error.errorMessage); }
);

VEREINFACHTE ZUSAMMENSTELLUNG VON ANWENDUNGEN

Das Kompilieren von Apps mit anderen Tools, wie Android Developer Kits, fühlt sich oft an wie das Zusammenbauen von IKEA-Möbeln: mühsam und frustrierend. Mit App Cloud Studio werden Apps mit nur wenigen Klicks in der Cloud kompiliert. In wenigen Minuten ist die App für den Download und die Bereitstellung in verschiedenen App-Stores bereit - ohne spezielle Tools.

INHALTSOPTIMIERUNG: WENIGER IST MEHR

Bei inhaltsgesteuerten Anwendungen ist der Inhalt selbst oft der Engpass. App Cloud optimiert die Leistung durch:

  • Entfernen unnötiger Daten, Komprimieren von Feeds und Zwischenspeichern von Inhalten. Mein Blog-Feed schrumpfte zum Beispiel von 39 KB auf 4 KB - eine Reduzierung um 90 %.
  • Transkodierung von Bildern zur Verringerung der Dateigröße. Ein Bild wurde von 125 KB bei 425 Pixeln Breite auf 8 KB bei 200 Pixeln Breite verkleinert - eine Reduzierung um 94 %.

Durch diese Optimierungen werden die Ladezeiten erheblich verbessert, was für das Engagement der Nutzer entscheidend ist.

FLEXIBILITÄT ÜBER DEN EINSATZ HINAUS

Im Gegensatz zu anderen Tools kann ich mit App Cloud Studio Daten, Design und Einstellungen nach der Bereitstellung ändern - ohne die App neu kompilieren oder verteilen zu müssen. Dank dieser Flexibilität kann ich mehrere Apps aus einer einzigen Vorlage erstellen, indem ich Datenfeeds austausche und Einstellungen anpasse.

ZUSAMMENARBEIT LEICHT GEMACHT

App Cloud macht es einfach, Apps mit Kollegen zu teilen. Screenshots können direkt aus der Workshop-App geteilt werden, oder Vorlagen können über URLs oder QR-Codes verteilt werden, was eine effiziente Zusammenarbeit und Tests ermöglicht.

UMFASSENDES CLOUD-MANAGEMENT

App Cloud bietet alles, was ich zum Verwalten und Monetarisieren von Apps benötige, von der Bereitstellung nativer Werbung bis hin zu Echtzeit-Analysen. Ich kann Installationen, Nutzungszeiten und andere wichtige Metriken verfolgen.

Außerdem bietet App Cloud kostenlose Leistungsverbesserungen und Funktionsupdates. Künftige Verbesserungen, wie Push-Benachrichtigungen und In-App-Käufe, werden die Plattform noch leistungsfähiger machen.

App Cloud kombiniert die Einfachheit der Webentwicklung mit der Funktionalität nativer Anwendungen und ist damit ein unverzichtbares Tool für Entwickler, die effiziente, skalierbare und ansprechende mobile Anwendungen erstellen möchten.

KODIERUNGSEINSTELLUNGEN FÜR PERFEKTE IPAD/IPHONE-VIDEOS

Jeder ernstzunehmende Videoverlag unterstützt entweder bereits iPad und iPhone oder muss über eine zusätzliche Unterstützung nachdenken. Bei einigen großen Anbietern macht die iPad-Auslieferung ein Drittel oder mehr der gesamten Videoaufrufe aus.

Die Kodierung für iOS ist allerdings etwas knifflig. Diese Geräte haben mehrere Generationen an technischen Möglichkeiten durchlaufen, und die idealen Videoeinstellungen für das iPhone 4 sind nicht ideal für das iPhone 3GS oder das iPad.

Glücklicherweise können Sie mit nur wenigen Codierungsprofilen qualitativ hochwertige Videos auf jedes iOS-Gerät übertragen, vom ersten iPhone bis zum iPad 2, und sich sogar auf zukünftige Generationen mobiler Hardware vorbereiten.

Allgemeine Einstellungen

Wie bei den meisten Videos heutzutage sollten Sie für iOS h.264-Video und AAC-Audio verwenden.

On the audio side, consider using HE-AAC at <64kbps, for App Store compliance. HE-AAC sounds reasonably good at these bitrates, even for complex audio.

Auf der Videoseite sollten Sie mehrere Profile für jedes Gerät verwenden. Das iPhone 3GS und frühere Geräte unterstützen nur das h.264-Baseline-Profil, Stufe 3.0 (und einige unterstützen eine eingeschränktere Version als diese), während neuere Geräte die Profile Main und High unterstützen.

Für ein optimales Nutzererlebnis ist HTTP Live Streaming (HLS) ein Muss. Apple verlangt dies von jeder Video-App im App Store, die Inhalte abspielt, die länger als 10 Minuten sind, und es ist das einzige echte Streaming-Format, das von iOS unterstützt wird. HLS wird auch von Android (Version 3+), Roku und einer Reihe anderer Ziele übernommen.

Allgemeiner Ansatz

AuflösungProfilBitrate@ 16:9@ 4:3AudioKommentare
1024×768[email protected]2Mbps1024×5761024×76856kbps HE-AAC 
960×640[email protected]1.5Mbps960×540854×64056kbps HE-AAC 
640×432[email protected]1Mbps640×360576×43256kbps HE-AAC 
480×320[email protected]600kbps480×272426×32056kbps HE-AAC 
400×288[email protected]400kbps400×224384×28856kbps HE-AAC 
400×288[email protected]200kbps400×224384×28856kbps HE-AACFramerate dezimieren
N/A (nur Audio)    56kbps HE-AAC 

Warum diese Empfehlungen?

  • Dies sind nur Empfehlungen. Andere Auflösungen und Bitraten sind durchaus zulässig und können unter bestimmten Umständen sogar vorzuziehen sein. Zum Beispiel können extrem komplexe Inhalte höhere Bitraten rechtfertigen.
  • 720p ist das größte Video, das auf dem iPad 1 und dem iPhone 4 wiedergegeben werden kann, und das iPad 2/iPhone 4S kann alles bis zu 1080p wiedergeben. Da das native Display aber nur 1024 Pixel breit ist, ist eine Auflösung von 720p oder 1080p nicht so wichtig. Es sei denn, Sie möchten ein Video an anderer Stelle wiederverwenden - 720p ist eine großartige Auflösung für die Vollbild-Wiedergabe im Internet, und 1080p ist für angeschlossene Fernsehgeräte durchaus geeignet. Künftige iPads sollen Gerüchten zufolge die vierfache Auflösung des aktuellen iPads haben, also sollten Sie für die Zukunftssicherheit 720p in Betracht ziehen.
  • Das h.264-Profil ist wichtig. Das iPad 1 und das iPhone 4 unterstützen beide das Main-Profil. Das iPad 2/iPhone 4S unterstützen das Profil "High", das geringfügig besser ist als das Profil "Main", aber angesichts der Anzahl der iPad-1-Geräte in der Welt ist es wahrscheinlich besser, beim Profil "Main" zu bleiben. Für eine wirklich optimale Geräteausrichtung kodieren Sie sowohl mit Main als auch mit High.
  • Diese sechs Auflösungen und Bitraten bieten eine recht gute Abdeckung unterschiedlicher Bandbreiten. Sie können sicherlich noch mehr machen, also fügen Sie Auflösungen und Profile nach Belieben hinzu oder ziehen Sie sie ab.
  • Älteren iPhone/iPod Touch-Benutzern stehen drei Streams zur Verfügung, darunter ein Video in angemessener Qualität von 480×320 (der Bildschirmauflösung dieser Geräte). Nutzer des iPad und des iPhone 4 werden alle sechs Streams nutzen können.
  • Die Auflösungsskalierung auf dem iPad ist ziemlich gut, sodass Videos, die neu skaliert werden, im Allgemeinen gut aussehen.
  • Diese Einstellungen ermöglichen so weit wie möglich eine durch 16 teilbare Auflösung. Dies führt zu einer effizienteren Komprimierung. Die Effizienzgewinne sind gering, vor allem bei hohen Auflösungen, aber bei niedrigeren Auflösungen beginnen sie, einen Unterschied zu machen.
  • Achten Sie darauf, dass der Ton in jedem Video identisch ist. Wenn sich die Audiospezifikationen von einer Version zur anderen ändern, kann der Benutzer beim Umschalten zwischen den Streams während der Wiedergabe Knackser und Klicks hören.

Andere Einstellungen

  • Legen Sie die Geschwindigkeit entsprechend der gewünschten Durchlaufzeit fest. Für diese Empfehlungen verwenden wir die Geschwindigkeit 2, die die Komprimierung gegenüber der Grundeinstellung etwas verbessert, aber immer noch recht schnell ist.
  • Stellen Sie sicher, dass jedes Segment ungefähr die gleiche Größe hat, indem Sie eine Spitze verwenden bitrate\_cap von 150 % der Ziel-Bitrate, aber innerhalb einer langen buffer\_size (z. B. fünf Sekunden oder 5x die bitrate\_cap).
  • Brightcove wählt automatisch die richtige Keyframe-Platzierung, wenn Sie den Typ auf "segmentiert" einstellen. Wenn Sie in MP4 für die separate Segmentierung in HLS codieren, legen Sie forced\_keyframe\_rate auf "0,2" oder "0,1" (für Keyframe-Intervalle von fünf bzw. 10 Sekunden).
  • Wenn Sie etwas unvorhersehbare Bitraten akzeptieren können, die Qualität der Mischung erhöhen und die video\_bitrate zu max\_video\_bitrate um die Dateigröße zu optimieren. Der Encoder verwendet bei Bedarf die maximale Bitrate und verwendet eine niedrigere Bitrate, wenn er die gewünschte Qualität mit weniger Bits erreichen kann.
  • Setzen Sie die max\_frame\_rate auf 30 und die max\_audio\_sample\_rate bis 48000.
  • Die erste Generation der iOS-Geräte erlaubt nur eine h.264 reference\_frameAktivieren Sie diese Option für die Baseline-Streams, um maximale Kompatibilität zu gewährleisten.

Integration von Brightcove Video Cloud und Google Analytics

In diesem Artikel stellen wir Ihnen ein Google Analytics-Integrationsprogramm vor, mit dem Sie Videos mit Google Analytics messen können. Das Google Analytics-Integrationsprogramm kann verwendet werden, wenn Sie einen Video Cloud -Vertrag haben und bereits über Google Analytics verfügen.