[softhddevice 0.5.1] Aufnahmen und Schnittmarken

Moin,

Im Config File von xine bzw. xineliboutput:

#engine.decoder_priorities.ffmpegvideo:0
#engine.decoder_priorities.vdpau_h264:0
#engine.decoder_priorities.vdpau_h264_alter:0

Johns

Also ich habe mir beim Suchen des Fehlers von "ABC News 24" das Ganze noch einmal angesehen.

Mit Software Dekoder funktioniert es die Schnittmarken zu verschieben.
Ich bekomme aber diesen Fehler:

[mpeg2video @ 0x7fc2ec3fe320] releasing zombie picture
[mpeg2video @ 0x7fc2ec3fe320] ac-tex damaged at 79 44
[mpeg2video @ 0x7fc2ec3fe320] concealing 50 DC, 50 AC, 50 MV errors

Mit Hardware Dekoder funktioniert es nicht.
Es kommt nur:

[mpegvideo_vdpau @ 0x7fb1283f4340] releasing zombie picture

Meine Vermutung ist, daß der Softwaredekoder mit Fehlern besser zurecht kommt.

Als Lösung wäre eigener Mpeg Parser, wie xine, wenn es mit xine-lib immer klappt.
Oder umschalten auf Softwaredekoder für Standbilder, wenn der Softwaredekoder immer klappt.

Man kann mit

• -wno-hw-decoder alle Hardwaredekoder ausschalten.
• -no-mpeg-hw-decoder nur den MPeg Hardwaredekoder ausschalten.

Ausgabe erfolgt weiterhin über VDPAU mit dem eingestellten VDPAU Deinterlacer.

Johns

Falls das der Schnipsel ist von hier, dann kann ich darin auf meiner TT S2-6400 Schnittmarken problemlos setzen und verschieben.

Das nur zur Info - ich möchte beileibe keinen "Software vs. Hardware"-Disput vom Zaun brechen. Aber vielleicht hilft dir ja der Hinweis, daß die Daten vielleicht nicht unbedingt fehlerhaft sind. Vielleicht ist aber auch der Decoder in der Karte toleranter...

Klaus

Ja dieses Schnipsel meinte ich.

Danke das du nochmal bestätigst, daß die StillPicture Daten vom VDR ok sind.
Dieses habe ich schon vermutet, da ja der Software Dekoder diese vernünftig anzeigen kann.
Bzw. auch xine-lib funktioniert.

Die Schnittmarken sind das einzige verbleibende große Problem in meinem Plugin.
Johns

So hier ein Patch: Es wird nun der Software Dekoder für Standbilder verwendet.

Alle Testschnipsel HDTV/SDTV/HD+ haben beim Schnittmarken verschieben ein Bild gezeigt,
welches sich auch veränderte.

Wenn man die Schnittmarken schnell verschiebt, gibt es immer noch ein Nachlaufen.

Bitte um Feedback,
Johns

Zitat von johns

So hier ein Patch: Es wird nun der Software Dekoder für Standbilder verwendet.

Coole Idee!

Gerald

Funktioniert gut, aber als ich die Wiedergabe beendet habe, ist er mir mit nem segfault ausgestiegen.

Zitat von johns

So hier ein Patch: Es wird nun der Software Dekoder für Standbilder verwendet.

Wenn ich mich recht entsinne, dann war das bei der Reel-eHD nach Umstellung auf > vdr-1.7.x mit *.ts-Streams auch so gelöst!
Da hatten wir oftmals auch nur ein schwarzes Bild bei Schnittmarken.

Paulaner

Zweiter Test ohne segfault, aber keine Verbesserung, es geht um die Aufzeichnung Hitch - Der Date Doktor von Sat1 HD, da bleibt das Bild sauber stehen (Erster Test war eine Aufzeuchnung von Kabel1 HD).

Jetzt habe ich versucht einen Testschnipsel davon zu erstellen und dabei den index neu aufgebaut, jetzt lässt sich die Schnittmarke wunderbar verschieben ...
segfault ist auch keiner mehr aufgetaucht.

Zitat von johns

So hier ein Patch: Es wird nun der Software Dekoder für Standbilder verwendet.

Alle Testschnipsel HDTV/SDTV/HD+ haben beim Schnittmarken verschieben ein Bild gezeigt,
welches sich auch veränderte.

Wenn man die Schnittmarken schnell verschiebt, gibt es immer noch ein Nachlaufen.

Keine schlechte Idee. Ein einzelnes Standbild sollte ja auch nicht sonderlich rechenaufwendig sein.

Testergebnis folgt.

Zitat von jsffm

Funktioniert gut, aber als ich die Wiedergabe beendet habe, ist er mir mit nem segfault ausgestiegen.

segfault sollten nicht sein, können jetzt bei fehlerhaften Streams durch den Software Path kommen.

Johns

habe gerade es mit FOXHD und RTLHD getestet. Ich hatte nun auch immer ein Bild beim Verschieben. Beim Wiedergabestart nach dem Anspringen einer Schnittmarke gibt es zwar immer noch Pixelsalat, aber ausgestiegen ist er bei den 2 Versuchen nicht.

Kann es sein, dass das Verschieben mit der 4/6 andere größere und schwankende Schrittweiten macht als bei Xine? Da kommt mir das deutlich feiner vor, hier schwankt es zwischen 0,3-1s bei 1080i Sendungen und bei 720p ist es konstanter bei ca. 0.4s. D.h. ich kann nicht so exakt die Filmstart und Endposition anpeilen. Die 5s. Sprünge sind beim Verschieben hingegen exakt.

Außerdem fällt mir auf, dass das Verschieben der Schnittmarken eine sehr spürbare Zeit nachläuft (mehrere Sekunden), d.h. Ich halte die Taste 1 o. 3 gedrückt und wenn ich loslasse läuft das ganze noch munter weiter. Und das auf meinem Xeon Server, der wahrlich mehr als genug Power hat. htop zeigt auch nur eine geringe Systemlastzunahme.

Beim Springen während der Wiedergabe (ohne Schnittmarken auszuwählen) sind weiterhin bei HD Auflösungen Verpixelungen/Kästchen kurz nach dem Start der Wiedergabe zu erkennen. Dies ist nur bei sich stark ändernden Flächen der Fall, z.B. ein bewegter Arm, oder bei laufenden Menschen.

Das mit dem Pixelsalat nach dem Springen zur Schnittmarke kommt mir so vor wie als wenn der Wiedergabepuffer nicht ausreichend vor wiedergabestart syncronisiert wird. Vermutlich weil hier nicht die gleiche Sync Technik wie beim Starten der Wiedergabe bei Filmbeginn oder zappen zw. den Kanälen verwendet wird?
Was ich nicht verstehe, was ist anders an dem Start der Wiedergabe nach Pause irgendwo im Film und nach dem Start einer Pause an der Schnittmarke? Ersteres hat keine Klötzchenbildung.

Ist zwar vielleicht nicht die optimalste Lösung, aber auf jedenfall besser als vorher

Und danke für das schnelle Einstellen in yavdr-stable

Zitat von Torsten73

habe gerade es mit FOXHD und RTLHD getestet. Ich hatte nun auch immer ein Bild beim Verschieben. Beim Wiedergabestart nach dem Anspringen einer Schnittmarke gibt es zwar immer noch Pixelsalat, aber ausgestiegen ist er bei den 2 Versuchen nicht.

Das passiert nur beim Übergang von Standbild zur Wiedergabe?

Zitat

Kann es sein, dass das Verschieben mit der 4/6 andere größere und schwankende Schrittweiten macht als bei Xine? Da kommt mir das deutlich feiner vor, hier schwankt es zwischen 0,3-1s bei 1080i Sendungen und bei 720p ist es konstanter bei ca. 0.4s. D.h. ich kann nicht so exakt die Filmstart und Endposition anpeilen. Die 5s. Sprünge sind beim Verschieben hingegen exakt.

Da bin ich überfragt, wie es VDR Intern macht. Ich stelle nur das da was mit der VDR als Standbild übergibt, dar.

Zitat

Außerdem fällt mir auf, dass das Verschieben der Schnittmarken eine sehr spürbare Zeit nachläuft (mehrere Sekunden), d.h. Ich halte die Taste 1 o. 3 gedrückt und wenn ich loslasse läuft das ganze noch munter weiter. Und das auf meinem Xeon Server, der wahrlich mehr als genug Power hat. htop zeigt auch nur eine geringe Systemlastzunahme.

Siehe Post mit dem Patch: Dies ist ein bekanntes Problem. Ich muß noch die Ursache suchen.

Zitat

Beim Springen während der Wiedergabe (ohne Schnittmarken auszuwählen) sind weiterhin bei HD Auflösungen Verpixelungen/Kästchen kurz nach dem Start der Wiedergabe zu erkennen. Dies ist nur bei sich stark ändernden Flächen der Fall, z.B. ein bewegter Arm, oder bei laufenden Menschen.

Das mit dem Pixelsalat nach dem Springen zur Schnittmarke kommt mir so vor wie als wenn der Wiedergabepuffer nicht ausreichend vor wiedergabestart syncronisiert wird. Vermutlich weil hier nicht die gleiche Sync Technik wie beim Starten der Wiedergabe bei Filmbeginn oder zappen zw. den Kanälen verwendet wird?
Was ich nicht verstehe, was ist anders an dem Start der Wiedergabe nach Pause irgendwo im Film und nach dem Start einer Pause an der Schnittmarke? Ersteres hat keine Klötzchenbildung.

Siehe erste Frage. Also bei jedem Spung gibt es den Pixelsalat?
Egal ob beim Laufenden Film mit Rot/Grün oder mit Patch 1 und 3.
Oder beim Schneiden bei dem Start von der Wiedergabe.

Die Pause bei der normalen Wiedergabe ist ein Sonderfall, da werden nur Bild und Ton eingefroren und keinerlei Puffer gelöscht.
Bei Sprüngen wird alles verworfen und der gesamte Stream neu synchronisiert.

Es könnte auch der Deinterlacer sein, ich glaube dessen Referencen werden nicht zurückgesetzt.
Dann dürfte es 720p Sendern nicht der Fall sein.

Johns

Je nach Quellmaterial messe ich 80ms bis 300ms, wobei die 300ms vereinzelte Ausreiser sind.

Da ich 4x ein Bild ausgebe, damit die Ausgabepuffer gefüllt sind, stimmt es.
4 * 20ms = 80ms bei 50Hz Progressive, bzw. 4 * 40ms = 160ms bei 50Hz Interlaced.
Damit liegen die Zeiten im zu erwartenden Rahmen.

Wenn nun der Tasten Repeat kleiner ist, kommt es zu dem Nachlaufen,
Johns

Zitat von johns

Das passiert nur beim Übergang von Standbild zur Wiedergabe?

Zitat von johns

Siehe erste Frage. Also bei jedem Spung gibt es den Pixelsalat?
Egal ob beim Laufenden Film mit Rot/Grün oder mit Patch 1 und 3.
Oder beim Schneiden bei dem Start von der Wiedergabe.

Die Pause bei der normalen Wiedergabe ist ein Sonderfall, da werden nur Bild und Ton eingefroren und keinerlei Puffer gelöscht.
Bei Sprüngen wird alles verworfen und der gesamte Stream neu synchronisiert.

Es könnte auch der Deinterlacer sein, ich glaube dessen Referencen werden nicht zurückgesetzt.
Dann dürfte es 720p Sendern nicht der Fall sein.

Alles anzeigen

720P (ARDHD Rote Rosen) : Das Springen verursacht nur ganz kurz Klötze bei bewegten Elementen
1080i: Die Klötzchen sind kleiner, aber auch stärker und etwas länger zu sehen.

Es ist egal ob man eine Schnittmarke anspringt oder nur so frei springt. Klötze gibt es immer.
Nur bei Schnittmarken ist das komplette Bild verpixelt und es dauert gut 1s-1,5s bis das Bild normal aussieht. Im Grunde bleibt dabei der alte Inhalt stehen, zerfällt dann und wird langsam vom neuen Inhalt ersetzt. Das hat man beim normalen Springen nicht.

Warum fügst Du nicht einfach nach einem Sprung ganz kurz eine Pause ein, damit die Puffer mit dem neuen Inhalt syncron gefüllt werden? Also praktisch nach jedem Sprung intern für 0,3s Pause machen und dann erst die Wiedergabe starten. Und bei der Pause sicherstellen, dass das erste Bild der nächsten Wiedergabeposition wiedergegeben wird.
Cool wäre es den Pufferfüllstand zu berücksichtigen, d.h. erst die Wiedergabe starten wenn der gefüllt ist. Denn dann wird auch die unterschiedliche Systemleistung berücksichtigt.

Naja ist nur ne Idee, keine Ahnung ob das umsetzbar ist oder auch nur ein umgehen des eigentlichen Problems darstellt. Der Nachteil einer solchen Lösung wäre dann natürlich ein langsameres Springen, aber Xine hat auch eine leichte Verzögerung beim Springen und solange die nicht zu lange ist, würde ich das in Kauf nehmen. Immer noch besser als Pixelsalat.

Hallo Torsten,

da kann ich Dir nicht zustimmen. Pixelsalat nach einem Sprung stört mich eigentlich nicht, eine Wartezeit aber schon. Vor allen, wenn ich eine etwas längere Zeit durch öfteres Drücken der Springen Taste springen möchte.

- Markus

Ich frage deshalb so doof, weil es mir nicht aufgefallen ist.
Es könnte an den Optionen:

softhddevice.BlackPicture = 0
softhddevice.SoftStartSync = 1

liegen oder an der FFMPeg/libav Version.

Einzig bei alten Aufnahmen im ".vdr" (PES) Format, sehe ich beim Starten kurz Pixelsalat.

Viel kann man gegen den Pixelsalat nicht machen, da ich keinerlei Information über die
Qualität von FFMpeg bekomme. Nur total kaputt oder kann angezeigt werden.
Wenn es jemand mehr weiss, bitte melden. Ansonsten gucke ich mal ffmpeg code ob
ich was finde.

Ansonsten dürfte nur ein paar Frames defekt sein, bis man alle Referenceframes zusammen hat,
das sind 2 Frames bei Mpeg und bis zu 17 Frames bei HDTV.

Ich werde mal suchen und beim Spulen/Springen genau achten ob mir etwas auffällt,
Johns

Ich habe den Patch jetzt auch getestet.

Wenn ich Schnittmarken schnell verschiebe (4 oder 6 gedrückt halte), flackert das Bild. So als ob zwischen jedem Stillpicture ein schwarzes Stillpicture eingefügt wird.

Zitat von johns

Ich frage deshalb so doof, weil es mir nicht aufgefallen ist.
Es könnte an den Optionen:

Code

softhddevice.BlackPicture = 0
softhddevice.SoftStartSync = 1

liegen oder an der FFMPeg/libav Version.

Hier wäre es eventuell angebracht dem Nutzer gar nicht mehr die Wahl zu lassen.

Zitat von Torsten73

720P (ARDHD Rote Rosen) : Das Springen verursacht nur ganz kurz Klötze bei bewegten Elementen
1080i: Die Klötzchen sind kleiner, aber auch stärker und etwas länger zu sehen.

ARD liegt an libav, mit ffmpeg habe ich keine Probleme. Mit libav sehe ich ein Bildverwackeln, wobei es keine Klötzchen sind.
Sondern sieht aus wie ein verwackeltes Bild.

Sowohl mit libav als auch mit ffmpeg hat hier ein RTL HD Aufnahme extreme Probleme beim Springen.

Ich habe mal versucht die ffmpeg/libav Fehlererkennung schärfer zustellen, aber ich kann keinen Unterschied erkennen.
Scheint sehr vom Sender und von ffmpeg/libav abzuhängen.

Zitat von Copperhead

Ich habe den Patch jetzt auch getestet.

Wenn ich Schnittmarken schnell verschiebe (4 oder 6 gedrückt halte), flackert das Bild. So als ob zwischen jedem Stillpicture ein schwarzes Stillpicture eingefügt wird.

Schalte BlackPicture aus, dann sind die Schwarzen Bilder weg. Ich muß mal suchen wie ich dies automatisch hinbekomme.

Zitat

Hier wäre es eventuell angebracht dem Nutzer gar nicht mehr die Wahl zu lassen.

Da möchtige ich nicht das Geschrei hören, wenn meine Wünsche der Default sind.

Johns