h264 / xine-lib und "Klötzchenbildung"

  • edit 2:


    Leider nur wenig Interesse am Thema und keine Antworten, evtl auch Thema falsch gewählt, aber wie auch immer...
    Was hier stand war infolge falscher Schlussfolgerung meinerseits (daher entfernt) aber mit der Hoffnung, jemanden zu finden der mit h264 mehr vertraut ist, also wenn da jemand folgendenden Patch mal mit überdenken kann wäre gut.


    Also, ich hänge hier einen Patch an, der das Problem der "Klötzchenbildung" bei HD (genaugenommen h264 mit VDPAU) u.a. beim Umschalten lösen soll.
    Das ist sehr experimentell, sollte aber zumindest für "live"-Wiedergabe funktionieren.
    Was nicht (ohne Bildfehler) gehen wird ist Rewind in Aufnahmen, FF sollte aber gehen.
    Springen in Aufnahmen dauert noch zu lange.
    Wiedergabe von Dateien ungetestet.


    Erklärung, was durch den Patch passiert folg noch, da
    a) wenig Zeit
    b) schon spät
    c) a+b


    ;)


    Gruss,
    Thomas

  • Dein Patch ist etwas unübersichtlich. Der Teil für h264_parser.c enthält fast ausschließlich Änderungen im white space und auskommentierte printfs. Ein einsames printf für Diagnose-Zwecke bleibt übrig.


    Eine kurze Erklärung deiner Änderung wäre nett.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Hi tbshi-vdr,


    Interressant! Das ist noch das I-Tüpfelchen :) Werd morgen mal Testen.


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Zitat

    Original von gda
    Dein Patch ist etwas unübersichtlich. Der Teil für h264_parser.c enthält fast ausschließlich Änderungen im white space und auskommentierte printfs. Ein einsames printf für Diagnose-Zwecke bleibt übrig.


    Eine kurze Erklärung deiner Änderung wäre nett.


    Gerald


    Ja, wie geschrieben sehr experimentell, daher auch noch (auskommentierte / deaktivierte) Debug-Dinge drin.
    Aber in 'h264_parser.c' sollte

    Code
    if((int32_t)pic_order_cnt_msb < 0){printf("skip: ------------------------>set pocm to 0\n");pic_order_cnt_msb = 0;}


    vorhanden sein, das ist schon relevant. Ob genau das so richtig oder nicht kann ich nicht sagen...
    Wie geschrieben, genauere Erklärung später, sie a), b), c) ;)


    Wichtig vor allem sind Änderungen in vdpau_h264.c, es geht um den ersten Frame bzw. die nachfolgenden Frames (oder Slices), die diesen als Referenz verwenden.


    Genaueres da wegen zu spät jetzt dann frühestens morgen,
    danke für's lesen


    Thomas


    edit:
    Das "skip:" in den printf's hab ich zu debug-Zwecken drin um darauf zu greppen, experimentell eben...

  • Am Beispiel einer so ablaufenden Sequenz von Frames

    Code
    1 1 1 1 0 0 1 0 0 1 1 0 0 1 0 0


    1 gleich Referenzframe, der erste ein I-Frame,
    folgender Ablauf beim Start eines Streames ohne Patch:


    rf[x] sind die Referenzframes, auf die sich ein Frame bezieht.


    Ab Frame 2 haben diese Frame 1 als Referenz, aber dieser befindet sich zeitlich nach der ersten Sequenz (hier ja 16 Frames). In der zweiten Sequenz (Frame 9) beziehen sie sich auch auf den ersten Frame, der dann auch zeitlich richtig der erste ist.
    Der Patch bewirkt nun, dass nur der erste Frame genommen wird, und alle, die sich zeitlich davor befinden, verworfen werden.
    Nur damit kommt es aber trotzdem manchmal noch zu Bildfehlern, es müsste wahrscheinlich bei der Berechnung der 'pic_order_cnt' noch sowas wie ein "Reset" gemacht werden, aber scheinbar reicht es, wenn wie mit dem Patch in 'calculate_pic_order' der Wert von 'pic_order_cnt_msb' auf 0 gesetzt wird wenn er negativ wird. Ich weiss aber nicht, ob das auch später passieren kann, da der Wert scheinbar ständig steigt.


    Gruss,
    Thomas

  • Hi tbshl-vdr,


    hab den Patch grade ausgetestet und funzt Klasse! Keine Artefakte mehr beim Umschalten, weder auf ARD/ZDF HD und co (da war es immer am schlimmsten) noch auf den 1080i Sendern (Anixe, Servus, etc.). So macht das Spass :)


    Beim Spulen hab ich noch keine Verbesserung gemerkt. Kann aber auch daran liegen, dass in einer laufenden Aufnahme zu Spulen generell ein Problenm ist (nur bei mir? Der VDR spult bei mir auch bei SD in einer laufenden Aufnahme träge und sehr "abgehackt").


    Teste weiter...


    Vielen Dank, ohne den Patch wirkt das Umschalten immer so "billig", wir wollen ja keine Baumarktreceiver ;)


    Gruß
    Atech


    PS: Habs grade nochmal in einer ARD HD Aufnahme ausgetestet. Beim Spulen sind nach wie vor diese Artefakte. Interessanterweise ist das bei 1080i nicht. Habe eine AstraHD Aufnahme getestet und da ist es OK. Sowohl Vor- und Rückspulen funktioniert ohne Fehler und Artefakte.

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

    Einmal editiert, zuletzt von Atechsystem ()

  • Zitat

    Original von Atechsystem
    So macht das Spass :)


    Prima! :)


    Zitat

    Original von Atechsystem
    Der VDR spult bei mir auch bei SD in einer laufenden Aufnahme träge und sehr "abgehackt").


    Welche Versionen (vdr, xine...) verwendest Du? Das sollte nicht sein.


    Zitat

    Original von Atechsystem
    PS: Habs grade nochmal in einer ARD HD Aufnahme ausgetestet. Beim Spulen sind nach wie vor diese Artefakte.


    Eigenartig, passiert hier nicht. Das könnte evtl. von 'vdpau_h264_discontinuity' oder 'vdpau_h264_flush' kommen, kannst ja mal die Konsole-meldungen ansehen und evtl. mal die Zeile(n) 'if(this->nal_parser->dpb.used < MAX_DPB_SIZE)' auskommentieren.


    Aber wie erwähnt, ist ja noch "experimentell", wird noch einiges zu tun sein. Werd aber leider vor nächster Woche nicht viel dazu kommen.


    Ach ja, das Abspielen von Dateien wird Probleme machen, dann kann erstmal in vdpau_h264.c, Zeile 640 ca., 'if(skip)' in 'if(skip && !(this->stream->input_plugin->get_capabilities(this->stream->input_plugin) & INPUT_CAP_SEEKABLE))' geändert werden.


    Gruss,
    Thomas

  • Ich verwende:


    - vdr 1.7.14
    - vdr-plugin-xine 0.9.3
    - xine-lib-1.2 11499 (mit deinem Patch - klar)
    - xine-ui-vdr-cvs 0.99.6


    Ich werde das nochmal überprüfen. Die Artefakte beim Umschalten haben mich am meisten gestört. Die Aufnahmen sind erstmal nicht so Wild. Werde aber deine Vorschläge einmal Austesten.


    Gruß
    Atech


    Ach noch etwas - diese Änderung in der xinelib:


    http://hg.debian.org/hg/xine-l…-lib-1.2/rev/927e4da8983c


    hat dazu geführt, dass sowohl bei SD als auch bei HD der gleiche in xine konfigurierte Deinterleacer verwendet wird. Könntest du evtl. ein diff machen, dass für SD wieder Temporal Spatial verwendet? Früher hat man ja nur den HD deinterleacer eingestellt.


    Aber das nur am Rande...

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Zitat

    Original von Atechsystem
    - vdr-plugin-xine 0.9.3


    Ah, ich verwende xineliboutput. Wüsste jetzt aber nicht warum das einen Unterschied machen sollte.


    Zitat

    Original von Atechsystem
    Ach noch etwas - diese Änderung in der xinelib:


    http://hg.debian.org/hg/xine-l…-lib-1.2/rev/927e4da8983c


    hat dazu geführt, dass sowohl bei SD als auch bei HD der gleiche in xine konfigurierte Deinterleacer verwendet wird. Könntest du evtl. ein diff machen, dass für SD wieder Temporal Spatial verwendet? Früher hat man ja nur den HD deinterleacer eingestellt.


    Lade Dir den Patch dort (oben 'raw') und rufe patch mit '-R' auf.

  • Hallo,


    habe deinen Patch gerade eingespielt und muss sagen dass die Artefakte beim Umschalten weg sind. Sieht wirklich besser aus :)
    Werde die nächsten Tage weiter testen (Aufnahmen usw.).


    Danke erstmal.

    HD-VDR:
    HW: ZOTAC D2550-ITX | Mystique SaTiX-S2 Sky Xpress DUAL
    SW: Debian Stretch | vdr-2.3.8

  • Absolut keine Artefakte mehr, weder beim umschalten noch beim "Minutensprung" in den Aufnahmen


    super Arbeit!


    verwende übrigens die Pakete aus dem testing-vdr Repository vom yavdr-team habe nur die xinelib aktuallisiert (Plugins müssen nicht neu gebaut werden bei dem Patch da an den Funktionen bzw. deren Übergabewerten nichts geändert wurde :) und somit die Kommunikation mit der xinelib immer noch gleich funktioniert)


    mfg
    aelo

  • Hmm... bei mir sind die Klötzchen und grauen Flächen immer noch nicht ganz weg. Allerdings kann man einen Unterschied zum Besseren hin feststellen. Ich werde das die Tage mal mit einer "Digital Devices DuoFlex S2 miniPCIe" und ner NVIDIA G210 probieren. Eventuell funzt die Kombi besser als meine derzeitige (siehe Signatur) Hardwarezusammenstellung.


    Gruß
    iNOB

  • Zitat

    Lade Dir den Patch dort (oben 'raw') und rufe patch mit '-R' auf.


    Aha, raw - das war ja einfach :) Hoffentlich bleibt das Zukünftig nicht so....


    Danke für den Tip!


    Gruß
    Atech

    HTPC:
    Softtware: Archlinux mit VDR aus Archvdr repo (1.7.31 mit softhddevice) und xbmc 12.2 Frodo stable
    Hardware: Coolermaster 260 mit Core I3 540, 4 GB Kingst. Ram, GA.H55M-D2H, PCIe 16X RiserCard, NVIDIA 430GT, TT3600USB, TT3650-CI USB, Samsung SSD 640, WD Blue 1TB (WD10TP), IR Einschalter, imon Display, mce FB und 12 Kanal Atmolight (4 Led Streifen) über DFatmo und Boblight

  • Der Patch funktioniert bei Live-TV 1a.
    Bei HD Aufnahmen (ZDF) kann ich beim Springen (nicht Spulen) immer noch Klötzchen erkennen.


    Thx

    Powered by Point of View ION330 und Mystique SaTiX-S2 Dual
    Geguckt wird auf einem 52PFL5605H/12 per HDMI mit Atmolight Quattro
    Audio optisch per Yamaha RX-V459 auf einem Teufel Concept P
    Non-TV content über XBMC und boblight
    Remote Harmony 525 durch Atric-IR
    Remote und Streaming mit Motorola XOOM und AndroVDR sowie Daroon Player
    Streaming auf ZBOX ID-81 und Desktop per streamdev
    All based on selfbuild OpenenELEC master


    Nebenbei noch ein par andere VDRs

  • Hallo,


    erstmal Danke allen Testern und für die Berichte.
    Bis nächste Woche werde ich aber kaum dazu kommen daran weiterzumachen.
    Interessant, dass bei einigen das Springen in Aufnahmen richtig funktioniert, bei anderen nicht. Dazu mal an die, bei denen weiterhin Bildfehler da sind: Bitte mal (in 'src/video_dec/libvdpau/vdpau_h264.c') so Debug-Ausgaben einbauen/aktivieren, dass man sieht, ob nach dem Beginn eines Streams 'vdpau_h264_discontinuity' oder 'vdpau_h264_flush' (evtl. auch 'vdpau_h264_reset') aufgerufen wird.
    (Bzw. in 'vdpau_decoder_render', um den Start zu sehen, in den anderen ist ja schon eine Ausgabe).


    In 'vdpau_h264_reset' habe ich auch

    Code
    if (this->decoder != VDP_INVALID_HANDLE) {
        this->vdpau_accel->vdp_decoder_destroy( this->decoder);
        this->decoder = VDP_INVALID_HANDLE;
    }


    und einige Zeilen weiter

    Code
    this->wait_for_frame_start = this->have_frame_boundary_marks;


    auskommentiert, da ich sonst (auch mit ungepatchter xine-lib) Probleme beim Abspielen von Dateien hatte (big_buck_bunny_1080p_h264 ist da mein Test-File), das evtl. auch mal rückgängig machen.



    Gruss,
    Thomas

  • Noch ein Nachtrag:


    Ich hatte immer das Problem, dass nach unbesimmter und variabler Zeit der Stream auf HD Sendern zusammen bricht und xine oder gleich der ganze VDR hops geht.
    Die Streamabbrüche, Klötzchen und Tonaussetzer, sind zwar immer noch ab und zu da, jedoch scheint sich das nun alles wieder zu fangen und es geht normal weiter.

    Powered by Point of View ION330 und Mystique SaTiX-S2 Dual
    Geguckt wird auf einem 52PFL5605H/12 per HDMI mit Atmolight Quattro
    Audio optisch per Yamaha RX-V459 auf einem Teufel Concept P
    Non-TV content über XBMC und boblight
    Remote Harmony 525 durch Atric-IR
    Remote und Streaming mit Motorola XOOM und AndroVDR sowie Daroon Player
    Streaming auf ZBOX ID-81 und Desktop per streamdev
    All based on selfbuild OpenenELEC master


    Nebenbei noch ein par andere VDRs

  • Moin,



    changeset 11500: Separate options for SD and HD vdpau deint.


    tbshl-vdr:
    Das Switchen auf HD-Kanäle sieht jetzt wirklich sehr gut aus!


    Gruß
    Tomas

  • tbshl-vdr


    Vielen Dank für Deinen Patch, funktioniert hervorragend.


    Habe allerdings ein kleines Problem mit dem Patch.
    Wenn ich mit "7" und "9" Markierungen "anspringe" oder mit "4" und "6" verschiebe, wird das Bild nicht mehr aktualisiert. Ohne den Patch geht es einwandfrei.


    Hat sonst noch jemand das Problem oder eine Lösungsmöglichkeit?


    Gruß
    grappi

    Wohnzimmer-VDR: Hardware: ASRock Mainboard M3N78D; AMD 240e CPU; Zotac GeForce GT220 passiv; Mystique Dual SaTiX-S2; TT-DVB-S2 3200 Software: VDR-2.0.0; softhddevice (aktuelle git) ; NVIDIA-Treiber 313.26

Jetzt mitmachen!

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