[announce] pvrinput-2008-10-04 -jetzt auch für PVRUSB2!

ich habe die in den letzten Beiträgen diskutierten Fixes integriert und eine neue Version hochgeladen (siehe 1. Beitrag)

aus der HISTORY:

2008-07-05 (Dr. Seltsam)
- fix handling of CARD-parameter (thanks to mgoeben from vdrportal for reporting
the problem, and to Wirbel for telling me how to solve it )
- extend log info for SetChannelDevice and ProvidesChannel (add number of device)
- don't allow tuning to a radio channel if device has no radio
(avoids endless "Can start transfer mode" loop)
- increase number of kMaxPvrDevices to 8 (vdr also increased the maximum number
of DVB devices to 8 in vdr 1.5.1)

einhergehend zum letzten Punkt können jetzt CARD0 bis CARD7 in der neuen channels.conf-Syntax definiert werden. Im Nachhinein hätte ich auch noch bis CARD8 oder CARD9 gehen können, denn eventuell belegen ja andere (nicht-PVR-Karten) die device-Nummern. Ich denke aber mal, in 99,9% aller Fälle wird niemand soviele devices betreiben. Es ist aber schon mal gut, dass man jetzt nicht als höchstes device /dev/video3 hat, wie bisher bei CARD3.

Moin Röhrenheli,

noch ein Hinweis:
Meinen Kernel 2.6.23.9 hast Du ja sicher schon installiert. Trotzdem fehlen dem noch zwei Patches am pvrusb2-Treiber für optimale Funktion. Probier doch bitte mal etwas:
Im plugin-setup steht "PVRUSB2 Stop bei Kanalwechsel" standardmäßig auf nein. Du merkst vielleicht, dass das Umschalten nicht ganz sauber ist. Wenn Du es auf ja stellst, wird der Encoder vor dem Tunen gestoppt und danach wieder gestartet. Dann wirdd as Umschalten sauber. Ich habe bei mir aber bemerkt, dass dann öfters mal das Bild beim Umschalten schwarz bleibt. (Das liegt am Treiber, und ich weiss inzwischen, wie ich ihn patchen muss.) Teste doch bitte mal, ob das bei Dir auch auftritt und wenn ja, wie oft.

Zitat

Original von Röhrenheli
allerdings habe ich gestern abend bemerkt, dass es nach alle den anpassungen jetzt auch mit dem plugin pvrusb2 geht
bei pvrusb2 ist die bildqualität um längen besser als bei pvrinput und deshalb bleibe ich wohl bei diesem plugin

das pvrusb2-Plugin habe ich im Paket natürlich auch gleich mit upgedatet. Es wird allerdings nicht mehr weiterentwickelt. Im Gegensatz zu pvrinput unterstützt es nicht die Radiofunktion.

Grundsätzlich muss es möglich sein, mit pvrinput exakt die gleiche Bildqualität zu ezielen wie mit dem pvrusb2-Plugin. Das ist nur eine Frage der Einstellung des Encoders. pvrinput bietet erheblich mehr Möglichkeiten, an Werten zu drehen, die direkt die Bildqualität beeinflussen. Standardmäßig werden die meisten Werte auf die Treiber-defaults gesetzt. pvrusb2 gibt hingegen einige Werte explizit anders vor.

Ich habe jetzt mal mit v4l2-ctl verglichen, in welchen Pukten die Plugins bei jeweiligen default-Einstellungen (d.h. ich habe vorher in der setup.conf die Einträge beider Plugins gelöscht) die Box unterschiedlich initialisieren:

--- pvrinput-controls	2008-07-11 09:42:51.000000000 +0200
+++ pvrusb2-controls	2008-07-11 09:42:28.000000000 +0200
-linvdr:/etc/vdr# v4l2-ctl --list-ctrls -d2
-                     brightness (int)  : min=0 max=255 step=1 default=128 value=128
-                       contrast (int)  : min=0 max=127 step=1 default=68 value=64
-                     saturation (int)  : min=0 max=127 step=1 default=64 value=64
+linvdr:/etc/vdr# v4l2-ctl --list-ctrls -d1
+                     brightness (int)  : min=0 max=255 step=1 default=128 value=130
+                       contrast (int)  : min=0 max=127 step=1 default=68 value=70
+                     saturation (int)  : min=0 max=127 step=1 default=64 value=65
                             hue (int)  : min=-128 max=127 step=1 default=0 value=0
-                         volume (int)  : min=0 max=65535 step=1 default=62000 value=62258
+                         volume (int)  : min=0 max=65535 step=1 default=62000 value=65535
                         balance (int)  : min=-32768 max=32767 step=1 default=0 value=0
                            bass (int)  : min=-32768 max=32767 step=1 default=0 value=0
                          treble (int)  : min=-32768 max=32767 step=1 default=0 value=0
@@ -119,17 +119,17 @@
                    video_aspect (menu) : min=0 max=3 default=0 value=1
                  video_b_frames (int)  : min=0 max=33 step=1 default=2 value=2 flags=update
                  video_gop_size (int)  : min=1 max=34 step=1 default=12 value=12
-              video_gop_closure (bool) : default=0 value=0
-             video_bitrate_mode (menu) : min=0 max=1 default=0 value=0 flags=update
-                  video_bitrate (int)  : min=0 max=27000000 step=1 default=6000000 value=6000000
-             video_peak_bitrate (int)  : min=0 max=27000000 step=1 default=8000000 value=15000000
+              video_gop_closure (bool) : default=0 value=1
+             video_bitrate_mode (menu) : min=0 max=1 default=0 value=1 flags=update
+                  video_bitrate (int)  : min=0 max=27000000 step=1 default=6000000 value=3600000
+             video_peak_bitrate (int)  : min=0 max=27000000 step=1 default=8000000 value=10000000 flags=inactive
       video_temporal_decimation (int)  : min=0 max=255 step=1 default=0 value=0
             spatial_filter_mode (menu) : min=0 max=1 default=0 value=0 flags=update
                  spatial_filter (int)  : min=0 max=15 step=1 default=0 value=0 flags=slider
-       spatial_luma_filter_type (menu) : min=0 max=4 default=0 value=0
-     spatial_chroma_filter_type (menu) : min=0 max=1 default=0 value=0
+       spatial_luma_filter_type (menu) : min=0 max=4 default=0 value=1
+     spatial_chroma_filter_type (menu) : min=0 max=1 default=0 value=1
            temporal_filter_mode (menu) : min=0 max=1 default=0 value=0 flags=update
-                temporal_filter (int)  : min=0 max=31 step=1 default=0 value=0 flags=slider
+                temporal_filter (int)  : min=0 max=31 step=1 default=0 value=8 flags=slider
              median_filter_type (menu) : min=0 max=4 default=0 value=0 flags=update
      median_luma_filter_minimum (int)  : min=0 max=255 step=1 default=0 value=0 flags=inactive slider
      median_luma_filter_maximum (int)  : min=0 max=255 step=1 default=255 value=255 flags=inactive slider

Konkret heißt dies:
-das pvrusb2-Plugin verwendet etwas höhere Einstellungen für Helligkeit, Kontrast und Sättigung ggü. den default-Werten.
-es setzt die Box auf 100% Lautstärke (das ist eher ungünstig wegen möglicher Verzerrungen).
-es setzt V4L2_CID_MPEG_VIDEO_GOP_CLOSURE auf 1 (geschlossen), was eigentlich auch der v4l2-Standard ist. Aus mir unerfindlichen Gründen ist die default-Einstellung im pvrusb2-Treiber aber 0 (offen). Das hat aber auf die Bildqualität keinen Einfluss.
-jetzt wird es interessant: Obwohl im setup-Menü des pvrusb2-Plugins "VBR Mode aktivieren" auf ja steht, sagt v4l2-ctl dass die Einstellung 1 ist, d.h.
V4L2_CID_MPEG_VIDEO_BITRATE_MODE
Set CBR vs VBR: 0=variable bitrate, 1=constant bitrate. Hier haben wir also einen Bug im pvrusb2-Plugin!
-dafür ist die Videobitrate mit 3,6 MBit/s geringer als der (von pvrinput-verwandte) default-Treiber-Wert von 6 MBit/s
-video_peak_bitrate ist nur ein statistischer Wert, der bei variablen Bitraten einen Maximalwert in den Stream schreibt. Da die PVRUSB2 aber gar nicht auf VBR läuft, ist dieser flag inaktiv.
-Bei drei Filterwerten setzt die PVRUSB2 andere Werte, als im Treiber als Standard definiert ist. das kann je nach Empfangsqualität durchaus zu subjektiv besseren Bildern führen.

Zusammenfassend glaube ich, dass Du mit dem pvrinput-Plugin exakt die gleiche Bildqualität erreichst, wenn Du dort folgende Werte im setup-Menü änderst:
Helligkeit: 51
Kontrast: 55
Sättigung: 51
(das sind %-Werte, die exakt den 130/70/65 values entsprechen!)
Bitraten-Modus: CBR (lass die Video Bitrate Tv ruhig auf 6000, dann wird es noch besser ...)
Helligkeit Spatial Filter Typ: 1 D horizontal
Farben Spatial Filter Typ: 1 D horizontal
Stärke Temporal Video Filter: 8

Die von Dir als besser empfundene Bildqulität kommt vermutlich hauptsächlich wegen der Einstellungen des digitalen Rauschfilters. Allerdings ist das schon eine recht hohe Einstellung, beid er das Bild etwas flau wird. Ein großer Nachteil des Temporalfilters sind Geisterbildeffekte, die ich jetzt mit Stufe 8 schon wahrnehme.

Hinweis: Da pvrusb2 die channels.conf Einträge für sich angepasst hat, musst Du die für pvrinput vermutlich wieder zurückändern.

auf alle Fälle.

was mir auffiel:
wenn ich nur ivtv lade, ohne das Plugin zu starten, ist der Wert 8 gesetzt:

mporal_filter (int) : min=0 max=31 step=1 default=0 value=8 flags=slider

die 8 entspricht auch cx2341x.c:

753 /* encoding filters */
754 .video_spatial_filter_mode =
755 V4L2_MPEG_CX2341X_VIDEO_SPATIAL_FILTER_MODE_MANUAL,
756 .video_spatial_filter = 0,
757 .video_luma_spatial_filter_type =
758 V4L2_MPEG_CX2341X_VIDEO_LUMA_SPATIAL_FILTER_TYPE_1D_HOR,
759 .video_chroma_spatial_filter_type =
760 V4L2_MPEG_CX2341X_VIDEO_CHROMA_SPATIAL_FILTER_TYPE_1D_HOR,
761 .video_temporal_filter_mode =
762 V4L2_MPEG_CX2341X_VIDEO_TEMPORAL_FILTER_MODE_MANUAL,
763 .video_temporal_filter = 8,

trotzdem setzt pvrinput dann 0, weil default=0 ist:
pvrinput: 13:50:18 SetControlValue(Temporal Filter, 0)

offenbar sind die vom Kartentreiber verwandten Einstellungen nicht automatisch identisch mit den als default hinterlegten Werten. Zum temporal Filter sagt cx2341x.c z.B:

832         if (new->width != 720 || new->height != (new->is_50hz ? 576 : 480)) {
833                 /* Adjust temporal filter if necessary. The problem with the
834                    temporal filter is that it works well with full resolution
835                    capturing, but not when the capture window is scaled (the
836                    filter introduces a ghosting effect). So if the capture
837                    window is scaled, then force the filter to 0.
838 
839                    For full resolution the filter really improves the video
840                    quality, especially if the original video quality is
841                    suboptimal. */
842                 temporal = 0;
843         }

hiernach ist 0 nur dann sinnvoll, wenn die Auflösung kleiner als 720x576 ist. Trotzdem habe ich genau diesen ghost-Effekt auch mit 720x576 bemerkt und bin über den 0-Wert gar nicht unglücklich ...
Zum temporal filter heißt es

Hallo Kauli,

das dürfte ähnlich wie die zuvor beschriebenen Dinge mit einem Bug im pvrusb2-Treiber und/oder cx2341x-Treiber zu tun haben, der dazu führt, dass die default-Werte (nach denen sich pvrinput richtet) falsch ausgewiesen werden.

siehe auch
http://www.gossamer-threads.com/lists/ivtv/devel/38637
und
http://linuxtv.org/hg/v4l-dvb/rev/66afba4ce32f

Ob die fixes im v4l-dvb hg schon ausreicehn, oder ob auch der pvrusb2-Treiber noch gefixt werden muss, habe ich noch nicht getestet.

Das Problem ist bisher nicht bemerkt worden, weil entweder schon passende default-Werte angelegt waren, oder von einer parallel installierten ivtv-Karte gesetzt wurden.

soweit ich weiss, ist grab eine Funktion von Ausgabeplugins. Das pvr350-plugin unterstützt grabimage nicht. Wie jetzt pvrinput die Funktion der FF-Karte beeinflussen soll, ist mir schleierhaft. Geht grab denn auf digitalen Kanälen?

ist ivtv in den Fällen, wo pvrinput nicht geladen wird, ebenfalls nicht geladen? Dann könnte ich es verstehen. Laut wiki greift grab auf das erste device zurück (/dev/video0), und das wäre, wenn ivtv vor dvb-ttpci geladen ist, die PVR250. Ob dieses device dann geöffnet ist (durch pvrinput) oder nicht, sollte aber eigentlich keine Rolle spielen, da der ivv-Treiber in jedem Fall einen error zurückmelden wird, wenn der grab-Befehl (ich glaub das basiert noch immer auf v4l1?) kommt.

Lade also mal dvb-ttpci immer vor ivtv und berichte, was sich dann tut.

Zitat

Original von MarkusE
ln -s /dev/video1 /dev/video0

also das halte ich nun für eine Schnapsidee. Das würde ja bedeuten, dass immer dann, wenn eine Anwendung /dev/video0 (was wohl die PVR250 ist) ansprechen will, stattdessen die FF-Karte (die video1 ist) angesprochen wird.

Wie soll pvrinput dann aber die PVR250 öffnen und ansprechen?
mal abgesehen davon, dass die devices doch sicher nicht statisch sind, sondern von udev angelegt werden.

Wo/wie werden denn die Module derzeit geladen?

Zitat

Original von MarkusE
Pvrinput greift auf

zu.

mit Sicherheit nicht!!

Zitat

Bevor ich mit dem Link /dev/video0 angelegt habe, hat diese Datei nicht existiert.

vermutlich weil sie erst von udev angelegt wird, wenn der Treiber geladen wird

Zitat

Optimal wäre, wenn VDR automatisch auf die korrekte /dev/videoX zugreifen würde oder ich VDR die korrekte mitteilen könnte.

vdr greift immer auf das richtige device zu. Ein Problem gibt es anscheinend nur mit der grab-Funktion. Aber wie schon mehrfach gesagt: Das problem lässt sich doch wirklich ganz einfach dadurch lösen, dass Du die Reihenfolge der Treiber beim Laden änderst.