Posts by S:oren

Quote from S:oren

Habe gerade nochmal kurz in den Code geschaut, dvbhddevice hat tatsaechlich zwei verschiedene OSD-Implementierungen, die aber beide hardware-gerendert werden.

Wenn man etwas laenger hinschaut, sieht man, dass das TrueColor-OSD eigentlich komplett vom VDR intern gerendert wird. Das dvbhddevice nimmt die VDR-gerenderten Pixmaps, konvertiert die ggf. von ARGB8888 in ARGB8565 oder ARGB4444 (je nach Einstellung im Setup), teilt das Ergebnis ggf. auf (weil die Buffer-Maximalgröße fuer einen Treiberaufruf 1MByte betraegt), und schickt das auf die Karte. Das Hardware-Rendering beschraenkt sich dann auf das Zusammenkopieren der Teile.

Quote from kamel5

Ich habe jetzt als aktuelle Lösung ein zusätzliches Lock() Unlock() Paar vor die Animationsschleife gesetzt.

Das LOCK_PIXMAPS ist wirklich nur ein Mutex. Ja, das wird beim Flush im dvbhddevice gelockt. Aber wenn das zu Verzögerungen führt, dass muss ja ein anderer Thread auch gerade ein Lock auf dem Mutex haben. Aber welcher Thread sollte das sein, wenn nur ein einziger Thread sich mit dem OSD befasst?

Gruss,

S:oren

Quote from kamel5

Übrigens habe ich gerade festgestellt, das die Zeit auch vom Farbformat abhängt, bei ARGB4444:

1080: skinnopacity: First Flush(): 336 ms

720: skinnopacity: First Flush(): 150 ms

Schon sehr seltsam.

Bei ARGB4444 gehen ja nur halb so viele Daten ueber den Bus wie bei ARGB8888.

Habe gerade nochmal kurz in den Code geschaut, dvbhddevice hat tatsaechlich zwei verschiedene OSD-Implementierungen, die aber beide hardware-gerendert werden. Das hatte ich anders in Erinnerung.

Waere nochmal interessant, ob Software-Rendering bei modernen Mehrkernprozessoren nicht schneller ist. Wenn ich mal viel Zeit habe...

Gruss,

S:oren

Quote from kamel5

Schon seltsam, ich würde es trotzdem aber erst einmal darauf beruhen lassen.

Die OSD-Größe "Folge Auflösung" scheint nicht (immer?) richtig zu funktionieren. Wenn ich die fest auf 1920x1080 stelle, dann sehe ich auch größere Zeiten (~745ms). Dann war das doch nur eine Einstellungssache bei mir, sorry.

Ist das OSD bei Dir schärfer (bunter, hübscher) mit 1080er als mit 720er Auflösung? Ich habe hier an meinem Test-VDR eh nur einen alten Fernseher mit 720er Panel, da sehe ich (bis auf "Geometriebesonderheiten" bei der Darstellung / Logogröße) keinen Unterschied. Ist aber tatsächlich deutlich langsamer.

Gruß,

Sören

Quote from kamel5

Du hattest irgendwo mal geschrieben, das Du ein 720p OSD benutzt, dann wäre das erklärbar, denn es hängt von der OSD Größe ab.

Jetzt mal mit 1080i probiert: 308 bis 325 ms.

Dann wieder mit 720p: 301 bis 331 ms.

Die Größenordnung bleibt.

Gruß,

Sören

Quote from kamel5

Anbei mal ein Patch für die Kanalanzeige, der die Zeit vom ersten Flush misst. Animation dabei global aus.

Bei mir sieht das dann so aus:

Mai 02 14:49:08 vdr[364594]: [364594] skinnopacity: First Flush(): 626 ms

Bei mir

May 2 20:33:33 rockpro64 vdr: [1547] skinnopacity: First Flush(): 331 ms

Diese Drittel-Sekunde (329 - 334 ms in 10 Versuchen) hatte ich bisher als normal und unvermeidbar angesehen - auf einem RockPro64 (arm64) und der S2-6400 hinter einem PCIe-Switch (PCI bridge: ASMedia Technology Inc. Device 1182).

Ob es sich bei den Zeiten lohnt, da bei mir weiter zu suchen?

Gruss,

S:oren

Danke fuer's Fixen.

Quote from kamel5

- Im breiten Aufzeichnungsmenü gibt es ja nur eine Zeile und es werden auch keine Fehler angezeigt, nur das "!".

Ich sollte diese beiden Menüpunkte dann auch nur anzeigen, wenn "Schmales Menü" eingestellt ist.

Oder habe ich da noch was falsch verstanden?

Dann habe ich das falsch verstanden. Ja, es gibt das "!", das ist auch richtig so. In den Details zur Aufnahme stehen dann die Anzahl Fehler, aber das soll vermutlich nicht abschaltbar sein. Da habe ich die beiden Menues vermutlich verwechselt.

Wenn diese Einstellungen nicht angezeigt werden, wenn sie keinen Unterschied ergeben, dann wäre das wahrscheinlich weniger verwirrend.

Quote from kamel5

- Das Kanallogo ist jetzt in der Lage konfigurierbar "Vertikale Ausrichtung" -> unten, mittig, oben.

Wenn Du hier beim Default-Theme "unten" einstellst, sollte sich gegenüber dem alten Branch nichts verändert haben (die Berechnung der Lage ist dann die Selbe).

Ich habe das wie vorher auf "unten" stehen. Der Logohintergrund ist jetzt eine(?) Zeile höher und der Radius von dem Logohintergrund oben-links hat dadurch einen anderen Mittelpunkt wie der Radius der Fensterbegrenzung daneben. Nur oben-links passt es nicht (etwas zu hoch), unten-links passt es , rechts faellt es ggf. nicht auf. Ich hoffe, das ist halbwegs verständlich erklärt. Muss ich sonst selber irgendwann debuggen, haengt vielleicht auch von den eingestellten Raendern usw. ab.

Quote from kamel5

Es geht hier um jedes neue OSD (osd = CreateOsd()), genauer den ersten Flush() .

Da muesste ich jetzt nachschauen, wann man ein CreateOSD aufruft. Jedes Mal, wenn man ein OSD-Fenster oeffnet? Vermutlich schon, weil ja die Größe immer anders ist. Bei meinen Versuchen schien es mir, dass nach dem Senderwechsel der erste Aufruf etwas langsamer ist, aber das kommt vermutlich von der Abfrage von EPG und Timern und hat nichts mit Deinem Problem zu tun.

Quote from kamel5

Diese erste Verzögerungszeit ist außerdem abhängig von der OSD Größe und nicht skinnopacity spezifisch, tritt allerdings nicht bei Nutzung eines anderen Ausgabeplugin auf. Dadurch schließe ich den Core-VDR ursächlich aus, und wenn man davon ausgeht, das auch die TT6400 selbst nicht Ursache ist, bleibt nur noch das dvbhddevice-Plugin übrig.

Das Debuggen des dvbhddevice-Plugin übersteigt aber im Moment meine Möglichkeiten.

Hm, wuerde ich mir schon genauer ansehen, nur habe ich diesen Effekt bei mir nicht. Bei mir gibt es keine "Gedenksekunde", oder ich merke es nicht.

Hast Du irgendwo den Patch zum Anzeigen der Verzoegerung? Am besten bei abgeschaltetem Einblendeffekt und ohne Threads, das kann ich aber sonst auch Einschalten, wo ich jetzt den selben Branch verwende. Vielleicht ist es doch ein Effekt durch die "verbotenen" Thread-OSD-Zugriffe!?

Gruss,

S:oren

Quote from kamel5

nachdem es hier schon länger scheinbar keine akuten Probleme gibt, habe ich den letzten Stand mal zu Version 1.1.10 gemacht.

Vielen Dank fuer die neue Version!

Wie vor fast einem Jahr versprochen (auweia!), bin ich jetzt auf den neuen master-Branch umgestiegen (von 1.0.9 auf 1.1.10).
Sieht insgesamt alles gut aus, soweit ich heute getestet habe.

Folgende Kleinigkeiten sind mir noch aufgefallen:

- typo im Kanalwechsel-Menue-Setup: Schriftgr_ä_ße bei den letzten beiden Eintraegen

- mit breitem Aufzeichnungsmenue scheinen die Einstellungen fuer die Fehleranzeige nicht zu wirken (0 Fehler anzeigen aus, 2./3. Zeile ??)

- Der Kanallogo-Hintergrund im Kanalwechselmenue sitzt bei mir jetzt minimal zu hoch. Das kann doch eigentlich nichts mit der neuen Logogröße zu tun haben!? Eher mit dem anderen Branch?

Diese Sache war noch nicht wirklich geklaert:

Quote from kamel5

Noch was TT6400 spezifisches bzgl. Animation:

Das erste cPixmap::Lock() dauert gegenüber anderen Ausgabewegen unverhältnismäßig lange. Das erschließt sich mir nicht ganz, da an dieser Stelle die Hardware der TT6400 ja noch nicht beteiligt sein sollte. Alle nachfolgenden cPixmap::Lock() sind dann unauffällig. Möglicherweise liegt das am dvbhddevice Plugin.

Hieß das, die erste Ausgabe nach dem Start des VDR, oder nach jedem Kanalwechsel? Gab es da noch eine Idee, an welcher Abfrage von anzuzeigenden Details das liegt?

Gruss,

S:oren

Quote from zillerbaer

VDR schickt aus dem Bitstream Packete an PlayVideo/PlayAudio. Ohne den Bitstream zu Parsen geht das gar nicht!

Du moechtest ueber steinalte PES-Aufnahmen diskutieren? Wirklich?
Relevant ist heute doch eher PlayTsVideo/PlayTsAudio. Und da geht es eben um TS-Pakete als die relevante Granularitaet des Bitstroms.

Quote from zillerbaer

Ich mache keine Stimmung, Ich spreche Probleme an.

Selbstgemachte Probleme? Andere Leute suchen Loesungen. Kein weiterer Kommentar.

S:oren

Quote from zillerbaer

Es wir von vdr geparsed

Nicht bei Live-TV und nicht bei Wiedergabe.

Quote from zillerbaer

Das ist doppelte Arbeit.

Somit nicht. Und hat exakt nichts mit dem hier im Thread beschriebenen Problem zu tun.

Quote from zillerbaer

Der Bitstream wird von vdr in Blöcke geschnitten die unlogisch sind.

Der DVB-Bitstrom ist zunaechst mal ein "unendlicher" Strom von Bits (TS-Paketen). Und wird so vom vdr behandelt.

Quote from zillerbaer

Ich vermute Beschränkungen die von den FF Karten kommen

Und das ist genau falsch. Bei den FF-Karten parst die Hardware alles selbst, was fuer die Dekodierung noetig ist. Der VDR hat einfach nichts damit zu tun. Der VDR parst nur beim Aufnehmen, um spaeter in der Aufnahme verzoegerungsfrei springen zu koennen. Nicht mehr, nicht weniger. Das Prinzip einer FF-Karte ist gerade, den Bitstrom vom Demod zu nehmen und direkt in den Dekoder zu schicken (ggf. mit Umweg ueber die Festplatte, aber das ist dem Dekoder egal).

Wenn Dir der VDR-Parser so gut gefaellt, dann binde ihn doch in Dein Ausgabeplugin ein. Ergibt mehr Sinn, als den Core-VDR z.B. bei Live-TV irgendwas parsen zu lassen, was spaeter vom Ausgabeplugin gar nicht benoetigt wird. Das VDR-Design ist hier doch klar: eine minimale Schnittstelle zwischen Core und Ausgabeplugins. Wenn fuer die Ausgabe irgendwas geparst werden muss, dann im Plugin. Der Core macht da nichts, weil es sowieso nicht fuer alle Ausgabeplugins identisch sein kann.

Ja, ein Ausgabe- und Dekoder-Plugin ist nicht trivial. Besonders aergerlich, wenn die eigentliche Dekoder-Hardwaere auch (fast) so viel selbst koennte wie die FF-Karten, aber die ach-so-tollen stateless v4l2-m4m-Treiber die Funktionalitaet nicht weitergeben. Aber das doch kein Grund, hier Stimmung gegen den Core-VDR und FF-Karten zu machen, auf Basis von aus der Luft gegriffenen Vermutungen. Zumal das nichts mit dem Problem aus dem Thread zu tun hat.

Gruss,

S:oren

Quote from kamel5

Das Du im dvbhddevice-Setup nur bis 1080i umschalten kannst, liegt wahrscheinlich daran, das das die in Deutschland damals gängigen Formate waren.

Insbesondere sind das die Formate, die man zum Hochskalieren von SD-Material bei bei hoeher aufgeloestem OSD einstellen kann. Die eingestellte Aufloesung an sich ist dann das, was auch das OSD an Auflösung hat. Das i ist eher ein dezenter Hinweis, dass man nicht auf 1080p bestehen darf.

Die Framerate kommt immer aus dem Video-Datenstrom, unabhaengig von der Setup-Einstellung. Der HDMI-Ausgang hat einen maximalen Pixeltakt (74.25MHz), der fuer 720p60, 1080i60 bzw. 1080p30 reicht. 1080p gibt es also bei der 1080er Einstellung, wenn die Framerate klein genug ist, sonst 1080i.

Gruss,

S:oren

Quote from zillerbaer

VDR krankt mir zu sehr an der alten FF! Leider ist unsere alte Community nicht in der Lage VDR zu modernisieren.

Habe in dem ganzen Thread nicht gelesen, dass irgendwer hier sich ueber dieses Problem mit der alten FF beschwert haette. Eigentlich steht fast nie dabei, welches Ausgabeplugin verwendet wird, vermutlich ueberwiegend Soft-Devices. Und dort hat das Ausgabeplugin doch alle Freiheiten, den Bitstrom komplett vom vdr entgegen zu nehmen, ggf. zu parsen und die Wiedergabe korrekt zu beenden. Ein guter Platz fuer moderne Ideen.

Quote from FireFly

Bei mir tritt es mit der TT S2-6400 Full-Featured-Karte bei HD-Aufnahmen auf, SD habe ich nicht getestet.

Das ist in der Tat ein Problem, (auch?) auf der S2-6400. Dort ist es jedenfalls nicht trivial, fuer Bitraten von z.T. unterhalb 1 MBit/s bis ueber 15 MBit/s sinnvolle Buffergrößen und Transferchunks einzustellen. Zumal der Audio/Video-Versatz im Transportstream total verschieden ist und im Treiber nicht sinnvoll behandelt werden kann (OK, hat noch niemand versucht, Freiwillige vor).

Das größte Problem ist vermutlich, dass entweder am Ende Audio-Daten fehlen (Schnitt) oder zu spaet im Transportstream stehen (Remux), so dass sie am Ende in einem halbvollen Buffer liegen und nicht weitergeleitet werden. Der Dekoder wartet auf Audio-Daten fuer die A/V-Synchronisation, der VDR wartet auf die Ausgabe der letzten Bilder. Oder der Video-Dekoder wartet wegen Vorwärtsreferenzen auf Bilder, die nicht mehr kommen und kommt dadurch mit der Audiosynchronisation durcheinander, schwer zu debuggen auf einer FF-Karte.

Ja, das war 'frueher' einfacher, als es nur MPEG2 mit einfacher GOP-Struktur und niedrigeren Bitraten fuer DVB gab. Mit den FF-Karten an sich (oder mit Anpassungen des Core-VDR dafuer) hat das meiner Ansicht nach nichts zu tun (Ich waere natuerlich trotzdem froh, wenn jemand einen einfachen Fix findet.).

Gruss,

S:oren

Hab den Treiber fuer die Kernelversionen 5.15 bis 5.17 auf den gleichen neuen Stand gebracht.

5.15 habe ich noch kurz getestet. Ein Backport der I2C-Anpassungen fuer aeltere Kernelversionen ist sicher moeglich, wenn sich ein Tester findet...

Gruss,

S:oren

Hallo kamel5 ,

auch bei mir habe ich in der letzten Woche keine Probleme mehr feststellen koennen. Ich habe auch ein gutes Gefuehl mit diesem Code. Somit waere es fuer mich absolut OK, das im Titel als erledigt zu betrachten. War ja letztendlich ein bei Dir aufgetretenes Problem, was hoffentlich geloest werden konnte.

Offene Punkte sind fuer mich:

Sollte der Fastmode auch fuer 5.16 mit eingecheckt werden? Ist ja einigermaßen gut getestet.

Sollte man nochmal versuchen, wieder Interrupts zu nutzen, um die usleeps zumindest fuer writes loszuwerden? Hauptproblem hier (neben der Zeit fuer die Implementierung) ist der Test mit Budget-Karten. Da der Treiber jetzt ja schon recht "willig" reagiert, ist der Nutzen vielleicht nicht so groß, dass sich das lohnt.

Was ist mit 5.17? Wann kann das jemand außer mir testen? Wann kann das -test aus dem Branch gestrichen werden?

Gruss,

S:oren

Quote from mauerspecht

Ich habe die .config vom saa761x-5.17-test Kernel genommen und in das Quellverzeichnis vom Gentoo bzw. Vanilla Kernel kopiert.

Wenn das nicht der _selbe_ Kernel ist, dann wird das nicht funktionieren. Jedenfalls nicht zuverlaessig und irgendwie zu debuggen.

Ein paar Beitraege weiter oben steht, dass Gentoo einen (alten) saa716x-Treiber hat. Also sollte man fuer Gentoo wohl den verwenden.

Ich jedenfalls kann keinen Support fuer einen Mix verschiedener Kernel leisten, und auch dieser Thread hat eigentlich nichts damit zu tun. Das war's von mir zu diesem Thema.

Gruss,

S:oren

Quote from S:oren

Ich habe auch keine Idee, wieso sich Aenderungen am I2C-Controller des saa716x-Treibers auf eine Digital Devices v7 auswirken sollten.

Außer vielleicht, dass doch nicht beide Treiber (und dvb-core) aus den selben Sourcen mit identischer config gebaut wurden...

Gruß,

Sören

Quote from md_berlin

S:oren Ich benutze https://packages.gentoo.org/pa…/media-tv/v4l-dvb-saa716x

Das ist https://bitbucket.org/powARman/v4l-dvb-saa716x plus ein paar Patche damit es sich mit aktuellen kerneln compilieren lässt.

Wenn bei Gentoo der alte Stand besser funktioniert, oder zumindest nicht schlechter, dann ist ja gut.

Da Sachen wie "import fixes from https://github.com/s-moch/linux-saa716x" hinein zu packen, statt gleich meinen Treiber zu nehmen, ist bestimmt eine gute Idee, um Entwicklungs- und Testressourcen zu buendeln und effektiv zu nutzen. Aber ja, die Lizenz erlaubt das.

Gruss,

S:oren

Quote from mauerspecht

Ich habe in dem System eine tt6400 als Ausgabedevice und eine Digital Devices v7 mit Erweiterung zum Empfangen, somit brauche ich beide Treiber.

Mit einem Vanilla 5.17.0 wird die Digital Devices Karte und das Erweiterungsmodul erkannt wie auch mit dem Gentoo 5.17.0, aber damit habe ich keinen Treiber für die Ausgabe.

So ein Setup kann ich nicht testen. Ich habe auch keine Idee, wieso sich Aenderungen am I2C-Controller des saa716x-Treibers auf eine Digital Devices v7 auswirken sollten.

Gruss,

S:oren

Du nutzt eine S2-6400 mit 5.16er Kernel ohne meinen Treiber?

https://github.com/s-moch/linux-saa716x

Gruss,

S:oren

Was soll denn ein unbenutzter saa716x-Treiber fuer eine voellig unabhaengige ddbridge-Karte kaputt machen?

Vielleicht hat ja Gentoo irgendwas gefixt, was an dem mainline-ddbridge kaputt ist? Aber heh, ich weiss es nicht. Kannst ja mal ein git bisect versuchen. Wuerde empfehlen, erstmal mit vanilla-5.17 zu starten.

Gruss,

S:oren

PS: Ist vielleicht nicht ganz fair, diesen Thread fuer ein komplett anderes Thema zu hijacken...

Quote from S:oren

Nochmal: Hier geht es nur um den Controller- (Master) Treiber im saa716x.

Vielleicht haette ich besser schreiben sollen: _Mir_ geht es hier nur um den Master-Treiber. Andere Lösungen wuerde ich unterstuetzen, aber nicht selbst bauen.

Gruss,

S:oren