Beiträge von LigH

Was du da hast, ist also gar keine "MPEG-Datei", sondern ein VCD-Image zum Brennen auf CD. Auf einer VCD ergibt sich der Zeitstempel aus der Sektorposition; auf Festplatte ist die unbekannt, also sind Programme hilflos, die sie in den GOPs erwarten.

Meine theoretische Empfehlung wäre, den MPEG-ProgramStream aus dem VCD-Image heraus neu in eine MPEG-Datei zu multiplexen, bei der das Video auch fortlaufende Zeitstempel hat, dafür aber keinen CD-Session-Header. Leider weiß ich praktisch nicht genau, welche Tools sich dafür eignen. ReStream arbeitete nur mit rohem MPEG-Video, glaube ich. Vielleicht geht was mit PVAStrumento oder ProjectX ... aber ich geb da gern weiter an Leute, die überhaupt je (S)VCDs erstellt haben.

Ein Hinweis an den Player, die Wiedergabe in einer anderen Geschwindigkeit laufen zu lassen, als der Stream ursprünglich encodiert wurde. Bei Video kein Problem; bei Audio dagegen u.U. mit Resampling.

Bei ffdshow (und ffvfw) nicht nur installieren, sondern u.U. auch die Raw-Umwandlungs-FourCCs explizit aktivieren.

Verwendet AegiSub eigentlich VfW oder DirectShow?

Und was davon unterstützt Windows 10 im aktuellsten Update noch?

Vielleicht wären noch "Standard- und erzwungene Streams festlegen" und "Sprachen und Eigenschaften von Streams festlegen" interessant, damit diejenigen, die kaum dermaßen fortgeschrittene Funktionen nutzen, wie du sie bisher aufzählst, überhaupt was zum Anhaken haben...

Mal die Videoausgabe aus einem AviSynth-Skript in unterschiedlichen Farbräumen versucht? Vielleicht fehlt da ein genereller Farbraumkonverter als VfW-Codec (da können ffdshow oder Xvid helfen).

Basilisk erreicht v2019.06.08

Und ab 11.6. wird Space Engine auf Steam erhältlich sein, mit erheblichen Verbesserungen in Funktionalität und Stabilität seit der letzten kostenlosen Version 0.9.8.0e.

Space Engine News

Pale Moon wurde aktualisiert zu Version 28.5.1 und gleich weiter zu 28.5.2.

Unter anderem sieht man nun auch wieder Icons in der Tabliste im Taskleistenbutton, wenn man kein Aero Peek verwendet.

Firefox Quantum ist aktuell bei Version 67.0.1.

In FFVideoSource wäre falsch, weil dann der Decoder versucht, auf Krampf diese Framerate zu erzeugen, indem eventuell Frames übersprungen oder verdoppelt werden.

AssumeFPS im AviSynth-Skript ist sicherlich wichtig, weil dann der Bruch wohl mit besserer Genauigkeit verarbeitet wird. Eigentlich sollte der fps-Parameter für x265 genügen, um das richtige Framerate-Flag zu setzen; allerdings arbeite ich auch eher ohne StaxRip...

Du kannst je gerne noch ein AssumeFPS(24000,1001) an den Source-Filter anfügen, um exakt das richtige Verhältnis sicherzustellen.

Es kann gut sein, dass in rohem HEVC-Video keine Framerate erkannt wird. Dann kann man sie für ffmpeg aber immer noch per Parameter festlegen.

AviSynth kann darauf keinen Einfluss mehr haben. Wie du siehst, ist die korrekte Rate bereits im Video enthalten. Die Ursache kann also ausschließlich im Multiplexer liegen. Bei einer Gesamtdauer von etwa 17 Sekunden wird optisch keine Veränderung auffallen, vielleicht ist auch die kurze Dauer ein Grund für ein "Abrunden"; am besten weiß das aber sicherlich Mosu als Autor von mkvtoolnix (HandBrake und VidCoder werden stattdessen wohl ffmpeg im Kern als MKV-Multiplexer verwenden).

Flatlander ist offiziell "fertig"!

https://www.flatlander.eu

Ein junger Influenzer hat mal so richtig ausführlich recherchiert und rechnet in einer knappen Stunde (!!!) mit der Unionspolitik ab.

Viel weiß ich über Dolby Atmos nicht ... außer: Atmos sind Metadaten zur räumlichen Orientierung, und die werden wahrscheinlich immer noch von jedem Softwaredecoder ignoriert, es sei denn, er hätte eine kostspielige Lizenz, die eigentlich eher Consumer-A/V-Geräten vorbehalten wäre.

Es wäre überraschend für mich, wenn ein frei verfügbarer Decoder existieren sollte, der die Atmos-Daten versteht. Auch wäre es insofern unwahrscheinlich, weil die Decodierung von einer Ausmessung des Raumes abhängig wäre, diese Messdaten müsste man z.B. ffmpeg oder eac3to (wenn es das mal könnte) irgendwie zur Verfügung stellen.

TrueHD lässt sich decodieren. Mit eac3to vielleicht einfacher als mit ffmpeg (für separate Mono-Kanäle mit Dateiendung .wavs). An einen externen Receiver würden die zusärtlichen Atmos-Daten aber per Bitstreaming einfach durchgeleitet werden, der PC würde sich daran sicher nicht vergreifen.

Über 100 MB sollte ffmpeg nicht werden, wenn man es strippen lässt. Packen mit UPX muss man es aber nicht.

Ich weiß, dass die Suite nicht immer problemlos durchläuft. Aber in den seltensten Fällen liegt das an der Suite; meist hat sich mal wieder eine Komponente so weiterentwickelt, dass sie plötzlich nicht mehr wie zuvor mit ffmpeg kompatibel ist. Die schwierigste Arbeit in solchen Fällen ist dann herauszufinden, wer über das Problem benachrichtigt werden muss.

Neben DASH (Dynamic Adaptive Streaming over HTTP) gibt es auch simples HTTP-Streaming mit der Variante HLS (HTTP Live Streaming für Echtzeitaufnahmen), das dürfte für den Fall, dass man nicht mehrere verschiedene Bitraten anbietet, deutlich einfacher zu realisieren sein. All das ist aber nicht wirklich die Aufgabe von ffmpeg, da werden ja erstmal Dateien erzeugt. Der Live-Streaming-Dienst auf ffmpeg-Basis wäre ffmbc (ffmpeg Media BroadCaster).

DASH ist kein Datei-Container, die segmentweise Übertragung per HTTP-Netzwerkprotokoll wird vom Webserver durchgeführt, dafür wird er möglicherweise sogar getrennte Video- und Audiodaten bevorzugen, wer weiß ... ich kenne das Verfahren nicht im Detail.

Wer immer das aktuellste haben will, was geht, der compiliert es sich selbst mit der media-autobuild suite (hat auch den Vorteil, dass man sich damit ein ffmpeg mit "non free license" zusammenbauen kann, das man woanders nicht herunterladen dürfte, weil sich Lizenzen der enthaltenen Codecs widersprechen). Ausnahme: eac3to; da ist der doom9-Thread schon richtig.

DASH dürfte, soweit ich mich erinnere, ein Containerformat sein, das vor allem beim Streaming mit alternativen Inhalten verwendet wird, wenn du also selbst keine Videostreams anbietest, dürfte das wenig relevant sein.

"So was wie ffdshow" wäre heutzutage "LAV Filters" (bereits oben erwähnt).

Und zum Finden der Crop-Werte eignet sich u.U. auch VirtualDub2 mit dem altbekannten Filter-Trick: irgendeinen Filter einfügen (im Original gab es dafür den Null-Transform-Filter, der nichts verändert), und für diesen Filter lässt sich dann ein Crop-Bereich über einen eigenen Button und speziellen Dialog einstellen.

Das nennst du "weit ausholen"? Ich weiß noch nicht mal, wie diese VOB-Dateien einzuordnen sind. Ist das wenigstens jeweils eine PGC-VOB (nur der Hauptfilm am Stück), oder sind das immer noch Segmente (max. 1 GB) wie auf DVD geauthort?

Mit AvsPmod öffnet man normalerweise AviSynth-Skripte ... ich weiß jetzt nicht auswendig, welche Source-Plugins es unterstützt, um gleich geeignete Skripte zum Öffnen von Mediendateien zu generieren. Wenn es denn unbedingt DirectShowSource sein muss, dann wird das schon klappen, wenn LAV Filters installiert ist (für AviSynth 2.6 auch die 32-bit-Variante). Besser wäre aber, man verwendet FFMS2 oder L-SMASH Works.

Und davon abgesehen sollte man VOB-Dateien sowieso nicht in AviSynth so laden, wie sie von DVD gerippt wurden (außer es ist eine PGC-VOB). Soweit ich mich erinnere, unterstützt kein Source-Plugin außer die von DG das Laden von mehreren VOB-Segmenten, alle anderen arbeiten nur mit einer einzigen zusammenhängenden Quelldatei.

Du möchtest also nicht die Variante verwenden, die ich empfohlen habe: QTGMC oder TDeint im Bob-Modus (der sollte bei QTGMC Standard sein)? Da passiert genau das (Halbbilder separieren und Auffüllen der jeweils abwechselnd fehlenden Halbbilder aus der Umgebung), nur mit Bewegungsinterpolation noch hochwertiger, vor allem bei QTGMC. Aus dem Ergebnis erhältst du schon mit SelectOdd() oder SelectEven() jeweils die beiden Clips, in denen überall das eine Halbbild original und das andere interpoliert ist.