Beiträge von LigH

    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?

    Ja, das ist ein AviSynth-Plugin.


    Warum soll AviSynth nicht laufen? Ob AvsPmod startet oder nicht, ist kein Kriterium, das ist nur eine von mehreren möglichen Anwendungen zum Bearbeiten und Ausführen von Skripten. VirtualDub2 wäre ein anderes. Davon unabhängig wird das Skript aber in AviSynth ausgeführt, nicht unmittelbar durch die aufrufenden Programme.


    AviSynth selbst ist unsichtbar, ein Frameserver im Hintergrund, wirkungslos ohne ein Programm, das es benutzt. Ob es funktioniert, ermittelt man am besten mit dem AviSynth Info Tool oder AVSMeter(64).

    Ich weiß nicht genau, was dieses NGU im Detail tut. Aber es muss wohl einfach und schnell genug sein, dass es in einem Shaderprogramm innerhalb der Grafikkarte in Echtzeit ausgeführt werden kann (eine hinreichend leistungsfähige GPU und genug VRAM vorausgesetzt).


    In einem AviSynth-Plugin kann man da durchaus noch weiter gehen und noch aufwändigere Berechnungen im Hauptprozessor durchführen, als das in Shaderprogrammen möglich wäre, die doch eher auf simplere Mathematik beschränkt sind.


    Seit Jahren wird immer wieder empfohlen, beim Upscaling (Vergrößern) zunächst die Verdopplungsfunktion von NNEDI3 mit Kanteninterpolation zu verwenden – mit einem Faktor, dass das Ergebnis gerade so größer als die Zielgröße wird (von SD nach 720p genügt ein Faktor 2, nach 1080p sollte es 4 sein) – und von da auf die gewünschte Größe herunterzuskalieren.


    Das Ergebnis muss allerdings nicht wesentlich besser aussehen als das NGU-Upscaling in madVR; dafür aber wird es mit Sicherheit jede Menge mehr Bitrate beim Encodieren beanspruchen. Ob es das wirklich Wert ist? Teste und berichte...

    MVC ist ein Zusatz-Stream, der die Differenzen zwischen den "Augenwinkeln" encodiert. Nach obiger Beschreibung nimmt FRIMencode wohl ein SBS-Video mit den sichtbaren Inhalten beider "Augenwinkel" an und berechnet sich die Differenz daraus selbst?

    An AviSynth liegt es wohl meist nicht, wenn AvsPmod nicht richtig startet, eher an einer ungeeigneten Python-Umgebung. Aber die Suche nach Ursachen wäre nicht mein Fachgebiet.


    Als Alternative würde ich VirtualDub2 empfehlen, das hat auch einen integrierten Editor (aus VirtualDubMod weiterentwickelt). Außerdem gibt es noch einige Konverter, die selbst AviSynth-Skripte generieren und diese auch zu einem gewissen Grad manuell bearbeiten lassen (z.B. MeGUI oder StaxRip).


    AviSynth+ sollte man ausgerechnet von der Website nicht herunterladen, die ist völlig veraltet. Aktuelle Versionen gibt es jetzt bei github (z.Z. Version 3.4.0). Für 32-bit- und 64-bit-Prozesse hat AviSynth+ jeweils eine eigene DLL, die im dazu passenden Systemverzeichnis installiert wird.

    Auswärtiges Amt - zum Fremdschämen: Ein Update zur Petition "Verhindert die Auslieferung von Julian Assange an die USA!" berichtet:


    Zitat

    Am 26. November weilte der UN-Sonderberichterstatter über Folter, Nils Melzer, im Auswärtigen Amt für Gespräche mit der dortigen Menschenrechtsabteilung. Wie er am 27. November bei der öffentlichen Anhörung im Bundestag – sichtlich konsterniert – darlegte, erklärten ihm die bundesdeutschen Diplomaten unverblümt, dass man seine Berichte zur Folter an Assange noch immer nicht gelesen habe.


    Hier ein Videoausschnitt aus einer öffentlichen Anhörung im Bundestag:


    https://twitter.com/FWarweg/status/1200020417248997377



    RT deutsch: Außenamt zu Berichten des UN-Sonderberichterstatters über Assange: "Diese Berichte gibt es nicht"


    Weiter aus dem Petitionsupdate:


    Offensichtlich existieren sie doch.


    Mehr Details in einem Video der Bundestagsfraktion DIE LINKE: