Beiträge von LigH

    Es gibt formal tatsächlich Qualitätsunterschiede, weil die Suche nach Redundanzen nicht über die Thread-Slices hinaus geht. In der Praxis dürften sie bei HD-Auflösungen aber auch noch mit 4 Threads vertretbar gering sein (wo keine Ähnlichkeit gefunden wurde, wird eben intracodiert, und das stört nur im Falle begrenzter Bitrate), und die Steigerung der Effizienz durch Parallelisierung ist bei größeren Flächen wirklich vernünftig.

    In der Codec-Liste von ffmpeg taucht H.266/VVC auf als "V"(ideo codec) und "L"(ossy); allerdings weder mit "D"(ecoder) noch "E"(ncoder). Wird also vermutlich bisher lediglich identifiziert.

    Ich weiß jetzt nicht in wiefern man klar die "Schuld" zuweisen kann, wenn GPU-Funktionen betroffen sind. Zumindest kenne ich den Bedarf an VRAM für FFT3dGPU nicht. Aber wenn es nötig ist, Videoframes erst mal in den Grafikspeicher hochzuladen, dann hilft eine Erhöhung des Zugriffs auf normalen Arbeitsspeicher vielleicht wenig, wenn deine Grafikkarte zu wenig Grafikspeicher hat, um mehrere UHD-Videoframes aufzubewahren, die der Filter vielleicht von dort her verarbeitet.

    Dann gäbe es immer noch die Privatkopie in unerheblicher Anzahl, wenn man sich untereinander kennt, die dann ungestraft bleibt. Und der Nebeneffekt beim heimlichen privaten Tausch: Wo kein Kläger, da kein Richter. Man muss ja nicht über alles öffentlich sprechen.

    LoadPlugin: unable to load "D:\Neuer Ordner\MeGUI\tools\lsmash\LSMASHSource.dll", Module not found. Install missing library?

    Ziemlich sicher fehlt dir hier die Installation der dazu passenden Version der Microsoft Visual C++ Runtime. Leider weiß ich nicht, welche der vielen Versionen (mit Jahreszahlen wie 2010, 2013, 2015, 2017, 2019) du für diese Version des Plugins brauchst, aber MSVC-Runtimes aller möglichen Versionen brauchen ja sowieso viele Programme.

    Ja, das ist eine Kompromissfrage.


    Lässt man Interlaced-Material interlaced, korrekt gekennzeichnet, ermöglicht man dem Wiedergabegerät, selbst für optimale Darstellung zu sorgen. Im Falle von Röhrenfernsehern damals war das einfach, die haben ihr Bild ja ohnehin schon interlaced dargestellt. Heute bei den LCD/LED-Flachbildfernsehern ist dagegen progressive Darstellung sinnvoller. Hier haben die Fernseher aber auch recht hochwertige Methoden zum Bobben (Darstellung beider Halbbilder zu ihren jeweiligen Zeitpunkten als aufgefüllte Vollbilder).


    Sicherlich kann eine Vorausberechnung mit Software (v.a. QTGMC, CQTGMC) noch bessere Qualität bringen. Der Nachteil davon ist aber, dass man dann auch größere Ergebnisse bekommt, da ja doppelt so viele Frames pro Laufzeit gespeichert werden. Man braucht nicht unbedingt doppelt so viel Platz für vergleichbare Qualität mit Interlaced-Codierung des Originalvideos, aber dennoch wesentlich mehr, wenn man nicht eine Qualitätsminderung riskieren will. Dabei sollte man aber beachten, dass viele Fernseher beim Abspielen von Videomaterial von eingesteckten Datenträgern so ihre Grenzen der Bitrate haben können.


    Progressive Umwandlung kann also je nach Rahmenbedingung sinnvoll sein. Eine Rückumwandlung ins Interlaced-Format kann ich aber nicht im Allgemeinen empfehlen. Da müsste es schon sehr konkrete Gründe dafür geben. Beispielsweise Hochskalieren zu 1080i, weil Blu-ray kein 1080p unterstützt.

    Der hat aber auch eine zusammenhängende PGC-Datei erzeugt, wenn man ihn im Movie-Modus benutzt (bzw. IFO-Modus beim DVD Decrypter). Und so macht es MakeMKV im Grunde auch ... nur mit MKV-Container statt PGC-VOB oder Elementarstreams.

    Ich hoffe, du verstehst, was "interlaced" bedeutet: Die beiden Halbbilder (Fields) eines gemeinsam encodierten Vollbildes (Frames) zeigen den Inhalt verschiedener Zeitpunkte. Deshalb kann man nicht einfach so entscheiden, das mal so und mal so handhaben zu wollen.


    Sollte das Interlacing durch Telecine erzeugt worden sein, lässt es sich rückgängig machen, weil das Original eigentlich progressiv war; hat die Kamera dagegen die Szene interlaced aufgenommen, braucht man ein Deinterlacing-Verfahren, das mindestens das halbe Bild neu dazu erfindet, wenn man im Ergebnis progressives Video will. Man bekommt dadurch völlig neue Inhalte, die eine Kamera so nie aufgenommen hatte.

    Nicht unbedingt. Mehr so, dass ein Titleset vor und nach dem Hauptfilm noch Trailer oder manchmal sogar Bewegtmenüs mit enthalten kann, und das oft die Tonspuren asynchron macht. Oder noch schlimmer: Falls es Multi-Angle-Szenen gibt, könnte es passieren, dass man die gemischt bekommt, weil die parallelen Videostreams nicht korrekt auseinander gehalten werden.

    Vielleicht ist die DLL-Version zu alt und unterstützt diese Funktion noch nicht. Ich habe auf meinem PC über 20 Dateien mit diesem Dateinamen, die über verschiedene Verzeichnisse (WinSxS, servicing ...) verteilt sind, von 24 bis 961 KB Größe.


    Vielleicht weiß Mosu den Grund. Ob jetzt vielleicht Windows neuer als 7 nötig ist, oder wenigstens ein aktuelles DirectX...

    Grundsätzlich ja; sowohl LSMASHWorks (LwLibavVideo/AudioSource) als auch FFMS2 können mit dem MKV-Container und den darin enthaltenen A/V-Formaten gut umgehen. Was "diverse Schnittprogramme" angeht, ist die Unterstützung von MKV bei hochpreisiger Software eher schlecht, bei kostenloser (wie Avidemux oder ShotCut) aber teilweise vorhanden.

    Gegenwärtig ist mein Workflow so, dass ich das uralt Programm VOBMerge nutze und mir aus den vob Dateien eine mpeg Datei erstellen.

    Bloß nicht... Wenn du VOB-Dateien verarbeitest, ohne auf deren logische Struktur zu achten, wie sie in den IFO-Dateien definiert wird, hast du immer das Risiko, dass das Ergebnis ein Durcheinander enthält, nicht nur den reinen Hauptfilm.


    Verwende MakeMKV, das kann die Program Chain des Hauptfilms so extrahieren, wie sie ein DVD-Player abspielen würde, und packt das DVD-Material verlustfrei in eine MKV-Datei. Das Entschlüsseln von DVDs unterstützt es immer, auch ohne Jonglieren mit Testversionen und Ablaufdaten (wie bei Blu-rays).