Artefakte bei schnellem Vorlauf in HD-Aufzeichnungen

  • Zitat

    Original von MartenR
    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


    Hallo Marten,


    wenn du mich instruierst, was da genau zu tun ist, mach ich das gerne ;)


    Gruß
    Tomas

  • mahlzeit,


    habs grad mal versucht, bekomme aber nur mist raus.


    *EDIT*
    Habs nochmal geändert, nun sinds zahlen ;)


    hab ne log.h erstellt:



    und dann in der ringbuffer.c unter cFrame so eingefügt:



    wenn ich nun ne aufnahme starte wird auch in die data.log geschrieben, jedoch nur son kram, kannst du so eine ausgabe gebrauchen ?(ist nur nen beispiel von einer laufenden aufnahme) :


    Code
    1. 47577A1F6E657747577A186E657747577A196E657747577A186E657747577A1E6E657747577A1E6E657747577A1C6E657747577A1B6E657747577A136E657747577A196E657747577A1F6E657747577A1D6E657747577A146E657747577A196E657747577A166E657747406E657747577A126E657747577A176E657747577A1B6E657747577A1B6E657747577A1C6E657747577A1F6E657747577A196E657747577A1C6E657747577A1F6E657747577A1E6E657747577A116E657747577A146E657747577A1E6E657747577A1A6E657747577A196E657747406E657747577A176E657747577A1D6E6


    bzw. ist cframe überhaupt nen ansatzpunkt ?

    MfG


    bex


    server -> Asus p8h67-i -Intel 2100T - Cine CT v6

    client 1 -> Asus p5n7a-vm -Intel E5200 - Technisat Cablestar HD 2

    client 2+3 -> Raspberry Pi - Openelec

    Dieser Beitrag wurde bereits 3 Mal editiert, zuletzt von bexbier ()

  • bexbier
    ich denke im PlayVideo des verwendeten Devices ist der richtige Ort zum herausschreiben bzw. auch im PlayTSVideo.
    Wobei das ganze als Binärdaten einfach herausgeschreiben werden sollte(dann kann man es sich z.B. auch mit VLC anschauen), ich brauche etwa 20 MByte an Daten, da ein Frame etwa 100-200 Kbyte groß ist und ich am Anfang und Ende die Probleme vermute


    Gruß


    Marten

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

  • hi marten,


    habs mal eben in xine unter playtsvideo eingebaut, dann wird aber auch das livebild mitgeloggt, und ich bekam von xine-ui nach kurzer zeit eine meldung das zuviele bilder verworfen wurden.
    Die data.log ist auch schnell sehr groß geworden und wenn ich versuch sie zu öffnen mit vlc passiert nichts, aber vlc meckert auch nicht.
    Da ja nur das spulen interessant ist muss ich mal schauen wie man es hinbekommt das nur das geloggt wird.


    Bin für jeden tip dankbar

  • Ich weiß nicht obs weiterhilft, aber im aktuellen xinelib Zweig mit Durchflieger Patchen und startstream Patch habe ich beim rückwärtsspulen von 720p/1080i keine Probleme.
    Nur beim Vorwärtsspulen wird es extrem pixelig und man kann optisch ein vor/zurückspringen der Frames/Bilder sehen. D.h. es werden immer wieder alte Frames/Bilder angezeigt. Die Spulgeschwindigkeit scheint aber zu passen. Es ist aber schwer zu erkennen, aufgrund der massiven Pixel/Kästchen.

    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

  • Zitat

    Originally posted by Torsten73
    Ich weiß nicht obs weiterhilft, aber im aktuellen xinelib Zweig mit Durchflieger Patchen und startstream Patch habe ich beim rückwärtsspulen von 720p/1080i keine Probleme.
    Nur beim Vorwärtsspulen wird es extrem pixelig und man kann optisch ein vor/zurückspringen der Frames/Bilder sehen. D.h. es werden immer wieder alte Frames/Bilder angezeigt. Die Spulgeschwindigkeit scheint aber zu passen. Es ist aber schwer zu erkennen, aufgrund der massiven Pixel/Kästchen.


    Treffend beschrieben, genau so sieht es bei mir (xine-plugin mit xine-lib-1.2-r11577, Durchflieger v15-stream-start-v100614, nvidia 256.53) auch aus ....


    Grüße, Peter

    VDR1: vdr-latest, arch x86_64, Octopus net 2 x Duoflex C/C2/T2 , NUC7i3BNH, Crucial MX300 2TB, LG LM 669S
    VDR2: RasPI 2, MLD
    VDR-User #81

    Linux is the best OS I have ever seen -- Albert Einstein

  • Ich habe mir das jetzt mal genauer angeschaut und glaube, eine Lösung gefunden zu haben.


    Die Problemkanäle senden ja in 720p/50, also mit 50 Vollbildern pro Sekunde, und nicht, wie ich irrtümlich angenommen hatte, mit 25. Nach Anwendung von folgendem Patch läuft bei mir der schnelle Vor- und Rücklauf bei solchen Kanälen ohne jede Artefakte.


    Könnt ihr das bitte mal mit diversen Ausgabedevices verifizieren?
    Es greift übrigens nur bei neuen Aufnahmen. Bei einer bereits bestehenden Aufnahme müsste die 'index'-Datei gelöscht werden, damit sie neu generiert wird.



    Klaus

  • Zu welchen VDR-1.7.xx gehört diese "remux.c" anscheinend nicht in die das ich noch hatte (VDR 1.7.0-extp-72-v3 ?) leider hatte ich meine Platte wieder platt gemacht wegen Komprimierens Fehler beim XBMC-9.11.


    Zum infos ich renne (oder mochte gerne) ein EasyVDR-8...



    Auf jeden Fall schent meine Exemplar vom 2007:

  • Zitat

    Originally posted by Ichijoe
    Zu welchen VDR-1.7.xx gehört diese "remux.c"


    Sorry, der Patch ist natürlich gegen die aktuelle Developer-Version 1.7.16.


    Klaus

  • Hallo Klaus,


    danke für den Patch gegen remux.c, sieht soweit alles i.O. aus, keine Verpixellungen mehr.


    Ich hatte noch alte ZDF-Aufnahmen und ARD-Aufnahmen, wenn man da den index löscht und neu generieren lässt, dann wird jetzt die doppelte Aufnahmezeit angezeigt.


    Kann das auch mit dem Patch zu tun haben?


    VDR-Version, 1.7.16.


    Danke vorab!


    Gruß
    Wolfgang


  • In der 'info' Datei steht die Framerate auch drin, da müsstest du die Zeile


    F 25


    durch


    F 50


    ersetzen.


    Klaus

  • Sehr schön...funzt!


    Vielen Dank
    iNOB


  • Heist das nun, dass man das bei allen Aufnahmen in der "info" ersetzten muss?

  • Zitat

    Original von C-3PO


    Heist das nun, dass man das bei allen Aufnahmen in der "info" ersetzten muss?


    Natürlich nicht, nur bei den Aufnahmen die auch eine Framerate von 50 haben. Also wohl im wesentlichen bei ARD HD und ZDF HD. Zumindest bei mir im Kabel.


    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

  • Zitat

    Die Problemkanäle senden ja in 720p/50, also mit 50 Vollbildern pro Sekunde, und nicht, wie ich irrtümlich angenommen hatte, mit 25. Nach Anwendung von folgendem Patch läuft bei mir der schnelle Vor- und Rücklauf bei solchen Kanälen ohne jede Artefakte.


    Das ist ein interessanter Grund.
    Da hatte ich extra einen Workaround in den Vomp client code für HD eingebaut, um die 50 fps als 25 fps (bzw. 60 fps als 30 fps) abzufangen.
    Den muß ich jetzt wohl irgendwie deaktivieren.


    Marten

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

  • Nur aus Interesse, ergibt sich das mit den 50 Frames nicht aus der Angabe in den Sendeformaten? Also 720p50 und 1080i50?


    Dementsprechend wird doch auch 1080i hier in Europa mit 50 Frames gesendet, wobei jeder Frame eben ein Halbbild ist, wie auch bei 576i50 und bei 720p(rogressive) eben dann ein ganzes Bild. Warum steht da dann F25 in der Info Datei?


    Ist kein Gemaule, ich möchte es nur verstehen.


    Gruß
    Frank

    HowTo: APT pinning