softhddevice und yavdr 0.4 - hat das jemand am laufen?

Das ganze läuft bei mir noch auf einem Testsystem mit wahrscheinlich vielen Fehlern in den upstart scripten. (z.b. "sudo -u vdr"). Man muß es halt noch richtig anpassen. Aber das ganze hat eben nichts mehr mit yavdr zu tun und gehört wahrscheinlich auch nicht ins yavdr forum.

Dazu muß ich auch noch sagen das softhddevice auf einem Testrechner mit einer natty alternate installation und yavdr paketen läuft, ich aber noch nicht geschafft habe das mein vdr mit dem yavdr upstart jop "vdr.conf" läuft. Deshalb der wahrscheinlich etwas komplizierte weg.

...öööh ja gut das Plugin ist gebaut - völlig problemlos aber ich konnte dem Ding noch kein Bild entlocken. Wäre ja jetzt blöd auf halber Strecke aufzuhören. Kann mir jemand sagen was ich wo ändern muß, damit es auf dem TV :1.0 startet?

hotzenplotz5
was genau ist denn zu kompliziert?

Was passiert denn wenn Du das machst:
sudo stop vdr
sudo stop openbox
vdr --log=3 --plugin="softhddevice -g 1920x1080+0+0 -x"

Nix passiert, der kleine GraphTFT-Monitor zeigt ein schwarzes Bild und der Fernseher 'kein Signal'.
Wenn ich ein Device mitgebe -d :1.0 beispielsweise bekomme ich ein zu großes Bild auf dem kleinen Monitor - aber nicht aufs TV...

So bei Deinem Aufruf sucht er die xorg.conf in /usr/share/X11/xorg.conf.d dort habe ich die xorg.conf von yavdr abgelegt und jetzt habe ich das Bild in 1920x1080 auf dem TV...

Hast Du denn die Beispiel upstart scripte getestet? Ansonsten ist eigentlich alles in diesem Thread beschrieben: softhddevice - Software VDPAU/VA-API/CPU Decoder und Ausgabe Plugin.
Und nochmal möcht ich darauf hinweisen das softhddevice nicht vom yavdr team bereitgestellt wird und auch nichts damit zu tun hat. Alle die es trotzdem versuchen wollen müßen halt ein bißchen fummeln bis es läuft. Das bei Dir der Vdr nicht gestartet wird kann viele Ursachen haben. Wenn Du es nicht mit den upstart scripten testen willst mußt Du dieses hier: vdr --log=3 --plugin="softhddevice -g 1920x1080+0+0 -x" an deine Umgebung anpassen. Vielleicht mal das hier testen: vdr -u vdr -v /srv/vdr/video.00 --plugin="softhddevice -g 1920x1080+0+0 -x"

Oh Fast gleichzeitig. Deshalb einfach zum testen die upstart beispiele nutzen oder selbst umbauen.

Ich habe gestern Abend abgebrochen weil mit halbherzigen Änderungen vielleicht das plugin läuft, aber die Funktionalität von yaVDR grob abgeändert würde und das enstpräche dann nicht mehr yaVDR da gebe ich Asta recht...
Das plugin läuft jedenfalls und läuft auch völlig ruckelfrei in der Zeit die ich es an hatte. Sieht nach ernsthafter konkurenz für xine aus und müsste warscheinlich über templates usw als weiteres frontend ins wfe integriert werden. Ich würde es aber ernsthaft auch für die 0.4 in Betracht ziehen. Vielleicht bekommt ja hotzenplotz5 doch noch Lust

Zitat von Taipan

Sieht nach ernsthafter konkurenz für xine aus

Ist es und mit VDPAU schon annähernd Ready-to-use. Aber so richtig fertig wird es wohl erst wenn zumindest noch das Intel Zeugs ähnlich gut und einfach nutzbar ist ...

Zitat von Taipan

und müsste warscheinlich über templates usw als weiteres frontend ins wfe integriert werden. Ich würde es aber ernsthaft auch für die 0.4 in Betracht ziehen. Vielleicht bekommt ja hotzenplotz5 doch noch Lust

Das hat wohl wenig mit Lust zu tun und wird ziemlich sicher nicht seinen offiziellen Weg in yaVDR 0.4 finden. Das sind ja nicht nur ein paar wenige popelige Änderung, wie es hier suggeriert wird, sondern ein signifikanter konzeptioneller Aufwand, den man eher gleich in eine neue Version kanalisiert. Kann mir auch gar nicht vorstellen, das das Plugin in den Natty Repo's landet, daran hat mit Oneiric oder Precise doch eh keiner mehr Interesse und Ihr Nutzer macht das yaVDR Team ja für alles in den Repositories verantwortlich. Für Lucid LTS (0.3) sieht es auch nicht gut aus, da ist ffmpeg zu alt und nur dafür eine eigene neuere Version in den Repo's zu pflegen rechnet sich offen gesagt nicht ...

Regards
fnu

full ACK

ein anderer Weg wäre vllt eine precise preprepre mit Grundfunktionalität (ich meine vdr mit xine sollte eingermaßen sicher laufen) + immer aktuellem softhddevice plugin bereitzustellen und somit die User rund um johns mit in die diesbezügliche yavdr implementierung einzubinden?

Denke dann hätten die einen was zum Spielen und das Team könnte sich mehr der Distri an sich widmen. Ich könnte mir sehr gut vorstellen das ich das sofort im Esszimmer auf ne freie Partition aufspielen würde.....

Christian

Sorry, es sollte nicht so klingen als sei es eine Kleinigkeit...
Vielleicht als addon!?
Wir werden sehen

Moin,

Von der VDR Seite sollte softhddevice wie jedes andere Plugin zubehandeln sein.

Dann braucht Ihr diese Optionen.

-f            start with fullscreen window (only with window manager)
  -g geometry   x11 window geometry wxh+x+y
  -s            start in suspended mode

Bei "-f" bin ich mir nicht ganz sicher wie es yavdr haben will. Mit -f meldet das Plugin dem Fenstermanager (Openbox) das es im Fullscreen Modus laufen will, sonst hat diese keinerlei Funktion.
Mit "-g" kann man die Position und Größe festlegen, hier kommt es wiederum auf den Windowmanager an, ob er dies befolgt.
Mit "-s" wird noch keine Verbindung mit dem X11 Server versucht.
Man kann nun ganz normal alle Init (upstart) Scripte abarbeiten.

An der Stelle wo normaler Weise das Frontend gestartet wird, macht man ein:

svdrpsend plug softhddevice resu

nun verbindetet sich das Plugin mit dem X11 Server.

Johns

Zitat von CKone

Denke dann hätten die einen was zum Spielen und dsa Team könnte sich mehr der Disti an sich widmen.

Die Praxis sieht da leider häufig anders aus. Da wollen dann gleich alle mit spielen und tanzen dann gleich hier an wenn was nicht funktioniert. Es reicht wenn ich meinem Söhnchen den Popo wische

Andererseits läuft unsere Entwicklung doch völlig öffentlich ab. Wir bemühen uns immer alle Pakete sowohl für Oneiric als auch für Precise aktuell zu halten. Es ist also alles da zum Spielen. Es ist klar das damit nicht jeder in der Lage ist sich ein yaVDR aufzusetzen, aber auf die Art wären eben die Anfänger außen vor. Diejenigen die damit klar kommen, werden uns höchstwahrscheinlich nicht mit Kleinkram ablenken.

Aktuell ist wohl das größte Hindernis für softhddevice, dass das Plugin nicht mit der libav von Ubuntu mag. Es ist nicht wirklich ein Problem ein ffmpeg-Paket zu bauen, aber ein Wechsel auf ffmpeg kommt nicht in Frage, weil dann etliche Applikationen nicht mehr laufen und wir die nicht alle auf ein neues API ändern wollen, weil wir sie dann ständig weiterpflegen müssten.

Sollte sich ein begnadeter Paketbauer in der Community finden, der ein ffmpeg-Paket baut, dass mit der libav von Ubuntu koexistiert und ein softhddevice-Paket so anpasst, dass es dieses ffmpeg-Paket benutzt, dann würde das die Aufnahme des Plugins ins yaVDR-Repository brutal beschleunigen. Ein weniger schöner Ansatz wäre es, das softhddevice-Paket so anzupassen, dass eine lokale Kopie der ffmpeg enthält und diese statisch linkt.

Da bin ich mal gespannt was die viel beschworene Community so zu Tage fördert.

Gerald

Zitat von johns

-f start with fullscreen window (only with window manager)

Das würden wir eher nicht benutzen. Ein fullscreen window erlaubt es nicht unseren Launcher (und in Zukunft vielleicht einen vollständigen Desktop) in den Vordergrund zu holen. Bei unseren aktuellen Frontends maximiert Openbox die Fenster und entfernt dann die Dekoration. Für diesen Modus ist sogar ein Patch von mir in vdr-sxfe eingeflossen, damit vdr-sxfe auch im Windows-Mode den Mauscursor versteckt wenn die Maus idle ist. In Zukunft machen wir das Maximieren und Dekoration entfernen entweder mit Devilspie, oder mit einer Anwendung die ich gerade schreibe. Solange das Fenster deines Plugins einen eindeutigen Namen hat über den man es finden kann, ist das auch ohne weiteres mit dem softhddevice möglich.

Gerald

Zitat von Taipan

Sorry, es sollte nicht so klingen als sei es eine Kleinigkeit...
Vielleicht als addon!?

Inwiefern sollte ein Addon einfacher sein?

Aber auch egal, die Integration ist eher das kleinere Problem, siehe meine anderen Posts.

Gerald

Ja ja, is ja gut ich hab euch trotzdem lieb...

Zitat von gda

Aktuell ist wohl das größte Hindernis für softhddevice, dass das Plugin nicht mit der libav von Ubuntu mag. Es ist nicht wirklich ein Problem ein ffmpeg-Paket zu bauen, aber ein Wechsel auf ffmpeg kommt nicht in Frage, weil dann etliche Applikationen nicht mehr laufen und wir die nicht alle auf ein neues API ändern wollen, weil wir sie dann ständig weiterpflegen müssten.

Sollte sich ein begnadeter Paketbauer in der Community finden, der ein ffmpeg-Paket baut, dass mit der libav von Ubuntu koexistiert und ein softhddevice-Paket so anpasst, dass es dieses ffmpeg-Paket benutzt, dann würde das die Aufnahme des Plugins ins yaVDR-Repository brutal beschleunigen. Ein weniger schöner Ansatz wäre es, das softhddevice-Paket so anzupassen, dass eine lokale Kopie der ffmpeg enthält und diese statisch linkt.

Da bin ich mal gespannt was die viel beschworene Community so zu Tage fördert.

Aber nur das ganz alte Ubuntu ab Oneiric sollte es keine Probleme geben. Somit braucht man nicht umbedingt ein statisches ffmpeg, wenn es einer einbaut ist es auch gut, aber nicht zwingend erforderlich.

VA-API und Intel ist ein anderes Problem, was zwar langsam aber stetig in die richtige Richtung entwickelt.

Manchmal überrascht sie, meist enttäucht sie, einfach nichts erwarten, dann ist man immer freudig überrascht,
Johns

Zitat von johns

Aber nur das ganz alte Ubuntu ab Oneiric sollte es keine Probleme geben. Somit braucht man nicht umbedingt ein statisches ffmpeg, wenn es einer einbaut ist es auch gut, aber nicht zwingend erforderlich.

Na ich weiß nicht recht johns:

video.c: In function 'VdpauRenderFrame':
video.c:6822:41: error: 'AVFrame' has no member named 'sample_aspect_ratio'

Buildlog

Gerald

Das ist kein libav Fehler.

#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(53,60,100)
    if (decoder->InputWidth && decoder->InputHeight
        && av_cmp_q(decoder->InputAspect, frame->sample_aspect_ratio)) {
        Debug(3, "video/vdpau: aspect ratio changed\n");


        decoder->InputAspect = frame->sample_aspect_ratio;
        VdpauUpdateOutput(decoder);
    }
#else
    if (decoder->InputWidth && decoder->InputHeight
        && av_cmp_q(decoder->InputAspect, frame->sample_aspect_ratio)) {
        Debug(3, "video/vdpau: aspect ratio changed\n");


        decoder->InputAspect = video_ctx->sample_aspect_ratio;
        VdpauUpdateOutput(decoder);
    }
#endif

sondern meiner ich habe zweimal das Gleiche. Die zweite Version sollte "video_ctx->sample_aspect_ratio;" sein.
Ansonsten kann man die Version noch anpassen falls, eine neuere libbav die Funktion noch nicht an.

Johns

Zitat von johns

Das ist kein libav Fehler. sondern meiner ich habe zweimal das Gleiche. Die zweite Version sollte "video_ctx->sample_aspect_ratio;" sein.

Danke für den schnellen Fix.

Zitat von johns

Ansonsten kann man die Version noch anpassen falls, eine neuere libbav die Funktion noch nicht an.

Das sollten wir hinbekommen ;). Wir melden uns falls das nötig sein sollte.

Gerald

habs mal hochgeladen.

so sieht es jetzt mit oneiric aus :
https://launchpadlibrarian.net…0~oneiric_BUILDING.txt.gz

und so mit precise :
https://launchpadlibrarian.net…0~precise_BUILDING.txt.gz