Die Entwicklung schreitet voran. Mittlerweile wird uvg266, der VVC-Encoder des Kvazaar-Teams, unterstützt, und der Autor des VVCEasy-Paketes, Martin Eesmaa, hilft mit beim Einbinden von Fraunhofer VVenC und VVdeC (die separat auch schon compilierbar sind, wenn man seinen Fork testet).
Beiträge von LigH
-
-
Die stammt wohl von Fraunhofer.
-
Selur - du hast ja Erfahrung darin, Qt-Applications zu compilieren. Schaffst du das mit dem bitmovin vvDecPlayer?
PS: VVCEasy sieht auch interessant aus. Allerdings auch ein wenig unübersichtlich. Damit kann man anscheinend mittels Batch-Datei den bitmovin-Player oder ein VLC-Plugin von Inter Digital Inc. installieren lassen, oder es wird bei der Nutzung der CLI-Codecs geholfen.
-
Noch sind wir bei der VVCDecoderApp.
-
Die media-autobuild suite unterstützt jetzt uvg266!
uvg266 0.2.3-be90897 [GNU 12.1.0] 2022-06-06
-
Nee du, ich war damals schon eher an Neuentwicklungen interessiert.
-
-
Hauptgrund bei YouTube: Die müssen für Streaming optimieren, also weitgehend konstante Bitrate.
War bei VCD auch so, MPEG-1-Video mit 1150 kbps.
-
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.
-
Da in unserem Forum ja einige Pioniere dieser Ära ihr gesammeltes Fachwissen geteilt haben, sind vielleicht noch ein paar davon übrig, die dieses Thema amüsant finden könnten:
SVCD in 2022 im VideoHelp-Forum
-
-
Hier mal schnell compiliert, nachdem ein paar kleine Problemchen mit den Build-Skripten korrigiert wurden (x86-64, erfordert u.U. AVX2).
-
Selur - pinterf hat keine große Lust auf eine Portierung, falls Neo FFT3dFilter vergleichbare Geschwindigkeit erreicht. Vielleicht kannst du dort auf github was dazu anfügen.
-
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.
-
-
Das wird eigentlich alles in der AviSynth-Wiki-Seite zu QTGMC zusammengetragen.
Als Plugins braucht man mindestens nur das, was in Core Plugins and Scripts aufgelistet wird. Dafür aber immer alle jeweils aktuellen Versionen. Und ein AviSynth+ v3.x als Basis.
PS: Beachte noch darunter den Hinweis zu FFT3D und den Abschnitt Getting started.
-
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.