Beiträge von LigH

Moin Alf.

Bin mir nicht ganz sicher, was die Anleitung meint, da müsste ich die Passage wohl mal selbst lesen, um den Zusammenhang zu verstehen. Ich nehme aber an: Es geht um das Ausnutzen von Schlüsselbildern zum Setzen von Kapitelmarken in einem Authoringtool. Denn nur bei Schlüsselbildern kann das Abspielen nach einem Sprung sofort fortgesetzt werden.

Videos, die in effizient komprimierenden Formaten vorliegen, verwenden für ein gutes Komprimierungsverhältnis eher selten Schlüsselbilder, die von allen anderen Bildern im Video unabhängig sind, weil die viel Speicherplatz benötigen; alle anderen Bilder speichern zum Platzsparen nur Unterschiede zu Bildern, die schon bekannt sind.

Deshalb versuchen gute Encoder, Schlüsselbilder überwiegend nur dort zu verwenden, wo so starke Veränderungen auftreten, dass das Speichern von Unterschieden nicht mehr Platz spart. Eben bei Szenenwechseln. Bei harten Schnitten ist das einfach. Überblendungen zu erkennen ist aber nicht ganz einfach, deshalb kann man sich nicht darauf verlassen, dass davor auch ein Schlüsselbild eingefügt wird, und man dort dann später ein Kapitel setzen kann.

Wenn man einen Encoder wie x264 manuell steuert, kann man ihm auch eine Liste an Frame-Nummern geben, wo er unbedingt Schlüsselbilder einfügen soll, damit man dort mit Sicherheit später Kapitel festlegen kann. Diese detaillierte Steuerung unterstützt der Video-Remaker vielleicht nicht?

2.0.3 Stable wurde veröffentlicht.

https://github.com/staxrip/staxrip/blob/master/changelog.md

https://github.com/staxrip/staxrip/releases

Pale Moon 28.6.1 verbessert neben der Sicherheit u.a. auch die Nutzung von FTP-Funktionen.

Pale Moon v28.6.0 bringt neben einem neuen Icon auch jede Menge Änderungen mit sich.

Und Firefox Quantum v68 wird Konflikte mit Antivirus-Software beheben, die sich wie ein Man-in-the-Middle-Angreifer verhält und HTTPS-Datenverkehr entschlüsseln will ... indem es das nun stillschweigend zulassen wird – und damit ein Sicherheitsrisiko erzeugt. Der Bequemlichkeit zuliebe.

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.