7 Kommentare

1. Schepp am 9. Juli 2010 #

   Ich füge das jMediaelement zu Deiner Liste hinzu.

   Und da landen wir auch schon bei einem weiteren, sehr wichtigen Aspekt: Kann man den Player über eine JS-API genauso vollständig steuern und abfragen, wie das beim echte HTML5-Video der Fall ist?

2. Simon am 9. Juli 2010 #

   Mir gefällt »FlareVideo« mit Abstand am Besten.

3. alexander farkas am 11. Juli 2010 #

   Eine gut gemachte Gegenüberstellung unter gleichen und vielleicht sogar heftigen Bedingungen, wäre tatsächlich sehr wünschenswert. Übrigens nicht nur für die Anwender, sondern auch für die Entwickler (Ich bin für jme verantwortlich). Allerdings auch extrem aufwendig.

   Hoffe allerdings, daß dein Urteil etwas sachkundiger ausfällt als von Simon.

   Es gibt in dem Zusammenhang übrigens auch einen anderen Sport, der extrem um sich gegriffen hat und um sich greift. In etlichen Blogs werden ohne erkennenswerten Mehrwert und ohne, daß der Blogger genauer hingesehen hat, ein paar »HTML5« Video Scripte aufgelistet. (Ich zähle deinen nicht dazu, du hast großes vor.)

   Ich würde an deiner Stelle sublime, video.js und html5media aus der Liste streichen, da sie alle zu einer anderen Kategorie gehören. html5media ist überhaupt nicht stylbar. Dafür aber leichtgewichtig. Und bei sublime und video.js ist das Fallback nicht stylbar.

   jMediaelement spielt da übrigens in jeder Kategorie mit, da es modular von embed-only, embed+API zu embed+API+UI-Komponeten (letzteres über jQuery UI) aufgebaut ist.

   Ach ja, du hast bei Kaltura das l vergessen.

4. FlashJunior am 12. Juli 2010 #

   Hier noch eine kleine collection von html5 videoplayern

5. Sascha Kluger am 12. Juli 2010 #

   JS Video Player sind wie JS Scripte zum Einbinden von Bildern in Webseiten – zunächst einmal unnötig. Die meisten Player Scripte ziehen ihren vermeintlichen Mehrwert aus dem umstylen der Kontrollelemente und bestenfalls noch dem Flash Fallback. Ersteres ist nett aber eigentlich keine Hexerei, Letzteres ist mit einem geschickt gehackten Markup mit Browsermitteln zu bewerkstelligen (vergl. http://camendesign.com/code/video_for_everybody, btw: darum ist z.B. das VIDEO.JS Script gerade mal wenige hundert Zeilen lang). Schlussendlich m.E. allesamt Lösungen für den Web-Visitenkarten-Besitzer oder diejenigen, die nicht wissen, dass es ein video-Tag mit JS API gibt. Der Punkt ist nur der: Für diese Zielgruppe sind – Stand heute – Flash basierte Lösungen (leider noch) viel besser geeignet.

   Ich schreibe PROJEKKTOR den ich für ein komplexeres Projekt benötige. Die meiste Vorarbeit bestand darin aktuelle X-Browser Probleme zu lösen. Hinsichtlich der wahrscheinlichen Weiterentwicklung gängiger Browser eine Arbeit, die in grossen Teilen bald obsolet sein dürfte – was im Übrigen ziemlich frustrierend ist. Weitere Funktionen wie die Playlisten blähen im Vergleich bswp. zu Alexanders Lösung das Script relativ auf und machen es für 3. schwer zugänglich. Alles Weitere wird so speziell werden, dass der Mehrwert sich nicht mehr aus dem ollen Player-Kern, sondern dem tatsächlichen Endprodukt ableitet. Dafür, ich wiederhole mich, ist der Umgang mit den nativen Videoplayern viel zu unproblematisch – auch für Laien.

   Mein Fazit: »Projektbezug« das Stichwort und der Einsatz der oben genannten Scripte nur eingeschränkt sinnvoll. Eines sind sie aber alle: Prima Referenzen – wenn man mal nicht weiter weiss.

6. alexander farkas am 13. Juli 2010 #

   @Sascha

   Du hast in vielen Punkten recht, aber in Details muß ich dir da ziemlich widersprechen:

   >>Ersteres ist nett aber eigentlich keine Hexerei, Letzteres ist mit einem geschickt gehackten Markup mit Browsermitteln zu bewerkstelligen

   Zu 1.:
   Das Verbinden des Kontrol-Markups mit der API nimmt in meinem Script beispielsweise 300-400 Zeilen ein und wenn man es vernünftig macht, wird man das nicht wesentlich kürzer schreiben können. Im Vergleich zum übrigen Script natürlich ein Witz, aber allein die paar Zeilen, will niemand immer wieder schreiben. Etwas zu haben was umfangreich getestet ist und funktioniert ist da schon eine Hilfe.

   Zu 2.: Falsch, der Fallback-Mechanismus von Video/Audio führt eben dazu, daß man bei reinen Markup-Lösungen immer »alle« HTML5-Video-/Audio-Codecs vorhalten muß, damit es funktioniert. Kaum ein Webentwickler kann von seinen Kunden erwarten, daß er alle Videos mehrfach codiert. Außerdem ist der Einbindecode dadurch alles andere als elegant und intuitiv.

   >>Schlussendlich m.E. allesamt Lösungen für den Web-Visitenkarten-Besitzer…

   Ich kann und will Dir hier für die anderen Scripte als jme nicht widersprechen, aber jme funktioniert ganz anders. Letztendlich ist dies auch meine Hauptkritik an den derzeitigen »Player-Scripten«. Mit HTML vs. Flash werden ja vom gemeinen Frontendentwickler bestimmte tatsächliche und vermeintliche Vorteile verbunden. Bessere Stylebarkeit, Zugänglichkeit etc. gehören dazu. Brad Neuberg hat das in der Introduction to HTML5 mit den Worten video/audio is a »intrinsic part of the web« zusammengefaßt. Ich sehe nun bei den meisten Scripten genau hier das Problem: Sie zerstören genau dieses »intrinsic part of the web«. Kaum ein Script verwendet semantisches Markup für die vordefinierten HTML-Kontrollelement -> Zugänglichkeit ist insbesondere, wenn das Flash-Fallback kommt gleich null.

   Am Ende können die meisten das machen, was wir von Flash her kennen, aber eben nur schlechter. Die HTML-Vorteile sind dahin.

   Die Stylebarkeit und die Anpassbarkeit des UI-Verhalten werden dadurch eingeschränkt, daß die Player-Scripte einen monolithischen Block an Controls rendern und zusätzlich noch UI-Behavior (Controlbar wird bei Useridle ausgeblendet) integrieren. Bei jme ist das Vorrendern von typischen Controls und/oder das Hinzufügen von typischem UI-Verhalten für Controls alles Extra, nicht Kernbestandteil und mit Absicht in uitils-Scripte ausgelagert.

   Ein kleines Beispiel: Du bietest ein Logo-Plugin an, damit es einfach ist, ein Logo-Overlay zu machen, welches auch im Fullwindow-/Fullviewport-Modus noch an der richtigen Stelle sitzt.

   Aber im Prinzip hat uns HTML5 »versprochen«, daß Videos so einfach einzubinden sind wie Bilder und jeder Frontendentwickler weiß wie er beispeilsweise eine Lupe über ein Bild legt. jme wird so ein Plugin daher nie anbieten und muß dies auch nicht, man kann ein Bild oder irgendein HTML-Element einfach über das video-Display legen. Dadurch, daß nicht nur das video, sondern auch das vom Entwickler bestimmte gemeinsame wrapper-Element im Fullviewport-Modus groß gezogen wird, funktioniert dieses overlay-Element automatisch auch mit Fullviewport.

   Das heißt bei jme gab es für mich immer ein oberstes Prinzip/Konzept, daß ich erreichen wollte: Eine bessere Integrierung von Multimedia in die HTML-/DOM-Welt, dies hat automatisch dazu geführt, daß ich eine DOM- statt einer einfach JS-/Plugin-API nutze und ebenso eine relativ interessante Markup-API, welche ich – gern zur Erläuterung dieser Technik – als »mögliches« HTML6-Controls-Feature bezeichne.

   Im Ergebnis: jme ist nicht für Leute, die ein fertiges schön gestyltes Theme haben wollen, sondern für Frontendentwickler, welche maximale Anpassbarkeit von UI und Features wünschen und das auf eine Weise, die ihrem normalen Workflow entspricht (HTML & CSS). Kurz es gibt einen Grund, warum jme als einziges Script eine umfangreiche Dokumentation besitzt und mit dem Untertitel »not only just another HTML5 audio/video player« versehen wurde.

7. Igor am 29. Juli 2010 #

   Hi Gerrit,

   auch Chip-Online hat sich mit dem Thema HTML5 <video> mal ein wenig näher befasst und gleich noch eine Competition gestartet die eine sehr interessante Umsetzung zu Tage gefördert hat, die ich bisher noch nicht gefunden habe: http://bit.ly/aDgsHQ oder http://bit.ly/dyJftG bzw. die Ergebnisse unter http://bit.ly/d7oFii

   Interessant dabei ist vor allem die Umsetzung in Richtung Tastatur-Interaktion und Untertitel für HTML5-Videos. Vielleicht passt das auch zu Deiner Auflistung bzw. in Deinen Vergleich.

   Grüße