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.
Ich mache keine Stimmung, Ich spreche Probleme an.
Selbstgemachte Probleme? Andere Leute suchen Loesungen. Kein weiterer Kommentar.
S:oren
Es wir von vdr geparsed
Nicht bei Live-TV und nicht bei Wiedergabe.
Das ist doppelte Arbeit.
Somit nicht. Und hat exakt nichts mit dem hier im Thread beschriebenen Problem zu tun.
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.
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
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
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.
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
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
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
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
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...
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
Hm. Was hat ein ddbridge-Problem mit dem saa716x-Treiber zu tun?
Gruss,
S:oren
Die letzte Antwort bezog sich auf den vorletzten Post (den letzten hatte ich verpasst), aber das ist trotzdem alles klar geworden, denke ich. Gerne auch mit dem 400kHz-Takt noch testen.
Ergibt sich da gefuehlt ein Unterschied in der Umschaltzeit der Sender? Mir kommt die Verbesserung von dem alten Stand auf die 5.16er Version größer vor als dann der Schritt mit dem I2C-Fastmode. Probleme gab es damit aber auch nicht. Ich hatte das so vorher schon immer mal mitlaufen...
Gruss,
S:oren
Das ist fuer mich erstmal kein Problem, ich habe die 5.17er Version bei mir jetzt laufen. Die ist etwas aufgeraeumter, z.B. wenn man sie fuer aeltere Versionen backportieren will. Ansonsten ist bei 5.16 alles gleich, bis auf die Takterhöhung im letzten Commit (das koenntest Du auch mit 5.16 ausprobieren, ist ja nur eine Ziffer zu aendern).
Im Moment gibt es fuer 5.17 nur den test-Branch. Ein bisschen unabhaengiges Testen ist sicher gut. Aber ich blicke auch nicht so ganz durch, ob irgendwer hier noch ein Problem damit hat oder eine andere Loesung gewuenscht ist. Jedenfalls sind gegenueber der alten Treiberversion einige Sachen verbessert, die durchaus fuer mich Sinn ergeben. Aber wie man gesehen hat, koennen bei mehr Testern auch mehr Probleme auftreten.
Gruss,
S:oren
Ich habe jetzt noch einen 5.17-test-Branch eingecheckt. Ich hoffe, das ergibt alles so Sinn, ist schon recht frueh heute morgen...
Gruss,
S:oren
Nochmal: Hier geht es nur um den Controller- (Master) Treiber im saa716x. Im Target-Treiber fuer einen EEPROM oder Demod oder was-auch-immer wuerde ich natuerlich Transfers wiederholen, die fehlgeschlagen sind. Oder irgendwas machen, was dieser Chip so erfordert.
Aber das ist nicht der Job des Master-Treibers, der schreibt einfach nur die Bytes auf den Bus, wie es ein anderer Treiber angefordert hat. Auch die eingebaute Wartezeit gehoert da eigentlich nicht hin (wie es auch in dem Commit steht). Aber diese Wartezeit ist immer noch schneller als irgendeine Wiederholung, und so eine Wartezeit laesst sich nicht mit dem bestehenden I2C-API im Linux-Kernel anfordern. Es ist halt ein Hack, der gut funktioniert. Und hoffentlich auch mit den ganzen saa716x-Budget-Karten, die unterstuetzt bleiben muessen und die ich nicht testen kann, weil ich sie nicht habe.
In dem jetzigen Treiberstand wird (im Gegensatz zu vorher) auf das Ende eines kompletten Transfers (mit STOP) gewartet. Nur auf das Ende einer Message (vor dem Repeated-START) kann nicht präzise gewartet werden.
Gibt es irgendein Problem, das noch gefixt werden muesste, oder ist das ganze hier eine Diskussion "im luftleeren Raum" fuer langweilige Stunden (die ich nicht kenne)?
Gruss,
S:oren
Auch mit fix5 bisher keine Auffälligkeiten.
OK, danke!
Ich habe den aktuellen Stand der Treiberimplementierung in den 5.16er Branch gepusht. Hier doch nur als zusaetzliche Patches. Fuer Leute, die nur einen Gesamtpatch erzeugen, ist es egal. Fuer die, die den Git-Branch pullen, braucht es kein force.
Die NACK-Meldung ist jetzt wieder eine normale Debug-Message, ein echter Fehler ist es ja nicht. Fuer i2cdetect ist es ja ganz normales Verhalten.
Falls es mit diesem Stand erstmal keine Probleme mehr gibt, werde ich das (am Wochenende?) auch fuer 5.15 und 5.17 anpassen.
Gruss,
S:oren
Was soll ich hier dazu sagen?
Im Prinzip hoere ich mir gerne neue Ideen und Vorschlaege fuer bessere Workarounds an. Am liebsten Ideen, wie man etwas sauber ohne Workarounds implementieren kann. Wenn jemand hier selbst irgendwas ausprobieren will, gerne. Ist alles Open-Source-Code.
Ich kenne EEPROMs, wo man zum Feststellen des erfolgten Schreibens solange Lesen muss, bis die Schreibdaten wieder gelesen werden (und nicht Daten mit invertiertem unteren Bit, aber immer mit ACK). Das ist alles fuer einen Target-Device-Treiber schoen und wichtig, fuer den hier diskutierten Controller-Treiber eher nicht.
War Dein Vorschlag, lieber keine Quirks fuer merkwuerdige Target-Devices oder deren Treiber hier einzubauen? Von mir aus gerne. Hast Du Patches oder zumindest konkrete Ideen, das anders besser zu loesen? Der vorliegende Status quo versucht die Probleme der alten saa716x_i2c-Implementierung (unendliche read transfer errors, selten) zu loesen, ohne neue Probleme zu schaffen. Eine große bessere Loesung soll mir recht sein. Hilfe jederzeit willkommen.
Ich habe schon vor Jahrzehnten mit Philips Semiconductor in einem Chipdesignprojekt zusammengearbeitet und arbeite immer noch mit Kollegen zusammen, die noch mehr und laenger fuer Philips Hardware implementiert haben. Ich kann mir sehr gut vorstellen, dass alles so schlimm ist wie es aussieht. Ich habe ein Datenblatt und ein UserManual fuer den SAA7160, die sind leider nicht so ausfuehrlich und hilfreich, wie man sich wuenschen wuerde. Aber ich bin mir ziemlich sicher, dort nicht ein Status-Bit uebersehen zu haben. Was nicht heißen muss, dass es das nicht doch gibt und nur nicht dokumentiert ist (oder ich mittlerweile alt und senil bin).
Ich bin auch der Meining, dass man nicht alles machen muss, was prinzipiell erlaubt ist, sondern moeglichst alles so macht, wie die meisten anderen. Dann ist die Chance am groessten, dass alles kompatibel ist. Aus diesem Grund habe ich STOP-Bits dort eingebaut, wo sie hingehoeren, und keine wo man ueblicherweise keine hat.
Gruss,
S:oren
