Posts by Dr. Seltsam

Ich bin hier am verzweifeln. kls sagt, dass das vaapidevice mit git-Stand 18.November 2018 bei ihm auf dem J4105M stabil funktioniert. Ich hatte zeitweilig sogar seine Umgebung (openSUSE 15.0. mit manuell installierten libva und intel-vaapi-driver aus dem git von Intel sowie ffmpeg 4.0) installiert, habe dort aber die gleichen Probleme und bin wieder zurück auf derzeit Xubuntu 19.04., das aber gegenüber 18.04. keine Verbesserung brachte - allenfalls die Bildqualität hat sich in Punkto Detailschärfe möglicherweise etwas verbessert.

Auch ein Versuch unter Xubuntu 19.10 ergab die gleichen Probleme.

Ich habe jeweils sowohl die libva+Treiber von Ubuntu als auch jeweils die neuesten aus dem gut probiert. Ebenfalls verschiedene Versionen von ffmpeg.

Fazit ist weiterhin:

• vdr mit softhddevice oder vaapidevice bis 20.02.18 laufen mit Einschränkungen (alle paar Minuten sausen Artefakte durchs Bild oder das BIld bleibt stehen/wird schwarz)
• Das aktuelle vaapidevice läuft grottig - bei SD-Sendern gibt es gelegentlich beim Umschalten und generell, wenn vdr auf einem SD-Kanal startet, Pixelsalat.

Der x-server läuft auf 1920x1080 mit dieser xorg.conf:

Kann jemand, bei dem die Ausgabe über Intel UHD Graphics 600 (Gemini-Lake-Generation) stabil läuft, mal seine Ausgabe von vainfo (ist Teil der libva-utils) posten?

Ich suche im Moment auch noch nach einer Erklärung, warum der TV nach ein paar Minuten immer auf "no signal" schaltet, obwohl in den xfce-Einstellungen die Bildschirm-Energieverwaltung bereits aus ist. Das HDMI-Kabel geht vom Mainboard in den AVR und der Ausgang des AVR in den TV. Der AVR ist so eingestellt, dass er im Stand-by das Signal durchschleust. Das klappt beim VDR2 mit Nvidia-Grafik auch problemlos. Nur beim VDR1 mit Intel-Ausgabe verschwindet das Bild immer wieder und ich muss dann den AVR ein- und wieder ausschalten, damit es wieder beim TV ankommt.

und Artefakte huschen weiterhin gelegentlich durchs Bild

richtig stabil läuft das leider auch nicht.

Mittendrin beim Live-TV wird das Bild plötzlich schwarz und kommt auch nach dem Umschalten nicht wieder

xorg läuft auf 1920x1080@50. Dieses OSD-Problem hatte ich mit softhddevice übrigens nicht.

Die Skalierung steht auf normal, und ich habe sowohl Bob als auch Motion Adaptive probiert. Asynchronitäten habe ich ebenfalls.

Zwischen 20.02.18 und Anfang März gab es im vaapidevice so viele Umbaumaßnahmen, dass es schwer werden wird herauszufinden, ob und welcher einzelne commit die Ursache ist.

Was mich mal interessieren würde: Was für Versionen von Plugin, ffmpeg benutzen denn die Leute, die von der Intel-Ausgabe so schwärmen, und was sagt dort vainfo?

Danke, das hat funktioniert. In code.cmusste CODEC_CAP_HWACCEL noch durch AV_CODEC_CAP_HARDWARE ersetzt werden.

Wenn der vdr auf einem SD-Kanal startet, kommt das grüne Pixelgewitter jetzt nicht mehr (es kam vorher auf HD-Kanälen meistens -vielleicht sogar immer- auch nicht). Das OSD ist weiterhin beim Start nicht gleich in richtiger Größe vorhanden.

Dazu habe ich hier übrigens etwas gefunden:

https://github.com/pesintta/vdr-plugin-vaapidevice/pull/122

Quote

TODO:

• black surface should be displayed if no video data available
• initial osd not drawn at startup
• ffmpeg stream info issues with some test recordings and rofafor#4
• occasional lip sync issues with huge negative A/V drift values

Ob der Rest besser läuft, muss ich morgen testen.

Bislang kann ich noch nicht erkennen, warum ich nicht einfach wieder meine Nvidia-Karte einstecken sollte und mit einem älteren ffmpeg und VDPAU weiterarbeite. Das hat wenigstens stabil funktioniert, und das Bild war auch brillianter.

Der Revisionsstand 6372704835b62bee882feed92686edc75e70b55f vom vaapidevice kompiliert bei mir nicht:

Wie bereits unter Ubuntu 18.04 habe ich auch mit 19.04 (Kernel5.0.0-25-generic) Stabilitätsprobleme mit der Intel-Ausgabe meines neuen J4105B-ITX.

Sporadisch gibt es beim Kanalwechsel Pixelsalat.

Generell gibt es beim vdr-Start erstmal kurz ein zu kleines und in den Proportionen verzogenes OSD.

Innerhalb von einer Sekunde kommt dann das OSD in richtiger Größe, aber häufig gibt es anstelle eines Bildes Pixelsalat

Der Pixelsalat verschwindet, wenn man den Kanal umschaltet.

Häufig blitzen grüne Artefakte durch das BIld, obwohl der DVB-C-Empfänger laut femon weder UNC hat noch die BER auffällig ist.

Wenn man das setup-Menü des vaapidevice-Plugins aufruft und die bestehende Video-Konfiguration mit ok bestätigt (ohne etwas geändert zu haben) , wird das Bild dunkel. Erst nach einem Kanalwechsel hat es wieder normale Helligkeit/Kontrast.

Ich verwende das aktuelle vaapidevice aus dem git von rofafor. ffmpeg ist Version ffmpeg version 4.1.3 von Ubuntu.

Sind die beschriebenen Probleme bekannt bzw. gibt es eine Abhilfe?

CvH wrote:

in "HD" weil Mpeg2 in grausiger Bitrate kaum auszuhalten ist auf einem großen TV, das Programm macht dann noch sein übriges dazu

Ich habe Kabel, und mein letzter Stand ist, dass es (abgesehen von monatlichen Mehrkosten von 5,-) nahezu unmöglich ist, von Vodafone eine Smartcard zu bekommen, die in einem Alphacrypt läuft. Mal abgesehen davon, dass mein neuer USB-Empfänger gar kein CAM unterstützt.

Gibt es eine andere, mit vertretbarem Aufwand einrichtbare Lösung, über die ich mich in einem anderen Forum (digitalelite?) informieren sollte?

Meine Erfahrungen bezogen sich auf Ubuntu 18.04, aber ich werde jetzt trotzdem nochmal eine Neuinstallation mit 19.04 machen.

Zum Thema SD und mpeg2 ist tot: Wie schaut Ihr denn die Privaten??

fnu wrote:

Also bei SD gibt es klare Unterschiede, das hält nichtmal annähernd mit Nvidia's VDPAU Aufbereitung mit, wenn man es denn überhaupt vernünftig zum Laufen bekommt. Ich glaube aber das war nie ein Geheimnis ...

ich hatte durch einige Aussagen hier im Forum den Eindruck bekommen, als wenn Intel da mittlerweile gleichgezogen hätte.

Interessanterweise finde ich SD auf den ersten Blick gar nicht so schlecht - was ich halt sofort sehe ist, dass bei HD die feinen Details wie Poren und Barthaare im Gesicht matschiger sind.

Ich muss dazu sagen, dass der xserver natürlich auf 1920x1080 läuft, weil ich noch keinen UHD-TV habe. Kann mir aber irgendwie nicht vorstellen, dass das auf UHD mit upscaling besser aussehen soll.

Ich habe mir jetzt ein Asrock J4105B-ITX mit Intel UHD Graphics 600 gekauft. Inzwischen habe ich sowohl 1080p-Filme mit vlc abgespielt als auch HD und SD mit vaapidevice getestet. Gewohnt bin ich bisher eine Wiedergabe über eine betagte Nvidia GT-520.

Also Leute, wer ernsthaft behauptet, zwischen Intel und Nvidia gäbe es keinen sichtbaren Unterschied mehr, der sollte mal zum Augenarzt gehen!

Das Bild hat erkennbar weniger Details und wirkt matschiger . Selbst der kleine Raspberry Pi kann das besser - zwischen dem und der Nvidia konnte ich nie Unterschiede ausmachen.

ich habe mir den Stick jetzt auch gekauft (in der günstigeren Sports Edition). Auf meinem Ubuntu-18.04-System mit Kernel 4.11 wurden zunächst zwei firmware-Dateien gesucht, anschließend ging ein Tuner. Nach dem update von media_build wird nun nur noch das Laden von dvb-demod-si2168-b40-01.fw protokolliert. Ich kann von beiden Tunern gleichzeitig aufnehmen.

Leider wird das Log von solchen Meldungen geflutet:

Ich habe den Stick mit einem Koax-Doppelstecker direkt auf den Ausgang meines Antennen-Verteilverstärkers gesetzt und mit einem USB-Verlängerungskabel zum USB-Anschluss des Boards geführt. Ein USB-3-Kabel wird man ja wohl nicht brauchen?

Abgesehen davon, dass die Logflut stabilitätsgefährend ist, scheint der Empfang einwandfrei zu sein. Femon zeigt leider keine BER an, aber die arbbalken sind tiefgrün, d.h. STR und SNR sind gut.

Man soll wohl die defaultmäßig gesetzte OptionCONFIG_DVB_DEMUX_SECTION_LOSS_LOG vor dem Übersetzen von media_build in v4l/.config abschalten. Wahrscheinlich ist dass in neueren Kernelversionen diverser Distris schon Standard.

Setz doch mal zwei parallele timer auf ARD und ZDF und poste das konkrete Log ab dem Zeitpunkt, wo die Aufnahmen starten.

Was hat es mit der Abbildung in #19 auf sich? Was ist das für ein Tool?

Aber selbst wenn vdr mit der Option -d auf eine Karte beschränkt wäre, dürfte vdr im log nicht beide initialisieren.

Wenn kein device für den angeforderten Kanal zur Verfügung steht, wird das eigentlich mit einer deutlichen Fehlermeldung protokolliert. Die habe ich hier bisher noch nicht gesehen.

Die Idee ist in der Tat, zumindest einen beider beiden klobigen VDRs durch einen NUC oder Mini-ITX zu ersetzen.

Spricht rein technisch (also abgesehen vom hohen Preis) eigentlich etwas gegen den Einsatz einer SSD auch für die Video-Partition? Oder stresst die SSD zu sehr, so dass vorzeitiger Verschleiß droht?

ja, aber mir ist noch nicht klar, ob die devices nun als DVB-C oder DVB-T2 devices verwandt werden. Das siehst Du dann evtl. tatsächlich nur im OSD oder im femon-Plugin.

Das Problem bei diesen Hybrid-devices ist ja, dass sie in der Regel nur entweder DVB-C oder DVB-T2 empfangen können. Hast Du denn DVB-T2-Kanäle in Deiner channels.conf?

und wenn vdr zwei DVB-C frontends ausweist, musst Du mal zwei Sendungen auf unterschiedlichen Frequenzen starten und im syslog schauen, was vdr bei der Ablehnung der zweiten Aufnahme loggt.

Du schreibst ja, dass zwei Aufnehmen nicht gehen. Geht denn eine Aufnahme von ZDF und ein gleichzeitiges Live-Ansehen von ARD?

Du kannst mal schauen, was vdr im syslog protokolliert.

bei mir z.B.

ist es die WinTV dualHD?

Du siehst sowohl "DVB: registering adapter 0 frontend 0" als auch "DVB: registering adapter 1 frontend 0" in dmesg?

Wieviele devices zeigt vdr an? Im LCARS-skin siehst Du rechts die devices. Sind es zwei, und werden beide als DVB-C angezeigt?