Posts by mini73

Dr. Seltsam
Nur die PVR150 in meinem VDR. Vielleicht finde ich heute Zeit, da einen neuen Kernel einzuspielen. Momentan muss ich nicht so viele Sachen aufnehmen, da kann er mal einen Tag ausfallen.
Sollte ich eine bestimmte gcc-Version benutzen und muss ich sonst noch was beachten (glibc o.ä.)?

wirbel
So hab ich deinen Code auch interpretiert. Ich kenn mich mit den Innereien von Transport- und Programm-Stream nicht so richtig aus, aber wäre es vielleicht ein Idee, ein korrektes TS-Paket mit schwarzem Bild und ohne Ton an den VDR weiterzureichen, solange der Lesethread im Pause-Modus ist? ivtv kriegt ja von der Pause nichts mit, weil die Daten einfach weiter ausgelesen werden, und der VDR würde dann auch nichts merken. Oder stört es den VDR nicht, wenn er keine Daten mehr kriegt?

Moin!

Wenn in SetChannelDevice ein Fehler passiert, z.B. bei SetVideoNorm usw., bleibt der Lesethread im Pause-Modus. Ist das Absicht oder sollte der Thread wieder das Signal zum Weiterlaufen bekommen?
Vermutlich ist es aber besser, wenn er nicht weiter versucht, Daten zu dekodieren, dass könnte ja sonst was für Müll sein, wenn der Kanal nur halb umgeschaltet wird. Er holt ja trotzdem weiter Daten vom Treiber, so dass es dem ja egal ist, was damit passiert.

Ich versuch mal, meinen VDR mit einem neuen Kernel zu versorgen, damit ich das Plugin auch mal testen kann.

mini.

zu videodev2.h:

Das Makefile im Plugin-Verzeichnis liest die Make.config aus dem VDR-Verzeichnis. Wenn man da also DVBDIR auf den richtigen Wert setzt, wird die richtige Datei eingebunden. Also kann es (meiner Meinung nach) problemlos aus dem Plugin-Verzeichnis wegfallen.

mini
Nachtrag:
In der Make.config sollte man absolute Pfade angeben, sonst taugt das nicht... Das Beispiel "../DVB" leitet da einen in die Irre. Denn vom Plugin-Verzeichnis aus sieht die Welt ja anders aus.

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.

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...

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.

Quote

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.

struct v4l2_queryctrl queryctrl;
 memset (&queryctrl, 0, sizeof(queryctrl));
 queryctrl.id = V4L2_CID_BRIGHTNESS;
 if (IOCTL(video_fd, VIDIOC_QUERYCTRL, &queryctrl) != -1)
  PvrSetup.Brightness = queryctrl.default_value;


 memset (&queryctrl, 0, sizeof(queryctrl));
 queryctrl.id = V4L2_CID_CONTRAST;
 if (IOCTL(video_fd, VIDIOC_QUERYCTRL, &queryctrl) != -1)
  PvrSetup.Contrast = queryctrl.default_value;


 memset (&queryctrl, 0, sizeof(queryctrl));
 queryctrl.id = V4L2_CID_SATURATION;
 if (IOCTL(video_fd, VIDIOC_QUERYCTRL, &queryctrl) != -1)
  PvrSetup.Saturation = queryctrl.default_value;


 memset (&queryctrl, 0, sizeof(queryctrl));
 queryctrl.id = V4L2_CID_HUE;
 if (IOCTL(video_fd, VIDIOC_QUERYCTRL, &queryctrl) != -1)
  PvrSetup.Hue = queryctrl.default_value;


 memset (&queryctrl, 0, sizeof(queryctrl));
 queryctrl.id = V4L2_CID_AUDIO_VOLUME;
 if (IOCTL(video_fd, VIDIOC_QUERYCTRL, &queryctrl) != -1)
  PvrSetup.AudioVolume = queryctrl.default_value;

bzw. mit

struct v4l2_control control;
 memset (&control, 0, sizeof(control));
 control.id = V4L2_CID_BRIGHTNESS;
 if (IOCTL(video_fd, VIDIOC_G_CTRL, &control) != -1)
  PvrSetup.Brightness = control.value;


 memset (&control, 0, sizeof(control));
 queryctrl.id = V4L2_CID_CONTRAST;
 if (IOCTL(video_fd, VIDIOC_G_CTRL, &control) != -1)
  PvrSetup.Contrast = control.value;


 memset (&control, 0, sizeof(control));
 queryctrl.id = V4L2_CID_SATURATION;
 if (IOCTL(video_fd, VIDIOC_G_CTRL, &control) != -1)
  PvrSetup.Saturation = control.value;


 memset (&control, 0, sizeof(control));
 queryctrl.id = V4L2_CID_HUE;
 if (IOCTL(video_fd, VIDIOC_G_CTRL, &control) != -1)
  PvrSetup.Hue = control.value;


 memset (&control, 0, sizeof(control));
 queryctrl.id = V4L2_CID_AUDIO_VOLUME;
 if (IOCTL(video_fd, VIDIOC_G_CTRL, &control) != -1)
  PvrSetup.AudioVolume = control.value;

Quote

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...).

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.

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.

Moin!

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

Quote

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.

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.

Moin!

Ich kann zwar programmieren (zumindest verdiene ich mein Geld damit), hab allerdings noch nie in ein vdr-Plugin bzw. in Linux-Kernel-Module reingeschaut. Und da ich selbst eine PVR150 habe, hab ich Interesse daran, dass es mit dem Ding weitergeht, weil ich zu den Leuten gehöre, die das Flackerproblem haben.

Wenn mir jemand verrät, wo ich aktuelle Sourcen zum pvrinput bekomme, werde ich mal versuchen, mich in die Materie einzuarbeiten.

Was sollte ich noch lesen, um ein vdr-plugin zu verstehen? Was für eine Distribution sollte ich als Entwicklungsumgebung benutzen? Ich hab kein Problem mit vi und Kommandozeile...

mini.

Moin!

Der Antennenverstärker tut seine Pflicht und das Bild ist jetzt in Ordnung. Hoffentlich bekomme ich dadurch das Flackern seltener...

mini.

Moin!

Noch benutze ich eine 0.4er-Version von ivtv und Kernel 2.6.14, da da ja noch beim Kanalwechsel ein eventuelles Flackern verschwindet. Ich programmier dann immer eine 5-Minuten-Aufnahme vor den eigentlichen Aufnahmen, um dann einen Kanalwechsel vor der Aufnahme zu erzwingen.
Dass das Flackern an einem schlechten Signal liegt, könnte auch erklären, warum das Überspielen von alten VHS-Bändern das Flackern hervorruft, wenn mal eine Stelle kommt, wo das Band nicht mehr ganz in Ordnung ist.

Sollte es also einen aktuellen Kernel mit entsprechend gepatchtem ivtv geben, so dass beim Kanalwechsel das Flackern wieder verschwindet, bin ich gerne bereit, es zu testen.

Außerdem könnte ich mal versuchen, meine TV-Verkabelung auf Vordermann zu bringen, damit das Signal besser wird... Ich hab nämlich bei Sat1 (161,25 MHz) ein schlieriges Bild (bei der PVR und bei meinem neuen Fernseher), der alte Videorekorder und ein alter Fernseher im Schlafzimmer liefern allerdings ein sauberes Bild. Haben vielleicht moderne Tuner bei bestimmten Frequenzen ein Problem?
Naja, ich hab hier noch einen Signalverstärker mit zwei Ausgängen rumliegen, den werde ich mal als erstes in die Reihe schalten.

mini.

P.S.: Ich hatte mal den 2.6.15er Kernel probiert, da hab ich es aber nicht geschafft, dass meine PVR150 MCE vernünftig erkannt wurde. Unten ist die Meldung unter ivtv 0.4.1/2.6.14. Gibt es bekannte Probleme mit meinen Tuner?

ivtv:  ==================== START INIT IVTV ====================
ivtv:  version 0.4.1 (development snapshot compiled on Sa 29 Okt 2005 16:05:48 CEST) loading
ivtv:  Linux version: 2.6.14 386 gcc-3.3
ivtv:  In case of problems please include the debug info
ivtv:  between the START INIT IVTV and END INIT IVTV lines when
ivtv:  mailing the ivtv-devel mailinglist.
ivtv0: Autodetected WinTV PVR 150 card (iTVC16 based)
PCI: Enabling device 0000:01:0b.0 (0014 -> 0016)
ACPI: PCI Interrupt Link [LNKD] enabled at IRQ 3
PCI: setting IRQ 3 as level-triggered
ACPI: PCI Interrupt 0000:01:0b.0[A] -> Link [LNKD] -> GSI 3 (level, low) -> IRQ 3
ivtv0: i2c attach to card #0 ok [client=tveeprom, addr=50]
tveeprom 2-0050: Hauppauge model 26559, rev C260, serial# 7735902
tveeprom 2-0050: tuner model is LG S001D MK3 (idx 60, type 38)
tveeprom 2-0050: TV standards PAL(B/G) PAL(I) SECAM(L/L') PAL(D/K) (eeprom 0x74)
tveeprom 2-0050: audio processor is CX25843 (idx 37)
tveeprom 2-0050: decoder processor is CX25843 (idx 30)
tveeprom 2-0050: has radio, has no IR remote
tuner (ivtv): chip found at addr 0xc2 i2c-bus ivtv i2c driver #0
ivtv0: i2c attach to card #0 ok [client=(tuner unset), addr=61]
cx25840 2-0044: cx25843-23 found @ 0x88 (ivtv i2c driver #0)
cx25840 2-0044: loaded /lib/modules/HcwMakoA.ROM firmware (14264 bytes)
ivtv0: i2c attach to card #0 ok [client=cx25840, addr=44]
wm8775 2-001b: chip found @ 0x36 (ivtv i2c driver #0)
ivtv0: i2c attach to card #0 ok [client=wm8775, addr=1b]
tda9885/6/7: (ivtv) chip found @ 0x86
ivtv0: i2c attach to card #0 ok [client=tda9887, addr=43]
ivtv0: loading /lib/modules/ivtv-fw-enc.bin
ivtv0: Encoder revision: 0x02050032
ivtv0: Allocate DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total)
ivtv0: Allocate DMA encoder YUV stream: 161 x 12960 buffers (2048KB total)
ivtv0: Allocate DMA encoder VBI stream: 80 x 26208 buffers (2048KB total)
ivtv0: Allocate DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total)
ivtv0: Create encoder radio stream
tuner: type set to 38 (Philips PAL/SECAM multi (FM1216ME MK3)) by ivtv i2c driver #0
ivtv0: Initialized WinTV PVR 150, card #0
ivtv:  ====================  END INIT IVTV  ====================

Ich vermute mal, das meine Avermedia 771 an der bt865-Erkennung Schuld ist, die benutzt ja einen bt-Chipsatz. Kann das sein?
Aber ist für mich auch nicht mehr wichtig...
So, bin jetzt erst mal im Urlaub, bin gespannt, wie es ausgeht...

mini.

Parameterset 3+4 funktionieren, allerdings behauptet das Script, ich hätte eine Karte mit bt865, obwohl es eine mit adv717x ist.

mini.

Hi,

Das Phänomen habe ich auch mit meiner PVR 150MCE. Gerade heute hab ich mich wieder darüber geärgert, als ich eine VHS-Aufnahme digitalisieren wollte (4 Stunden Konzert zu Mandelas 70.). Die erste Stunde ist in Ordnung, aber nach ca. 65-70 Minuten setzt das Flackern ein. Es kommt also auch, wenn man nicht den Tuner benutzt, da ich über die Composite-Eingänge aufgenommen habe.

Ich werde aber die nächsten 2 Wochen im Urlaub sein, werde mich also dann erst wieder melden und evtl. irgendwas beisteuern können (und wenn's nur testen ist).

mini.

Moin!

So, es ist vollbracht! Mit dem Kernel 2.6.14 und dem tveeprom aus kernel/drivers/media/video funktionieren beide Karten.

Ein großes herzliches Dankeschön für die Unterstützung! Ich bin jetzt glücklich und meine Frau ist es auch, weil es im Wohnzimmer wieder wohnlicher aussieht...
Noch steht der vdr zwar in einem Standard-Minitower hinter'm Sofa in der Ecke, aber sobald ich mal für wenig Geld ein schönes Desktopgehäuse finde, kommt das Ding ins Hifi-Regal. Aber das ist ja nur noch Makulatur...

mini.

Moin!

So was ähnliches hab ich mir schon gedacht. Ich werde den neuen Kernel (wahrscheinlich am Wochenende) mal ausprobieren und melden, ob's funktioniert.
Geld für eine andere DVB-T-Karte wollte ich eigentlich nicht ausgeben, da hier in Flensburg eh' nur die Öffentlich-rechtlichen senden. Aber da kommen die Spielfilme jedenfalls ohne Werbung...

Mein Post zu deinem "Avermedia 771"-Thread kannst du dann getrost ignorieren...

mini.