Bild wird grau nach Umschalten

Das mit dem anfangs teilweise grauen oder andersfarbigen Bild (bei h264-Material) kommt mir bekannt vor. Hauptsächlich allerdings bei Medienwiedergabe wenn gesprungen wurde.
Schuld ist wohl xine-lib, hier hat folgende Änderung geholfen:

--- vdpau_h264.c.orig   2010-03-30 18:04:26.000000000 +0200
+++ vdpau_h264.c        2010-04-03 19:23:46.000000000 +0200
@@ -725,13 +725,14 @@
  */
 static void vdpau_h264_reset (video_decoder_t *this_gen) {
   vdpau_h264_decoder_t *this = (vdpau_h264_decoder_t *) this_gen;
+//printf("---->  vdpau_h264_reset...\n");
 
   dpb_free_all( &(this->nal_parser->dpb) );
 
-  if (this->decoder != VDP_INVALID_HANDLE) {
+/*  if (this->decoder != VDP_INVALID_HANDLE) {
     this->vdpau_accel->vdp_decoder_destroy( this->decoder );
     this->decoder = VDP_INVALID_HANDLE;
-  }
+  }*/
 
   reset_parser(this->nal_parser);
 
@@ -746,7 +747,7 @@
      * have to hope that the next nal will start with the next
      * incoming buf... seems to work, though...
      */
-    this->wait_for_frame_start = this->have_frame_boundary_marks;
+    //this->wait_for_frame_start = this->have_frame_boundary_marks;
   }
 
   if (this->last_ref_pic) {

in 'src/video_dec/libvdpau'

Wer das mal testet - würde mich sehr interessieren ob's was ändert...

Gruss,
Thomas

Bei mir bringt das mit den Pufferwerten keine Änderung. Werde mal den Patch probieren...

Gruß
iNOB

Zitat

Original von grappi
Der Grauschleier bei meiner GF9500 ist damit leider immer noch vorhanden.

Schade...

Zitat

Original von grappi
Was die Änderung bei mir allerdings bewirkt (sowohl bei der onboard-Grafik wie auch bei der GF9500):
Beim Umschalten auf HD-Sender bzw. auch beim Springen innerhalb von Aufnahmen habe ich kaum noch "Verpixelungen".

Gut! Das Springen sollte auch viel schneller sein (beim Umschalten wird man's nicht merken).
Hoffe die Änderung hat nicht irgendwelche Seiteneffekte, hab's aber schon länger drin und nichts bemerkt.

Den "Grauschleier mit Konturen" (also nicht falsche Blöcke) hatte ich glaube aber auch schon, sollte mir Einfallen ob und was ich dagegen gemacht habe teil ichs aber mit...

Gruss,
Thomas

tbshl-vdr

Wenn Du da was angepasst hattest, wäre das interessant

@all

An die anderen mit dem Problem, wenn Ihr neben den o.a. Puffer-Anpassungen noch diesen Parameter im xine-plugin so setzt:

Puffer-Überwachungsmodus:                    Durchgehend

Ändert sich dann was?

Gruß
Frank

nö... das graue Zeuch iss immer noch da

Grad vorhin mal ne GT8400 mit 256MB RAM probiert. Software-Einstellungen wurden beibehalten. Kein Unterschied feststellbar. Eventuell liegts ja auch an der Satkarte? Die hatte ich weiter oben schonmal im Verdacht, eine Rolle als zu lahmer Datenlieferant zu spielen. Ebenso könnte es einen Unterschied machen, ob man eine Graka OnBoard oder eben dediziert benutzt...

Gruß
iNOB

iNOB

Danke, mir ist erst im Nachgang aufgefallen, das der Wert bei mir so gesetzt ist und augenscheinlich nicht Standard ist. Daher fragte ich vorsichtig mal nach, wäre ja der Hammer gewesen und das wäre die Lösung gewesen, aber das wäre ja zu einfach ...

Hmm, die SAT Karte? Du Tevii S650, ich TT S2-3200 ...

Wie gesagt, habe nach den wenigen Änderung aktuell keine Malesse mehr. Sollte ich mal alle Einstellung des xine-Plugins und die xine-config posten?

Gruß
Frank

Zitat

Sollte ich mal alle Einstellung des xine-Plugins und die xine-config posten?

JA!!

Thx
iNOB

hab nun endlich wieder mal Zeit gefunden am VDR zu basteln

Puffer-Überwachungsmodus:                    Durchgehend

aktiviert
die SD-Puffer auf 10 und die HD-Puffer auf 50
und den obigen Patch eingespielt

Leider wird das Bild immer noch manchmal grau

mfg

Hab jetzt nochmal meine alte NOVA HD S2 eingebaut und siehe da, die grauen Flächen und sonstiger Pixelmüll beim Zappen ist weg

Da die Karte leider defekt ist, das Bild fällt auf SD-Sendern Mangels SNR nach 3 - 4 Minuten aus, hab ich eine neue geordert. Somit dürfte für mich das Problem behoben sein.

Gruß
iNOB

iNOB

Möchte Dich nicht entmutigen, das Eingrauen hatte ich ja schon meinem HauptVDR gesehen, mit 195.36.15, wo ich dann wieder auf 195.30 zurück bin. In dem Gerät ist aber z.Zt. u.a. eine Nova HD S2 verbaut ...

Hatte dort allerdings etwas mit dem Tearing-Effekt wie in einem anderen Thread beschrieben zu kämpfen, aber auch das habe ich scheinbar den Griff bekommen.

Wie o.a. meine Settings, xine-plugin:

Einstellungen - Plugin 'xine'


SD-Video Puffer für Live-TV [Bilder]:        4
HD-Video Puffer für Live-TV [Bilder]:        50
Audio Puffer für Live-TV [Bilder]:           4
Puffer-Hysterese [Bilder]:                   10
Puffer-Überwachungsdauer [s]:                10
Puffer-Überwachungsmodus:                    Durchgehend
Anzeigeart für OSD:                          Überlagern (X11)
OSD Gamma Korrektur [ 123 => 1.23 ]:         123
OSD Ausdehnung X:                            1920
OSD Ausdehnung Y:                            1080
4:3 Bilder X-Skalierung [%]:                 100
4:3 Bilder Y-Skalierung [%]:                 100
16:9 Bilder X-Skalierung [%]:                100
16:9 Bilder Y-Skalierung [%]:                100
Lautstärke in xine steuern:                  Ja (in Software)
Stummschalten:                               Ausführen
Automatisch zum primären Interface werden:   Ja
Unterstützung für halbtransparente Farben:   Ja
Verbindung interagiert mit EIT-Scanner:      Nein

Die Parameter in der ~/.xine/config, die sich vom Standard unterscheiden:

.version:2
gui.splash:0
gui.vo_brightness:33500
audio.driver:alsa
audio.device.alsa_front_device:iec958
audio.output.speaker_arrangement:Pass Through
video.output.vdpau_deinterlace_method:temporal_spatial
video.output.vdpau_enable_inverse_telecine:0
video.output.vdpau_studio_levels:1
video.processing.ffmpeg_thread_count:2
media.xvdr.num_buffers_hd:10000
engine.buffers.audio_num_buffers:250
engine.buffers.video_num_buffers:1000
engine.buffers.video_num_frames:25
engine.performance.memcpy_method:libc

IMHO eigentlich nichts aussergewöhnliches.

[EDIT]

Diese Parameter scheinen mit den neueren xinelib's obsolete zu sein:

video.output.vdpau_sd_only_properties:noise+sharpness
video.output.vdpau_display_queue_length:4

Kann das jemand bestätigen?

[/EDIT]

Gruß
Frank

Hallo,

so, was helfen könnte ist ein ffmpeg-Update.

ftp://ftp.videolan.org/pub/videolan/x264/snapshots/
(hab den vom 25. genommen)

und

svn checkout svn://svn.mplayerhq.hu/ffmpeg/trunk ffmpeg

Gruss,
Thomas

Ist das eine Hoffnung oder eine Erfahrung?

Erfahrung, aber leider nur bei Nicht-VDPAU wie ich feststellen musste.

Auf den VDPAU-VDRs hab ich aber eingrauen so gut wie gar nicht, dafür falsche Blöcke. Ich hab mir mit nem kleinen Hack erstmal beholfen, der nicht die Ursache, aber den Effekt beim Umschalten unterdrückt, hier
xineliboutput (buffer-handling bei live-stream / speed-adjust / Umschaltzeiten)
zu finden im xine-lib-Patch, zwei Blöcke mit DECODER_START_HACK. Die in src/video_dec/libvdpau/vdpau_h264.c einbauen, oder gleich mal das ganze testen.

Bei mir hat das Eingrauen definitiv etwas mit den verwendeten Satkarten zu tun. Bei PCI-Karten ist der Effekt weniger zu sehen als bei USB-Boxen. Wäre interessant zu erfahren, ob bei PCIe-Karten der Effekt auch auftritt...

Gruß
iNOB

Zitat

Original von fnu

[EDIT]

Diese Parameter scheinen mit den neueren xinelib's obsolete zu sein:

Code

video.output.vdpau_sd_only_properties:noise+sharpness
video.output.vdpau_display_queue_length:4

Kann das jemand bestätigen?

[/EDIT]

Alles anzeigen

Die gibt's ja nur im xine-lib-1.2-vdpau-extensions-Patch, wie ich gerade feststellte, als ich mich wunderte dass hier trotz der Parameter bei HD sharpness eingeschaltet war.

Wegen eingrauen: h264 / xine-lib und "Klötzchenbildung"

Gruss,
Thomas

tbshl-vdr

Hmm, ja kann sein. Nutze die xinelib aus dem testing-vdr Repo von "hotzenplotz5" und ich meine mich zu erinnern, er hatte diverse df-Erweiterungen nicht einge-Patch-t.

@all

Mal was anderes an alle die das Eingrauen mit xine-ui@xine-plugin haben, testet doch mal, ob sich einer Verbesserung ergibt, wenn "/tmp" in eine RAM Disk legt, z.B. mit folgendem Eintrag in der fstab:

none    /tmp                    tmpfs   size=96m        0       0

Damit liegen die Fifo's vom xine-plugin ("/tmp/vdr-xine") auch auf/in der RAM-Disk. "/tmp" ist ja eigentlich immer nur mit ein paar KB belegt, aber mit 96MB könntet ihr im Notfall auch mal was drin arbeiten. RAM Disk ist kein Problem, da bei den meisten Distros "/tmp" beim Shutdown eh gelöscht wird.

Gruß
Frank