Artefakte bei schnellem Vorlauf in HD-Aufzeichnungen

  • Wenn ich bei der Wiedergabe einer HD-Aufzeichnung von z.B. "Das Erste HD" oder "ZDF HD" schnellen Vor- bzw. Rücklauf mache, dann sehe ich ab und zu Klötzchen im Bild.


    Da ich jetzt nicht weiß, ob das an meiner TT 6400 Karte liegt oder ein generelles Problem ist, würde mich mal interessieren, ob andere, die mit anderen Mitteln wiedergeben, dieses Problem auch haben.


    Klaus

  • Hallo,


    ...soweit ich mich erinnern kann, habe ich das selbe Problem (Klötzchen beim Spulen mit 720p-Sendern) auch schon bei der VDPAU-Lösung hier in verschiedenen Threads gelesen. Ist also möglicherweise ein generelles Problem. Ich muss mal hier im Portal versuchen, den (die) Threads zu finden...


    Klaus, übrigens nochmal Danke für die neue Version 1.7.15!


    Gruss Steve135


    PS: Vielleicht das hier: Klick mich

  • Zitat

    Originally posted by Steve135
    Hallo,


    ...soweit ich mich erinnern kann, habe ich das selbe Problem (Klötzchen beim Spulen mit 720p-Sendern) auch schon bei der VDPAU-Lösung hier in verschiedenen Threads gelesen. Ist also möglicherweise ein generelles Problem. Ich muss mal hier im Portal versuchen, den (die) Threads zu finden...


    Danke, dann können wir wohl davon ausgehen, daß das ein generelles Problem ist.


    Ich vermute mal, daß die Erkennung der Frame-Grenzen nicht ganz 100%ig hinhaut.
    Leider fehlen mir sowohl Zeit als auch Kenntnisse um das genauer zu ergründen.
    Vielleicht kann sich ja mal jemand, der sich damit besser auskennt, den Code in cFrameDetector::Analyze() genauer anschauen und findet den Fehler darin. Aber bitte keinen kompletten h.264-Parser reinbauen, der das Ganze wieder bis ins letzte Bit aufdröselt ;) Dafür geht es nämlich zu gut, um solchen Aufwand zu rechtfertigen...


    Klaus

  • Hallo,
    ich bastele gerade an einen Projekt wo aus vdr dateien clpi Dateien für blu ray erstellt werden müssen.
    Dort gibt unteranderem eine Tabelle von sogenannten entry data points, was im Prinzip die unabhängigen Frames sind.


    Ich habe mich dazu auch ein bisschen in die specs eingelesen, so dass ich ein paar vermutungen für die Ursache des Problems habe, auch wenn meine Vermutungen große Fragezeichen haben.


    Vdr überprüft zur Zeit mit dem Access Unit Delimiter, welche Art von primary_pic_type es ist. Wenn ich es richtig sehe wird, wird geschaut ob es I oder P frame 0x10.
    Wobei mir nicht klar ist warum nicht auf 0x00 geprüft wird was reines I frame bedeutet (http://neuron2.net/library/avc/T-REC-H%5B1%5D.264-200503-I!!PDF-E.pdf 7.3.4 und 7.4.2.4), es kann also durchaus sein das einzelne slices sich noch auf andere Frames beziehen, was störungen hervorrufen kann. Ein problem des Access Unit Delimiter ist das es sich um informationen handelt die beim decodieren nicht benötigt wird also Fehlerhaft sein kann.


    Auf der anderen Seite überprüft tsremux für die Entrydatapoints (also im Prinzip I Frames) auf das Vorhanden sein von Sequence parameter sets siehe folgenden Code aus BluMux.cs


    wobeii H264_PREFIX = 0x00000107.
    Fehlt dem decoder die Informationen daraus, weil die sich geändert haben könnte es auch zu Problemen kommen. Vielleicht sollte mal auf das Vorhandensein dieses Sache gescannt werden, sollte den FrameDetector nicht groß komplizierter werden.


    Ich habe für einzelnene Frames (5) Stichproben gemacht mit einem TS Packet viewer und eigentlich bei Sachen immer zusammen gefunden, so dass ich bis jetzt dachte es sei egal ob man nach dem einen oder anderen testet, aber jetzt bin ich mir nicht sicher.


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • Hallo,


    was heisst denn genau "ab und zu Klötzchen" - nur beim Start / Springen oder einfach so? Wenn auch mitten im Stream, dann kann das doch nicht Ursache sein, oder springt der dvbplayer beim schnellen Vorlauf? Rückwarts klar, aber vorwärts doch nicht.
    Beim HD-Umschalten gibts keine Probleme?


    Gruss,
    Thomas

  • Hmm, habe noch eine Idee, gibt es die probleme nur bei 720p?
    Oder auch bei 1080i?


    Falls es 720p spezifisch ist, könnte es da Punkt sein das vdr bei 50 fps, in seiner Logik nur 25 fps zählt aber zwei frames pro payload hat. Vielleicht ist dort irgenwoein bug. (Warum gibt es den Mechanismus eigentlich? Für mich wäre es einleuchtender 50 fps zu nehmen...)


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

  • Hallo,


    also ich habe dieses Problem nur beim Vorspulen in 720p Material. Dort treten auch nach dem Umschalten vermehrt die Klötzchen auf, bei 1080i ist das Spulen ohne Klötzchen und beim Umschalten treten eher selten zu Beginn ein paar Klötchen auf.


    System ist VDPAU.


    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

  • Beim reelvdr mit ehd ist es so das man manchmal bei ard-hd aufnahmen gar nicht spulen kann :(
    aber wenn es geht dann sauber :)

  • kls


    Das Fehlerbild ist bei 720p wie bereits mehrfach beschrieben ebenso existent. Was aber vergessen wurde zu erwähnen, der schnelle Vor- und Rücklauf bei Ausgabe über xine(lib) funktioniert tatsächlich erst seit einigen Wochen überhaupt bei 720p Aufnahmen. Es gabe damals eine ganz entscheidende Änderung im xinelib-Zweig, eben mit beschriebenen doch recht starken Verpixelungen beim Scrollen durch die Aufnahmen.


    Es gibt noch ein anderes Thema das evtl. in diese Ecke passt, der fehlende Bildupdate beim Verschieben von Schnittmarken in 1080i Aufnahmen. Mit 1.7.9/1.7.10 war das immerhin für 1920x1080i Aufnahmen möglich, leider nicht bei 1440x1080i Aufnahmen. Ab 1.7.14 ist das weder noch möglich. Schnittmarken setzen und verschieben ist generell möglich, aber ohne das der Bildinhalt dabei dem Verschieben der Marken angepasst wird.


    An xine(lib) kann es IMHO nicht liegen, da der Umstand sofort mit der Umstellung von 1.7.10 auf 1.7.14 bei gleicher xinelib-Version auf meinem Test-VDR auffiel. Mein Haupt-VDR hatte noch 1.7.10, da ging es, der Test-VDR daneben hatte 1.7.14, da ging es bei der gleichen Aufnahme nicht. Alle seitherigen xinelib-Updates bei den 1.7.14er Installationen haben an der Tatsache nichts geändert, ausser das man inzwischen bei 720p schnell vor und zurück scrollen kann.


    Im Changelog zu 1.7.15 steht diesbezüglich auch keine Änderung, aber vmtl. hat das auch noch nie jemand angesprochen.


    So, und jetzt bitte nicht so feste zuhauen, falls das doch kein Thema der VDR-Bits ist oder wirklich nicht zu dem hier eigentlich angesprochenen Bildproblemen passt.


    Gruß
    Frank

    HowTo: APT pinning

  • Zitat

    Original von kls
    [...] Da ich jetzt nicht weiß, ob das an meiner TT 6400 Karte liegt oder ein generelles Problem ist, ...


    Da ich , wie übrigens die allermeisten hier, keine 6400er habe (woher auch?) lässt sich die Frage wohl nur sehr schwer beantworten.

  • Zitat

    Originally posted by C-3PO


    Da ich , wie übrigens die allermeisten hier, keine 6400er habe (woher auch?) lässt sich die Frage wohl nur sehr schwer beantworten.


    Finde ich nicht - wenn andere mit anderen Ausgabedevices gleiche (oder zumindest ähnliche) Probleme haben, dann liegt es wohl eher an VDR.


    Vielleicht findet ja noch jemand eine Schwachstelle in der Ermittlung der Framegrenzen bei 720p-.Aufnahmen...


    (Die Hinweise von MartenR kann ich mir erst am Wochenende genauer anschauen).


    Klaus

  • Zitat

    Original von kls
    [...] Finde ich nicht - wenn andere mit anderen Ausgabedevices gleiche (oder zumindest ähnliche) Probleme haben, dann liegt es wohl eher an VDR.....


    Das einzige Ausgabedevice, das im Moment (einigermasen) stabil laüft ist die eHD. Das ganze xine Zeugs is IMHO mehr als "Bastelei" anzusehen.


    Aber vlt. bringt ja irgendwann der VDR ja mal ein eigenes (Software-)Ausgabedevice mit?

  • Zitat

    Original von C-3PO
    Das einzige Ausgabedevice, das im Moment (einigermasen) stabil laüft ist die eHD. Das ganze xine Zeugs is IMHO mehr als "Bastelei" anzusehen.


    [OT] Da möchte ich doch widersprechen, bei einigermaßen stabil ist man mit xine@VDPAU schon lange.


    Meine Familie hat unseren Haupt-VDR seit Umstellung von Softdevice auf xine@VDPAU vor Monaten nicht in Bredouille gebracht. Im Gegenteil, er hat sich entgegen meiner Erwartung als sehr stabil erwiesen. Und man kann in allen Aufnahmen schnell scrollen, wenn auch bei 720p mehr oder weniger stark verpixelt. Und letztens hatte ich mal eine 720p Aufnahme, da war beim scrollen gar nichts, keine Pixel, Klötzchen o.ä. [/OT]


    Gruß
    Frank

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • einigermassen stabil = instabil
    sehr stabil = stabil


    Dazwischen gibt es nix.


    Hoerst dich ja an wie son AKW-Betreiber..
    "Unsere AKWs sind sehr stabil, ab und zu geht mal nen Kuehlturm hoch aber wir sind echt begeistert..manchmal passiert garnix.." :mua

  • @Morone


    [OT] Ok Meister, d'accord, VDPAU ist sehr stabil und eHD nach anderen Angaben nicht ?( [/OT]


    Aber zu einem integrierten Software-Ausgabedevice ála softdevice@VDPAU höre ich mich tatsächlich nicht nein sagen :D


    Gruß
    Frank

    HowTo: APT pinning

  • Zitat

    Original von fnu
    [..] VDPAU ist sehr stabil und eHD nach anderen Angaben nicht ?( ...


    Genau das Gegenteil ist der Fall!


    Vlt. liegt es aber auch ein meinen Settings.
    Ich zumindest, habe bisher noch nirgends eine vernünftige und vorallem vollständige Anleitung mit einer Erlärung zu allen Parametern für xine gesehen....

  • Zitat

    Original von C-3PO


    Genau das Gegenteil ist der Fall!


    Vlt. liegt es aber auch ein meinen Settings.


    Code
    echo "Vlt. liegt es aber auch ein meinen Settings." | sed 's/Vlt\./Das/;s/es//;s/ein/an/'

    ;)

  • leute, leute, was soll das bringen, hat auch nichts mit dem problem zu tun


    ich habe das mal mit aufnahmen von arte hd (720p), bbc hd (1440x1080i) getestet


    eHD, klassischer patch, vdr 1.7.15, ausgabe source resolution (nur bedingt aussagekräftig da das plugin nicht wirklich ts verarbeitet), vdpau mit nvidia 9600gt und yavdr 0.2 (vdr 1.7.14)


    die verpixlungen tauchen eigentlich nur bei 720p auf, interlaced scheint nicht betroffen zu sein (auch nicht 576i)
    bei der eHD sind sie sowohl beim vor- und zurückspulen sichtbar und sehr stark, bei vdpau nur beim rückwärtsspulen und nur alle paar sekunden

  • Mhmm, wenn der Nalustripperpatch eine Rolle spielt, bedeutet das, dass vermutlich der vdr beim Spulen die Nalupakete kaputt macht.
    Wir müßten uns im Prinzip den Strom den der vdr beim zurückspulen ausgibt mal im Hexeditor anschauen, dann könnte wir wahrscheinlich sehen, was falsch läuft. Ich bin nur leider von vdr räumlich isoliert.
    Falls wir jemand sowas zur Verfügung stellen kann werde ich mir das anschauen.


    Marten

    vdr experimental, Femon, vdr live, acpi-wakeup, vompserver, undelete, epgsearch, vdr-burn, Raspberry Pi und Vompserver Windows Client (build from git)

Jetzt mitmachen!

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