web (HbbTV, VDR*ELEC), Milestone 1 erreicht

    Ich hatte das gestern ohne qoi probiert glaub ich und da passt es. Im übrigen sollten alle Ausgabedevices dasselbe Format erwarten, also ARGB/BGRA. Also 32bit tColor Werte http://git.tvdr.de/?p=vdr.git;…8c464b77957b3;hb=HEAD#l58 wenn ich es richtig verstanden habe.

    Mit shared Memory (ohne qoi) kam ich ohne Formatumwandlung aus. Okay. Dann werde ich das so erstmal so ändern und falls es Probleme gibt, dann muss ich da nochmal ran.

    Es gibt einfach zuviele Pixelformate auch mit R,G,B,A: RGBA, RBGA, ARGB, ABGR, ..... :D

    Zitat von Zabrimus

    Aktuell macht der Transcoder sowieso nur ein copy von audio/video, weil mir noch nichts anderes untergekommen ist. Ich denke, das sollte im VDR*ELEC funktionieren, sofern die ffmpeg-tools mit installiert werden.

    Sollte aber echtes Transcoding stattfinden müssen, bin ich mir da gar nicht mehr sicher. Ich meine irgendwo gelesen zu haben, daß Hardware-Transcoding funktioniert, aber nur wenn nicht parallel ein Decoder (Ausgabedevice) läuft. Vielleicht liege ich da auch falsch oder es betraf nur ältere Hardware. Beim Software-Encoding bin ich mir absolut unsicher, ob das schnell genug ist.

    Wie zillerbaer schon festgestellt hat, würde sich für die Zukunft anbieten, fürs Decodieren auf z.B. softhddevice-drm oder mpv oder ein neues simples Player Plugin zurückzugreifen. Da bei softhddevice-drm(-gles) sowieso ffmpeg mit an Bord ist, könnte das der mitgelieferte Mediaplayer sicher erledigen, dann müsstest du nur die Stream-URL liefern. Das hätte den Vorteil, dass alles auf einem Rechner sein kann. Ob der transcoder und das ffmpeg vom Ausgabeplugin parallel laufen können, kann ich ausprobieren. In jedem Fall würde ich versuchen, den Transcoder erstmal so wie er ist auf den Client zu bringen.

    Zitat von Zabrimus

    Ich wollte gerade fragen, was denn im Stacktrace steht. Aber das wird ja nix, weil ich eine eigen-compilierte Version von cef habe und da die sanitizer eingeschaltet habe. gdb und valgrind funktionieren leider mit cef nicht.

    Wenn du das irgendwie reproduzieren kannst.... :)


    Zitat von Zabrimus

    Überhaupt nicht. Den Level habe ich mehr oder minder zufällig gewählt. Welcher Wert soll es denn werden?

    Wenn das OSD vom VDR gelöscht oder inaktiv gesetzt wird, kannst du nach meinem Verständnis auch 0 wählen. Alles ausser 10 ist besser.

    Klaus Schmidinger's git trees - vdr.git/blob - osd.h

    Zitat von Zabrimus

    Die Patches muss ich mir mal in Ruhe anschauen. Da ist ja eine Menge Holz.

    Alles gut. Mir gehts eigentlich nur um die Fixes, die m.E. Sinn machen.


    Zitat von Zabrimus

    Ich wollte gerade fragen, was denn im Stacktrace steht. Aber das wird ja nix, weil ich eine eigen-compilierte Version von cef habe und da die sanitizer eingeschaltet habe. gdb und valgrind funktionieren leider mit cef nicht.

    Wenn du das irgendwie reproduzieren kannst.... :)

    Backtrace bekomme ich keinen und gdb hängt sich auf. Aber es sind eh keine Symbole vorhanden. Es trat auf, als ich ein Video abspielen wollte. Mal sehen, ob ichs reproduzieren kann.

    Einmal editiert, zuletzt von rell ()

    Zitat von Zabrimus

    Mit shared Memory (ohne qoi) kam ich ohne Formatumwandlung aus. Okay. Dann werde ich das so erstmal so ändern und falls es Probleme gibt, dann muss ich da nochmal ran.

    Es gibt einfach zuviele Pixelformate auch mit R,G,B,A: RGBA, RBGA, ARGB, ABGR, ..... :D

    Ich sehe das Problem noch nicht ;)


    Liefert denn der Browser immer dasselbe Format bzw. kann er immer dasselbe liefern? Falls nicht, kann er dem vdr-plugin ja mit einem flag mitgeben, was er liefert und das wandelt es in das Format für ein Image() (das ja immer gleich ist - also ARGB) um.

    Theoretisch kann die OpenGL Ausgabe diese Umwandlung auch mit der GPU machen, aber dann müsste die VDR-API nochmal erweitert werden, damit man den Format-Identifier mitgeben kann.

    Ich bin mir außerdem nicht sicher, ob man sich über die Endianess überhaupt Gedanken machen muss.

    Zitat von rell

    Wie zillerbaer schon festgestellt hat, würde sich für die Zukunft anbieten, fürs Decodieren auf z.B. softhddevice-drm oder mpv oder ein neues simples Player Plugin zurückzugreifen. Da bei softhddevice-drm(-gles) sowieso ffmpeg mit an Bord ist, könnte das der mitgelieferte Mediaplayer sicher erledigen, dann müsstest du nur die Stream-URL liefern.

    Die URL zu liefern ist das geringste Problem. Man kann ja parallel beide Optionen anbieten. Ich persönlich würde nur ungern auf das OSD beim Player verzichten, aber andere sehen das vielleicht anders und wollen sich auf das Video konzentrieren.

    Die Video-Kommandos im Browser abfangen und das Plugin nicht belästigen oder das video-Tag komplett rausnehmen ist kein großer Akt. Der Rückweg fehlt dann zwar noch: Video-Ende -> Browser OSD. Aber auch das lässt sich lösen.

    Wie wäre es denn mit einer Service-Schnittstelle in den Plugins? Mein Plugin empfängt die URL, startet aber nicht den VideoPlayer, sondern gibt die URL einfach nur weiter und die Verantwortung liegt dann woanders. Umgekehrt genauso. Ist alles beendet, Call meines Plugins und das OSD wird wieder dargestellt. Oder so oder anders.

    Kein OSD ist keine Option. Im Prinzip müsste es so laufen:

    - Der Browser schickt die Seiten des OSD und die Adresse des Videos inkl. Größe und Koordinaten, wo es hin soll an vdr-plugin-web

    - vdr-plugin-web zeichnet das OSD wie ein Skin-Plugin und leitet die URL an den Player (oder den Player im Ausgabedevice) weiter

    - der rendert dann das Video und vdr-plugin-web liefert das OSD und die Steuerung dazu

    Zitat von Zabrimus

    Wie wäre es denn mit einer Service-Schnittstelle in den Plugins? Mein Plugin empfängt die URL, startet aber nicht den VideoPlayer, sondern gibt die URL einfach nur weiter und die Verantwortung liegt dann woanders. Umgekehrt genauso. Ist alles beendet, Call meines Plugins und das OSD wird wieder dargestellt. Oder so oder anders.

    Wie auch immer man es macht, es lohnt sich wohl etwas mehr darüber nachzudenken. Wie das technisch zu lösen ist, weiß ich nicht, aber es gibt sicher einen Weg. Bis dahin läuft ja der Transcoder. Und die Trennung der 3 Komponenten hat schon auch seinen Charm - aktuell aber den Nachteil, dass es eigentlich darauf ausgelegt, mindestens 2 Rechner zu haben.

    Es gibt doch die Funktion PlayVideo die ein PES paket verlangt. Dafür muss man doch nicht in TS wandeln. Über exotische/neuere Videoformate würde ich mir im Moment keine Gedanken machen. Die würden bis dahin eh alle in FFMPEG abgeandelt werden und könnten somit im Ausgabeplugin auch gehandelt werden.

    Alternativ wäre ich für die übergabe der URL an das Ausgabeplugin.

    Das softhddevice-drm kann ja eine URL direkt abspielen. Insofern verstehe ich rell wenn er die URL an das Ausgabeplugin übergeben will. Das ist dort das einfachste. Nur das Ende des Videos zu erkennen ist da noch ungelöst.

    Das softhdodroid kann das (bisher) noch nicht, lässt sich aber einbauen.

    Zitat von zillerbaer

    Was beinhaltet den das OSD während das Video abgespielt wird?

    Hier mal 2 Beispiele, wie das so aussieht (mit Fehlfarben in softhdcuvid. In softhdodroid stimmen die Farben:(

    Das Video läuft oben rechts und alles andere gehört zum OSD.


    Das Video ist Vollbild und alles andere gehört zum OSD.

    Zitat von jojo61

    Das softhdodroid kann das (bisher) noch nicht, lässt sich aber einbauen.

    Wenn die Ausgabedevices alles abspielen können, wäre das die allerbeste Lösung. Den Transcoder gibt es nur, um eben das Video irgendwie zur Verfügung stellen zu können.


    Edit: Ich lag falsch. Die Fehlfarben gibt es nur, weil ich das Plugin lokal noch nicht gepatcht habe. Alles gut.


    Edit2: Aber ob das immer und in jeder Situation funktioniert? Gerade das Tagesschau-Beispiel könnte schwierig werden. Auf anderen Sendern wird das Fernsehbild skaliert, aber das ist erstmal nur TV und nicht Video.

    Zitat von Zabrimus

    Wenn die Ausgabedevices alles abspielen können, wäre das die allerbeste Lösung.

    Naja auch die Fernseher mit Hbbtv Support können nicht alle Video codecs. Insofern denke ich das da derzeit nur wohl 3 codecs zum Einsatz kommen.

    mpeg2, h264 und evtl. h265. Ich lasse mich da aber gerne eines besseren belehren.

    Diese codecs können schon heute von den Ausgabeplugins abgespielt werden. Und da braucht es "nur" noch eine Schnittstelle um eine URL übergeben zu können. Die scheint es ja bei softhddevice-drm schon zu geben. Ich schau mal ob ich die Tage das auch in softhdodroid übernehme.

    Dann würde das Video unabhängig vom OSD laufen. Vorspulen/Pause usw. würde dann so wie bei der Wiedergabe einer Aufnahme realisiert werden. Nur das Ende der Wiedergabe muss ja das plugin-web mitbekommen weil es dann ja im OSD/Hbbtv weitergeht.

    Zitat von zillerbaer

    VDR schließt eh das OSD nach einiger Zeit.

    Das OSD halte ich im Plugin künstlich offen, weil eben die Seiten das ganze OSD ausblenden können. Das sieht man z.B. an der Startseite ganz gut: Erst ein kleines Fenster mit dem Hinweis auf den Red-Button. Nach einiger Zeit verschwindet der Hinweis. Das OSD ist aber noch weiterhin offen und sobald man eine Taste drückt oder eben den roten Knopf geht es weiter.


    Ich habe die VDR Patches überarbeitet und im VDR*ELEC Branch scale_test auch Patches für

    softhdcuvid, softhddevice, softhddrm, softhdodroid und softhdvaapi hinzugefügt. Ich will noch ein paar Tests machen, bevor ich die Patches nach master merge.

    softhdcuvid habe ich auch auf der Entwicklungsmaschine erfolgreich im Einsatz.

    Der Vorteil ist, daß alle Ausgabeplugins weiterhin ohne Patches kompilieren. Die machen nur nicht das, was sie machen sollen, wenn der Scale verwendet wird.


    softhddevice-drm und softhddevice-drm-gles unterscheiden sich zu sehr und ich habe die Stellen nicht gefunden.


    Der VDR sieht so aus:

    0001-scalefactor_image.patch.txt


    Und für softhdodroid so (die anderen sind sehr ähnlich):

    0001-draw_image_scale.patch.txt

    Hier wäre der Patch für softhddevice-drm-gles.

    softhddevice-drm hat kein OpenGL und müsste entweder darauf verzichten oder das in Software implementieren, bzw. eigentlich müsste das dann VDRs DrawImage machen.


    EDIT: Btw, das direkt in die Plugins zu übernehmen funktioniert natürlich nur mit einer Abfrage auf die APIVERSION.

    Zitat von Zabrimus

    Die machen nur nicht das, was sie machen sollen, wenn der Scale verwendet wird.

    Was meinst du damit?

    Ich habe übrigens remotetranscode auch in VDR*ELEC integrieren können, nur fehlen bei ffmpeg wohl noch ein paar build flags:

    Ideen?

    Zitat von rell

    Hier wäre der Patch für softhddevice-drm-gles.

    softhddevice-drm hat kein OpenGL und müsste entweder darauf verzichten oder das in Software implementieren, bzw. eigentlich müsste das dann VDRs DrawImage machen.


    EDIT: Btw, das direkt in die Plugins zu übernehmen funktioniert natürlich nur mit einer Abfrage auf die APIVERSION.

    Perfekt. Das habe ich auch direkt übernommen. Das Plugin ändere ich gerade so, daß man auswählen kann, ob das Outputdevice skaliert oder ob das sws_scale machen soll. Damit sollte eigentlich alles abgefackelt werden können.

    Der neue Parameter wäre dann: -f oder --fastscale


    Was meinst du mit APIVERSION? Was genau soll wo überprüft werden?


    Zitat von rell

    Was meinst du damit?

    Wenn --fastscale verwendet wird, aber das Ausgabedevice die neuen FactorX/FactorY nicht verwenden, dann werden die OSD-Teile nicht skaliert. Da aber die x/y-Koordinaten noch stimmen, kann man das OSD sehen, aber nicht so, wie man es erwarten würde. Ich habe den Patch für softhdcuvid rückgängig gemacht und am Besten sieht man es auf diesem Bild

    Zitat von rell

    Unable to find a suitable output format for 'movie/transparent-video-127.0.0.1_50001.webm'

    Das habe ich vergessen zu erwähnen. Der FFmpeg braucht noch den vp8 Codec.

    --enable-libvpx

    Zitat von Zabrimus

    Was meinst du mit APIVERSION? Was genau soll wo überprüft werden?

    Falls die Patches upstream gehen und VDR den Patch nicht hat, bauts nicht.


    Zitat von Zabrimus

    Wenn --fastscale verwendet wird, aber das Ausgabedevice die neuen FactorX/FactorY nicht verwenden, dann werden die OSD-Teile nicht skaliert. Da aber die x/y-Koordinaten noch stimmen, kann man das OSD sehen, aber nicht so, wie man es erwarten würde. Ich habe den Patch für softhdcuvid rückgängig gemacht und am Besten sieht man es auf diesem Bild. Der FFmpeg braucht noch den vp8 Codec.

    --enable-libvpx

    Aber wenn die Plugins gepatcht sind, passt doch, oder?


    libvpx hab ich. Matroska als muxer auch, was brauch ich für webm? Ich vermute aktuell opus...

    Zitat von rell

    Falls die Patches upstream gehen und VDR den Patch nicht hat, bauts nicht.

    Ah okay. Es steht ja noch in den Sternen, ob VDR überhaupt gepatched wird - offiziell. Und solange das nicht passiert, werden die anderen Patches auch nicht Upstream gehen können. Im Plugin habe ich so alle notwendigen Patches gesammelt. Nur für den Fall, das dies jemand einsetzen will. In VDR*ELEC habe ich mehr Kontrolle darüber und sehe zumindest da kein Problem.


    Mein lokales FFmpeg habe ich so gebaut:

    Code
    ./configure  --prefix=/usr/local/ffmpeg-6.0/ --enable-gpl --enable-nonfree --enable-libx265 --enable-libx264  --enable-libvorbis --enable-libvpx --enable-libfdk-aac --extra-cflags="-I /usr/local/ffmpeg-6.0/include" --extra-ldflags="-L /usr/local/ffmpeg-6.0/lib" --extra-libs=-lpthread --extra-libs=-lm --enable-libfreetype --enable-libmp3lame --enable-libopus  --pkg-config-flags="--static"

    Ich wüsste nicht, was noch fehlen sollte? Oder wird in den Flags noch etwas explizit abgeschaltet?

    Ich habe mir die patches nun mal angeschaut und ihr habt cImage erweitert. Das ist zwar durchaus sinnvoll bricht aber das API nun komplett.

    Mit DrawImageScale würde das nicht passieren. Das könnten die Ausgabeplugins schonmal implementieren ohne den VDR und dennoch würde es compilieren (abwärtscompatible). Und wenn die fertig sind könnte Klaus nachziehen. Nur so meine Meinung :)

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden