Felias hat geschrieben:Bei der Kodierung lasse ich einen Deinterlacing-Filter drüber laufen, der die konstanten Deinterlacing-Artefakte rausfiltert.
Jeder Deinterlacer steht vor dem Problem, daß ihm Informationen fehlen. Eine Ausnahme machen hier Kinofilme, die mit 24 Vollbildern pro Sekunde produziert wurden und in PAL-Ländern mit 25 fps gesendet werden (PAL-Speedup). Hier stammen die beiden Halbbilder vom gleichen Vollbildframe, es gibt also keinen zeitlichen Versatz. Diese Halbbilder kann man einfach wieder zusammenkleben (Weave), ohne daß Artefakte auftreten.
Anders sieht es bei Material aus, daß von einer elektronischen Kamera stammt. Die liefert 50 Halbbilder. Die zwei Halbbilder, die zu einem Frame gehören, stammen von unterschiedlichen Zeitpunkten. Wenn man die jetzt einfach zusammenklebt, bekommt man an den Stellen, wo sich das Bild bewegt, ausgefranste Kanten. Weave kann man hier also vergessen.
Der bessere Ansatz für Material mit Zeilensprung ist also, von 50 Halbbildern irgendwie auf 50 Vollbilder zu kommen. Am einfachsten geht das, indem ich einfach jede Zeile verdopple. Das ändert aber nichts daran, daß meine 50 Vollbilder jetzt nur die halbe vertikale Auflösung haben. Mehr Informationen stecken in einem Halbbild nun mal nicht drin. Dafür ist auch dieses Verfahren frei von Artefakten.
Jedes moderne Verfahren zum Deinterlacing versucht nun, die fehlende Zeilen pro Halbbild geschickt zu raten. Die Verfahren werden immer aufwendiger. Es werden zum Teil Bewegungen über mehrere Frames analysiert, um beim Pixellügen möglichst Zeilen zu generieren, die so aussehen, wie die Originalzeile ausgesehen hätte, wenn sie denn jemals überhaupt aufgenommen worden wäre. Das klappt zum Teil erstaunlich gut. Bei bestimmten Bildinhalten geht es aber auch mal schief, bei Laufschriften zum Beispiel. Das grundsätzliche Problem bleibt: Man muß Bildinformation erfinden, weil man sie nicht hat.
Ich erkläre das hier so ausführlich, um dir klarzumachen, daß es den oben von dir beschriebenen Deinterlacingfilter, der garantiert artefaktfrei aus 50 Halbbildern mit jeweils halber Auflösung, 50 Vollbilder mit voller Auflösung generiert, nicht gibt und auch nicht geben kann.
Übrig bleibt ein ruhig laufender Stream, der allerdings im Abstand von knapp einer Sekunde eine kurzen Hänger hat. Im .ts-Stream sind genau diese Ruckler ebenfalls, wenn auch etwas minimaler zu erkennen.
An dieser Stelle kommen wir zum nächsten Problem. Nachdem wir uns aus 50 Halbbildern 50 Vollbilder zusammengelogen haben, gucken wir uns das Ganze auf einem Display an, das mit 60 Hz arbeitet. Wir geben also in einer Sekunde 50 Bilder sechszigmal aus. Jedes fünfte Bild bekommen wir also zweimal zu sehen. Das ruckelt. Noch blöder wird es, wenn der Bildwechsel des Displays mit dem Bildwechsel des Videostreams nicht synchronisiert ist. Die Abhilfe für das erste Problem besteht darin, Zwischenbilder zu berechnen, um so aus den 50 Vollbildern 60 Vollbilder zu machen. Jetzt erfinden wir also nicht nur Zeilen, die nie aufgenommen wurden, sondern sogar komplette Frames.
Bist Du sicher, dass dies Interlacing-Ruckler sind? Denn meiner Erfahrung treten die Deinterlacing-Ruckler eher beim Aufbau eines jeden Bildes auf, und nicht nur bei jedem ... ~20 Bild?
Es können Deinterlacing-Ruckler sein. Es kann aber auch mit dem eben geschilderten Problem zusammenhängen, daß sich 50 Vollbilder nun einmal nur sehr schwer auf einem 60 Hz-Display darstellen lassen. Bei gleichmäßigen Bewegungen, wie einer Laufschrift, sieht man so etwas sehr viel besser, als bei anderen Bildinhalten.
Hast du noch einen alten Ferseher, also Röhrengerät ohne 100 Hz-Gedöns? Wenn ja, dann gib den TS-Stream mal über die D-Box auf der Kiste wieder. Du wirst feststellen, daß da plötzlich gar nichts ruckelt.
Ich verallgemeinere ja auch nicht. Ihr habt sicher recht, dabei geht Qualität verloren. Für mich ist es aber ein optimaler Kompromis aus Qualität und Speicherplatz. Allerdings natürlich nur, wenn ich es ruckelfrei hinbekomme. Momentan liegen die Filme noch alle in .ts-Format vor.
