[vdr] [ANNOUNCE] vdr-xine-0.4.2 plugin

Hi,

das rucklige Bild beim Deinterlacing bekommt man durch eine Einstellung im Xine-Player weg.

Unter setup -> gui -> Deinterlace plugin

tvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1

Offenbar gibt es im Xine-Player zwei Deinterlacer, einen internen und einmal als Postprocess-Filter über TvTime. Der interne ist leider nicht brauchbar. Irgendwie ist dies sehr unglücklich gelöst. Die Einstellungen unter Video kann man sich schenken.

Leider läuft HDTV bei mir noch nicht richtig. Die Framerate ist sehr niedrig obwohl die CPU-Auslastung bei ca. 30% liegt. Der HDTV-Patch für VDR 1.3.11 und für das Xine-Device überschneiden sich auch an einer Stelle. Welche Buffergröße ist den die Richtige?
HDTV TS-Streams kann ich Problemlos mit dem Xine-Player abspielen.

Gruß
Carsten

Hallo,
Seit mein Fernseher kaputt ist und ich am Monitor gucke, bin ich sehr froh dass es vdr-xine gibt! Nun ein paar Fragen:
Was hat denn FIXME: xineDevice.c:914 zu bedeuten?
Das erhalte ich ab und zu. Ich benutze vdr-xine mit fbxine.
Könnte ich die Umschaltzeiten beim zappen verbessern, wenn ich mit VIDEOBUFSIZE und POLLTIMEOUTS_BEFORE_DEVICECLEAR in transfer.c experimentiere? Und was wäre da sinnvoll?
Das Bild "hängt" beim Umschalten nämlich manchmal, und läuft erst nach einer kurzen Pause weiter, dann sehe ich PP...PPClear.
Jörg

Hi,

Zitat

Original von jrie
Was hat denn FIXME: xineDevice.c:914 zu bedeuten?
Das erhalte ich ab und zu. Ich benutze vdr-xine mit fbxine.

die Meldung solltest du nur bei Sendern mit Dolby-Ton sehen. Der Grund dafür ist, dass der Dolby Ton vom Satelliten in einem PES-Paket der Größe 8974 Byte kommt. VDR zerhackstückt solch große Pakete zu mehreren, maximal 2048 Byte großen. xine kann nun aber wiederrum mit solchen "Fragmenten" nichts anfangen, weswegen ich das ursprüngliche PES-Paket wieder aufbauen muss. Das FIXME zeigt an, dass zu dem Paket die "Vorgeschichte" fehlt und es deshalb nicht zum Zusammensetzen herangezogen werden kann.

Eigentlich könnte man das FIXME auch aus dem Code nehmen, denn man kann mit dem derzeitigem Verhalten von VDR an dieser Stelle nichts fixen. Langfristig möchte ich aber dafür sorgen, dass VDR die Fragmentierung nicht wahllos alle 2048 Byte vornimmt, sondern abhängig vom Inhalt des Pakets. Beim Dolby-Ton sind nämlich mehrere Dolby-Pakete (5 x 1792 Byte) in einem PES-Paket enthalten. Würde VDR die Fragmentierung an geeigneten Stellen vornehmen, dann könnte das Zusammensetzen (und damit auch das FIXME) entfallen.

Zitat

Original von jrie
Könnte ich die Umschaltzeiten beim zappen verbessern, wenn ich mit VIDEOBUFSIZE und POLLTIMEOUTS_BEFORE_DEVICECLEAR in transfer.c experimentiere? Und was wäre da sinnvoll?

Bzgl. VIDEOBUFSIZE sehe ich keine Verbesserung, denn der Wert stellt die Maximalgröße von VDRs internem Puffer dar. Typischerweise wird dieser Puffer nur teilweise belegt (bitte mal das Logfile beim Programmwechsel prüfen, denn hier wird die maximale Puffernutzung als Prozentwert ausgegeben). Für HDTV habe ich diesen Wert vergrößern müssen, da es aufgrund der größeren Datenmenge pro Zeiteinheit zu einem Pufferüberlauf kam, bis xine mit der Wiedergabe begonnen hat.

Warum habe ich POLLTIMEOUTS_BEFORE_DEVICECLEAR erhöht? Bis einschließlich Version 0.4.1 sind beim Ankoppeln von xine an VDR typsicherweise mehrere 'P' ausgegeben worden (ein 'P' bedeutet, dass das Poll-Timeout abgelaufen ist. D. h., xine hat in den 100 ms nicht genügend Daten aus dem Fifo gelesen, so dass dieser noch immer voll ist und VDR nichts hineinschreiben kann), und bei HDTV waren es noch mehr. Ohne die Erhöhung hätte VDR bereits nach 3 Poll-Timeouts das Verwerfen der gepufferten Daten erzwungen (DeviceClear), und xine hätte nie mit der Wiedergabe begonnen, da nach jedem DeviceClear wieder gepuffert werden muss, sonst kommt es während der Wiedergabe zu "Rucklern".

Seit 0.4.2 habe ich den Soft-Start eingeführt, bei dem die Wiedergabe so früh wie möglich, aber mit einer niedrigeren Geschwindigkeit (erst 50 %, dann 25 % und dann 100 %) startet und somit implizit ein Puffer aufgebaut wird, da der Satellit natürlich mit 100 % sendet. Die Zeitspanne, in der mit niedriger Geschwindigkeit wiedergegeben wird, kann über die Plugin-Einstellungen vorgenommen werden. Die Vorgabe von 31 Bildern (= 31/25 Sekunden) könnte mitunter manchmal keinen ausreichend großen Puffer sicherstellen, was wieder zu "Rucklern" führt. Mit dem Wert 50 für 2 Sekunden sollte es aber "immer" klappen (den Wert wird man so niedrig wie möglich einstellen, da man ja schnellstmöglich eine Wiedergabe erreichen will, aber er wäre auf jeden Fall zu groß eingestellt, wenn VDR während der Wiedergabe laufend Ps ausgibt).

Nach soviel "Gerede" über Internas zurück zur Frage: Wie kann man die Umschaltzeiten verbessern?

Auch für mich stellt(e) sich diese Frage, wenn man bei Linux-basierten SAT-Empfängern von Schaltzeiten unter einer Sekunde liest, und beim eigenen VDR-System nur davon träumen kann. Verschiedene Untersuchungen haben mir gezeigt, dass die Umschaltzeit eigentlich zu Lasten der DVB-Hardware/-Treiber geht. Die minimale Umschaltzeit sollte gegeben sein, wenn zwischen Programmen des gleichen Transponders gewechselt wird (z. B. RTL, RTL II, SuperRTL). Ich denke, dass hier 0.4.2 deutlich zugelegt hat, wenn es um die Zeit bis zum ersten Bild geht.

Internas: Nach dem Umschalt-Kommando (ich gehe davon aus, dass Kanal+ bzw. Kanal- verwendet wird, denn die Direktwahl eines Programms per Ziffern dauert aufgrund des Eingabe-Timeouts sowieso länger) dauert es eine Weile, bis auf der Console der erste '.' erscheint, d. h. vdr-xine das erste Datenpaket von VDR innerhalb der Soft-Start-Phase erhält. Ab dann startet die Zeit für die Soft-Start-Phase, und jeder weitere '.' zeigt ein weiteres Datenpaket innerhalb dieser Zeitspanne an.

Die Zeit vom Umschalt-Kommando bis zum ersten '.' ist also der DVB-Hardware/-Treiber und VDRs-Parameterübergabe zuzuschreiben (ich habe schon überlegt, ob es was bringen würde, wenn VDR auch die FEC explizit setzen und sich nicht auf die Automatik der Hardware/des Treibers verlassen würde). Die Zeit ab dem ersten '.' bis zum ersten Bild in xine ist vdr-xine bzw. xine zuzuschreiben.

Zu VDR: Hast du WAIT_FOR_LOCK_AFTER_TUNING in dvbdevice.c aktiviert? Es dauert mitunter recht lange, bis die Karte den Lock meldet, obwohl bis zu diesem Zeitpunkt schon ettliche Daten übertragen worden sind. Früher hatte ich es immer an, aber seit 0.4.2 nicht mehr.

Zu xine: Leider geht ohne Puffern in xine gar nichts, denn derzeit betreibt xine sein Metronom recht stur und verlässt sich darauf, dass die Datenquelle durch variable Datenraten (z. B. durch Lesen von DVD mit mehr als 1 x) die Daten rechtzeitig bereitstellen kann. Beim Streamen über Satellit ist das natürlich nicht der Fall, und bei zu kleinem Puffer führt xines Lesestrategie zu einem Puffer-Unterlauf, mit der Folge, dass die nachfolgenden Daten zu spät bei xine eintreffen und Bilder verworfen werden, weil sie zu alt sind ("Ruckeln").

Zitat

Original von jrie
Das Bild "hängt" beim Umschalten nämlich manchmal, und läuft erst nach einer kurzen Pause weiter, dann sehe ich PP...PPClear.

Diesen Fall hatte ich bis jetzt nur beim Kinderkanal, abends in der Sendepause. Ich erkläre es mir derzeit damit, dass hier nur alle 0,7 Sekunden ein Standbild übertragen wird. Da ich die Wiedergabe-Geschwindigkeit von xine an die Datenübertragung gekoppelt habe, geschieht die Erhöhung zu spät, wodurch xine nicht genügend Daten aus dem Fifo liest. Es wäre hier wohl besser, einen eigenen Thread für diesen Vorgang einzusetzen.

Kannst du ein paar Angaben zu deinem Rechner machen? Es mag durchaus sein, dass mein Pentium 2.8 GHz HT sich anders verhält (das HyperThreading macht sich z. B. in einer flüssigeren Wiedergabe von HDTV bemerkbar).

Bye.

Hi,

Zitat

Original von der-wolff
das rucklige Bild beim Deinterlacing bekommt man durch eine Einstellung im Xine-Player weg.

Unter setup -> gui -> Deinterlace plugin

tvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_flag=1

Das Dumme ist nur, dass damit die Wiedergabe nun gut doppelt so viel CPU-Last verursacht wie mit dem ursprünglichen Plugin. Und ich habe das Gefühl, dass es mit der Einstellung gerade bei Sendungen wie Will & Grace auf Pro7 (Vermutung: ursprünglich NTSC) ganz komische Ruckler gibt.

Zitat

Original von der-wolff
Offenbar gibt es im Xine-Player zwei Deinterlacer, einen internen und einmal als Postprocess-Filter über TvTime. Der interne ist leider nicht brauchbar. Irgendwie ist dies sehr unglücklich gelöst. Die Einstellungen unter Video kann man sich schenken.

Nun, ich denke, dass es sich hier nicht um zwei grundsätzlich verschiedene Sachen handelt. Ich denke, dass bei ausgeschaltetem Deinterlaceing und entsprechendem Eintrag unter Video/Postprocessing das gleiche Ergebnis erzielt werden kann. Die Parametrierung eines Deinterlacer-Plugins sehe ich vielmehr als "erstes" Post-Processing-Plugin, das man bequem mit 'd' ein- und ausschalten kann (ohne Gewähr).

Zitat

Original von der-wolff
Leider läuft HDTV bei mir noch nicht richtig. Die Framerate ist sehr niedrig obwohl die CPU-Auslastung bei ca. 30% liegt. Der HDTV-Patch für VDR 1.3.11 und für das Xine-Device überschneiden sich auch an einer Stelle. Welche Buffergröße ist den die Richtige?
HDTV TS-Streams kann ich Problemlos mit dem Xine-Player abspielen.

Die größere Buffergröße ist die richtige.

Ich muss mal die CPU-Last bei Wiedergabe über VDR bzw. mit xine direkt vergleichen. Evtl. gibt es hier irgendwo noch "Reibungsverluste".

Wenn du die Möglichkeit hast, bitte mal xine mit '--verbose=2' starten und die Ausgabe auf Frame-Drops untersuchen. Evtl. auch das Logfile von VDR auf Pufferüberläufe prüfen.

Bye.

Hallo Reinhard,

ich hab auch mal das neue xine-plugin 0.4.2 getestet, fazit nicht benutzbar.

beim xine start mit --verbose=2 bekomme ich folgende Meldung

video_out: throwing away image with pts 6238018 because it's too old (diff : 55374).

bei der Ausgabe von von vdr sehe ich lauter "...." manchmal kommen dann die PPPclear und dann hab ich ein Bild aber meist nicht.

top reagiert gar nicht allerdings muss die CPU AMD Athlon 2800 auf 100% sein da so gut wie keine Reaktion auf Maus Bewegungen gibt.

Mit den prebuffern hab ich auch schon rumprobiert. setze ich diese auf 50 bekomm ich gar kein Bild mehr.

alle Versionen die ich vorher eingesetzt habe funktionieren perfekt.

Im Moment habe ich vdr-1.3.11 mit deinem HDTV Patch. vdr-xine-0.4.1 funktionierte in dieser Umgebung perfekt.

Und ich habe 2 verschieden xine-lib und xine-ui Versionen einmal mit den patches aus 0.4.1 und einmal 0.4.2

wenn ich irgendwas machen kann damit die neue Version auch funktioniert, werde ich das gerne tun.

cheers
gerald

PS:
hier noch die Ausgabe von hdparm -t
hdparm -t /dev/hda

/dev/hda:
Timing buffered disk reads: 134 MB in 3.04 seconds = 44.08 MB/sec

hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 0 (off)
geometry = 14593/255/63, sectors = 234441648, start = 0

Hi,

Zitat

Original von gerald
ich hab auch mal das neue xine-plugin 0.4.2 getestet, fazit nicht benutzbar.

beim xine start mit --verbose=2 bekomme ich folgende Meldung

video_out: throwing away image with pts 6238018 because it's too old (diff : 55374).

bei der Ausgabe von von vdr sehe ich lauter "...." manchmal kommen dann die PPPclear und dann hab ich ein Bild aber meist nicht.

top reagiert gar nicht allerdings muss die CPU AMD Athlon 2800 auf 100% sein da so gut wie keine Reaktion auf Maus Bewegungen gibt.

Mit den prebuffern hab ich auch schon rumprobiert. setze ich diese auf 50 bekomm ich gar kein Bild mehr.

Alles anzeigen

hört sich ähnlich an, wie ein Beitrag aus der ML (hier schon mit meiner Antwort):

Zitat

Hi,

Luca Olivetti wrote:

>> - New feature for Live-TV mode: "soft-start" replays the stream in slow
>> motion while buffering. Useful for zapping, where you'll see an image of the current program quite early. The stream speed starts now at 50 %,
>> slows down to 25 % and then speeds up to 100 %. This happens within the
>> prebuffer time, so you should increase it (e. g. to 50) if you experience
>> problems.
>
>
> I don't know if this feature is causing the problem, but with this release of the plugin xine "freezes" after changing channels (not always but quite frequently), it seems just after doing this trick (i.e when speed has supposedly reached 100%). Sometimes if I wait long enough (a minute or so) it will start working again, sometimes pressing "q" will unlock video but no audio and xine won't respond to any keypress. Sometimes pressing "q" would end xine. Most of the times though I have to kill xine and run it again (vdr itself is still working). I took the xine snapshot from the plugin home page, and I tried increasing the prebuffer time with no success.

I'm sorry for causing such troubles.

So the freeze happens just after VDR stops writing '.' to console, right?
Are there any 'P' characters or even 'Clear'?

Does 'xine --verbose=2' provide any useful information?

The (almost) last output should be 'set_speed 4' to prove your observations.

Please tell a little bit about your hardware. It's likely that I don't run into your troubles using a Pentium 4 HT 2.8 GHz.

Bye.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@gmx.de

Alles anzeigen

Leider habe ich derzeit keinerlei Idee, was das sein könnte. Das Plugin ist bei mir seit damals täglich im Einsatz und dergleichen ist mir noch nicht passiert.

Damit steht es jetzt wohl 2 : (1+n), wobei n die noch unbekannte Zahl der erfolgreichen Nutzer von 0.4.2 außer mir angibt.

Bye.

Hallo Reinhard,

Bin auf xine-0.4.1 zurückgestiegen.
Bei 0.4.2 hatte ich auch Probleme. "...." u.s.w.
Das gleiche wie bei Gerald.

Konnte jetzt aber follgendes Verhalten feststellen.
Habe mit der deinterlace Einstellungen "linearblend" und

Unter setup -> gui -> Deinterlace plugin
tvtime:method=Greedy2Frame,cheap_mode=0,pulldown=0,use_progressive_frame_fl ag=1
(der-wolff)

beste Bildergebnisse. Nur liegt die CPU Last ziehmlich hoch. Wenn ich jetzt noch das OSD aufschalte ist meine arme CPU am Ende und es ruckelt. Wenn ich das deinterlace ausschalte habe ich keine Probleme mit xine.

Würde alle bitten ihre deinterlace Einstellungen zu posten. Vor allem solche für Laptop LCD's und <= 1,4GHz Prozessoren.
Danke

Gruß
Peter

Hi Peter,

ich benutz xine mit deinterlace auf 2 19" LCD mit xinerama (was auch nochmal CPU benötigt) und rufe xine wie folgt auf:
xine -A esd -V xv --post tvtime:method=LinearBlend vdr://tmp/vdr-xine/stream#demux:mpeg_pes.

CPU Last ist zwischen 25 und 50 % je nach dem ob ich nebeher was mach, allerdings bei AMD Athlon 2800Mhz

Hallo Reinhard,
erstmal vielen Dank für die ausführlichen Erläuterungen!
Wenn er beim Umschalten "hängt", sieht das so aus:
Bild vom altem Programm bleibt stehen, es wird schwarz, Bild vom neuen Programm kommt ohne Ton, auf der Konsole erscheinen ein paar Zeilen Punkte, Bild bleibt stehen, dann läuft das Bild weiter und der Ton kommt und auf der Konsole ist P..PClear zu sehen.
Das passiert genauso beim Umschalten zwischen Sendern auf demselben Transponder.
Der Hänger tritt also, wenn ich Deine Beschreibung richtig verstehe, am Ende der Softstart-Phase auf (nachdem alle Punkte geschrieben sind).

Bei mir läuft er mit POLLTIMEOUTS_BEFORE_DEVICECLEAR 3 besser. Wenn ich das Verhalten beim Umschalten beobachte, sehe ich dass er entweder kein P ausgibt, oder so viele bis Clear kommt.
Das bleibt auch so, wenn ich den Vorpuffer für Live-TV auf 50 erhöhe.

WAIT_FOR_LOCK_AFTER_TUNING ist bei mir nicht aktiviert.
Mein Rechner hat einen Celeron 1,3 GHz.

Jörg

Hi,

Zitat

Original von jrie
Mein Rechner hat einen Celeron 1,3 GHz.

ich verstehe nur nicht, warum langsam Abspielen zu solchen Problemen führt. Gut, in Release 0.4.2 wurde bei jedem Punkt die Geschwindigkeit in xine nachgestellt, und die Ausgabe der Punkte bzw. die Beschwerde des alsa-Plugins erzeugten auch bei mir einen CPU-Peak, der etwa doppelt so hoch war wie sonst.

Wer mag, kann ja mal das Code-Stück in xineDevice.c austauschen:

static int softStartState = -1;
  static double softStartTime = 0;
  static const double softStartSpeedStart = 0.5;
  static const double softStartSpeedMin = 0.25;
  static double softStartDuration = 31 / 25.0;
  static const int softStartMaxSpeedChanges = 20;
  static int softStartLastSpeed = 0;
  static double softStartLastTime = 0;

  static const double pi = 4 * ::atan(1);


  int cXineDevice::PlayVideo2(const uchar *Data, int Length)
  {
    if (softStartTrigger)
    {
      softStartTrigger = false;


      softStartState = 0;
    }


    if (softStartState >= 0)
    {
//      ::fprintf(stderr, ".");
/*
      int64_t ptsVdr = -1, ptsXine = -1;
      if (getPTS(Data, Length, ptsVdr))
      {
        m_xineLib.execFuncGetPTS(ptsXine);


        ::fprintf(stderr, "ptsVdr: %lld, ptsXine: %lld, delta: %lld\n", ptsVdr, ptsXine, ptsVdr - ptsXine);
      }
*/
      m_xineLib.execFuncFirstFrame();

      if (0 == softStartState)
      {
        ::fprintf(stderr, ".");

        softStartState++;

        timeval tv;
        ::gettimeofday(&tv, 0);


        softStartTime = tv.tv_sec + tv.tv_usec / 1.0e+6;

        softStartLastSpeed = (int)(1000 / softStartSpeedStart + .5);

        m_xineLib.execFuncSetSpeed(softStartLastSpeed);
        m_xineLib.execFuncWait();


        softStartDuration = m_settings.GetModeParams()->m_prebufferFrames / 25.0;


        softStartLastTime = softStartTime;
      }
      else
      {
        timeval tv;
        ::gettimeofday(&tv, 0);


        double now = (tv.tv_sec + tv.tv_usec / 1.0e+6);

        double deltaTime = now - softStartTime;

        if (deltaTime > 0)
        {
          const double t = deltaTime / softStartDuration;


          double p = (1 + ::cos(2 * pi * t)) / 2;

          p = softStartSpeedMin + p * ((softStartSpeedStart * (1 - t) + t) - softStartSpeedMin);


          int speed = (int)(1000 / p + .5);

          if (speed <= 1000)
          {            
            speed = 0;

            softStartState = -1;


            ::fprintf(stderr, ":\n");
          }

          if (0 == speed
              || (speed != softStartLastSpeed
                  && (now - softStartLastTime) > softStartDuration / softStartMaxSpeedChanges))
          {
            softStartLastTime = now;

//            fprintf(stderr, "slowstart: %d, %lg\n", speed, p);


            m_xineLib.execFuncSetSpeed(speed);
            m_xineLib.execFuncWait();

            softStartLastSpeed = speed;
          }
        }
      }
    }

Damit gibt es nur noch 20 Geschwindigkeitsanpassungen und nur noch den ersten und letzen (dafür nun aber Doppel-) Punkt der Soft-Start-Phase.

Bitte mal auf die Anzahl der insgesamt nicht angezeigten Frames achten. Bei mir sind es gerade mal 3 - 5.

Wer mag, kann auch mal den cos() durch was anderes austauschen, das evtl. nur 4 mal die Geschwindigkeit ändert 25 %, 50 %, 75 %, 100 %.

Bye.

Ich hab es versucht, aber es kompiliert nicht.
make[1]: Entering directory `/zz/VDR/PLUGINS/src/xine'
g++ -O2 -Wall -Woverloaded-virtual -c -D_GNU_SOURCE -DPLUGIN_NAME_I18N='"xine"' -DFIFO_DIR=\"/video/vdr-xine\" -DDATA_DIR=\"./PLUGINS/src/xine/data\" `xine-config --cflags` -I../../../include -I../../../../DVB/include xineDevice.c
xineDevice.c: In member function `virtual int
PluginXine::cXineDevice::PlayVideo2(const uchar*, int)':
xineDevice.c:866: error: cannot declare static function inside another function
xineDevice.c:866: error: syntax error before `{' token
xineDevice.c:920: error: `origJumboPESsize' undeclared (first use this
function)
xineDevice.c:920: error: (Each undeclared identifier is reported only once for
each function it appears in.)
xineDevice.c: In member function `virtual void
PluginXine::cXineDevice::PlayAudio(const uchar*, int)':
xineDevice.c:965: error: `mkJumboPES' undeclared (first use this function)
xineDevice.c:970: error: `jumboPESdata' undeclared (first use this function)
make[1]: *** [xineDevice.o] Error 1
make[1]: Leaving directory `/zz/VDR/PLUGINS/src/xine'
make: *** [plugins] Error 2
Kannst Du es als patch bereitstellen? (Um copy + paste Fehler auszuschliessen).
Jörg

also, bei mir funktioniert das plugin jezt!
danke für die nette arbeit

mfg z421

Hi,

Zitat

Original von jrie
Kannst Du es als patch bereitstellen?

war gestern schon zu müde

http://home.vr-web.de/~rnissl/vdr-xine-0.4.2-1.patch.gz

Bye.

Hi,

Zitat

Original von z421
also, bei mir funktioniert das plugin jezt!

das wird aber noch nicht die endgültige Lösung sein, denn ich kann das Problem nun ausreichend oft beim Umschalten zwischen HDTV-Programmen (Euro1080, Astra HD) reproduzieren: ein wichtiger Schritt in Richtung einer Lösung

Bye.

sicher sind noch verbesserungen möglich, aber ich kann sowieso kein hdtv hier schauen, denn der 900er TB macht mir da noch einen strich durch die rechnung.

aber im großen und ganzen scheit das plugin recht stabil und funktionell, wenn man so wie ich keinen fernseher und ne ss2/budget hat.

mfg z421

Hi,

Zitat

Original von z421
sicher sind noch verbesserungen möglich, aber ich kann sowieso kein hdtv hier schauen, denn der 900er TB macht mir da noch einen strich durch die rechnung.

ich wollte damit eigentlich zum Ausdruck bringen, dass das Problem noch nicht 100 %ig gelöst ist. Wenn die Maschine etwas schwächer ist oder vielleicht ein etwas aufwendigerer Deinterlacer verwendet wird, dann wird das Problem auch nach dem Patch wieder auftauchen.

Bye.

rnissl

Hi,

Zum Thema deinterlacen:

Zitat

Das Dumme ist nur, dass damit die Wiedergabe nun gut doppelt so viel CPU-Last verursacht wie mit dem ursprünglichen Plugin. Und ich habe das Gefühl, dass es mit der Einstellung gerade bei Sendungen wie Will & Grace auf Pro7 (Vermutung: ursprünglich NTSC) ganz komische Ruckler gibt.

Das liegt daran dass wirklich 50 Frames pro Sekunde produziert werden, die für eine flüssige Wiedergabe von interlaced PAL auch benötigt werden. Die komischen Ruckler bei ursprünglichen NTSC Sendungen sind leider normal. Eine perfekte Umwandlung von 60 Hz auf 50 Hz ist nunmal nicht möglich. Die letzten Folgen von Enterprise auf SAT1 waren z.B. extrem schlecht konvertiert. Das hat aber nichts mit dem Plugin zu tun, sondern war auch auf dem Ferseher sichtbar.

Zum Thema HDTV:

Zitat

Wenn du die Möglichkeit hast, bitte mal xine mit '--verbose=2' starten und die Ausgabe auf Frame-Drops untersuchen. Evtl. auch das Logfile von VDR auf Pufferüberläufe prüfen.

Ich bekomme dann im Sekundentakt in etwa diese Meldung:
video_out: throwing away image with pts 6238018 because it's too old (diff : 55374).

Der Rechner ist schnell genug ich spiele mit Xine HDTV-Streams ohne Probleme ab. Ich benutze dafür die Xv-Ausgabe.

Gruß
Carsten

Zitat

Original von rnissl
http://home.vr-web.de/~rnissl/vdr-xine-0.4.2-1.patch.gz

Hallo Reinhard,
ich habe den patch jetzt mal getestet, aber leider keine Veränderung.
Aber da Du ja schon daran arbeitest, wohl nur noch eine Frage der Zeit.
Jörg

Hi,

Zitat

Original von jrie
ich habe den patch jetzt mal getestet, aber leider keine Veränderung.
Aber da Du ja schon daran arbeitest, wohl nur noch eine Frage der Zeit.

habe gerade die 0.4.3 online gestellt. Bitte mal probieren.

Bye.

Hi,

Zitat

Original von der-wolff
Zum Thema deinterlacen:

Das liegt daran dass wirklich 50 Frames pro Sekunde produziert werden, die für eine flüssige Wiedergabe von interlaced PAL auch benötigt werden. Die komischen Ruckler bei ursprünglichen NTSC Sendungen sind leider normal. Eine perfekte Umwandlung von 60 Hz auf 50 Hz ist nunmal nicht möglich. Die letzten Folgen von Enterprise auf SAT1 waren z.B. extrem schlecht konvertiert. Das hat aber nichts mit dem Plugin zu tun, sondern war auch auf dem Ferseher sichtbar.

Ich habe die Einstellung mal in MANUAL mit aufgenommen, da sie doch recht brauchbare Ergebnisse liefert.

Zitat

Original von der-wolff
Zum Thema HDTV:

Ich bekomme dann im Sekundentakt in etwa diese Meldung:
video_out: throwing away image with pts 6238018 because it's too old (diff : 55374).

Der Rechner ist schnell genug ich spiele mit Xine HDTV-Streams ohne Probleme ab. Ich benutze dafür die Xv-Ausgabe.

Bitte probier' es nochmal mit 0.4.3, damit wir vom gleichen Softwarestand ausgehen. Ich kann das so nämlich noch nicht nachvollziehen.

Euro1080 spielt mit bzw. ohne VDR problemlos ab. ASTRA HD erzeugt hingegen bei beiden regelmäßig Pufferunterläufe. Anscheinend spielt xine den Stream zu schnell ab, oder hat an den Übergängen der einzelnen Schnippsel Schwierigkeiten.

Ich verwende hier -V xshm, da -V vidix diese Auflösung nicht skalieren kann und -V xv abstürtzt (Matrox G550). Mit "Alt+1" stelle ich das Fenster auf 50 % ein und schalte den Deinterlacer aus.

Bye.