Mrz 202014
 
Der Google  #Chromecast  Stick liegt bei mir dank US Import schon etwas länger auf der Halde, wurde aber dank Regionlockl-Abfuck bisher wenig genutzt. Durch den Release der Hardware in Deutschland ziehen nun dankenswerterweise so langsam auch die Content-Anbieter und Apps hierzulande nach, weswegen der Stick endlich etwas nützlicher wird.

Bisher konnte ich für mich 3 Apps identifizieren welche mit dem Stick aktuell nutzbar sind: Watchever, Mediathek Cast und Youtube. Gerne würde ich noch Pocket Casts nennen, den Android Podcatcher meiner Wahl, diese App versagt aber leider bei der Übertragung von größeren/längeren Podcasts. Hier scheint es, als müsse die komplette MP3 File von Android an den Stick gestreamt werden bevor eine Wiedergabe startet – bei 4-stündigen Podcasts warte ich dann mal gerne 2-5 Minuten, bis Audio auf dem TV ausgegeben wird.

Zum Thema Videostreaming via UPNP/DNLA im LAN sehe ich in meinem Environment derzeit schwarz. Kurz zum Setup: Meine Videofiles – digitale Privatkopien meiner DVD/BluRay Sammlung – liegen auf einem Synology NAS (DS111) mit ARM Prozessor. Die Dateien liegen in verschiedenen Formaten und Codecs vor, beispielsweise auch im beliebten .mkv Container. Der Chromecast Stick selbst unterstützt dagegen leider nur recht wenige Video/Audio Codecs nativ, was bedeutet dass ich entweder sämtliche Videodateien auf meinem NAS in ein kompatibles Format konvertieren müsste (Aufwand!) oder über eine Echtzeit-Transkodierung die Dateien während dem Abspielen in einem kompatiblen Format streame. Mögliche Ansätze bieten dafür die Apps Plex, Bubble UPNP und CWM AllCast.

Plex bietet die Echtzeit-Transkodierung leider nur auf NAS Systemen mit x86 Prozessoren an. Bubble UPNP hingegen bietet sogar ein Server Paket für das Synology NAS an; dieser Server dient dann rein zur Transkodierung während der Bubble UPNP Client vom Tablet die Inhalte an den Chromecast sendet – allerdings reicht dazu die CPU Power vom NAS nicht aus. Wie AllCast die Geschichte löst ist mir bisher nicht klar, wahrscheinlich mit lokaler Transkodierung direkt auf dem Android Gerät (??), was allerdings bei mir auch nicht funktioniert und in der Praxis auch ziemlich auf den Akku gehen dürfte.

Fürs lokale Streaming von Medieninhalten greife ich also weiterhin auf einen bewährten Streaming-Client (WD TV) mit nativen Support für viele Video/Audio Codecs zurück, das läuft dann doch noch erheblich einfacher als via Chromecast. Falls Netflix nach Deutschland kommt oder Watchever sein Videoangebot weiter ausbaut wird das Streamen lokaler Inhalte ggf. sowieso irgendwann obsolet. Die Musikindustrie hat es mit Spotify & Co. vorgemacht, bitte diesem Beispiel einfach folgen.

Embedded Link

Supported Media for Google Cast

  6 Antworten zu “Der Google  #Chromecast  Stick liegt bei mir dank US Import schon etwas länger…”

  1. Ich bin richtig begeistert ob des Potentials, das da noch drinsteckt. Sobald screen mirroring ruckelfrei läuft, bin ich glücklich.
    Aber der Mehrwert für dich – da du ja bereits wd tv nutzt – war doch ohnehin von vornherein überschaubar, oder?

  2. Genau, insofern bin ich gerade bei dem Preis auch zufrieden, alles was jetzt noch kommt ist Bonus. Neben dem lokalen Streaming fehlt mir so etwas wie TuneIn oder Songza derzeit noch, aber das ist meckern auf hohem Niveau und anders lösbar.

    Ich fürchte Screen Mirroring wird nicht zufriedenstellend hinzubekommen sein, damit würde ich an deiner Stelle nicht rechnen.

    Zum einen ist der Stick dafür nicht konzipiert/optimiert worden, er soll ja als eigenständiger Client fungieren, das Tablet/Phone währenddessen lediglich als Controller mit kleinen Statuspaketen behelligt werden ("ich spiele derzeit noch ab, bin bei Minute 5:03" ) um Bandbreite und Akku zu sparen.
    Bei einem Screen Mirroring muß das Bild des Tablets in Echtzeit abgebgriffen und codiert/komprimiert werden (CPU!), und via WLAN (Latenz!) zum Router und von dort aus via WLAN (Latenz x2) an den Stick geschickt werden. Hinzu kommt dass man vielleicht nicht nur Bild sondern auch Ton übertragen möchte, welcher zusätzlich noch weitere Bandbreite&CPU frisst.

    Und dann ist die Frage wo das gezeigte Material denn herkommt? Geht man mal nicht von einem Spiel (wegen der Latenz sowieso nicht zufriedenstellend machbar) oder von lokalen Tablet-Inhalten aus, sondern von einem Film aus dem Internet oder von einer Netzwerkfestplatte, dann benötigt das Tablet seine eigene WLAN Bandbreite eigentlich um den 1080p Film zu saugen – da ist nicht mehr viel Platz zum streamen von Audio/Video an einen Stick. Hab da leider bereits einige ernüchternde Miracast Experimente hinter mir welches ja eigentlich genau dafür entwickelt wurde, aber das performt einfach nicht zufriedenstellend.

    Das Chrome Plugin Google Cast macht ja bereits etwas in dieser Art, nämlich einen Tab mitsamt Inhalten übertragen. Da ist sogar Video & Ton dabei, und die Verzögerung bis das Material beim Chromecast landet liegt um die 5 Sekunden, sehr beachtlich. Allerdings läuft der Chrome Browser in diesem Fall auf einem richtigen Computer. Der hat CPU Power, eine performante LAN Anbindung und ist nicht angewiesen auf seinen Akku.

    Ich lasse mich gerne von brauchbarem Screensharing überraschen, würde aber derzeit nicht davon ausgehen dass dies mit der aktuellen Generation möglich ist.

  3. Verstehe, dann sollte ich mir vielleicht doch mal plex zu Gemüte führen. (Und evtl. einen Pi dafür abstellen…)

  4. wofür, screen mirroring? via plex? wäre mir neu….?

  5. Nee, für beliebige Mediendateien.

  6. das funzt mit nem rasperry pi nicht, wegen der transkodierungsproblematik. plex will fast jede Mediendatei transkodieren bevor während sie abgespielt wird, dafür brauchst du nen kraftvollen prozessor – nicht ARM. hatte ich im ursprungsposting bereits geschrieben, daher läuft es ja auch nicht bei mir auf dem NAS

 Antworten

Du kannst diese HTML Tags und Attribute benutzen: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

(Pflichtfeld)

(Pflichtfeld)