Beiträge von LigH

    Grundlagen der analogen Fernsehtechnik von vor mehreren Jahrzehnten:


    Ein analoges PAL-Signal hat 625 Zeilen; davon enthalten aber nur 576 einen sichtbaren Bildinhalt (abzüglich zwei halber Zeilen, weil das Signal in der Bildschirmmitte beginnt bzw. endet). Vorher und nachher gibt es Zeilen mit Steuerpegeln und Zusatzdaten.


    Über die Länge einer Zeile gibt es ein Maximum an Helligkeitsschwankungen, die sich darstellen lassen, ohne dass es zu erheblichen Signalstörungen kommt. Laut ITU sind das 702 (in Worten: siebenhunderttzwei), was sich aus Modulations- und Signalfrequenzen in einem Timing in Mikrosekunden berechnen lässt. Das kann man aber nicht als "Pixel" bezeichnen, denn es ist ja ein analoges Signal mit Spannungsschwankungen, die zum An- und Absteigen so ein wenig ihre Zeit brauchen.


    Auf einer DVD werden Videos üblicherweise digital mit 720 Pixeln Breite gespeichert. Das ist eigentlich mehr, als ein analoges Fernsehsignal über FBAS verkraftet. Fernseher können das per Euro-SCART (RGB oder S-Video) noch sauber darstellen. Es kommt auch manchmal eine Breite von 704 Pixeln bei digitaler Speicherung vor, die auch verbreitete analoge Capture-Hardware bevorzugt ausgegeben hat.

    Es existiert zwar eine mehr oder weniger funktionierende Umsetzung von MKV-Menüs. Die erfordert aber, dass auch die Wiedergabegeräte dies erkennen und unterstützen. Auf einem PC müsste man sich dafür wohl einen experimentellen DirectShow-Splitter installieren oder einen Spezial-Player verwenden


    Eine Alternative wäre möglicherweise, wenn ein Player ein Blu-ray-Authoring mit AVCHD-Dateistruktur erkennt, so wie das wahrscheinlich multiAVCHD erzeugen kann.

    Damit wir uns nicht falsch verstehen. Die Ruckler entstehen nicht durch die Wiedergabe, sondern treten erst auf wenn ich den aufgenommenen Screencast ansehe.

    :/Den Unterschied verstehe ich nicht ganz. Aber vielleicht stelle ich mir unter einem "Screencast" auch das falsche vor? Erzähl mal mehr darüber, was bei dir passiert, welche Software verwendet wird, wie die eingestellt ist, ...


    Für "Ruckler" kann ich mir drei mögliche Ursachen vorstellen:

    1. Zwischen mehreren aufeinander folgenden Frames sind die Zeitabstände der Aufnahme unterschiedlich (Variable Frame-Rate bei der Aufnahme). Selbst wenn jede einzelne Frame-Dauer jeweils bei der Wiedergabe korrekt beachtet wird, fällt ja doch eine Unregelmäßigkeit im zeitlichen Fortschritt auf. Und falls eine VFR-Aufnahme mit CFR abgespielt wird, umso mehr. Wenn man sich das Video während eines theoretisch gleichmäßigen Schwenks Bild für Bild anschaut, sollten unterschiedliche Abstände bei der Bewegung auffallen.
    2. Es gibt Tearing bereits während der Aufnahme, also der Bildinhalt wechselt, während die Aufzeichnungssoftware den Bildschirminhalt ausliest. Das sieht man beim Anschauen von Einzelbildern des Materials.
    3. Das Tearing entsteht allein bei der Wiedergabe, das Material enthält saubere Bilder.


    Wie kann man das nun vermeiden?

    1. Weiß ich nicht genau... nicht jede Aufnahmesoftware lässt sich wohl zuverlässig auf konstante Framerate zwingen, es wird immer etwas auch vom Zeitbedarf der Komprimierung jedes Frames abhängen, der umso höher ist, je mehr sich im Bild verändert.
    2. Pech gehabt. Muss die Aufnahme-Software verhindern (vertical retrace).
    3. ist ein Zusammenspiel von Mediaplayer, Grafikkarte und Monitor. Im Vollbildmodus versuchen manche Player, eine Bildwiederholrate einzustellen, die der des Videos oder Vielfachen davon entspricht; wenn aber nicht mit einer aus der Fernsehtechnik standardisierten Framerate aufgezeichnet wurde, wird das u.U. nicht klappen.

    Tja, wenn was "ruckelt", gilt erst mal zu klären: Was und warum? Es wäre Zeitverschwendung, an der Encodierung herumzuoptimieren, wenn die Ursache im Tearing liegt, also dass der Bildinhalt wechselt, während der Monitor sein Bild aufbaut.


    Lösungen sind hier auch nicht immer trivial. Theoretisch sollte Tearing sich vermeiden lassen, wenn der Player mit dem Framewechsel wartet, bis der Monitor einen Bildaufbau abgeschlossen hat (wait for vertical retrace). Nach meiner Erfahrung funktioniert das aber bei meinen Flachbildschirmen mit Computerspielen, die das anbieten, gerade eben nicht, was paradox ist.

    Nein, AVC ist nicht "im Allgemeinen RGB". Ganz und gar nicht. "Main Profile" und "High Profile" sind YUV 4:2:0. Zumindest wie die Daten digital gespeichert sind. Wie Abspielgeräte das decodieren, bevor sie Signale an Fernseher ausgeben, hat damit nichts zu tun. Wenn du ein Abspielgerät hast, das HDMI oder RGB-Anschlüsse hat, dann kann das durchaus RGB-Signale ausgeben. Es ist richtig, dass Composite, S-Video und Euro-SCART üblicherweise bei älteren SD-Abspielgeräten eher moduliertes YUV ausgeben. Aber moderne HD-Abspielgeräte können auch älteres SD-Material zu RGB decodieren. Das ist unabhängig davon, dass das Main-Profile von MPEG2 und MPEG4 digital als Datei auf dem Datenträger YUV 4:2:0 speichert.

    AVI für MP4:

    Hat man vor, SD-Filme als mp4 zu archivieren, dann muss einSD-AVI mit 16-235 zu 0-255 konvertiert werden. Erst dann zu mp4 wandeln.

    MP4ist ein RGB-Codec mit 0-255. Deswegen sind ca. 98% der Filme auf YT falscherstellt, da nicht auf 0-255 konvertiert wurde.

    Auch die RGB-Farben könntenclippen.

    So viel Blödsinn auf einmal hab ich ja schon lange nicht mehr gelesen...


    1. MP4 ist ein Container, kein Codec.


    2. Alle MPEG-Videocodecs – MPEG1, MPEG2, MPEG4-(A)SP, MPEG4-AVC, HEVC – unterstützen den YUV-Farbraum, weil der effizienter encodiert werden kann als RGB, indem man Eigenschaften der menschlichen Augen ausnutzt.


    3. MPEG4-AVC unterstützt auch Video in vollem Farbumfang. Üblich ist aber weiterhin der reduzierte Farbumfang aus den Standards der Fernsehtechnik. Dafür gibt es aber mehr als eine Umrechnungsmatrix von YUV zu RGB: In Zeiten von MPEG1 und MPEG2 mit SD-Auflösung war Rec601 verbreitet, seit den HD-Formaten wird jedoch Rec709 verwendet, und HEVC unterstützt sogar hohen Dynamikumfang mit Rec2020.


    4. Wenn Videos auf Videoportalen falsch aussehen, dann liegt das nicht daran, dass sie nicht in RGB konvertiert wurden, sondern eher dass sie während einer vorherigen Bearbeitung in RGB konvertiert wurden und dann vor dem Hochladen falsch neu encodiert wurden. Mit so teuren kommerziellen Programmen wie Adobe Premiere kann man hier mehr falsch machen als mit kostenlosen AviSynth-Skripten...

    Ich erkenne da nicht viel Stocken, das meiste sieht für mich ziemlich flüssig aus. Ausnahme vielleicht bei 2:34, wenn der Gefoulte aufsteht, da sehe ich im Vollbild etwas, das an "Tearing" erinnert, also dass ein Bildwechsel mitten im Bildaufbau des Monitors passiert. Da sollte man diese Szene vielleicht mal langsam analysieren, ob das ein Problem des Materials oder der Wiedergabe ist. Kann ich aber im Moment nicht.

    Selur - ich dachte, du meinst, dass MP4Box beim Multiplexen was inkompatibles erzeugt. Dass der MPC-HC der einzige Player ist, bei dem das nicht klappt, kam da im Startbeitrag noch nicht so eindeutig rüber. Also: englisches doom9-Forum. Müsste ja dann an LAV Filters liegen?


    Ach ja, den MPC-HC auch besser gleich mit dem MPC-BE vergleichen, die unterscheiden sich auch marginal.

    Es ist möglich, die Farben und den Deckungsgrad der Untertitel zu ändern. Das können die alten VobSub-Tools. ACHTUNG: Den DirectShow-Filter will man daraus heute wohl nicht mehr verwenden!


    Die Schrift kann man nicht ändern, weil DVD-Untertitel als Pixelgrafiken gespeichert sind. Da müsste man sie schon per OCR (Zeichenerkennung) in reinen Text konvertieren lassen, allerdings ist das kein idiotensicheres Verfahren, je nach Schriftart, die in den Untertiteln verwendet wurde.