Bugfix für Spulen in Aufnahmen mit vdr-xine-plugin und xineliboutput

    Sehr merkwürdig, das...


    Zitat

    Original von wbreu
    Meine GPU ist eine GeForce 9400 (C79), siehe ION in der Tabelle.


    selbiges hab ich ja auch und die Test-Werte stimmen auch mit denen aus der Tabelle überein:



    Trotzdem kann ich HD-Aufnahmen (ARD) fast nicht spulen, zweifache Geschwindigkeit etwa...
    Allerdings hab ich jetzt die letzte xine-lib + xinliboutput pur installiert - die Aufnahme lässt sich schneller abspielen, und, ich hab dann auch wie bei peter2 Pixelmüll...
    Was mir grad auffiel - bei manchen Videos (z.B. big-buck-bunny) kommts nach Sprüngen zu Darstellungsfehlern. Das konnte ich beseitigen indem ich in xineliboutput "use_driver_crop" gesetzt habe (geht nur im Source, nicht über Menu, Zeile 1153 in "xine_post_autocrop.c", Funktion "autocrop_draw), evtl. bringts da auch was (noch nicht probiert, momentan ja alles ungepatcht).


    Umschaltzeiten sind übrigens auch wieder sowas von schlecht.


    Nun gut, weiter testen...

    nabend wbreu,


    die Tabelle wäre etwas übersichtlicher wenn in den spalten nur die zahlen zentriert stehen würden,reicht doch wenn die "einheit" nur in der zeilen beschreibung ständen.

    Hi,


    hier von meiner Nvidia G100


    CU
    9000h

    Es ist eagl in wlehcer Reiehnfogle die Bchustebaen in Woeretrn vokrmomen. Huapstache der estre und leztte Bchustbae sitmmen.

    Zitat

    Original von tbshl-vdr


    Trotzdem kann ich HD-Aufnahmen (ARD) fast nicht spulen, zweifache Geschwindigkeit etwa...
    Nun gut, weiter testen...


    Nabend,


    ich habe gerade mal ein Testsample gemacht auf ARD, jetzt sehe ich was ihr meint.


    Beim Vor-/Zurück-Spulen der ARD-Aufnahme sieht man deutlich an der Zeitanzeige, dass immer wieder kleine Sprünge sind. Sieht aus, wie mal schneller und mal langsamer...


    Bei 1080i-Aufnahmen gibts das nicht.


    Ich mach mal ne frische ORF-HD-Aufnahme zum gegentesten wie es da aussieht.
    Die Aufnahme die ich in meinem Testspiegel habe ist das EM-Endspiel von 2008, eventuell hat sich da was geändert.


    Trotzdem muß ich sagen, das Spulen bei 720p ist erträglich, die Verpixelungen sind da, aber nicht sehr störend.


    Bei Kaufreceivern ist das ähnlich, die machen dann halt ein Standbild und geben das Bild erst wieder frei, wenn die entsprechende Zeit erreicht ist.


    PS: Die Tables der vdpau-Tests sind jetzt neu formatiert


    Gruß
    Wolfgang

    Hier mal die Messwerte meiner eVga GT240 512MB GDDR5:



    GPU wurde komischerweise nicht erkannt - ging aber vor ein paar Tagen noch... :whatever


    Gruß
    Guido

    VDR1
    HW: Lintec Senior, Aopen MK79G, Sempron 2600+, 1GB DDR1, HDD 80 GB, FF 2300
    SW: easyvdr 06.10 + 2.6.22-15 multiproto, vdr-1.7.0, nv-96.4316


    VDR2
    HW: SilverStone LC11, TFX 300W, Biostar G41D3, PDC E6300, 2GB DDR3, 500 GB WD-AV, 2x TT S2-1600, GT240
    SW: yaVDR-0.1.1 + nv-195.36.15, vdr-1.7.14, xinelibout-cvs20100331

    Zitat

    Original von wbreu


    Trotzdem muß ich sagen, das Spulen bei 720p ist erträglich, die Verpixelungen sind da, aber nicht sehr störend.


    Hi,


    hast du jetzt xinelibout oder vdr-xine getestet?


    Läuft unter xinelibout bei dir das spulen nicht nach?


    Hi,


    bei beiden das gleiche Verhalten mit der ARD-Aufnahme.


    Jepp, zwei Sekunden ca. Nachlauf, aber ich denke das sollte normal sein.


    Gruß
    Wolfgang

    Hi,
    bei mir sieht es nach einigem Suchen nach der config_xineliboutput und ein testen der Optionen auch gemischt aus. (die config ist übrigens im home/.xine/ gelandet! yavdr testing 10.04)
    Test mit vdr-sxfe:


    Was einwandfrei geht:
    - Spulen in SD, vorwärts und rückwärts mit voller Geschwindigkeit, alles perfekt
    - Umschalten SD geht besser, kaum mehr Pixelfehler und auch schneller
    - Umschalten HD schneller mit geringen Pixelfehlern und seltener nachfolgend Pixelfehler. (media.xvdr.min_playback_buffers_hd:2000) Weniger verursacht bei ARDHD/ZDFHD Tonprobleme nach ein paar Sekunden


    Was nicht geht:
    - Suchlauf vorwärts Sky HD geht nicht mit voller Geschwindigkeit (deutlich langsamer als rückwärts) und nach einigen Sekunden massive Pixelfehler an bewegten Objekten. Auch hier abhängig vom Material:
    720p(ARD) geht vorwärts sauber bis 2fach und mit nachlaufen von rund 2 sek. 3fach geht gar nicht und von 3 fach auf Normalwiedergabe bleibt bei 2fach hängen. rückwärts geht ist aber an bewegten Objekten ständig deutlich verpixelt.
    1080i (sky) geht rückwärts in allen Geschwindigkeiten und läßt sich sauber beenden, vorwärts wieder nur 1-2 fach ohne Möglichkeit des beendens. 3 fach geht auch nicht.
    - Nach Suchlauf vorwärts kann man nicht auf Wiedergabe schalten, es bleibt beim 1fachen Suchlauf vorwärts. Erst kurz rückwärts und dann play beendet den Suchlauf. (egal ob 720p oder 1080i)


    Leider sind noch nicht alle patches drin die Wolfgang beschreibt. Möglicherweise kann Hotzenplotz ja nochmal das ppa aktualisieren? Konkret fehlen die Einträge vom DF-Patch (Punkt3).


    Ein ganz komisches Phänomen habe ich beim editieren der config_xineliboutput. Obwohl ich selbstverst. den vdr mit sudo service vdr stop beende, kann ich die engine.buffers.video_num_buffers:500 nicht ändern, bzw nur einmal, bis zum Neustart. Alle anderen Werte die ich ändere werden aber übernommen!

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:     Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:     Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150    , DVBSky S960 und 1Tb WD Blue

    Hi Torsten,


    der letzte Paramater den du bechreibst (engine.buffers.video_num_buffers:?) wird auch übers OSD konfiguriert und der schreibt einen Wert in die setup.conf.


    Der Wert der im OSD eingestellt ist, wird dann auch wieder in die .config geschrieben.


    Im OSD Einstellungen zum xineliboutput-Plugin, Lokale Anzeige => Dekoder => Wert "Groß" = 1000, "Klein" = 250 usw.


    Mal ein bisschen in die "nahe" Zukunft geschaut, es tut sich da bald noch was im xineliboutput-cvs/git (scr-handling, damit entfällt der Patch von maniac), was eine erhebliche Verbesserung für das Umschaltverhalten verspricht/mitbringt und in der config anpassbar ist.


    Also wer nicht unbedingt updaten will/muß, sollte warten bis die Mantainer das freigeben.


    Gruß
    Wolfgang ( der jetzt ins Bett geht......)

    Hi wolfgang,
    merkwürdig ist das trotzdem. Ich hatte im OSD die Option gar nicht auf lokaler Anzeige aktiviert. Richtig, dort kann man den Wert auch ändern, aber auch hier wird die Einstellung nach beenden von vdr-sxfe wieder "vergessen".
    Mag vielleicht vom Lucid PPA liegen?


    Merkwürdigerweise ist auch zwischendurch media.xvdr.min_playback_buffers_hd verschwunden.
    Habe den Eintrag wieder manuell angelegt. Im Moment funktioniert übrigens 1300 doch. Kann heute Mittag beim Testen an Streamdev Client gelegen haben. jetzt habe ich die TT3600 USB direkt am NB.


    Gute Nacht

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:     Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:     Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150    , DVBSky S960 und 1Tb WD Blue

    Hallo,


    Zitat

    Original von tbshl-vdr
    Was mir grad auffiel - bei manchen Videos (z.B. big-buck-bunny) kommts nach Sprüngen zu Darstellungsfehlern. Das konnte ich beseitigen indem ich in xineliboutput "use_driver_crop" gesetzt habe (geht nur im Source, nicht über Menu, Zeile 1153 in "xine_post_autocrop.c", Funktion "autocrop_draw),


    sorry, stimmt nicht. Ich hatte bei manchen (nicht 16:9-)Videos Probleme (eine Art Flackern, halbes / dreiviertel Bild eingefärbt, Abstürze) wenn ich sie 16:9 abgespielt habe, dagegen half das.
    Für obiges Problem ist der Patch, den ich anhänge (xine-lib -> src/video_dec/libvdpau).
    Gegen die Fehler beim Spulen hilfts leider nicht.
    Evtl. stimmt doch was mit der Index-Datei nicht. Hab grad gesehen, vdr-sxfe gibt bei Sprüngen (oder beim Start einer Aufnahme) "Broken NAL, skip it." aus und der Decoder wird neu gestartet, was ähnlich ist wie bei dem Problem mit den Videos. Ich bleib mal dran...


    Gruss,
    Thomas

    @all


    Habs heute geschafft mich mit der neuen Version zu befassen, die "studio_levels" funktionieren, nicht erschrecken die Farben werden realistischer ...


    Aber was mir auffällt, xine-ui hängt sich in den Wald wenn ich in einer 1920x1080i Aufnahme zwischen den Schnittmarken springe, bei 576i nicht. Mit 720p hatte ich jetzt nix mit Schnittmarken auf dem TestVDR.


    Habe die Indexes schon neu erstellen lassen, obwohl beide Aufnahmen mit 1.7.14 getätigt wurden.


    Gruß
    Frank

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()


    hattest recht .. jetzt gehts ...

    leider bbekomme ich den patch nicht rein


    removescrminbufferconfig.diff


    Code
    patching file xine_input_vdr.c
Hunk #1 succeeded at 180 with fuzz 1 (offset -7 lines).
Hunk #2 succeeded at 322 (offset -11 lines).
Hunk #3 succeeded at 477 (offset -11 lines).
Hunk #4 succeeded at 573 (offset -15 lines).
Hunk #5 FAILED at 592.
Hunk #6 FAILED at 609.
Hunk #7 FAILED at 649.
Hunk #8 succeeded at 4361 (offset -136 lines).
3 out of 8 hunks FAILED -- saving rejects to file xine_input_vdr.c.rej
    Zitat

    Original von mentox
    leider bbekomme ich den patch nicht rein


    Der Inhalt hiervon:


    saving rejects to file xine_input_vdr.c.rej


    wäre ganz nützlich.
    Woher ist 'removescrminbufferconfig.diff' gleich nochmal?


    Gruss,
    Thomas


    edit: idealerweise auch die Datei die gepatcht werden soll und der Patch.


    der ist von wbreu
    http://wbreu.htpc-forum.de/dow…vescrminbufferconfig.diff


    http://wbreu.htpc-forum.de/vdr…onxineliboutput/index.php




    den bekomme ich auch nicht rein :(


    vdpau_h264.c.diff


    irgendwas ist doch komisch ..

    Ich bin gerade auf eine interessante Beobachtung in der Konsole gestoßen.
    Ich hatte gerade das Spulen in einer 1080i (skyHD) Aufnahme mir nochmal zu Gemüte geführt und dabei beim Wechsel zwischen Vorlauf (3x, 2x,1x) und Rücklauf (1x) danach wieder auf Normalwiedergabe um den Suchlauf zu verlassen, folgendes auf der Konsole mitgeloggt:



    Fällt Euch etwas zum Ausfall des Deinterlacing ein ?


    Dann was zum Live TV über Streamdev:
    Der Buffer wird bei mir über Streamdev und WLAN mit mind. 54Mbit - 122Mbit nur max. mit 15% gefüllt. Auch über Kabelgebundenes Netzwerk sind nie Füllstände >20% erreicht worden. Je höher die Bitrate, desto niedriger der mittlere Füllstand.
    Dies führt dazu das tatsächlich zeitweilig der Puffer leerläuft. Beobachtet auf NatGeoHD mit Bitraten von bis zu 20Mbit. In dem Moment gibt es natürlich Pixelfehler im Bild.


    Dies läßt mich vermuten, dass es einen Fehler im Füllen des Puffers gibt. Ob das aber am VDR liegt oder an vdr-sxfe?
    Ist es überhaupt möglich den Puffer so voll zu bekommen? Dazu müßte der Stream ja erst mal die Zeit haben, den Puffer zu füllen, was wir aber mit dem min.playback.buffer Patch uns zunichte machen.


    Müßte der Puffer nicht um die Variation der mittleren Bitrate + 50% bestehen und die Wiedergabe erst bei einem Füllgrad von 50% starten? Denn dann könnte der Puffer erst zwischen 50-100% schwanken.
    Anders formuliert, man müßte vom Stream die mittlere und maximale Bitrate ermitteln, dann dynamisch Puffer= mittlereBitrate+maximaleBitrate-mittlereBitrate und gleichzeitig Sicherstellen, dass die Streamwiedergabe erst ab einem Füllgrad von 50% gestartet wird.
    Damit erreichen wir zwar bei hohen Bitraten keine schnellen Umschaltzeiten, verhindern aber zuverlässig ein leerlaufen des Puffers.
    Ein starrer Puffer ist somit überflüssig.

    Proxmox VE, Tyan Xeon Server, OMV, MLD-Server 5.1
    MLD 5.1 64bit: Asus AT5iont-t, ION2, 4GB Ram, SSHD 2,5" 1Tb, HEX TFX 300W 82+, Cine S2 V6.2 , 38W max.
    Yavdr 0.5:     Zotac D2550ITXS-A-E mit GT610 OB, TT S2-4100 PCI-e ,Joujye NU-0568I-B
    Yavdr 0.5:     Sandy Bridge G840, Tests und Energieverbrauch , CoHaus CIR, Cine S2 V6.2
    MLD 5.1 Beebox N3150    , DVBSky S960 und 1Tb WD Blue

    Einmal editiert, zuletzt von Torsten73 ()


    Einen Fehler beim Füllen des Buffers gibt es nicht.
    Die Idee dahinter, den minimalen Buffer ab dem die Ausgabe startet konfigurierbar zu machen, war es ja gerade die Umschaltzeiten zu verkürzen.
    Normalerweise startet xineliboutput ab einem Füllstand von 66%. Bei Sender mit hohen Bitraten gab es dann aber das Problem, das der Buffer übergelaufen ist. Erhöht man die HD-Buffer dauert das umschalten aber auch wieder ewig. Da nun aber zusätzlich zur Buffer-Anzahl auch eingestellt werden kann ab wann er das Playback startet, kann man für beides brauchbare Werte finden.

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden