Beiträge von M-Reimer

Das der Windows Media Player einer von denen ist, der alles runterladen will, hatte ich eigentlich als bestätigt angenommen.

Mehrere <object>-Tags sollten wir nicht brauchen. Würde mich zumindest wundern. Werfe mal die zwei ersten (ActiveX und NPAPI) komplett in eines. Also alle Attribute und <param>s von oben in das untere mit rein.

Nachtrag: Dein HTML ist an mehreren Stellen defekt.

Das offene "<object" darfst du nicht mit "/>" am Ende abschließen sondern mit ">". Mit dem "/" schließt du das Tag gleich ab. Das folgende "</object>" wäre also überflüssig, was ja eigentlich nicht das ist, was wir erreichen wollen.

Für das "class"-Attribut hast du mehrfach das abschließende Quote-Zeichen vergessen.

Das letzte "<param" ist jeweils garnicht abgeschlossen. Hier gehört das abschließende "/>" hin.

Versuche mal für Opera:

<object classid="clsid:9BE31822-FDAD-461B-AD51-BE1D1C159921"
        codebase="http://download.videolan.org/pub/videolan/vlc/last/win32/axvlc.cab"
        type="application/x-vlc-plugin"
        data="<stream URL>"
        width="720"
        height="576"
        id="video">
  <param name="autoplay" value="true"/>
  <param name="loop" value="false"/>
  <param name="toolbar" value="true"/>
  Hier sollte Text stehen können, der bei fehlendem Plugin sichtbar ist.
</object>

Den ActiveX-Krampf für IE habe ich mal direkt mit reingefummelt. Im Firefox müsste das so gehen. Im IE sollte es. Es kann aber sein, dass der IE das "data"-Tag nicht auswertet und dafür doch wieder den <param> benötigt. Wenn das so ist, dann einfach noch mit rein.

Siehe auch: http://www.w3schools.com/html5/tag_object.asp und http://www.w3schools.com/html5/tag_param.asp
Ich hoffe doch, dass Opera prinzipiell das "<object>-Tag" unterstützt. HTML5-Fähig soll der ja sein...

Was den gecko-mediaplayer angeht: Da sind wir fein raus. Der reagiert auf "application/x-vlc-plugin" Geht also ohne Änderung. Nur die Buttons drunter sollten dann weg, denn sie werden eher nicht für etwas ungleich VLC funktionieren.

Wenn ich mich recht erinnere gab es aber einen Trick um doch die Höhe auf 100% zu bekommen. Ich werde mich da mal schlaumachen.

Was dein HTML angeht: Ich würde oben (bei dem Code-Block, den du für "ActiveX" vorgesehen hast) wieder den "type" für VLC mit reinnehmen.

Das <embed> in deinem <object> dann ganz raus und stattdessen dort ein weiteres <object> hin, welches hart auf den "gecko-mediaplayer" referenziert (Linux-Plugin, welches auch teilweise gecachtes spielen kann). Diese Verschachtelung kann man beliebig tief treiben. Immer wenn ein <object> nicht geladen werden konnte, wird vom HTML-Parser der darin enthaltene HTML-Code ausgewertet. Wir können so relativ einfach eine "Whitelist" von Plugins aufstellen, die mit den Streams via HTTP auch klarkommen. Wenn dann die ganze Liste abgewirtschaftet wurde, dann kann als letztes noch der Info-Text (kein Plugin gefunden) und der Link eingebaut werden.

Das "<embed>"-Tag ist spätestens seit HTML5 komplett obsolete und sollte demnach auch nicht mehr genutzt werden.

Soll heißen: Mehr als eine Favoritenliste? Also weiterhin nach Sparten sortierbar?

Wenn wir jetzt in der Tat bei "einfach Browserfenster nur mit Plugin" angekommen sind, dann setze mal "width" auf "100%" und "height" auch auf "100%" beim Plugin. Sollte sich dann analog zum Browserfenster in der Größe ändern.

Stimmt. Mir persönlich ist beides recht und was bereits da ist, funktioniert ja.

Allerdings wäre ich dankbar, wenn du den "type" mal auf "video/mpeg" setzen könntest. Wie es geht, weißt du ja bereits Wenn der VLC dann immer noch aufgeht, dann sollte, wenn man schon einen Patch für die Übernahme in Live vorbereitet, das gleich mit rein, damit auch andere Plugins nutzbar werden. Das es unter Windows zu VLC keine Alternative gibt bedeutet ja nicht, dass man unter Linux auch nichts anderes verwenden darf.

BTW: Die neuen Controls vom VLC-Plugin gefallen mir. Scheint mir so langsam durchaus brauchbar zu sein.

Zitat von Keine_Ahnung

Kommt ja erstmal auf den externen Player an wie der sich verhält. Und mann kann ja auch einfach alternativen Code reinbringen den man per makefile wählen kann. Dann wäre jeder glücklich.

Entweder das eine oder das andere. Sonst müssen zwei Lösungen weitergepflegt werden und eine davon wird zwangsläufig schlechter gepflegt sein.

Zitat

Ich habe jetzt das aktuelle VLC Plugin, die Controls und die URL (braucht man ja irgendwie nicht wirklich) gelöscht und die Fensterhöhe auf 576 gesetzt. Und damit bin ich jetzt glücklich. Ist genauso wie es eigentlich sein sollte.

Bleibt die Frage, ob dieses abgespeckte Browserfenster im Gegensatz zu einem externen Player einen Vorteil bietet.

Zitat

BTW: Was mich in diesem Zusammenhang auch interessiert. Ich habe den Apache (läuft auf Port 80) so eingestellt das live unter http://<vdr-ip>/live erreichbar ist und live an localhost gebunden. Finde ich irgendwie schöner.

Sonderkonfiguration. Meiner Meinung nach sollte man Live nicht mit sowas aufblasen. Wer Sonderkonfigurationen fahren will, der muss halt patchen

Ist mir aufgefallen. Hast aber Recht. Prinzipiell könnte Klaus bereits jetzt Stellung zu dieser ersten Änderung nehmen.

Eigentlich ist die Diskussion hier nur eine Folge eines von vielen Problemen, die dadurch auftreten, dass der VDR die Trenner zwar unterstützt, aber über keine eingebaute Funktion ändern kann.

Neben der Änderung über SVDRP wäre nämlich meiner Meinung nach auch Ändern via OSD ein wichtiger Punkt. Die Dinger sollten dort auswählbar und markierbar sein, dass man sie wie Kanäle schieben kann.

Wenn der Kanal am Ende der >100 Einträge umfassenden Liste landet, dann ist es nicht ganz so einfach, den mit dem Trick über Kanäle hin und herschieben irgendwie an den Anfang zu bekommen.

IMHO wäre es nicht verkehrt wenn du dich auch mal mit Klaus absprichst, wie er sich sowas vorstellen kann. Nur ein Patch, der zeitnah in den VDR übernommen wird, ist ein guter Patch.

Richtig hilfreich ist dein Patch aber doch nicht, oder? Es ist doch dann unmöglich den erzeugten Trenner zu verschieben...

Zitat von Keine_Ahnung

Nu können die Buttons da weg und aus dem Link kann nen Download Button werden.

Stimmt. Das ist eine Lösung. Um "Plugin-Unabhängiger" zu werden, dann aber dennoch "video/mpeg" als Content-Type, denn unter Linux habe ich noch ein paar mehr Plugins, die hier interessant wären.

Im Gegensatz zum ".m3u" ist das ziemlich einfach umsetzbar. Wenn mir keiner zuvor kommt, würde ich mich daran versuchen.

Bleibt nur die Frage, ob es lohnt die Einbettung zu fixen oder ob man die Zeit lieber direkt in einen Umbau nach .m3u investieren sollte. Machbar ist das durchaus. Halt etwas mehr Arbeit. Ist die Einbettung in ein Browserfenster aus der Sicht der hier mitlesenden in irgendeiner Form "eleganter" als das externe Öffnen eines Players?

Viel Unterschied zum externen Player gibt es, nach dem Killen der Controls unter dem Plugin, nicht mehr...

Zitat von Keine_Ahnung

BTW: Ich finde den VDR eh generell viel zu offen, jeder der ins LAN kommt kann einfach so den VDR plattmachen. Rein praktisch kein Problem (wird niemand mutwillig tun), aber Linux kann das eigentlich besser.

Dann hast du was falsch konfiguriert. Mein VDR ist garnicht "offen". Man kann sehr gezielt steuern wer via SVDRP zugreifen darf (bei mir aktuell ausschließlich "localhost") und live hat einen Passwortschutz und kann auch SSL.

Das Streamen von Aufnahmen ist ein Live-Feature. Das geht nicht pur mit Streamdev.

An der Stelle ist in der Tat die Frage, warum überhaupt einbetten?

So grob nachgedacht gefällt mir die Idee mit der ".m3u" irgendwie auch besser.

Zumal man einen extern laufenden Player mit Stream auch besser zwischen anderen Programmen mitlaufen lassen kann. Der Browser hat halt noch etwas "drumherum", das beim "Stream nebenbei laufen lassen" dann irgendwie immer im Weg wäre.

Nachtrag: Den Gedanken könnte man sogar noch beliebig weiterspinnen. Wenn ich z.B. in Live-TV schalten will, dann könnte die ausgelieferte M3U neben dem angeklickten Sender an erster Stelle darauf folgend auch die ersten X Sender der channels.conf enthalten. So könnte man direkt im Player zappen.

Zitat von Keine_Ahnung

Der funktioniert wenigsten Plattformübergreifend.

Wäre dennoch schade, wenn Live diesen proprietären Mist voraussetzen würde.

Zitat

Vorschläge für Alternativen werden gerne ausprobiert

Da kenne ich einige. Aber nur für Linux

Bloß kein Flash!!!

Wenn der Player vor dem kompletten Download kein Video spielt, dann ist der Player Schrott. Anderen nehmen. Worst-Case halt doch wieder VLC.

Nachtrag: Das Verhalten von Quicktime ist im Internet wohl mindestens einmal schon diskutiert worden. Zum Windows Media Player habe ich nichts gefunden.

Folglich gibt es unter Windows nur den VLC um Streams zu spielen. Das Verhalten von Live ist hier also korrekt.

Bleibt das Problem, dass ich unter Linux eine breitere Auswahl an funktionierenden Plugins habe. Hier muss ich noch eine Lösung finden, die dann parallel zum vorhandenen Verhalten läuft.

Was passiert denn, wenn du ein Video vom Web als Quelle angibst. Aber ein großes, das nicht sofort da ist. Muss das auch komplett da sein, bevor du "Play" drücken darfst?

So langsam kommt mir das so vor, als wäre dieser "Media Player" defekt.

Kannst du denn nicht während das Video noch lädt auf "Play" klicken?

Wenn das Plugin anläuft, dann hat der Rest mit der Umsetzung im HTML erstmal nichtsmehr zu tun.

Wenn man VLC installiert hat, und alle anderen Plugins, die sich für video/mpeg interessieren könnten, deaktiviert, dann hat man das alte Verhalten wieder.

Kann schon sein, dass es einen HTTP-Header für "unendlich großer Stream" gibt. Zumindest darf kein "Length" gesendet werden.

Bevor man den VDR transcodieren lässt, finde ich ein Player-Plugin auf Clientseite dann aber doch eleganter! Sofern man für selbiges eben die Wahl hat.

HTML5 halte ich erstmal für nicht realistisch. Es sei denn, irgendwann greifen die Browser tatsächlich auf System-Codecs zu und man kann faktisch alles via <video> einbetten. Bis das irgendwann mal der Fall ist, sollte man nutzen, was es schon gibt. Also Browser-Plugin um das VDR-Nativformat abspielen zu können.