ivtv + Flackern (PVR250/350)

  • Zitat

    Original von samc
    Bei mir bis jetzt kein Flackern, werd nochmal in ein paar Tagen berichten...


    ich habe jetzt beide Änderungen drin, und kann jetzt schon berichten, dass auf zwei Maschinen trotz heftigem Gezappe das Flackern nicht ein einziges Mal mehr aufgetreten ist :]


    Leider funktioniert videotext mit dem neuen ivtv-Treiber nicht mehr, da die benutzten IOC`s "ausradiert" wurden.
    http://www.gossamer-threads.com/lists/ivtv/devel/31635

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • bei mir auch nicht! :]


    Hast Du denn eine logische Erklärung? Dass ein Schließen +Öffnen des devices einen vollständigen reset bewirkt, der ein bereits aufgetretenes Flackern beseitigt, leuchtet mir ja ein. Dass es jetzt aber gar nicht mehr auftritt, muss ja darauf hindeuten, dass irgendwas beim Umschaltvorgang den ivtv-Treiber ohne Patch sonst "reizt".

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Hallo,


    hmm ja, ich beleibe bei meiner Theorie:


    Es tritt auf, wenn das Videosignal (vom Tuner) ungültige Werte annimmt, also Störungen. Und die gibts massenweise beim tunen...


    Grüße,
    Simon

  • Hi,


    also ich habe das Problem auch öfters mal. Ich benutze die PVR250 eigentlich sehr selten, da mein primäres Device die Nexus ist. Wenn ich mal auf die PVR250 ausweichen will (analoges Kabel) kommt es hin und wieder zu Problemen. Ganz selten steht das Bild mal ganz oder es ruckelt komplett oder wie im Thread beschrieben das Flackern. Das sieht fast so aus, wie ein altes VHS Band was nicht ganz in der Spur läuft. Ich beobachte das auch schon seit etlichen Kernel+ivtv Versionen - bisher hat nichts geholfen.


    Konfiguration siehe Sig, aber wie gesagt, das war mit etlichen Konfigurationen vorher auch schon.

  • Zitat

    Original von samc
    Es tritt auf, wenn das Videosignal (vom Tuner) ungültige Werte annimmt, also Störungen. Und die gibts massenweise beim tunen...


    ja, aber dazu sollte doch eigentlich die einstellbare Verzögerung von bis zu 2sec ("WaitAfterTuning") da sein. Aber das nützt leider nichts.


    und warum stört sich der ivtv-Treiber nicht an den Störungen, die durch den Patch auftreten? man sieht ja manchmal beim Umschalten erst noch Reste vom alten Kanal, Artefakte etc.
    der Encoder wird schon gefüttert, noch ehe der neue kanal richtig getunt ist. Auch mit WaitAfterTuning lässt sich das nicht vollständig kompensieren. Aber es führt nie zu Flackern!


    Das Flackern ist übrigens auch kein pvrinput-spezifisches Problem. Beim analogtv-Plugin hatte ich das genauso.


    Wird der Encoder beim Kanalwechsel eigentlich auf Pause gestellt? vielleicht wäre das ein Weg.


    Ich werde auch mal testen, was passiert, wenn man in OpenDrv nicht ReInit() aufruft, sondern nur delete readThread + readThread macht ... vielleicht reicht das ja auch schon.


    Gruß
    Dr. Seltsam

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Zitat

    Original von Dr. Seltsam
    Ich werde auch mal testen, was passiert, wenn man in OpenDrv nicht ReInit() aufruft, sondern nur delete readThread + readThread macht ... vielleicht reicht das ja auch schon.


    nee, das war ein Flop.


    Ich habe jetzt aber eine andere Lösung. Ich rufe ReInit (mit Patch) nicht in OpenDvr, sondern vor dem Tunen auf.

    Code
    bool cPvrDevice::Tune(int freq)
    {
    	ReInit();
    	struct v4l2_frequency vf;


    Das Ergebnis ist ein einwandfreier, sauberer Umschaltvorgang. WaitAfterTuning kann auf 0 gesetzt werden. Scheint genauso wirksam gegen Flackern zu wirken!

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Hallo,


    ja das ganze ist ein bischen ein Mysterium...meine "Vorstellung" ist, dass es beim Tunen bildlich gesprochen sowas wie einen "Peak" gibt. Der stört die Encodersoftware. Das Schließen des Devices stoppt wohl den Encoder und das Öffnen startet ihn neu. Danach passts wieder.


    Wenn meine "Vorstellung" stimmt, dürfte dein neuer Versuch wenigstens manchmal zu Flackern führen, dass nach einem Kanalwechsel aber wieder verschwindet...


    halt mich auf dem laufenden ... :)


    -> sind alles nur Mutmaßungen...


    Grüße,
    Simon

  • Hallo, jetzt melde ich mich auch mal zu Wort ;)
    ich habe das Flackern erst seid ivtv 0.6.0, allerdings sehr selten und es ist zum Glück noch bei keiner Aufnahme aufgetreten.
    Ich habe irexec im hintergrund laufen und eine tastenkombi für vdr neustart etc. - damit löse ich das problem. ivtv muß nicht neugeladen werden.


    Aber noch eine Frage @dr.seltsam - Du hattest mal eine deine sourcen vom pvr350 plugin gepostet, damit ging das spulen bei aufnahmen ohne Verzögerung (ansonsten 1-2sec), dafür war die umschaltzeit beim livetv miserabel ;) Hast Du jetzt eine Version wo beides gut geht?


    mfg

    Server: Seagate Dockstar - Debian Squeeze

    Client: Apple TV 2 / Samsung LExxC650

    OldOne: Debian Etch - Matrox G450 & SkyStar2

  • Zitat

    Original von uzer


    Aber noch eine Frage @dr.seltsam - Du hattest mal eine deine sourcen vom pvr350 plugin gepostet, damit ging das spulen bei aufnahmen ohne Verzögerung (ansonsten 1-2sec), dafür war die umschaltzeit beim livetv miserabel ;) Hast Du jetzt eine Version wo beides gut geht?


    Du glaubst nicht, wie mich das Thema seit Monaten schon beschäftigt. Ich habe auch regelmäßig bei Hans Verkuil und anderen ivtv-Entwicklern nachgebohrt. Aber die leiden alle unter kollektivem Gedächtnisschwund und können das Zustandekommen ihrer eigenen Codepassagen bzw. die exakte Bedeutung mancher ioctls nicht erklären ...


    Fakt ist: mit den ivtv-internen sogenannten Firmware-Api-calls geht das Umschalten sehr fix. Dafür ist das stop-Kommando fehlerhaft, was Du daran merkst, dass beim Beenden der Wiedergabe einer Aufzeichnung diese nach dem schwarz werden des BIldes nochmal wiederkommt und ein paar Sekunden "nachläuft", ehe dann das TV-Bild wiederkommt.
    Nach langem Basteln hatte ich tatsächlich eine Version, bei der die fw-calls nur beim Umschalten benutzt wedren, und IOC_STOP_DECODE beim "Spulen". Es bleib die o.g. Einschränkung beim Beenden einer Wiedergabe.


    Die Freude währte nur kurz, denn kurz darauf fing Hans an, den treiber im Hinblick auf die Integration in den Kernel radikal aufzuräumen. Die fw-api-calls wurden aus dem Code gestrichen. Mein erboster Aufschrei endete mit dem Versprechen, dass er sich die Problematik irgendwann mal in Ruhe anschauen will. Da warte ich jetzt drauf ...


    Status ist bei mir im Moment: Ich habe es mit Hilfe geschafft, sämtliche fw-api-calls durch gültige ioctls zu ersetzen. Es bleibt dabei, dass nach einem IOC_STOP_DECODE und anschließendem IOC_START_DECODE es ca. 4 Sekunden dauert, bis die Buffer voll sind und ein Bild kommt. Ich kann es mir nur so erklären, dass diese Buffer bei den fwapi-calls nicht zum Tragen kommen. Nun bin ich aber alles andere als ein Programmierer und darauf angewiesen, dass sich wirklich kundige Leute des Themas annehmen. Das problem ist, dass offenbar 99 % der ivtv-Entwickler mythtv benutzen und die vdr-Plugins nicht kennen. Die Pluginentwickler wiederum sind längst von der Bildfläche verschwunden und antworten nicht mehr auf emails.
    Möglicher ist auch das ganze Plugin "fehlkonstruiert". Hans Verkuil versteht z.B. gar nicht, warum beim Kanalwechsel der Decoder gestoppt und wieder gestartet wird. Ich haber aber keine idee, wie man es sonst erreicht, dass
    -die Wiedergabe sofort beendet wird
    -ein schwarzes Bild kommt
    -das neue Bild sauber startet

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • Ich habe bei mir das ganze WaitAfterTuning Geraffel komplett rausgeworfen und stoppe nur den LeseThread beim Tunen auf nen andren Sender (also nicht löschen und erst recht nicht das device schließen). Also noch n bissel weiter rumgebastelt. Allerdings nicht erst beim Frequenzwechsel wie es DrSeltsam tut. Funzt prima.


    Fakt ist, dass sich pvrinput also mittlerweile komplett mit den neuen ioctls problemlos betreiben lässt, allerdings sind die merklich langsamer.

  • Moin!


    Ich bin gerade dabei, mich mit dem Source von pvrinput vertraut zu machen. Dabei ist mir nur eine kleine Unstimmigkeit zu der VDR-Plugin-Doku aufgefallen, die wahrscheinlich überhaupt nichts mit dem Flackern zu tun hat.


    In der Doku steht, dass alle Devices in der Initialize()-Methode instantiiert werden sollen, damit andere Plugins während der Start()-Runde darauf zugreifen können. Pvrinput ruft cPvrDevice::Initialize(); allerdings in Start() auf.
    Da ich noch keinen VDR mit aktuellem Kernel habe (mittwochs ist mein Bastelabend, sonst hab ich keine Zeit, und ich muss mir erst mal eine Entwicklungsumgebung bauen), könnte mal jemand ausprobieren, ob es einen negativen Effekt hat, wenn man den Aufruf nach Initialize() verschiebt?
    Oder hat das schon mal jemand ausprobiert?


    mini.

  • cPvrDevice::Initalize(); und cPluginPvrInput::Initialize() ist doch nicht das gleiche.

  • Moin!


    Schon klar, aber in der Plugin-Doku unter "Devices/Initializing new devices" steht:


    Zitat


    A derived cDevice class shall implement a static function in which it determines whether the necessary hardware to run this sort of device is actually present in this machine (or whatever other prerequisites might be important), and then creates as many device objects as necessary. See VDR/dvbdevice.c for the implementation of the cDvbDevice initialize function.


    A plugin that adds devices to a VDR instance shall call this function from its Initialize() function to make sure other plugins that may need to have access to all available devices will see them in their Start() function.


    cPvrDevice::Initialize erstellt die cPvrDevice-Objekte. Laut Doku sollte die also in cPluginPvrInput::Initialize aufgerufen werden und nicht in cPluginPvrInput::Start. Das meinte ich.


    mini.

  • Dann müsstest du konsequenterweise auch cPvrDevice::cPvrDevice komplett ändern, da ein Plugin ja erst bei Start 'loslaufen' soll. Denk ich zumindest.

  • Das könnte sein, vermutlich indem man eine entsprechende Start-Methode implementiert, die dann aufgerufen wird. Ist vermutlich auch nicht so wichtig, da kein anderes Plugin auf pvrinput zugreift, oder? Ist letztendlich auch nur eine Fleißübung, die kann auf später verschoben werden.


    Andere Sache:
    Vielleicht könnte man das Anhalten des Lesethreads von dir und das ReInit von Dr. Seltsam kombinieren, indem man in SetChannelDevice (das ist doch die Methode, die vom PVR beim Tunen aufgerufen wird, richtig?) den Lesethread anhält, tunt, anschließend einen ReInit ausführt (das würde ich logischer finde als vor dem Frequenzwechsel) und dann den Thread weiterlaufen lässt?
    Falls der ReInit zu lange braucht, könnte vielleicht auch ein SetCodec und SetInput reichen. Mir ist allerdings noch nicht ganz klar, was diese Methoden bei ivtv auslösen, den ivtv-Source hab ich mir noch nicht angetan.


    mini.

  • Wozu sollte ich noch Reinit() ausführen? Hm?

  • D.h. durch das Pausieren des Lesethreads beim Umschalten kannst du ein aufgetretenes Flackern beseitigen?


    Zusätzlich kommt bei mir das Flackern nicht nur beim Umschalten (ehrlich gesagt ist es dabei bei mir noch nie aufgetreten), sondern manchmal einfach mal so zwischendurch. Und da ich ein noch etwas ältere ivtv-Version am Laufen habe, kann ich es durch ein Umschalten beheben. Das hilft zwar nicht während einer Aufnahme, aber vor einer Aufnahme kann ich durch einen kurzen Timer auf einem anderen Kanal dafür sorgen, dass die eigentliche Aufnahme vernünftig startet.

  • Dann wäre es bei dir auch prinzipiell nicht mit ReInit() zu beseitigen. Bei mir lässt es sich mit nem ungepatchten pvrinput durch Umschalten provozieren. Mit der gepatchten Variante lässt sich das nicht mehr auf meinem Rechner reproduzieren. Du kämpfst also (scheinbar) mit nem andrn Effekt.


    Was mit beiden Versionen auftritt ist, dass sich von Zeit zu Zeit ivtv 'aufhängt' Firmware Aufrufe gehn dann nicht mehr, selbst ein Neuladen des Treibers hilft nicht. Erst ein Reboot des Rechners hilft. Das scheint ein ivtv Prob zu sein, war früher nicht so.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!