Beiträge von LigH

    Da wirst du wohl für das Verständnis noch sehr viel Grundlagenwissen lernen müssen über das Zeilensprungverfahren, analoge Fernsehtechnik des vergangenen Jahrhunderts, DCT (Diskrete Cosinus-Transformation) als Basis der meisten modernen digitalen Bild- und Videoformate (v.a. JPEG und MPEG)... 17 Mbps für SD-Video scheint erstmal großzügig zu sein, aber wenn du sehr schnelle Bewegungen hast, dann sind die Stellen im Video, bei denen man bei Vollbild-Anzeige Combing (Kammstrukturen) sieht, im Progressiv-Modus nur mit stärkeren Qualitätsverlusten komprimierbar.


    Gemeint sind solche Muster wie in dieser Tabelle unten links:

    MediaInfo zeigt im ausführlichen Protokoll an, was alles im Header steht. Genau deshalb habe ich ja danach gefragt.


    Grundsätzlich lassen sich die Seitenverhältnis-Flags korrigieren. Zumindest wenn man eine endgültig komprimierte Kopie erzeugt. Eventuell auch schon in der aufgezeichneten Datei, mit den richtigen Programmen.


    Aber dass das Gerät im Progressiv-Modus encodiert, ist eine erhebliche Schwachstelle. Daher nochmal: Lässt der sich konfigurieren?

    Gespeichert wird das Video immer mit 720x576 Pixeln. Zusätzlich steht in einem Header aber noch (wenn alles korrekt und vernünftig gespeichert wurde), dass das Video (anamorph) gestaucht gespeichert wurde und bei der Darstellung entzerrt angezeigt werden soll.


    Wenn es eine Markierung enthält, die aussagt: "Zeige das als 4:3 an", dann entzerrt der Fernseher den Inhalt bei der Wiedergabe auf ein Seitenverhältnis von 4:3 (als wäre es 768x576).

    Wenn es eine Markierung enthält, die aussagt: "Zeige das als 16:9 an", dann entzerrt der Fernseher den Inhalt bei der Wiedergabe auf ein Seitenverhältnis von 16:9 (als wäre es 1024x576).


    Leider kann ich im kurzen MediaInfo-Report nicht erkennen, dass dein DVB-T-Modulator einen solchen Hinweis in das AVC-Video oder in den MP4-Kontainer geschrieben hätte... in einem ausführlichen MediaInfo-Report würden wir klarer sehen, was alles an Flags drin ist und was nicht. Falls da tatsächlich explizit drin steht: "Zeige das als 5:4 an", wäre das technisch falsch.

    _


    PS: Oh, du hast eine ausführliche Logdatei angehängt. Leider ist es keine reine Textdatei, sondern ein Word-Dokument mit der Endung ".txt" (das Ändern einer Dateiendung ändert nicht den Dateiinhalt!). Dein DVB-T-Modulator macht tatsächlich den Fehler:

    Code
    1. Pixelverhältnis : 1.000

    Außerdem wird das Video progressiv encodiert. Schlechte Idee, falls der Inhalt tatsächlich interlaced sein sollte.


    Kann man das Teil konfigurieren? Die nominale Bitrate ist ja an sich nicht schlecht für Zwischenmaterial.

    Es ist sehr schwer, vollautomatisch festzustellen, ob der Videoinhalt tatsächlich halbbildweise in der Zeit voranschreitet. Das menschliche Gehirn ist bei der Erkennung von Bewegungen dem PC bei weitem überlegen.


    Video für DVDs wird daher praktisch immer so encodiert, dass der MPEG2-Videoencoder auf das Interlaced-Verfahren eingestellt wird, damit man bloß nicht aus Versehen die Qualität versaut. Was MediaInfo an Header-Flags ausliest, bedeutet also nur: So war der Encoder eingestellt. Das sagt aber nichts über den sichtbaren Videoinhalt aus.


    Der Vorteil von MPEG4 AVC-Video ist (insbesondere beim x264-Encoder, der dies unterstützt), dass die MBAFF-Technik tatsächlich nur die Bereiche im Video im Interlaced-Verfahren encodiert, bei denen eine progressive Encodierung erhebliche Qualitätsverluste bedeuten würde. Bei ruhigen Bildbereichen, in denen man keinerlei Veränderungen im zeitlichen Verlauf bemerkt, werden diese Bereiche aber progressiv encodiert, was bei Vollbildaufnahmen etwas bessere Qualität bringt.


    Insofern also der Rat beim Encodieren von Material, das vielleicht aufgrund seiner Herkunft halbbildweise aufgezeichnet worden sein könnte: Besser x264 auf Interlaced-Modus stellen. Den progressiven Standard-Modus nur verwenden, wenn man sich sicher ist, dass die Videoquelle auch nur Vollbilder enthält.


    Hinweis am Rande: Es gibt durchaus Programme, die versuchen, Interlacing automatisch zu erkennen. MeGUI und HDConvertToX bieten so etwas an. Dafür encodieren sie einen kleinen Ausschnitt ... Überraschung! ... mit x264 jeweils in TFF- und BFF-Interlacing und vergleichen die Effizienz in dessen Statistiken. Aber was, wenn der gewählte Ausschnitt dafür ungeeignet ist? Als Mensch überblickt man das gesamte Video.

    private Aufnahmen mit einer alten Sony Videokamera, ich glaube das sind noch Super8 Kassetten, kann ich bei Bedarf nochmal genau nachschauen.
    Wie kann ich den herausfinden ob Interlacing verwendet wurde?

    Kurz: Bei der Hardware wahrscheinlich ja.


    Ausführlich testen kann man es, indem man bei einem Konverter die Halbbild-Dominanz festlegt und dann "bobbt" (also alle Halbbilder in Vollbilder interpolieren lässt) und das Ergebnis schließlich langsam Bild für Bild anschaut, ob das zeitliche Voranschreiten vor allem in bewegten Szenen gleichmäßig aussieht. Bei progressiver Aufnahme hätte man immer zwei (Halb-) Bilder, die offenbar um den gleichen Zeitpunkt aufgenommen wurden. Bei falscher Wahl der Halbbild-Dominanz würden Bewegungen vor und zurück springen. Hierzu kann man sagen, dass sie bei vielen Analogkameras "Top Field First" (TFF) ist, bei Digital Video (DV-Tape) dagegen fast sicher "Bottom Field First" (BFF).


    Ich weiß nur nicht, ob dir der ausführliche Test mit Handbrake gelingt. Bei einem Konverter, der AviSynth benutzt, lässt sich das generierte Skript leicht an geeigneter Position (zwischen Source-Plugin und Ausgabe) um zwei Befehle erweitern (nur zum Testen, nicht zum Encodieren!):


    Code
    1. AssumeTFF() # oder AssumeBFF()
    2. Bob()


    Davon abgesehen: Wenn du am Ende mit x264 encodierst, ist es technisch eigentlich recht sicher, den Interlaced-Modus bei solchen alten Videoquellen immer zu aktivieren. Der x264-Encoder verwendet eine Technik, die nur solche Bildbereiche tatsächlich interlaced encodiert, wo das vorteilhaft ist (MBAFF). Nur die Dominanz muss die richtige von beiden sein.

    Bloß das Seitenverhältnis bei der Aufnahme ist 5:4 statt 4:3 warum auch immer...

    Das ist völlig normal und "war schon immer so": Auf einer DVD Video gibt es niemals 1:1-Pixel, der Videoinhalt ist immer gestaucht, weil schon die Röhrenfernseher damals das um das passende Verhältnis bei der Wiedergabe entzerrt haben. Dein AVC-Video hat daher eine im gleichen Verhältnis gestauchte Auflösung. Aktuelle Flachbildfernseher, die AVC decodieren können, würden das auch genau so erwarten und bei der Wiedergabe ebenso entzerren.


    Du hast nur die Kurzfassung der MediaInfo-Analyse hier gezeigt. Wenn du dir die vollständige Analyse anschaust, wirst du wahrscheinlich auch ein Pixelseitenverhältnis darin entdecken. Wenn nicht ... erzeugt das Gerät vielleicht doch keinen ganz korrekten Header?

    Grundsätzlich wird die Qualität bei jeder neuen Encodierung in ein Videoformat, das Verluste in Kauf nimmt, um Platz zu sparen, schlechter. Ob man den Qualitätsverlust aber überhaupt bemerkt, ist eine Frage der sinnvollen Einstellungen. Grundsätzlich erhält man die Qualität seiner Videos am besten, wenn man weitere Konvertierungen vermeidet. Will man trotzdem unbedingt Platz sparen und dafür Zeit investieren, gibt es typische Fehlerquellen... hier nur mal eine als Beispiel:


    Gerade bei der Konvertierung von Aufnahmen aus Zeiten des Analogfernsehens kann es durchaus vorkommen, dass das Zeilensprungverfahren (Interlacing) verwendet wurde, um (angepasst an das Leuchtverhalten der Fernseher mit Kathodenstrahlröhren) flüssigere Bewegungen wiederzugeben, wo mit entsprechenden Kameras gearbeitet wurde (z.B. bei Sportübertragungen, aber nicht bei Kinofilmen, die ja zuerst auf Fotofilm aufgenommen wurden). Encodiert man Video, das mit Interlacing erzeugt wurde, ohne den Encoder im Interlaced-Modus zu verwenden, wird man in Szenen mit starker Bewegung auch starke Qualitätsverluste bemerken.

    Gibt es einen Unterschied zwischen "denoise" (englisch) und "entrauschen" (deutsch)? :D


    Relativ wirksam wäre eine Rauschmaskierung. Die hat aber immer den Nachteil, dass man vorher manuell einen Abschnitt suchen muss, der praktisch nur das typische Rauschen enthält, damit davon ein Spektrum ermittelt werden kann. Vollautomatisch geht diese Methode nicht. Und wenn man sie zu stark anwendet, bekommt man metallisch klingende Audio-Artefakte.

    "Das angegebene Modul wurde nicht gefunden" ist durchaus meist ein Hinweis darauf, dass eine benötigte DLL nicht gefunden wurde. Das kann eine der Visual-C++-Runtimes sein, aber je nach Funktionsumfang kämen ganz allgemein noch andere in Frage (es gibt z.B. auch andere Software, die eine FFT3D-DLL verwendet); ich kenne diese Plugins allerdings nicht, kann da keine konkreten Tipps geben, außer deren Dokumentation aufmerksam zu lesen.

    Im Allgemeinen gilt: Erst croppen. Denn wer erst skaliert, der skaliert die Ränder mit, die dadurch weicher werden können, und weiche Ränder beschneiden ist ziemlitsch dämlitsch.


    Wie das ganze danach in Standardauflösungen einzupassen ist, hängt vom Einzelfall ab. Aber auch hier wäre es wahrscheinlich vorteilhaft, dass eventuell noch nötige Ränder scharf angefügt werden.


    In deinem speziellen Fall weiß ich nicht recht. Dein Nettobereich hat anscheinend kein Standard-Seitenverhältnis (1394:892 ~ 1,563, 1:1-Pixel angenommen). Wenn man optimal auf Höhe skaliert (1394:892*720), ergäbe das eine Breite von 1125,2 in 1280 Pixeln ... unschön. Wenn man mehr über den Ursprung des Inhaltes wüsste, wären Vorschläge leichter.

    Weiß nicht genau, ob es mit 3.7.x läuft, aber mit 3.8.x vielleicht nicht mehr ... so oft installier ich kein neues.


    Für VirtualDub2 braucht man kein Python, das ist ein C/C++-Programm für Win32 / Win64.


    Was hast du eigentlich gegen VirtualDub2, dass du es bis jetzt immer noch nicht ausprobiert hast?

    Wir hatten schon mal so einen Fall, dass AvsPmod nicht recht starten wollte. Leider ist man im englischen doom9-Forum darauf nicht groß eingegangen, als ich vorgeschlagen hatte, man solle doch wenigstens klar zu erkennen geben, was da nicht klappt. Wahrscheinlichste Ursachen nach meinem Gefühl: a) ungeeignete Python-Version installiert; b) das Programm kann bestimmte Konfigurationsdateien nicht schreiben, man sollte es vielleicht nicht im UAC-geschützten Programme-Verzeichnis ausführen.


    Und wie läuft VirtualDub2 stattdessen?