Beiträge von LigH

Facebook-Videos ... da kommen wir der Sache doch näher ... da handelt es sich wahrscheinlich um eine spezielle Art des Video-Streamings, bei der der Player die Einzelteile nahtlos zusammensetzen muss, aber mit speziellem Hintergrundwissen über deren Aufbau. Es gibt sicher Downloader-Plugins für Webbrowser, die das korrekt beherrschen.

Bei solchen Problemen kenne ich die möglichen Ursachen nicht mit Sicherheit, da kann ich nur raten. Das einzige, was mir im Moment einfällt, wäre, dass vielleicht der Timecode der zweiten Videospur nicht nahtlos nach der ersten fortläuft, der Player aber die Stelle mit den passenden fortlaufenden Timecode sucht und nicht findet. Man kann ffmpeg dazu zwingen, neuen fortlaufenden Timecode zu generieren, wenn man Videos aneinander fügt, aber ob Avidemux das auch kann, weiß ich nicht auswendig.

Es kann sein, dass bestimmte Codecs ausschließlich für die Nutzung im ASF-Container freigegeben sind und in einem VfW-Editor für AVIs nicht benutzt werden können. DivX 3 wurde ja damals aus dem MS MPEG-4 V3 "freigehackt".

Zitat von Pro Jo

Der Ersteller des Originalvideos hätte ...

... wenn das überhaupt möglich war. Es sieht eher danach aus, dass die aufnehmende Kamera in einem Mobilgerät war, das gar keine höhere Auflösung hatte, da kann keiner mehr einstellen.

Zitat von HQ-LQ

wurde schon mal "FFDShow tryouts" ausprobiert?

Ja, hatte ich. Aber nur die aktuellste Variante. Vermutlich hätte man eine mehrere Jahre ältere Version benutzen müssen, in der noch die fehlerhafte Implementation enthalten war.

Tut mir leid. Ich habe verschiedene Sachen ausprobiert. Bei keiner Methode, die ich so zur Verfügung hatte, läuft es ordentlich. Ich vermute daher: Der ursprüngliche Encoder hat einen fehlerhaften Videostream erzeugt, deshalb ist das Ergebnis nur mit einem genauso fehlerhaften Decoder abspielbar. Aber sämtliche moderne Software hat diesen Fehler längst korrigiert.

Das wird wohl nur noch auf einem System laufen, auf dem man noch den Windows Media Player 9 benutzen kann. Also höchstens XP.

Aber man kann ja gern noch mal im englischen doom9-Forum fragen...

Wie ich oben geschrieben habe: Es gibt Player, die für sich ganz allein arbeiten, die andere Software nicht stören, die aber auch nicht die im System installierten Codecs benutzen. Dazu gehören VLC und MPC-HC. Und falls du einen anderen Lieblingsplayer hast, dann brauchst du nicht sämtliche Codec-Packs, da genügt in den meisten Fällen "LAV Filters".

Allerdings ... alle drei genannten verwenden die gleichen Decoder. Falls diese drei also deine Videos nicht korrekt abspielen, müssten man für den speziellen Fall nochmal schauen, ob man einen alten Codec findet, der ganz speziell dieses Format so unterstützt, wie es damals gedacht war. Vielleicht muss man da in der Konfiguration der Decoder von MPC-HC (oder LAV Filters bei einem anderen Lieblings-Mediaplayer) nachschauen, ob die richtige Variante aktiviert wurde.

Da wir jetzt den Codec durch den 4-Zeichen-Code M4S2 identifiziert haben, können wir da noch mal nachforschen, ob der von der Codecsammlung unterstützt wird, auf der alle drei oben genannten Empfehlungen basieren. Soweit ich bisher gefunden habe, wurde sie mal von ffdshow unterstützt, also ist es ziemlich wahrscheinlich, dass auch LAV Filters und MPC-HC das können sollten (MPC-HC verwendet auch die LAV Filters, aber eine eigene Kopie direkt, ohne sie im Windows-System zu installieren).

Und wenn das Problem hartnäckig bleibt, müssen wir vielleicht mal mit einer Beispieldatei gemeinsam testen...

PS: Eine weitere Lösungsmöglichkeit könnte sein, mit einem "FourCC Changer" die Markierung von M4S2 nach DIVX oder DX50 oder XVID zu verändern. Dann wird ein wahrscheinlich gleichwertiges Videoformat erkannt.

Wie gesagt: MediaInfo würde uns alles nennen, was wir brauchen. In den Daten, die du gerade gepostet hast, wäre wohl M4S2 das wichtigste Detail. Das klingt nach dem veralteten Microsoft MPEG4-Codec V2, der nicht zum ISO/IEC MPEG4-Standard kompatibel war.

Erst mal alle möglichen Codec-Packs zu installieren war keine schlaue Idee; nun hast du vielleicht zu viele Codecs im System, die sich gegenseitig stören, und am Ende versucht vielleicht einer dieses Videoformat zu decodieren, der dieses spezielle Format nicht gesondert behandelt, verdrängt aber den, der es korrekt tun würde. Schwer zu sagen.

"Einige der bekannten Player" sagt uns auch wenig, denn die arbeiten teilweise mit erheblich unterschiedlichen Techniken. Manche verwenden eingebaute Codecs, andere verlassen sich auf das, was in deinem Windows-System installiert ist.

Hallo.

Es wäre sicher hilfreich, wenn wir da mehr über deren Inhalt erfahren könnten. Ein Programm wie MediaInfo.NET berichtet sehr ausführlich über alle technischen Details eines Videos. Dann können wir sicherlich zuverlässiger passende Software empfehlen. Allgemein helfen aber möglicherweise Mediaplayer, die viele Decoder integriert haben (z.B. VLC oder MPC-HC); oder man installiert entsprechende Universaldecoder wie LAV Filters für beliebige Mediaplayer, die DirectShow unterstützen. Aber es wäre denkbar, dass diese nachprogrammierten Decoder nicht in jedem Fall alle Varianten alter Codecs unterstützen. Dann braucht man vielleicht die Original-Decoder der jeweiligen Hersteller. Dann muss man aber auch exakt wissen welche.

Wenn die Frage so einfach wäre, wie dir scheint, hätte ich (damals, vor 10 Jahren mittlerweile) nicht nachfragen müssen.

Klar können Programme wie IrfanView die Anzahl verschiedener Farben zählen. Das sagt aber nichts über die Bittiefe aus, mit der das Bild tatsächlich als Datei gespeichert wurde. Ein Bild, das ausschließlich nur schwarze und weiße Pixel enthält, kann ich z.B. mit 1-bit-Palette, 4-bit-Palette, 8-bit-Palette, 24 bit RGB oder 48 bit RGB speichern (und das sagt auch noch nichts darüber, wie viele Bits der gespeicherten Farbauflösung tatsächlich genutzt werden, also verschieden sind); all das verliert aber völlig seine Aussagekraft, wenn dann ein Videoformat zum Einsatz kommen soll, das auf dem YUV-Farbraum basiert anstatt RGB.

Die (elektronische) Bildverarbeitung war übrigens auch Teil meines Informatikstudiums. Während dieser ganzen Zeit haben wir allerdings diese Abkürzung exakt so niemals benutzt. Im Gegensatz zur EDV bezweifle ich, dass EBV eine im Alltag gebräuchliche Abkürzung ist. Google ist sie auch mit dieser Bedeutung nicht geläufig. Immerhin habe ich damals die Bedeutung ja korrekt erraten...

Aber gut. Der heutigen Generation ist es immer sehr wichtig, andere zu kritisieren. Dass man in Jahrzehnten noch was dazulernt, darf man nicht überbewerten, sonst fehlt einem noch die Rechtfertigung dafür, persönlich zu werden. Hätte sich ja sonst nicht gelohnt, sich deswegen hier extra anzumelden, um auf ein 10 Jahre altes Thema zu antworten — mehr oder weniger.

Zitat von CooCooC

Ich kann keinen Parameter in x264 finden, der sagt, "vertrau mir, das ist progressive" und dann auch "progressive" in die Metadaten schreibt.

Das machst du, indem du weder --tff noch --bff verwendest. Weglassen, dann arbeitet x264 progressiv.

Zitat von CooCooC

Müsste man dabei dann das jeweils zweite Bild wegschmeißen

Es gibt kein zweites Bild, das man wegwerfen müsste. Bei progressivem Video ist ein Vollbild zu einem Zeitpunkt aufgenommen worden; bei Interlaced sind zwei Halbbilder zu verschiedenen Zeitpunkten aufgenommen worden, wurden dann zu einem Vollbild vereint.

DAR = Display Aspect Ratio = Breite : Höhe
SAR = Sample Aspect Ratio = entzerrte Breite (wie es dargestellt werden soll) : encodierte Breite (wie es gespeichert wurde)
andere AR-Abkürzungen: kommt drauf an, was die in dem Zusammenhang bedeuten sollen...

Zum Skalieren kann man AviSynth oder VapourSynth verwenden, die haben jeweils eine breite Auswahl unterschiedlicher Methoden. Ich nehme an, dass ffmpeg das auch alleine kann, kenne aber den Parametersatz nicht auswendig. Aber ffms(2) ist was anderes, ich kenne das als Quell-Plugin für AviSynth/VapourSynth, nicht als eigenständiges Programm.

Anstatt die variablen Ränder abzuschneiden, könnte man sie auch mit einem scharfen schwarzen Rahmen überdecken. Dann bleibt zumindest das Seitenverhältnis des Gesamtbildes gleich.

Zu Problem 1: Ja, das kommt vor. MPEG2-Encoder für DVDs sind meist auf "interlaced, TFF" eingestellt, selbst wenn sie progressive Videoinhalte encodieren. Nur zur Sicherheit. Damit man nicht aus Versehen mal vergisst, ausgeschaltetes Interlacing wieder einzuschalten, wenn doch mal Interlaced-Material zu encodieren wäre, denn das wäre katastrophal, von der Qualität her. Aber x264 kommt damit klar. Dieser Encoder verwendet, wenn --tff (oder --bff) zum Aktivieren des Interlaced-Encodings verwendet wird, den PAFF-Algorithmus, der encodiert nicht die gesamte Bildfläche, sondern abschnittsweise nur dort im Interlaced-Modus, wo das wirklich vorteilhaft ist. Ohne den Parameter wird überall progressiv encodiert.

Zu Problem 3: Da ist unklar, ob du dich auf den Stauchungsgrad (1024:720 = 64:45) oder das Seitenverhältnis, und hier auf das des Gesamtbildes (1024:576=16:9) oder des interessanten Bildanteils beziehst. Ein Seitenverhältnis von 2,4:1 oder auch 2,35:1 wäre jedenfalls eine Art Kino-Seitenverhältnis, da müsstest du selbst auf einer 16:9-DVD noch eine recht breite Letterbox oben und unten im encodierten Video haben, also mehr als nur 2-4 Pixelzeilen wegschneiden wollen.

Die Suzi kriegt so langsam street credibility...

H.264 ist der Kern-Kompressionsalgorithmus, der im MPEG4-AVC-Standard verwendet wird; x264 ist ein spezieller AVC-Encoder. Der Unterschied zwischen den drei Begriffen ist häufig vernachlässigbar.

Wenn es grundsätzliche Inkompatibilitäten gäbe, würde ich erwarten, dass das ganze Video von Anfang an nicht geladen wird; dass es erst mittendrin nicht mehr läuft, verkompliziert die Sache. Aber es bringt mich auf eine Idee... vielleicht gab es an der Stelle einen Übertragungsfehler im Digitalfernseh-Stream. Dann müsste ffmpeg bei der Konvertierung zu DNxHD auch eine Warnung an der Konsole an dieser Stelle anzeigen, denke ich. Oder ffplay beim Anschauen um diesen Zeitbereich herum.

Nein. TransportStreams haben keinen Keyframe-Index. Und MediaInfo interessiert sich dafür ohnehin nicht; für eine solche Analyse bräuchte man ausführlichere Spezialprogramme, die Container in allen Details auseinander nehmen.

MP4, MOV und 3GPP(2) sind ziemlich ähnliche Container, alle Teil des Standards ISO/IEC base media file format (MPEG-4 Part 12), hier mit Einschränkungen, da mit Erweiterungen für spezielle Anforderungen. Es gibt Varianten, Versionen, vereinfachte und ausführlichere Strukturen. Insofern halte ich es durchaus für nachvollziehbar, dass es im MOV-Container funktioniert, aber vielleicht der MP4-Container von ffmpeg zu simpel erzeugt wird. Vielleicht gibt es Parameter, die ffmpeg dazu bringen, den MP4-Container in einer ausführlicheren Variante zu erzeugen; wenn nicht, braucht man u.U. MP4Box stattdessen.

Es gibt in vielen Container-Medienformaten eine Liste (Index-Chunk) mit Positionen, wo im Video sich Schlüsselbilder befinden, also ab wo eine Decodierung beginnen kann. Wenn diese Positionen nur mit 32 bit Auflösung gespeichert werden, dann kann man maximal Positionen bis 4 GB darin speichern (wenn die mit Vorzeichen ausgewertet werden, dann nur bis 2 GB). Wenn also Videodateien größer als 4 GB werden, muss man sich was im Container einfallen lassen. Bei AVI gab es dann die Version AVI 2.0 (OpenDML). Und ich erinnere mich, dass es beim MP4-Container auch mal Probleme mit Software gab, die einen vereinfachten Container-Standard erzeugt hatte. Das sollte heutzutage aber für ffmpeg eigentlich kein Problem mehr darstellen.

Ich hätte beinahe gefragt, ob ab Minute 25 zufällig 4 GB überschritten werden ... aber bei DNxHD müsste das ja noch viel früher der Fall sein.

Es könnte daran liegen, dass DR auf der Timeline im Schnitt Videoformate erwartet, in denen jedes Bild ein Schlüsselbild ist. Bei AVC ist das definitiv nicht der Fall (oder extrem selten). Allerdings kenne ich DR nicht aus eigener praktischer Erfahrung. Ich frage mal in einem Dashcam-Chat nach, da verwenden viele Leute DR, um Kennzeichen unkenntlich zu machen, die wissen das bestimmt besser...

Ist ja in dieser Richtung auch richtig. Man muss nur die Kausalität beachten: Für MPEG1-Video ist die Endung .mpg verbreitet; aber aus der Endung .mpg kann man überhaupt nichts auf den Inhalt schließen. Ich kann auch einer AVI-Datei die Endung .mpg verpassen, dadurch bekommt sie nicht plötzlich MPEG1-Video als Inhalt. Ein Mediaplayer würde sie trotzdem abspielen, weil die Dateiendung erstmal bloß dafür sorgt, dass der Player gestartet wird und die Datei öffnet; was drin ist und wie es abgespielt werden muss, entscheidet sich dann nach Inhalt.

Was mir auch nicht gefällt, sind die anhaltenden Spekulationen in Richtungen, die für dieses Thema vermutlich ziemlich irrelevant sind. rotmilan hat zu wenig geschrieben, als dass man sicher sagen könnte, was da passiert. Mindestanforderung sind aussagekräftige Screenshots von allen Einstellungen sowie MediaInfo-Analysen von Original und Kopien, sonst vergleichen wir Vermutungen und keine Daten und Fakten.

Zitat von Pro Jo

Und ja, mpg ist MPEG-1.

Nein. Einfach nur nein.