Windows Phone floppt als Multi Media Handy

  • Windows Live?
    Oder: Diese Datei kann auf Ihrem Handy nicht abgespielt werden.


    Nachdem nun einige Handymodelle mit Windows Phone 8 auf dem Markt sind und sich die erste Begeisterung gelegt hat, kristallisieren sich auch einige Nachteile im täglichen Betrieb heraus.
    Nahezu jeder Benutzer ist schon mehr oder weniger oft über die Meldung, „Diese Datei kann auf Ihrem Handy nicht abgespielt werden“, gestolpert. Hiervon betroffen sind verschiedene Audio- und Videoformate.
    Dieser Artikel soll Hintergrundwissen zu diesem Thema vermitteln.


    Bisher haben die Anbieter von Multimedia Inhalten wenig Rücksicht auf die Fähigkeit der einzelnen Plattformen nehmen müssen, die Inhalte auch darstellen zu können. Als Quasistandard war Adobe Flash etabliert. Durch Plugins oder andere Softwareerweiterungen wurden fast alle Multimediainhalte dargestellt.
    Selbst wenn ein Anbieter auf eine anderen Standard gesetzt hat, war es relativ einfach für den Nutzer, die passende Erweiterung zu finden.


    In der Welt von Windows Phone hat sich dieses nicht unbedingt zum Vorteil der Nutzer geändert.
    Microsoft setzt auf einen neuen Standart. Dieser Standard soll mit dem Wildwuchs der verschieden Multimedia Formate ein für alle Mal Schluss machen.


    Um den Hintergrund zu verstehen, ist hier ein kleiner Ausflug in die Technik der Internetbasierten Multimediawelt notwendig.


    Multimediainhalte werden auf der Anbieterseite durch einen Server bereitgestellt. Auf der Nutzer- oder auch Clientseite werden diese Inhalte durch einen Player aufbereitet und auf der jeweilige Hardware dargestellt.
    Nimmt man als Beispiel ein Video, welches korrekt auf der jeweilige Plattform dargestellt werden soll, muss für jeden Bildpunkt (Pixel) genau feststehen, welche Farbe und welche Helligkeit er annehmen soll. Um eine fließende Bewegung für das menschliche Auge entstehen zu lassen, muss dieser Vorgang bis zu 30 mal pro Sekunde und Pixel erfolgen. Hier beginnt das Dilemma. Eine nur grobe Betrachtung macht klar, das es sich hierbei um eine riesige Datenmenge handelt.
    Nimmt man als Beispiel die Auflösung eine Nokia Lumia 920 mit 1.280 × 768 Pixel, so müssten für die knapp eine Million Bildpunke 30 mal pro Sekunde der Farbwert (hier gibt es ca. 16 Millionen Farben) und die Helligkeit übertragen werden.
    Hieraus ergibt sich eine enorme Datenmenge. Da die Kapazitäten der Datenübertragung, sowohl im WLAN als auch, erst recht, im Mobilfunknetz, begrenzt sind, werden hier Verfahren zur Datenkompression angewendet.
    Microsoft setz hierbei hauptsächlich auf einen sehr modernen Standard: H264 im MP4-Container. Bei diesem Verfahren wird, grob gesagt, zunächst ein Referenzbild übertragen. Für die folgenden Bilder wird dann nur noch die jeweilige Änderung zum Referenzbild übertragen. Betrachtet man als Beispiel mal das Bild eines Nachrichtensprechers, der vor einem statischen Hintergrund die Meldungen verliest, wird klar, dass eine enorme Datenmenge bei der Datenübertragung gespart wird, da ja die Änderungen nur die Bewegungen des Sprechers betreffen.
    Technisch gesehen, wird das Video mit Hilfe des so genannten Codecs, hier h264 aufbereitet. Ist der entsprechende Player auf dem Endgerät in der Lage, diesen Code zu lesen, kann das Bildmaterial auch dargestellt werden. Um nun auch eine gewissen Komfort zu gewährleisten, wie z.B. das Anhalten und das Vor- bzw. Zurückspulen des Videos, wird die, in den h264-Codec umgerechnete Datei anschließend in einen sogenannten Container, hier MP4, verpackt.
    In diesem Container wird dem Video eine Tabelle vorangestellt, in der die Art und Lage der Einzelbilder beschrieben wird. Das erleichtert das Spulen, da der Player auf diese Tabelle zugreifen kann.
    Auf den ersten Blick ist das erst einmal Vorteilhaft.
    Das Problem liegt in den zwei Wörtern „anschließend“ und „vorangestellt“.
    Für das sogenannte „Video on demand“, kurz VOD, Verfahren, stellt diese Vorgehensweise kein Problem dar.
    Video on demand, heißt ja, Video bei Bedarf. Hier wird, bevor das Video von einem Server zur Verfügung gestellt wird, das gesamte Video in den h264-Codec umgerechnet, und anschließend in den MP4-Container verpackt. Bei dieser Art der Bereitstellung gibt es keine Probleme, da ja alle Informationen, wie Länge des Videos, Lage und Typ der einzelnen Bilder in der Datei usw. zum Zeitpunkt der Verpackung in das MP4-Contanerformat bekannt sind.
    Anders sieht es bei Livestreams aus. Hier ist das Video zum Zeitpunkt der Auslieferung noch nicht fertig.
    Für heutige Rechner ist es zwar kein Problem, das Video in Echtzeit in das h264-Format umzurechnen, aber das Voranstellen der Tabelle mit den Informationen zum Video ist zu diesem Zeitpunkt nicht möglich, da ja ein Livestream naturgemäß nicht in Gänze vorliegt. Auch die Lage der Bilder in der Datei steht noch nicht fest, da die Bilddaten der beschreibenden Tabelle folgen und zu diesem Zeitpunkt nicht einmal feststeht, wie lang die Tabelle sein wird.
    Daraus ist zu folgern, das die Methode, h264 im MP4-Container für Livestreaming nicht geeignet ist.
    Um nun dieses Manko zu umgehen, ist eine andere Methode, das so genannte „Pseudo-Livestreaming“ entwickelt worden.
    Beim Pseudo-Livestreaming werden die Vorteile die Komprimierung nach h264 genutzt und ein Quasi-Livestream erzeugt.
    Das funktioniert wie folgt.
    Die ersten z.B. fünf Sekunden des Livestreams werden zwischengespeichert und in eine Datei mit h264-Codierung und MP4-Containerformat umgerechnet. Dieses ist möglich, da es sich bei dieser Fünf-Sekunden-Datei ja um eine endliche Datei handelt. So ist es kein Problem, der Datei auch die benötigte Tabelle mit den nötigen Beschreibungen voranzustellen. Diese Datei wird nun vom Player des Clients abgespielt, während der Server die Nächsten fünf Sekunden berechnet und als Datei zur Verfügung stellt. Kennt der Player dieses HLS (HTTP Live Streaming) genannte Verfahren, ließt er nach Ablauf der ersten fünf Sekunden nahtlos die nächste Datei. Für den User ergibt sich daraus ein um kurze Zeit versetzter Quasi-Livestream.
    So weit, so gut. Leider handelt es sich bei diesem Verfahren um eine von Apple implementierte Technik.
    Diese Technik hat sich mittlerweile als Standard im Netz etabliert.
    Die Antwort, warum Microsoft darauf verzichtet, diesen Standart auch für Windows Phone 8 zu implementieren, bleibt der Spekulation der Nutzer überlassen. Anfragen bei Microsoft werden nicht, oder nur ausweichend beantwortet.
    Ob die Implementierung einfach vergessen wurde, oder ob der Nutzer hierbei mal wieder ob eines Patentstreites außen vor bleibt, muss also offen bleiben.


    Quelle: ostfriese2

  • Die letzte Antwort auf dieses Thema liegt mehr als 365 Tage zurück. Das Thema ist womöglich bereits veraltet. Bitte erstellen Sie ggf. ein neues Thema.

    • :)
    • :(
    • ;)
    • :P
    • ^^
    • :D
    • ;(
    • X(
    • :*
    • :|
    • 8o
    • =O
    • <X
    • ||
    • :/
    • :S
    • X/
    • 8)
    • ?(
    • :huh:
    • :rolleyes:
    • :love:
    • 8|
    • :cursing:
    • :thumbdown:
    • :thumbup:
    • :sleeping:
    • :whistling:
    • :evil:
    • :saint:
    • <3
    • :!:
    • :?:
    Maximale Anzahl an Dateianhängen: 10
    Maximale Dateigröße: 1 MB
    Erlaubte Dateiendungen: bmp, gif, jpeg, jpg, pdf, png, txt, zip

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!