Artefakte bei schnellem Vorlauf in HD-Aufzeichnungen

lostinspc · 31. Oktober 2010

Zitat

Originally posted by kls
....
Könnt ihr das bitte mal mit diversen Ausgabedevices verifizieren?
....

Mit dem xine-Plugin / xine-ui hatte ich das Problem ja ursprünglich auch. Bin allerdings zwischenzeitlich (aus anderen Gründen) auf xineliboutput / vdr-sxfe umgestiegen. Dort funktioniert das Spulen von HD-Kanälen ohne Artefakte bei meiner Config "out of the box" (sofern nalustripper verwendete wird).

Lange Rede kurzer SInn: Ich konnte bisher mit dem Patch bei xineliboutput / vdr-sxfe bei HD-Aufnahmen mit neu generiertem Index keine negativen Auswirkungen feststellen, Spulen funktioniert nach wie vor einwandfrei.

Grüße, Peter

3PO · 31. Oktober 2010

Zitat

Original von lostinspc
[...] mit neu generiertem Index ...

Wie erstellt man denn eine neue "index" bei HD Aufnahmen?

wbreu · 31. Oktober 2010

Zitat

Original von C-3PO

Wie erstellt man denn eine neue "index" bei HD Aufnahmen?

Na,

index-Datei der Aufnahme löschen, Wiedergabe der Aufnahme im VDR starten und schauen was das OSD sagt....

Gruß
Wolfgang

kls · 31. Oktober 2010

Zitat

Originally posted by MartenR
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.

Den dürftest du ganz ausbauen können

Möglicherweise läßt sich ja auch der Zweig

Code

else if (Delta == 1501) {
                             frameDuration = 3003; // NTSC, 29.97 fps
                             framesPerPayloadUnit = -2;
                             }

entsprechend ändern, denn das dürfte ja eigentlich 59.94 fps sein.
Damit würde das ganze "framesPerPayloadUnit < 0"-Handling entfallen, was ja eh nur ein Workaround war, da ich das nicht richtig gesehen hatte, daß das 50 bzw. (ca.) 60 Frames pro Sekunde sind.

Hat jemand Zugang zu NTSC-Sendungen mit 60 fps und kann das mal testen, indem er obige Zeilen zu

Code

else if (Delta == 1501)
                             frameDuration = 1501; // NTSC, 59.94 fps

ändert, eine Aufnahme macht und bei deren Wiedergabe den schnellen Vor-/Rücklauf testet?

Ich weiß, 1501 stimmt nicht genau, es müsste wohl 1501.5 heißen, aber dafür muß erst frameDuration zu 'double' werden. Für einen groben Test würde das hier aber schon reichen.

Klaus

kls · 31. Oktober 2010

Zitat

Originally posted by fnu
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?

Weil ich das nicht gecheckt hatte, daß das bei ARD ung ZDF 50 Vollbilder pro Sekunde sind
Ich dachte, die senden einen Frame aufgeteilt in zwei Payloads, und hatte deswegen diesen Workaround mit "framesPerPayloadUnit < 0" eingebaut. Wie ich jetzt sehe, braucht's das aber gar nicht...

Die Angabe in der 'info'-Datei ist immer die Zahl der Vollbilder pro Sekunde. Bei Aufnahmen mit dieser Änderung steht da dann künftig gleich 50 drin.

Klaus

fnu · 31. Oktober 2010

kls

Ja, bei 720p hatte ich das schon begriffen, dass ein Missverständnis vorlag.

Aber 1080i sind ja nun auch 50 Frames pro Sekunde, wenn auch Halbbilder, da komme ich mit dem Eintrag "F 25" in der info-Datei nicht ganz mit?

Mir war zumindest so, als ob VDR selbst nicht Vollbilder aus Halbbildern zusammenbaut, also neudeutsch deinterlace'd.

Gruß
Frank

kls · 31. Oktober 2010

Zitat

Originally posted by fnu
kls

Ja, bei 720p hatte ich das schon begriffen, dass ein Missverständnis vorlag.

Aber 1080i sind ja nun auch 50 Frames pro Sekunde, wenn auch Halbbilder, da komme ich mit dem Eintrag "F 25" in der info-Datei nicht ganz mit?

Mir war zumindest so, als ob VDR selbst nicht Vollbilder aus Halbbildern zusammenbaut, also neudeutsch deinterlace'd.

Alles anzeigen

Tut er auch nicht.

Bei 1080i sind in einer Payload die beiden Halbbilder drin. VDR "sieht" also 25 Payloads pro Sekunde, daher die 25 fps. Für VDR ist nur die Zahl der Vollbilder pro Sekunde wichtig.

Klaus

fnu · 31. Oktober 2010

kls

Danke für die Erklärung, jetzt habe ich endlich mal eine Antwort auf eine für mich alte Frage. Ich habe mich immer gefragt, ob es bei es sich um 50 "unabhängige" Halbbilder oder um 25 Paare handelt, die wie auch immer geartet synchronisiert sind.

Gruß
Frank

lostinspc · 7. November 2010

kls

Ich hatte heute mit patch beim Aufnehmen von "Polizeiruf 110" auf ARD HD noch ein merkwürdiges Phänomen: Ich habe die Sendung aufgenommen und gleichzeitig live angesehen. Als ich nach dem Ende der Sendung (um 21:45, Aufnahme lief noch) in das Recordings-Menü gegangen bin, wurde dort eine Aufnahme-Länge von 188 min angezeigt (was natürlich nicht stimmte, da die Aufnahme erst um 20:12 gestartet wurde)
Nach einem "touch" des video-dirs und erneutem Aufruf des Recording-Menüs wurde die korrekte Aufnahmelänge von 93 Minuten angezeigt.

Keine Ahnung wo das herkommt, werde in Zukunft mal verstärkt darauf achten.

Grüße, Peter

Atechsystem · 8. November 2010

Zitat

Mit dem xine-Plugin / xine-ui hatte ich das Problem ja ursprünglich auch. Bin allerdings zwischenzeitlich (aus anderen Gründen) auf xineliboutput / vdr-sxfe umgestiegen. Dort funktioniert das Spulen von HD-Kanälen ohne Artefakte bei meiner Config "out of the box" (sofern nalustripper verwendete wird).

Lange Rede kurzer SInn: Ich konnte bisher mit dem Patch bei xineliboutput / vdr-sxfe bei HD-Aufnahmen mit neu generiertem Index keine negativen Auswirkungen feststellen, Spulen funktioniert nach wie vor einwandfrei.

Grüße, Peter

Hallo,

das kann ich leider nicht bestätigen. Ich habe meinen VDR (1.7.16) mit dem nalustripper patch compiliert aber das Spulen funktioniert weder vor noch zurück nicht Fehlerfrei. Verwendest du außer diesem Patch noch einen anderen für die xinelib oder xinelibout?

Rechne rist der aus meiner Signatur, Software ist aber eine Testpartition mit aktuellem VDR, xine-1.2, vdr-xine und xine-ui.

Gruß
Atech

lostinspc · 8. November 2010

Zitat

Originally posted by Atechsystem
das kann ich leider nicht bestätigen. Ich habe meinen VDR (1.7.16) mit dem nalustripper patch compiliert aber das Spulen funktioniert weder vor noch zurück nicht Fehlerfrei. Verwendest du außer diesem Patch noch einen anderen für die xinelib oder xinelibout?

Xinelib cvs siehe Sig. und der obligatorische Durchfliegerpatch, in meinem Fall v16-streamstart. Aber auch mit dem normalen Durchflieger v16 spult es sich in HD-Aufnahmen (ARD bzw.ZDF) vorwärts und rückwärts einwandfrei und ohne Artefakte. Xineliboutput isitnicht gepatcht, im VDR ist der patch aus diesem Thread.

Nalustripper habe ich übrigens nicht in den VDR gepatcht, sondern ich verwende das separate executable. Wenn ich Nalustripper nicht verwende, habe ich nach einigen Sekunden schnellem Vorspulen (3x) das Problem, dass wenn man die Geschwindigkeit wieder zurücknimmt (3x -> 2x -> 1x -> Play) es bestimmt 30 Sekunden dauert, bis der schnelle Vorlauf aufhört und die Aufnahme wieder mit normaler Geschwindigkeit und Ton wiedergegeben wird. Drücke ich statt die Geschwindigkeit zurückzunehmen die Pause-Taste und von da aus wieder auf Play, dann funktioniert es besser. Beim Rückwärtsspulen tritt dieser Effekt so nicht auf.
Desweiteren hängts auch vom Film bzw. der Stelle im Film aus, irgendwer zählt da wohl NALU's mit die besser ignoriert würden.

Bezüglich der Reproduzierbarkeit der Ergebnisse bei Dir: Ich verwende ffmpeg 0.6 und den Nvidia 256.53. Ggfs. macht das einen Unterschied. Speziell der Nvidia-Treiber hat im Vergleich zu dem steinalten 195.36.31 den ich bis vor ca. einem Monat verwendet habe das Systemverhalten deutlich verbessert.

Grüße, Peter

iNOB · 9. November 2010

Atechsystem

Hast du dein System so wie hier (v16 ist aktuell) + den Patch von Klaus gebaut? Falls es dann immer noch nicht klappt, einfach den Index der Aufnahme neu generieren lassen, dann sollte das auch bei dir funktionieren.

Gruß
iNOB

Atechsystem · 9. November 2010

Hallo zusammen,

schonmal Danke für die Antworten - jetzt wird die Sache interessant

Ich habe gestern den Compiler heisslaufen lassen und lange getestet. Bisher habe ich zum HD schauen XBMC (PVR-testing) verwendet, da ich mit xine und dem Nvidia 195.35 (und auch aktuelleren Treibern) immer das "Stocken und Ruckelproblem" hatte. In XBMC trat dieses Problem aber auch manchmal auf. Wie es mit dem ganz neuen bzw. dem 256.53 ausschaut weiss ich nicht genau. Die letzte von mir getestete Treiber version lag in der Gegend aber ich habe es leider nicht notiert. Jedenfalls hat der Treiber bis dato nichts verbessert.

Jetzt habe ich folgendes erfolgreich in Betrieb:

- NVIDIA 195.30 mit Xorg 1.7.7 (gegen das Stocken im Livebild)
- VDR 1.7.16 mit nalus und dem Spulpatch von Klaus (natürlich noch weitere patches - aber die tun da nichts zur Sache)
- xinelib-1.2@11590 mit stream-start-patch
- vdr-xine 0.9.3
- xine-UI 0.96.6

Das ganze läuft soweit ich das gestern testen konnte Problemfrei
Das Verhalten bei Schnittmarken hab ich noch nicht getestet werde ich aber heute Abend nachholen.

Getestet und für gut befunden:

- Livebild ist Ruckelfrei
- Umschalten auf HD ist ohne Klötzchen
- Umschaltverhalten im gegensatz zu vorher 1-2 sek. (eher unter 2 sek.)
- Springen und Spulen in HD Aufnahmen funktioniert

Zu den Patchen (verhalten auf meinem System, Hardware siehe sign.):

nalus:

Ist aktuell mit drin aber hat bei meinem System keinerlei Auswirkung auf das Spulverhaten. Aufnahmen werden kleiner.

"Spulpatch" von Klaus:

Vor- und Zurückspulen funktioniert sowohl bei 720p als auch bei 1080i (AnixeHD und ServusTV HD). Spulen wirkt ein bisschen wie eine schnelle Diaschau (auch bei SD), ist aber nicht weiter störend.

stream start:

Hat bei meinem System keinerlei Auswirkungen auf das Spulverhalten. Mit Patch entstehen keinerlei Klötzchen beim Umschalten oder nach dem Play drücken beim Spulen (ohne treten diese auf). Beim abspielen von HD Aufnahmen Spielt das Video zu Beginn ein wenig zu langsam, das korrigiert sich aber binnen 10-20 Sekunden (Ton OK).

vdpau extension patch (v16) mit und ohne stream start patch:

Funktioniert bei mir leider nicht. Nach dem starten hängt sich xine-UI und xinelibout mit dem "no Signal" Bild auf. Durchflieger hat sich freundlicherweise der Sache angenommen.

Noch eine Feststellung:

Wenn ich eine laufende Aufnahme abspiele und kurz vor dem Ende (ca. 1-2 Minuten vorher) das Spulen beginne fängt das Bild irgendwann an zu Ruckeln und der VDR reagiert auf meine Eingaben (Play, Pause, Exit, etc.) nicht mehr. Dieses Verhalten habe ich auch ohne Patches bei SD und HD seit dem VDR 1.7.14 - irgendwann fängt sich der VDR wieder und die Befehle werden nacheinander abgearbeitet. Beim Spulen in fertigen Aufnahmen habe ich dieses Problem aber nicht.

Zitat

Nalustripper habe ich übrigens nicht in den VDR gepatcht, sondern ich verwende das separate executable. Wenn ich Nalustripper nicht verwende, habe ich nach einigen Sekunden schnellem Vorspulen (3x) das Problem, dass wenn man die Geschwindigkeit wieder zurücknimmt (3x -> 2x -> 1x -> Play) es bestimmt 30 Sekunden dauert, bis der schnelle Vorlauf aufhört und die Aufnahme wieder mit normaler Geschwindigkeit und Ton wiedergegeben wird. Drücke ich statt die Geschwindigkeit zurückzunehmen die Pause-Taste und von da aus wieder auf Play, dann funktioniert es besser. Beim Rückwärtsspulen tritt dieser Effekt so nicht auf.

Das erinnert mich an die zwei Punkte die ich oben genannt habe: Ruckeln beim Einstieg in eine Aufnahme und kurz vor dem Beenden zu Spulen.

Soweit mal von meinen Erfahrungen.... jetzt ist HD mit xine verwendbar

Gruß
Atech

PS: Nochmal vielen Dank an alle Patch-developer !!

iNOB · 9. November 2010

Dann probier bitte einmal, ob das Schnittmarkenversetzen mit Bildaktualisierung geht. Nach meiner Erfahrung dürfte genau dies mit dem Streamstart-Patch nicht funktionieren.

Gruß
iNOB

Atechsystem · 9. November 2010

Hi iNOB,

das mache ich wenn ich Zuhause bin. Wie sind denn deine Erfahrungen mit dem nvidia 260 Treiber? Hattest du auch vorher dieses "Stocken und Ruckelproblem"? Ein besserer name fällt mir dafür nicht ein

Gruß
Atech

iNOB · 9. November 2010

Bei eingeblendetem OSD (SkinEnigmaNG 1920x1080) ruckelt die TV-Wiedergabe mit dem 260er bei mir nicht mehr (bewegter Text ist OFF). Die Vorgängerversionen hatten das Problem noch. Im xine.log kann ich allerdings nach wie vor noch verlorene Bilder ausmachen, wenn auch nur ab und zu. Ärgerlich gerade bei verschlüsselten Sendern (z.B. Sky), wenn aus dem Grund die Entschlüsselung abreisst und Pixelschrott aufgenommen wird.

Ansonsten sind die Hänger kaum mehr wahrnehmbar. Das kann aber auch daran liegen, dass ich mittlerweile nicht mehr so genau hinschaue, bei dem Schrott der einem geboten wird

Gruß
iNOB

jrie · 9. November 2010

Ich verwende vdr 1.7.16 mit dem nalustripper patch. Funktionierte bisher tadellos.
Seit ich den "Spulpatch" drin habe, geht zwar nun das vorwärts spulen (freu), aber das Bild wird beim Schnittmarkenversetzen nicht mehr aktualisiert.
Außerdem stimmen die angezeigten Zeiten nicht mehr, aber das könnte ev. auch am extrecmenu plugin liegen.

lostinspc · 9. November 2010

Zitat

Originally posted by jrie
Ich verwende vdr 1.7.16 mit dem nalustripper patch. Funktionierte bisher tadellos.
Seit ich den "Spulpatch" drin habe, geht zwar nun das vorwärts spulen (freu), aber das Bild wird beim Schnittmarkenversetzen nicht mehr aktualisiert.
Außerdem stimmen die angezeigten Zeiten nicht mehr, aber das könnte ev. auch am extrecmenu plugin liegen.

Damit wir Deine Ergebnisse nachvollziehen können, wäre eine aussagekräftige Sig. oder ein paar Angaben zum System (xine-plugin mit xine-ui oder xinelibout, Version von xinelib und Nvidia-Treiber, ....) ja mal nicht schlecht.

Bezieht sich Deine Aussage auf bestehende Aufnahmen (Index vorher gelöscht?) oder neue? Bei neuen Aufnahmen: mit markad behandelt, vielleicht sogar mit Option "-G"?

Grüße, Peter

Atechsystem · 10. November 2010

Zitat

Dann probier bitte einmal, ob das Schnittmarkenversetzen mit Bildaktualisierung geht. Nach meiner Erfahrung dürfte genau dies mit dem Streamstart-Patch nicht funktionieren. Gruß iNOB

Morgen,

habe das gestern ausprobiert und direkt wieder den compiler angeschmissen
Es klappt weder mit noch ohne stream_start patch. Die Schittmarken werden gesetzt, ich kann zwischen ihnen hin und her springen aber beim Sprung auf eine Marke wird das Bild nicht aktualisiert. Erst wenn ich Play drücke wird ab Marke wieder normal abgespielt (ohne stream start teilweise mit anfänglichen Artefakten). Ich habe zum Schluss alle patche entfernt (auch nalustripper, etc.) und auch dann wird beim Sprung auf eine Marke nicht aktualisiert. Allerdings ist mir grade augefallen, dass ich den "Spulpatch" von Klaus auch zum Schluss noch aktiv hatte. Da werd ich nochmal compilieren müssen

Zum "Spulpatch":

Gestern ist mir aufgefallen, dass beim Spulen zwischenzeitlich immer wieder Bilder durchblitzen die eigentlich nicht zur aktuellen Bilderkette gehören. Die Zeit stockt dann meistens kurz und es geht anschließend normal weiter. Kann das jemand bestätigen? Tritt auch ohne andere patche auf. Besonders auf Stufe 3 wird das deutlich.

Außerdem tritt meine obige Festellung bezüglich des Spulens zum Ende einer Datei auch in einer fertigen Aufnahme auf. Wenn ich kurz vor Ende der Aufnahme noch im Spulmodus bin, bzw. das Spulen starte, sehe ich eine Diaschau die sich entweder irgendwann fängt und der Abspielmodus beendet wird oder es wird plötzlich wieder abgespielt. Der VDR reagiert während dieser Zeit nicht auf Eingaben. Dieses Probelm ist unabhängig von den Patchen.

Noch kurz zum Nvidia:

Mit "Stocken und Ruckeln" meine ich nicht Ruckeln bei eingeblendeten OSD sondern, völlig vom OSD unabhängig, ein Stocken und Ruckeln des Livebildes. Das ganze ist bekannt und kann mit dem 195.30 Treiber umgangen werden. Daher meine Frage ob das mit dem ganz neuen Treiber auch auftritt.

Soweit meine Erfahrungen...

Gruß
Atech

Atechsystem · 10. November 2010

Original von jrie:

Zitat

Ich verwende vdr 1.7.16 mit dem nalustripper patch. Funktionierte bisher tadellos. Seit ich den "Spulpatch" drin habe, geht zwar nun das vorwärts spulen (freu), aber das Bild wird beim Schnittmarkenversetzen nicht mehr aktualisiert. Außerdem stimmen die angezeigten Zeiten nicht mehr, aber das könnte ev. auch am extrecmenu plugin liegen

Das hatte ich überlesen - damit ist ja bestätigt, dass es auch am Spulpatch liegen kann.

Gruß
Atech

Artefakte bei schnellem Vorlauf in HD-Aufzeichnungen

Jetzt mitmachen!

Teilen