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?
Angeschnittene GOP am Anfang.
Aktuelle Versionen:
Vielleicht. Unter anderem. Aber auch:
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).
Deine Uralt-Version hatte ja noch nicht mal Multi-Threading.
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...
Vielleicht versucht man bei Live-Sendungen einen "Decoder Lag" auszugleichen, den DVB-Receiver mit Billigtechnik haben können, der aber bei Offline-Mediaplayern im Allgemeinen besser kompensiert wird? – Reine Spekulation...
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:
ZitatAm 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:
ZitatAlles anzeigenMittlerweile hat der UN-Sonderberichterstatter über Folter via Twitter auf die Aussagen des Auswärtigen Amtes reagiert und um 21:29 Uhr Links zu sieben öffentlich einsehbaren Berichten von ihm über die Lage von Assange veröffentlicht:
GBR27.05.19: https://t.co/e2Zp2sBFyE
ECU28.05.19: https://t.co/fQP1689h22
USA28.05.19: https://t.co/vtxSwPoFj9
SWE28.05.19: https://t.co/cZkgS4pzUd
USA12.09.19: https://t.co/KODDmmt8kI
SWE12.09.19: https://t.co/yc33dCgFFi
ECU02.10.19: https://t.co/Dvqe6Wkcd9
GBR29.10.19: 60 days
Offensichtlich existieren sie doch.
Mehr Details in einem Video der Bundestagsfraktion DIE LINKE:
Am x265-Encoder wird zwar immer noch kräftig weiter entwickelt, aber das HEVC-Videoformat ist an sich stabil. Nach Deinterlacing kann man x265 verwenden (zwar unterstützt x265 auch Interlaced-Encoding, aber viele Wiedergabegeräte vermutlich nicht komplett). Bei der relativ geringen Auflösung von SD-PAL (oder nach Cropping noch weniger) hat HEVC aber noch keine deutlichen Vorteile gegenüber AVC, braucht aber mehrfach längere Zeit. Etwas schnellere Presets können schon ausreichend leistungsfähig sein. Teste, ob du SAO in x265 deaktivieren willst, falls das Ergebnis zu weich und platt wirkt.
Für die Kompatibilität mit Heimkinogeräten wäre zu empfehlen: AVC (x264) oder HEVC (x265) mit AAC (ffmpeg genügt meist, oder qaac bzw. fdk-aac) in MP4.
Eine Erklärung nicht unbedingt, außer dass XMR vielleicht möglicherweise fehlerhafte Decoder für bestimmte Formate verwendet.
Dafür aber ein Lösungsvorschlag: Wenn VirtualDub das Video korrekt anzeigt, dann gleich auf VirtualDub2 umsteigen, dann braucht man XMR gar nicht mehr. Aus VirtualDub2 heraus kann man z.B. auch gleich mit x264 und ffmpeg-AAC in MP4 encodieren.
Hab ich doch gesagt: Energie- und Zeitverschwendung. Neue Kompressionsverfahren werden entwickelt, um neues Videomaterial gleich original mit einer besseren Effizienz zu komprimieren, was vor allem bei hohen Auflösungen notwendig ist. Schon einmal mit verlustbehafteten Codecs komprimierte Videos weiter zu komprimieren verschlechtert die Qualität nur weiter, warum dafür also Zeit und Strom investieren? Wenn überhaupt, dann nur verlustarme Originalvideos damit komprimieren.
Dazu käme noch, dass MPEG2-Video interlaced sein könnte. Die Unterstützung für Interlacing wollte man eigentlich schon bei HEVC (H.265) abschaffen, weil es eine überflüssige Technologie ist, seit man LCD/LED-Flachbildschirme statt Kathodenstrahlröhren benutzt.
Im Allgemeinen schon. Aufgrund der hohen Komplexität aber wohl eher mit reduzierten Parametern im praktischen Betrieb.
Ich muss aber davon abraten, als Privatperson seine Videosammlung nun komplett auf AV1 umzukonvertieren, "um Platz zu sparen". Das verschwendet nur Energie und Zeit, und Qualitätsverluste hat man dabei sowieso.
Sollte grundsätzlich nicht so kompliziert sein. Basis ist: ffmpeg -i Quelldatei.dts Bitrate-oder-Qualitäts-Option Zieldatei.Endung.
Je nach Zielformat wirst du u.U. eine konstante Bitrate -b:a kbps brauchen, z.B. bei AC3 für DVD- oder Blu-ray-Kompatibilität.
Und wenn du sichergehen willst, dass das Zielformat eindeutig erkannt wird, verwendest du noch den Parameter -c:a Audiocodec direkt vor der Ausgabedatei. Hier gilt eine Angabe aus der Liste, die ffmpeg -help codecs ausgibt.
Außerdem könnte noch der Parameter -fmt nötig sein, falls du sowohl Audiocodec als auch Ausgabeformat exakt angeben musst (z.B. kann AAC im M4A- oder ADTS-Container gespeichert werden). Aber da solltest du die Dokumentation lesen. Meist wird das Format aus der Dateiendung der Zieldatei vernünftig erraten.
Falls ffmpeg die Quelldatei nicht erkennt oder die Konvertierung aus bestimmten Gründen nicht durchführen will (vielleicht wegen der Samplingrate oder Mehrkanal-Konfiguration), wird es hoffentlich recht ausführliche Fehlermeldungen geben. Achte auf eine recht aktuelle ffmpeg-Version, um dts decodieren zu können, das wurde wohl erst etwa im letzten Jahr implementiert, glaube ich... oder war es der Encoder?
Zum Reparieren wäre mir nichts bekannt. Aber kann ein aktuelles ffmpeg vielleicht damit arbeiten?
Es sollen über die gesamte Länge 14 (verdoppelte) Frames eingestreut werden? Nein, ohne Rechnerei geht das nicht. Aber dann sollten entweder ChangeFPS oder ConvertFPS ein passendes Ergebnis liefern.
Es gibt Programme, die ändern ihr Verhalten abhängig von der Dateiendung, die verlassen sich auf eine bestimmte Benennung.
Und es gibt Programme, denen ist nur der Dateiinhalt wichtig, die erkennen Format und Eigenschaften an Header-Daten.
Ein Thema, das hier seit "Jahrzehnten" immer wieder diskutiert wird...