rfehr kannst du bauen?
rfehr kannst du bauen?
Ist gebaut
Erstmal vielen Dank für das immer schnelle Bereitstellen, rfehr
Folgende Erkenntnisse: Leider bringen beide Einstellungen sichtbar nichts. Dadurch etwas angestachelt habe ich weitere Tests mit anderen Geräten durchgeführt und dabei folgendes herausgefunden:
Das Info-Menü meiner LG Fernseher hat einen bekannten "Bug". Das Fenster zeigt immer 8bit Farbtiefe an, auch wenn ein 10bit Signal anliegt. Testen konnte ich dies mit einem AppleTV und auch der VDR Aufzeichnung, die auch bei Wiedergabe über den AppleTV auf dem LG 8bit anzeigt.
Nach Recherche war dann schnell klar, dass es ein Bug im LG TV ist.
Nebenbei habe ich noch herausgefunden, dass, wenn man Dolby Vision Inhalte abspielt, das Signal (was eigentlich 10 oder 12bit ist) in einem 8bit RGB Signal getunnelt wird. Holy shit, da blickt ja keiner mehr durch. Also wenn DolbyVision ausgegeben wird auf dem AppleTV zeigt der LG (richtigerweise) RGB 8bit an.
Ich möchte mich also entschuldigen für die all die Unannehmlichkeiten, die ich verursacht habe. Aber es deutet alles darauf hin, dass die Wiedergabe "tatsächlich" in 10bit erfolgt.
Das heißt, erstmal zurück auf Null und die Sachen aus dem 10bit branch brauchts nicht? Kann ich mich E-AC3 widmen...
Ja, genau. Tut mir leid.
Dr. Seltsam Mit deinen Artefakten komme ich nicht recht weiter. "Im Dunkeln tappen" trifft es...
Da hier im Forum (auch von dir
) aber immer wieder die Frage nach den Umschaltzeiten kommt, habe ich jetzt eine Zeitmessung eingebaut. Start der Messung ist sobald der VDR einen ChannelSwitch initiert - das Plugin reagiert auf cStatus::ChannelSwitch(). Gestoppt wird, sobal das erste Bild auf den Schirm wandert. Zusätzlich wird die Zeitspanne ab dem ersten vom VDR gesendeten Audio- oder Videopaket bis zum Erscheinen auf dem Monitor geloggt. Damit kann man Sender, Einstellungen und Platformen zu vergleichen und muss nicht mehr subjektiv beurteilen.
Außerdem kann man den internen Puffer (aktuell 450ms) per Setup nach oben und unten korrigieren und sich so an den optimalen Wert herantasten. Ich bin mit -135 jetzt mal bei 315ms Puffer und das Umschalten fühlt sich flott an...
Als Info wird im Setup auch der Jitter von Audio und Video angezeigt - einmal als Maximum der letzten 1000 Pakete und einmal als Maximum seit dem letzten Kanalwechsel.
Da das Thema A/V-Sync gerade im vaapivideo Thread diskutiert wird, habe ich in der developer-readme nochmal 3 Diagramme ergänzt, wie der Sync beim Streamstart in softhddevice-drm-gles gehandelt wird. Vielleicht ist das ja für den ein oder anderen wie zork hilfreich...
Danke, so etwas ähnliches hatte jojo61 auch mal als Debug-Code in softhdodroid eingebaut. Man muss im Hinterkopf behalten, dass die Dauer des Umschaltvorgangs stark davon beeinflusst wird, ob man gerade ein i-frame verpasst hat, oder ob dieses zufällig gerade kommt. Ich hatte mal die TS-Streams von Vodafone in avidemux geprüft und festgestellt, dass je nach Sender und Sendung die GOP eine Länge von knapp über 2s haben kann. Die verschiedenen Ausgabeplugins funktionieren ja auch sehr unterschiedlich. Bei softhdodroid werden die Videopakete direkt an den amlogic-Kernel geschickt, der sich um alles weitere selbst kümmert und sogar die Dekodierung der SPS-Daten zur Ermittlung des richtigen Seitenverhältnisses übernimmt. Wir verwerfen das Audio solange, bis Videodaten da sind und die Audio-PTS nicht hinterherhinkt. Die Synchronisation übernimmt dann wiederum der Kernel und blendet das Bild erst ein, wenn A/V synchron sind. Ffmpeg wird nicht benötigt!
Das Problem der Artefakte ist für mich eher nachrangig, da ich den Raspi ja nicht produktiv als VDR nutze. Mein Haupt-VDR ist und bleibt der N2+. Die Tanix TX3 ist im Vergleich zum RPi4 für mich besser als Zweit-VDR geeignet:
Wer seinen Raspi 24/7 betreibt und einen TV hat, der über CEC auch die Menütaste einbindet, wird beides nicht brauchen.
Wenn Sundtek irgendwann mal den avisierten Protoypen seines DVB-C USB Tuners ausliefert, werde ich den auch nochmal am Raspi testen. Meine positiven Erfahrungen mit dem WinTV dualHD-Stick basieren alle auf dem Einsatz unter Kernel 4.9 (CoreElec). Vielleicht ist da im 6er-Kernel auch was kaputt-optimiert worden.
neumann2k Wegen eac3 könntest du das mal testen https://github.com/rellla/vdr-plu…tree/fix-eac3-2 ...
rfehr Wärst Du so lieb?
rfehr Wärst Du so lieb?
sollte fertig sein
noch nicht da
Sehr geil. Standard sollte 1080p sein. Also 1920x1080 50Hz progressive.
rfehr Könntest Du noch mal schauen? Das Paket in Deinem Repo ist vom 11.03
Standardmäßig sollte die native Auflösung des Bildschirms ausgewählt werden, mit 50Hz.
Dann gäbe es einen Schalter "Auflösung automatisch einstellen". Damit würde versucht werden, z.B. bei 720p Material mit 1280x720 auszugeben. Dann kann man den TV skalieren lassen. Damit es nicht zu kompliziert wird, wäre das aber dann für alle Auflösungen. Ich weiß nicht, ob das WAF-tauglich ist, weil sich die Zeiten bis ein Bild kommt, durch das Umschalten des TVs erhöhen werden. Auch die Wiederholfrequenz könnte man anpassen, wenn der input stream da von 50Hz abweicht und das Display es kann. Fallback wäre immer die Standardauflösung.
Es gibt auch interlaced Formate, bei denen ich nicht weiß was sie machen. Deinterlaced der TV dann selbst? Dann müsste man aber den deinterlacer im Plugin dafür abstellen?!
Je mehr ich darüber nachdenke, fehlt mir der Anwendungsfall, die Auflösung tatsächlich manuell zu forcieren. Evtl. könnte man einen "Refresh" einbauen (=Detach+Attach), wenn der VDR woanders angestöpselt wurde. Ein Umschalten zwischen zwei HDMI Ausgängen wäre dann noch ein logischer Zusatzschritt.
Wäre das was?
Ok, verstehe. Mein Vorschlag:
Ja, Du hast Recht. Das Umschalten des TVs kann ein, zwei Sekunden dauern. Aber wer diese Optionen aktiviert, weiss das vermutlich und möchte es genau so.
Das Plugin startet "Vanilla" mit der Auflösung, die der TV mitteilt.
Dann im Setup folgende Einstellungen:
Generelle Einstellung: "Auflösung" und "Bildrate". Hier kann man einstellen, welche Auflösung, Bildrate man haben möchte, z.B. 1920x1080 und 50Hz. Man kann aber auch "automatisch" eingestellt lassen, dass verwendet das Plugin einfach die vom Monitor gemeldete Auflösung und Bildrate.
Schalter "Auflösung/Bildrate an Inhalt anpassen". Wenn das aktiv ist, zwei Optionen dazu: "Auflösung" und "Bildrate". Beides kann man separat aktivieren.
Wenn nur Auflösung aktiv ist, wird immer die Auflösung des Quellenmaterials verwendet, also 576i, 720p, 1080i, 1080o, 2160p etc.
Wenn beides aktiv ist, wird sowohl die Auflösung des Quellenmaterials verwendet als auch die Bilrate des Quellenmaterials, also 50Hz, 24Hz whatever.
Wenn jetzt z.B. bei "Auflösung" und "Bildrate" automatisch eingestellt sind und der Schalter "Auflösung an Inhalt anpassen" mit Auflösung und Bildrate aktiv ist, passiert folgendes:
Ich schaue "ZDF HD". Die Auflösung beträgt 1280x720 und 50Hz. Die Ausgabe erfolgt also in 1280x720 mit 50Hz progressive. Ich schalte um auf "UHD1", die Auflösung wird geändert auf das entsprechend gesendete Format, in diesem Fall also 3840x2160 mit 50Hz.
Setze ich die Auflösung und Bildrate nicht auf automatisch, sondern auf 3840x2160 mit 50Hz, wird bei ZDF HD von 720p auf 4k hochskaliert und dann ausgegeben.
Ich würde immer progressive ausgeben, also mich rein auf die Bildrate beschränken.
rfehr Könntest Du noch mal schauen? Das Paket in Deinem Repo ist vom 11.03
ich schaue mal, baut gerade.
neumann2k Wegen eac3 könntest du das mal testen https://github.com/rellla/vdr-plu…tree/fix-eac3-2 ...
Leider keine Besserung. Das Verhalten ist so: Ich spiele eine UHD Aufzeichnung ab. Ton ist da, ich springe mit gelb nach vorne, Ton ist für 1-2 Sekunden weg, kommt dann aber wieder. Springe nochmal mit gelb, gleiches Verhalten. Springe nochmal mit gelb, Ton kommt aber nicht mehr wieder. Spule nach vorne, Ton ist wieder da. Aber das passiert halt random. Kann auch mal sein, dass der Ton direkt nach dem ersten springen verloren geht. Brauchst du erneute Logs?
Don’t have an account yet? Register yourself now and be a part of our community!
