ivtv + Flackern (PVR250/350)

  • Zitat

    Original von wirbelstoppe 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.


    wie sieht der Code aus? möchte ich auch gerne mal im Vergleich ausprobieren.

    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

  • Wart mal noch n paar Tage, dann leg ich auf meine Seite für dich mal ne geänderte Version hin zum probieren.
    Erst mal kämpfe ih noch mit ner neuen Initailisierung die ivtv defaults lädt.

  • Zitat

    Originally posted by wirbel
    Du kämpfst also (scheinbar) mit nem andrn Effekt. ... Erst ein Reboot des Rechners hilft.


    Sieht so aus. Ich lass meinen VDR deshalb immer morgens einmal neu booten, um sicher zu sein, dass ivtv den Tag über läuft. Dadurch tritt das Problem nicht so häufig auf und ich muss mich nicht über missratene Aufnahmen ärgern.


    Mir ist noch ein Unterschied zwischen ivtv-tune und cPvrDevice::Tune aufgefallen. In pvrinput wird noch 0,5 addiert, um das Ergebnis der Division anders zu runden. ivtv-tune arbeitet einfach nur mit (freq * 16)/1000. Nachdem ich mir mal die Frequenztabellen angesehen habe, gibt es nur ein 9 Ausnahmen bei NTSC US IRC, bei denen die Frequenzen kein Vielfaches von 250 sind. Damit ist die Rundung eigentlich hinfällig, da (freq * 16) immer Vielfache von 1000 liefert (wenn wir schon mal beim Code-Review sind...).

  • Tja, das ist aber auch eher Nebensache. Ich arbeite auch ohne die 0.5


    Hässlicher ist schon, dass original Brightness, Contrast, Saturation, Hue, Audio Volume mit Werten aus dem ivtv hardcodiert sind.

  • Zitat

    Originally posted by wirbel
    Hässlicher ist schon, dass original Brightness, Contrast, Saturation, Hue, Audio Volume mit Werten aus dem ivtv hardcodiert sind.


    Die müsste man sich wohl so holen, in cPvrDevice::cPvrDevice zwischen dem Öffnen des Devices und dem Aufruf der SetXXX-Methoden (SetVideoNorm usw.). Ich hab aber leider noch keinen Compiler, um das mal zu testen.



    bzw. mit


  • Hast du in SetCodec auch schon entsprechende Aufrufe mit VIDIOC_G_MPEGCOMP/VIDIOC_S_MPEGCOMP eingesetzt? Da ist ja auch noch ivtv-Kram drin.


    Meiner Meinung nach müssten die tsBuffer-Aufrufe in cPvrDevice::GetTSPacket noch mit mutex.Lock();/mutex.Unlock(); eingeschlossen werden.

  • *g*


    Ja, so ähnlich sieht das z.Z. bei mir aus. Nicht ganz so, aber fast. Ich setze nur mit default_value, wenn der Wert noch nicht in der setup.conf bekannt war.
    SetCodec(), videodev2.h und ivtv.h hab ich komplett rausgeschmissen und durch die Dinge durch VIDIOC_S_EXT_CTRLS ersetzt. In GetTSPacket muss soweit ichs versteh kein Mutex, aber ich bin eben kein Programmierer der alles versteht.

  • Ich versteh auch nicht alles, da sind wir dann schon zu zweit. :) Ich hätte mal Lust, in deinen Code reinzusehen, sag bescheid, wenn du ihn veröffentlichen willst.


    Der tsBuffer wird ja vom Lesethread gefüllt, dort werden die Zugriffe auch durch die Mutex geschützt, ebenso in cPvrDevice::SetChannelDevice. Deshalb finde ich, sollten zumindest um die tsBuffer->Del-Aufrufe ein Lock, eventuell am Anfang der Methode einfach ein "cMutexLock mutexLock(mutex);". Vielleicht baust du das einfach mal ein und schaust, ob anschließend noch alles läuft... :)

  • Hallo mini73 und Dr.Seltsam:


    Ich leg hier mal (temporär und nur als Diskussionsgrundlage für diesen Thread hier, nicht als offizieller patch..) die Version von pvrinput ab, die ich z.Z. nutze:


    http://free.pages.at/wirbel4vd…l-ivtv-patch-20060922.tgz


    Unterschiede sind


    - angefangene Internationalisierung, d.h. deutsche Übersetzung im Menü
    - VIDIOC_EXT_CTRLS werden verwendet, statt die nicht mehr vorhandenen alten ivtv controls
    - ivtv.h und videodev2.h wurden gelöscht aus dem Paket, damit immer die Version von videodev2.h des linux Systems genommen werden muss
    - die Initialisierung des Plugins erfolgt nun nicht mehr mit festen Werten, sondern alle nicht in der setup.conf des VDR bekannten Werte werden mit den defaults des ivtv Treibers gesetzt
    - beim Umschalten werden nun keine Daten an den VDR gesendet
    - zusätzlich nun auch der median video Filter im Setup Menü.
    - SetCodec(..) entfällt, dafür die Funktionen SetControlValue(..) und QueryAllControls() mit Bereichsüberprüfung der an ivtv gesendeten Werte


    Aber wie gesagt, nur als Diskussionsgrundlage.


    Gruss wirbel

  • au ja, das teste ich gleich mal


    aber ist das sinnvoll:

    Zitat

    Original von wirbel- ivtv.h und videodev2.h wurden gelöscht aus dem Paket, damit immer die Version von videodev2.h des linux Systems genommen werden muss


    was heißt in diesem Fall System? /usr/include/linux oder Kernelsourcen?
    ich denke mal, die meisten Leute werden in /usr/include/linux eine sehr alte Version haben, die zur Distri gehört. Trotzdem läuft ein aktuellerer Kernel oder gar ein separat kompilierter v4l-dvb Treiber. Da findet der Compiler die videodev2.h dann aber nicht.


    Nachdem ich gelesen habe, dass sogar Linus T. ausdrücklich empfiehlt, keinen Link /usr/include/linux auf den entsprechenden Ordner der Kernelsourcen zu legen, lasse ich es nämlich bleiben.


    Da wäre es doch besser, die beueste videodev2.h mit in den Pluginordner zu legen. Wobei dann andererseits Gefahr besteht, dass das Plugin hinterher nicht läuft, weil der installierte Treiber die neuen controls nicht versteht.

    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

  • Na ehrlich gesagt macht es keinen Sinn, eine uralte videodev2.h auf dem Rechner zu haben. Woher soll Software wissen, was dein dein linux Kernel (Treiber) kann, wenn nicht aus deinen includes?


    Und da steht


    #include <linux/videodev2.h>

  • Moin!


    Prima, ich werde mir das Paket mal am Wochenende zu Gemüte führen. Mittlerweile hab ich auf meinem Desktop-Rechner ein ubuntu mit Kernel 2.6.18 und aktuellen v4l+ivtv-Sourcen. Ich hab hier zwar keine PVR drin, aber kompilieren geht zumindest...


    Ich denke auch, dass in dem Plugin-Verzeichnis keine videodev2.h stehen sollte. In der Make.config vom vdr kann man ja ein anderes Includeverzeichnis für die DVB-Treiber angeben. Ich weiß jetzt nur nicht, ob das auch an die Plugins weitergereicht wird. Falls nicht, wäre das vielleicht eine Alternative.


    Ich werde mich am Sonntag wieder melden, jetzt ist bei mir erst mal Feierabend... :)


    mini.

  • Ohne pvr kommst doch aber nicht weit. *g*

  • Ehe ich alle PVRInput-Einträge in der setup.conf von vdr rausgelöscht habe, war das Bild sehr dunkel. Nach Neustart griffen die neuen default-Werte, und alles war o.k. - exzellente Bildqualität!
    Was (noch?) nicht richtig funktioniert, ist die Einstellung von Helligkeit etc. über das vdr-Hauptmenü (PVR picture setting).


    Das Umschalten klappt sauber, habe aber leider nach mehrfachem Hin- und Herschalten


    ivtv0: All encoder MPEG stream buffers are full. Dropping data.
    ivtv0: Cause: the application is not reading fast enough.


    und später:


    Sep 22 21:08:57 linvdr user.debug vdr: [2192] buffer stats: 0 (0%) used
    Sep 22 21:09:00 linvdr user.info kernel: ivtv0 warning: No Free Mailbox for cmd 0x000000da after 100 tries!
    Sep 22 21:09:00 linvdr user.info kernel: ivtv0 warning: Mailbox[0] 0x000000da flags 0x00000003
    Sep 22 21:09:00 linvdr user.info kernel: ivtv0 warning: Mailbox[1] 0x000000dc flags 0x00000003
    Sep 22 21:09:00 linvdr user.info kernel: ivtv0 warning: Mailbox[2] 0x000000da flags 0x00000003
    Sep 22 21:09:00 linvdr user.info kernel: ivtv0 warning: Firmware UNRESPONSIVE when trying cmd 0x000000da!!!


    und nach einem vdr-Neustart:


    Sep 22 21:12:09 linvdr user.info kernel: ivtv0 warning: 1000 ms time out waiting for firmware
    Sep 22 21:12:09 linvdr user.info kernel: ivtv0 warning: Failed api call 0x00000082 with result 0xfffffff0
    Sep 22 21:12:09 linvdr user.info kernel: ivtv0 warning: ENC: Failed stopping capture -16
    ~


    Und wenn ich eine Änderung in den Plugin-Einstellungen abspeichere, passiert oft sowas:


    Sep 22 21:21:46 linvdr user.info vdr: [1413] saved setup to /etc/vdr/setup.conf
    Sep 22 21:21:46 linvdr user.err vdr: [1453] cAudioRepacker(0xC0): skipped 288 bytes to sync on next audio frame
    Sep 22 21:22:00 linvdr user.debug vdr: [1453] buffer usage: 80% (tid=6151)
    Sep 22 21:22:02 linvdr user.debug vdr: [1453] buffer usage: 85% (tid=6151)
    Sep 22 21:22:02 linvdr user.debug vdr: [1453] buffer usage: 90% (tid=6151)
    Sep 22 21:22:03 linvdr user.debug vdr: [1453] buffer usage: 95% (tid=6151)
    Sep 22 21:22:03 linvdr user.debug vdr: [1453] buffer usage: 100% (tid=6151)
    Sep 22 21:22:16 linvdr user.debug vdr: [1453] clearing device because of consecutive poll timeouts
    Sep 22 21:22:16 linvdr user.err vdr: [1423] ERROR: invalid Count in cRingBuffLinear::Del: 1000


    Diese Fehler sind sonst nie aufgetreten.


    Ich werde morgen mal schauen, ob die Probleme dann auch noch auftreten (Kiste läuft schon seit heute morgen unentwegt!) bzw. ob sie weggehen, wenn ich die Änderung beim Umschalten rückgängig mache.


    Kannst Du ggf. mal kurz beschreiben, was


    Zitat

    - beim Umschalten werden nun keine Daten an den VDR gesendet


    bedeutet ? ich werde morgen mal ein diff zu meinen letzten Sourcen machen, aber ob ich das alles verstehe ? :angst

    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
    Ehe ich alle PVRInput-Einträge in der setup.conf von vdr rausgelöscht habe, war das Bild sehr dunkel. Nach Neustart griffen die neuen default-Werte, und alles war o.k. - exzellente Bildqualität!


    Das ist logisch. Es stehen mit dem Patch nicht mehr Prozent Werte für Helligkeit, Farb sättigung etc in der setup.conf, sondern die Werte die ivtv selbst nutzt, also sowas wie 0..255 oder ähnlich.


    Zitat


    Was (noch?) nicht richtig funktioniert, ist die Einstellung von Helligkeit etc. über das vdr-Hauptmenü (PVR picture setting).


    Das Umschalten klappt sauber, habe aber leider nach mehrfachem Hin- und Herschalten


    ivtv0: All encoder MPEG stream buffers are full. Dropping data.
    ivtv0: Cause: the application is not reading fast enough.


    Hier hat sich scheinbar dein ivtv aufgehängt.. Es werden weiter vom ivtv device Daten gelesen. (Eigentlich ein ivtv Fehler: ivtv müsste selbst dann stoppen, wenn seine internen Buffer voll sind. ;) )


    Die Daten werden nur nicht weiter an den VDR gereicht.


    Auch die Message mit der Mailbox und dem Firmware Response sehn so aus.



    Ob du mit dem Diff da weiterkommst - na mal sehn. :)

  • Ach ja, ich glaube der Patch schrottet z.Z. das mit dem Hauptmenue. Aber meiner Meinung nach gehören diese Einstellungen ausschließlich in die Rubrik Plugins und sind eh doppelt, weshalb ich das bei mir rausschmeißen wollte.

  • Zitat

    Original von wirbel


    Ob du mit dem Diff da weiterkommst - na mal sehn. :)


    Junge, Junge, hast Du da rum gewütet :schiel :D


    Das Pausieren des ReadThreads und die retries der ioctls wären aus meiner Sicht die Hauptverdächtigen für die ivtv- und buffer-Probleme. Übrigens habe ich das in einem System mit PVR350 als Ausgabedevice getestet - da kommen also bei jedem Umschaltvorgang noch jede Menge ioctls des pvr350-Plugins dazu ...

    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

  • Versuchs mal nach Neuladen des ivtv, ob das Problem überhaupt bestehn bleibt.


    btw. wär das die Gelegenheit irgendwie mal das pvr350 plugin zu verheiraten..

  • die Probleme treten leider reproduzierbar auch nach reboots auf.


    Wobei die Mailbox-Meldung wohl dann kommt, wenn man den Stream (PS/DVD) wechselt. Vielleicht sollte das nur in die setup.conf geschrieben werden und beim nächsten Pluginstart berücksichtigt werden.


    was das Verheiraten der Plugins angeht: Willst Du vielleicht der Standesbeamte sein? :ausheck

    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

  • Klar geht das mit dem *nur* Speichern. Ich glaub sogar, dass PS genauso gut läuft, das ist eher ein experimentelles Feature um mal auszuloten obs Sinn macht..


    Ich denke für ein sinnvolles Plugin sollten später nur noch Lautstärke, Helligkeit, Sättigung, Farbton, Kontrast und Bildfilter einstellbar sein. Letztere schon optional.


    Hm. Ich nutze ja nur die FF als Ausgabekarte und hab auch nur den TV an der FF (kann nicht umstöpseln) - für mich sehr schwer zu testen.


    Hätte aber handfeste Vorteile: - nur ein device offen, man könnte ein wenig Rücksicht nehmen und evtl. den Videotext elegant durchschleusen.

Jetzt mitmachen!

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