vdr-sxfe verabschiedet sich mit [input-vdr] Control stream disconnected

fhg · 20. Mai 2017

@ fnu: Erstmal Dank für Deine Mühen.

Vielleicht sollte ich doch auf softhddevice umsteigen, denn das läuft ja wohl relativ stabil. Allerdings ist mir da die Integration in mein Konzept noch nicht ganz klar. Ich möchte, daß der VDR quasi "immer" läuft, wenn der Rechner an ist, Bild und Ton brauche ich dann jedoch nicht immer gleichzeitig, da ich parallel andere Dinge wie Kodi oder Internetbrowser benutzen möchte. Ich habe softhddevice bisher so verstanden, daß es immer mit dem VDR mitläuft also auch immer eine Ausgabe erzeugt.

Wenn die anderen Baustellen in meinem Leben es zulassen, werde ich mal mehr mit softhddevice beschäftigen.

Gruß Frank

fnu · 20. Mai 2017

fhg

Ich habe noch nicht aufgegeben, teste noch verschiedene Kombinationen von libva & xine-lib, mit verschiedenen VO Parametern.

Eins ist aber schonmal sicher, mit xineliboutput gibt es nur Weave oder Bob als Deinterlacer, leider nicht MADI/MCDI wie bei softhddevice vpp branch. Post Processing wie denoise oder sharpening gibt es auch (noch) nicht, aber einen HQ Scaler.

Regards
fnu

fnu · 20. Mai 2017

fhg

So, habe die Tests erstmal abgeschlossen und in meinem "ppa:fnu/vpp-vdpau-fnu" den IntelGraphics Stack 1.8.1 drin, womit Kaby Lake funktionieren sollte. Das Repo gehört nun mit "main-fnu" zu "unstable-vdr-fnu".

Es läuft aber alles noch nicht ganz fehlerfrei:

softhddevice-vpp-hevc: HD perfect, SD habe ich leider eine grün flackernde Bildausgabe, wie schon seit 1.7.3. Nur 1.7.0 läuft bei mir fehlerfrei ... weder ein neueres Mesa oder xserver-xorg-video-intel brachten Besserung.
=> h.265 HD läuft damit solala auf meinem NUC, vmtl. könnte müsste man die Software-Aufgabe optimieren oder auslagern ...
xineliboutput-sxfe: HD & SD laufen gut und rund mit "-v vaapi" & "-v opengl2". Leider funktionieren die xine-eigenen Deinterlacer nicht, nur "tvtime".
=> Die CPU Last ist bei vaapi sehr niedrig, bei opengl2 naturgemäß höher.
=> h.265 HD läuft fehlerfrei und absolut rund mit vaapi & opengl2 auf meine Haswell NUC, wobei die CPU Last bei opengl2 niedriger ist.
=> generell gefällt mir das opengl2 Bild besser, etwa temporal/MADI Niveau. Lt. phintuka werden hier auch Funktionen der GPU genutzt.
=> Achtung: nicht zu neue xine-lib-1.2 auschecken, Changeset 13096 läuft prima, neuere z.B. 13112+ zeigen flackerndes HD Bild.

Ach ja, meine Basis wie gesagt ein Haswell NUC, Intel Graphics 4400, Xenial 16.04 mit xorg-HWE und Kernel 4.10.0.

Regards
fnu

fhg · 10. Juni 2017

fnu DANKE!

Ich habe gestern mal eine Stunde Zeit gefunden, um Deine neuesten Änderungen einzuspielen. Ein erster Test mit vdr-sxfe sagt: "Läuft bei mir". Ein paar Stunden fehlerfrei, ohne Abstürze, das ist schon mal gut. Weiter habe ich nicht getestet. Gestartet habe ich vdr-sxfe lediglich mit dem Aufruf vdr-sxfe. Verstehe ich das richtig, daß ich mit "vdr-sxfe -v vaapi" bzw. "vdr-sxfe -v opengl2" unterschiedliche Qualitäten bei der Wiedergabe bekomme? Ich werde es mal testen.

Jetzt kann ich mich weiteren kleinen Problemen widmen, die aber nichts in diesem Thread zu suchen haben.

fnu · 10. Juni 2017

Zitat von fhg

Verstehe ich das richtig, daß ich mit "vdr-sxfe -v vaapi" bzw. "vdr-sxfe -v opengl2" unterschiedliche Qualitäten bei der Wiedergabe bekomme? Ich werde es mal testen.

Jein, in Details unterschiedlich, eher anders gelöst ...

Mit den letzten Bits, sind in meinem PPA, startet "vdr-sxfe" jetzt per Default mit "opengl2" ... wenn Du "vaapi" möchtest, musst Du das explizit angeben. Aber "opengl" sollte auf vielen Plattfomen problemlos laufen, egal ob die HW HEVC kann oder nicht, also quasi ein No-Brainer ...

Ein Problem will ich mit den allerletzten Ständen in meinem PPA nicht verschweigen, bei mir hängt sich "vdr-sxfe" in den Wald wenn ich auf SD Sender oder Aufnahmen schalte. Hab mal einen Backtrace an phintuka gesendet.

Regards
fnu

fhg · 15. Juni 2017

Das Problem bem Umschalten auf SD-Aufzeichnungen kann ich hier nicht nachvollziehen. Bisher tut vdr-sxfe bei mir genau das, was es tun soll

fhg · 16. Juni 2017

Schnelles Vorspulen ist allerdings eine Katastrophe. Zurück funktioniert.

fnu · 16. Juni 2017

Zitat von fhg

Schnelles Vorspulen ist allerdings eine Katastrophe.

Nun, eine sinnvolle Fehlerbeschreibung könnte schon helfen, dass man den Entwickler um Anpassung bittet.

Können ja kaum schreiben: "Fast forward sucks with xineliboutput-sxfe ..."

Regards
fnu

fhg · 17. Juni 2017

Selbstverständlich, ich bitte um Entschuldigung.

Beim schnellen Vorspulen von HD-material gibt es zumindest auf meinem Bildschirm kein Vorspulen sondern lediglich ein Standbild. Das Bild kommt aus der Aufzeichnung irgendwo ein paar Sekunden nach dem Start des schnellen Vorlaufs. Manchmal gibt es auch noch ein(ige) weitere(s) Standbild(er). Im Hintergrund findet der Vorlauf statt. Beim Drücken auf "Play" passiert nichts (oder ich sehe nur nichts außer dem Standbild). Ich stoppe dann die Aufnahme und starte sie wiederund befinde mich irgendwo in der Aufzeichnung nach dem Starten des Vorlaufs.

Genauer kann ich es z.Zt. nicht beschreiben, ich benutze den Vorlauf eben wegen dieses Vrehaltens kaum noch.

~~Ach ja unter Kodi war das Verhalten eingentlich fast genauso. Ich werde das aber nochmal testen.~~

Habe ich gerade getestet. Das kann ich nun nicht mehr bestätigen. Unter Kodi funktioniert das Vor- und Zurückspulen. So langsam komme ich mit meinen vielen Tests durcheinander.

vdr-sxfe verabschiedet sich mit [input-vdr] Control stream disconnected

Jetzt mitmachen!

Teilen