Beiträge von Tom Keller

    Würde mich auch an den Kosten beteiligen. Zwar bin ich in den letzten Jahren immer seltener hier auf dem Board gewesen, hab es aber regelmäßig als Nachschlagewerk genutzt. Dieses an einem Ort geballte Wissen in Text- und Personenform auseinander brechen zu sehen, wäre daher einfach traurig...

    Du könntest die Tonspur über "strecken um" anpassen. Eintragen müsstest du dort den Wert der bei 23.976/25 raus kommt - also 0.95904.
    Ob das empfehlenswert ist, ist allerdings eine andere Frage. Dadurch werden nämlich nur die Zeitstempel der Tonspur angepasst, aber die Tonspur selbst nicht verändert. Ob die Zeitstempel beachtet werden (sprich: ob das Ergebnis synchron läuft) und wie schlecht der Ton dabei klingt, hängt dann meines Wissens letztendlich vom Decoder ab (üblicherweise werden nämlich zum Erhalt der Synchronität Audiosamples weg gelassen bzw. mehrfach wiedergegeben, was nicht besonders toll klingt... und ob z.B. Hardware-Decoder das können, ist auch fraglich).

    Hier wird die Problematik dahinter genauer beschrieben und auch erklärt, warum das Strecken von Audio-Tracks nicht per MKVMerge/MKVToolNix erfolgen sollte:

    https://gitlab.com/mbunkus/mkvtoo…nk-audio-tracks

    Empfehlenswerter ist das vorherige Bearbeiten der Tonspur mit einem geeigneten Audiokonvertierungstool (z.B. BeHappy o.ä.) oder einem Audioeditor und das anschließende Muxen der so bearbeiteten Tonspur.

    Nach dem Sample zu urteilen lässt sich das nicht mehr reparieren. Das Problem ist nämlich, dass da scheinbar das normgewandelte/interlaced Quellmaterial OHNE vorheriges Deinterlacing bzw. ohne das vorherigen Zerlegen in seine Halbbilder hoch skaliert wurde. Dadurch wurden die Halbbilder miteinander vermischt. Wenn du dieses Sample jetzt durch SeparateFields() in seine Halbbilder zerlegst, enthalten die meisten Halbbilder einen Mischmasch aus den ursprünglichen Halbbildern mit verschmierten Interlacing-"Kämmen". Die ursprünglichen Halbbilder lassen sich somit nicht mehr wiederherstellen. Ohne die kann aber SRestore nicht die ursprünglichen Vollbilder rekonstruieren.

    Beim Sonic-Decoder könnte es klappen (falls du von dem überhaupt irgendwo eine Testversion auftreiben kannst)... aber beim Nero-Decoder musste meiner Erinnerung nach das Blu-ray/HD DVD Video Plug-in freigeschaltet werden (ohne Garantie -> kann mich da auch irren).

    Sonic- und ArcSoft-Decoder werden dir bei eac3to aber eh nichts nützen, da sie nicht für die Decodierung von E-AC3-Ton verwendet werden können. Das klappt da nur mit den Nero- oder libav/ffmpeg-Decodern. Aber versuchst du einen 8-Kanal E-AC3-Track per eac3to mit dem Nero-Decoder umzuwandeln, wird dir eac3to folgende Meldung ausspucken:

    Zitat

    The Nero E-AC3 decoder doesn't decode the back channels.


    ... und die libav/ffmpeg-Decoder können eben auch nur 6 Kanäle decodieren.

    Lange Rede... kurzer Sinn: meines Wissens kannst du mit eac3to aus einem 8-Kanal E-AC3-Track nicht alle 8 Kanäle decodieren. FFmpeg, FFAudioSource und LWLibavAudioSource versagen genauso, da die ja auch auf den libav/ffmpeg-Decodern basieren. Das einzige, was gehen könnte: nimm einen E-AC3-Decoder aus einem kommerziellen BluRay-Software-Player, bastele dir aus der Quelldatei und dem Decoder mit GraphStudio (o.ä.) einen Filtergraphen zusammen und verfüttere diesen per AviSynth an einen Encoder. Klappt natürlich nur, so lange der Entwickler des Software-Players die Funktionalität des Decoders nicht in jeglicher Software außerhalb des Players gesperrt oder eingeschränkt hat.

    Aus der beiliegende Readme:

    Zitat

    Tuning:

    • Tunes the settings for the type of content.

      • Film - This offers a good balance between the accuracy of individual moving things and the cohesiveness of the frame. Useful for content that was filmed or rendered (Recommended).
      • Animation - This should be used for cartoons/anime.
      • Smooth - This increases the accuracy of individual moving things while decreasing the cohesiveness of the frame. Some people prefer it since it gives the motion an overall "smooth" feeling.
      • Weak - This decreases the accuracy of individual moving things while increasing the cohesiveness of the frame.
        Note: This will weaken the interpolation a lot, meaning the motion isn't as smooth.

        Some people will prefer to use the Film tuning even for animated content, so don't automatically assume this is the right tuning for you; use with caution.

    • default - Film (string)


    Sprich: probier's mal mit Tuning="Smooth" oder Tuning="Weak". Beide Optionen haben aber technikbedingt ihre Vor- und Nachteile. Erwarte also keine Wunder. Perfekt kann das Ergebnis nämlich nie werden.

    Es ergibt trotzdem keinen Sinn... denn:

    Code
    tdecimate(mode=2,rate=23.976)

    ... ändert die Framerate indem Frames weggelassen(!) werden. Somit ändert sich NICHT die Videogeschwindigkeit und auch NICHT die Laufzeit, sondern nur die Gesamtframeanzahl und die Framerate.

    Oder um es mal an einem ganz simplen Beispiel zu erklären:
    Angenommen, du hast ein Video welches 60 Frames lang ist und mit 30fps läuft. Dieses Video ist (logischerweise) 2 Sekunden lang. Wenn du jetzt tdecimate(mode=2,rate=15) darauf anwendest, erhältst du ein Video, das 30 Frames lang ist und mit 15fps läuft. Und das ist genau... na(?)... wie lang? Richtig(!) - 2 Sekunden! Die Laufzeit hat sich also nicht geändert, sondern nur die Anzahl der Frames und die Framerate.

    Sprich: hinterher sollte der Ton ohne jegliche Änderung auf jeden Fall noch synchron sein. Bei mir war er es nach tfm() mit anschließendem tdecimate() jedenfalls IMMER. Ist er es bei dir nicht, kann es schlicht und einfach nicht an der Frameratenkonvertierung liegen, sondern muss andere Gründe haben.

    Inwiefern von Vorteil?

    FLAC wäre eher von Nachteil, da es im Vergleich zu MP3 von weniger Containerformaten unterstützt wird. Idealerweise bietet sich der Matroska-Container für FLAC an - aber einer MKV-Datei ist es tatsächlich herzlich egal ob sie nun MP3-, AAC-, Opus- oder FLAC-Ton enthält ;) . Es gibt dann höchstens minimale Unterschiede im Overhead, die allerdings nicht der Rede wert sind.

    Ach... sorry - war spät und ich hatte auf die Schnelle nur eine Seite gefunden, wo Flag 13 als "Field Sequential (Left Eye First)" beschrieben wurde. Die Beschreibung von hier klingt aber eher nach "Frame Sequential (Left Eye First)". Läuft aber auf's Selbe hinaus: dadurch werden bei der Auswertung durch den Player die Frames 1, 3, 5, usw. für's linke und Frame 2, 4, 6, usw. für's rechte Auge angezeigt - was aber immernoch nichts mit der Art und Weise zu tun hat, wie bei einem MVC-Video das Bild gespeichert wurde und natürlich auch nichts bringt, wenn nur der "2D-Anteil" decodiert wird. Das bringt dann höchstens bei Kameraschwenks eine Pseudo-3D-Ausgabe ähnlich dem Pulfrich-Effekt...

    wenn man aus einer ISO mit MakeMKV eine MVC-MKV generiert, dann setzt das Programm hier immer, zumindest bei den Sachen, die ich bisher umgewandelt habe, die "13"... ich frage mich halt auch, was es denn sonst setzen sollte? Bei allen 14 möglichen Einträgen gibt es ja keinen Eintrag, der für "Frame Packing" steht :(


    Das liegt schlicht und einfach daran, dass es meines Wissens keine offizielle Unterstützung für MVC-Video im Matroska-Container gibt. Moritz Bunkus hat laut eigener Aussage auch kein großes Interesse daran. Daher ist MakeMKV auch das einzige Tool, das MVC-MKVs (abseits der offiziellen Specs) erstellen kann.

    Dass es das Flag auf "13" setzt ist daher umso merkwürdiger - besser wäre es wohl, gar keins zu setzen. Denn ein Player, der zwar NUR den H.264-Anteil des MVC-Videos decodieren kann, aber sehr wohl das "Stereoscopic Flag" auswertet, wird dann nämlich ein 2D-Video decodiere, das Video in gerade und ungerade Bildzeilen aufteilen und diese dem linken und rechten Auge getrennt zuführen (was vermutlich in deinem Fall passiert und logischerweise kein wirkliches 3D-Bild liefert, da ja nur ein 2D-Bild decodiert wurde).

    Wie würde ich denn überhaupt unter Linux aus einer 3D-BD-(ISO) ein HOU-File generieren können (also jetzt nicht en detail, nur grob...)? Merci und Gute Besserung ;)


    Gute Frage - nächste bitte ;) . Von Videobearbeitung unter Linux habe ich leider nicht die geringste Ahnung. Unter Windows sollte es mit AviSynth + FRIMSource möglich sein.

    Liegt vielleicht an der Erkältungsmedizin... aber ich verstehe gerade die Ausgangskonstellation nicht. Du spielst eine MVC-MKV mit bino/sView ab? Seit wann kann denn einer der beiden Player MVC-Video decodieren :hm: ? Wäre mir neu...

    Abgesehen davon:
    Es macht keinen Sinn, dass der Header-Eintrag für das "Stereoscopic Flag" bei einer MVC-MKV auf "13" steht. Das Flag sagt nämlich darüber etwas aus, wie das 3D-Video in der MKV vorliegt - und "13" steht für "Field(!) Sequential (left eye = first field)"... aber bei MVC-Videos liegt das 3D-Bild nun einmal nicht "Field Sequential" vor.

    EDIT:
    Mein 666. Beitrag ;D !

    Ich glaube mich zu erinnern, dass man Vorbis Audio schon irgendwie in MP4 muxen kann (vermutlich als "private stream"... aber auf die Art lässt sich ja so ziemlich alles rein packen) - offiziell unterstützt wird das Ganze aber natürlich nicht.

    Das ist sowieso eins der größten Probleme mit MP4: sowohl die besten hocheffizient als auch verlustlos komprimierenden Audioformate werden nicht supported.
    Gleichzeitig sorgt aber gerade dieses "Problem" für die hohe Kompatibilität von MP4 ;) - die breite Flexibilität von Matroska (was die unterstützten Formate angeht) macht es nämlich praktisch unmöglich, alle in Matroska möglichen Audio- und Videoformate von in Hardware gegossenen Decodern zu unterstützen.

    Vielleicht hilft schonmal grundsätzlich dieser (oberflächliche) Vergleich verschiedener Containerformate:

    https://en.wikipedia.org/wiki/Compariso…ntainer_formats


    Bei meinen "einpacken" mit ffmpeg ist es am Ende egal ob ich out.mp4 oder out.mkv wähle, beide Ergebnisse sind gleich.


    Keine Ahnung, was du da erwartest - aber optisch oder akustisch wirst du bei unterschiedlichen Containerformaten mit identischen Inhalten NATÜRLICH keine Unterschiede bemerken. Letztendlich ist der Container schließlich "nur" die Verpackung. Oder anders (= analog) ausgedrückt: ob du nun einen Stapel Bücher, Bilder und Dokumente in einen Pappkarton oder in eine Plastikkiste verpackst, ändert nichts am Inhalt und Aussehen dieser Bücher, Bilder und Dokumente ;) .

    Man könnte vielleicht mit SelectEvery die Halbbilder nach einer vorgegebenen Regel neu ordnen, damit das eine Halbbild (welches im Bewegungsfluss zurück springt) mit dem vorherigen vertauscht wird - aber beim Ansehen ist mir aufgefallen, dass der Abstand nicht gleich bleibt. Sprich: normalerweise liegen immer 12 Halbbilder zwischen zwei "Spüngen" - aber alle ??? Frames verschiebt sich dieser "Sprung" scheinbar um ein Halbbild nach hinten. Eine feste Regel a la:

    Code
    [i]SeparateFields()
    SelectEvery(12, 0,1,2,3,4,5,6,7,8,9,11,10)
    Weave()[/i]


    ... funktioniert daher nur für einen kurzen Abschnitt.