Spulen in mkv files,...

    Hab hier ein mkv file von dem ich einige Teile mit folgenden x264 settings:

    Code
    "G:\Hybrid\MkvCutter\x264.exe" --profile high --level 40 --vbv-bufsize 25000 --vbv-maxrate 20000 --ref 1 --min-keyint 1 --keyint 48 --bframes 0 --non-deterministic --thread-input --crf 19 --demuxer avs --fps 24000/1001 --sar 1:1 -o "H:\Temp\test-010_reencode.264" "H:\Temp\test-010.avs"

    reencoded und später mit:

    Code
    -oH:\\Output\\test.mkv--disable-lacing--clusters-in-meta-seek--engageno_simpleblocks--engageno_cue_duration--engageno_cue_relative_position--compression-1:noneH:\\Temp\\test_AudioCut.mkv--compression-1:noneH:\\Temp\\test-001_reencode.264+H:\\Temp\\test-002_reencode.264+H:\\Temp\\test-003.264+H:\\Temp\\test-004_reencode.264+H:\\Temp\\test-005_reencode.264+H:\\Temp\\test-006.264+H:\\Temp\\test-007.264+H:\\Temp\\test-008_reencode.264+H:\\Temp\\test-009_reencode.264+H:\\Temp\\test-010_reencode.264+H:\\Temp\\test-011_reencode.264+H:\\Temp\\test-012.264+H:\\Temp\\test-013_reencode.264+H:\\Temp\\test-014.264+H:\\Temp\\test-015.264+H:\\Temp\\test-016_reencode.264+H:\\Temp\\test-017.264+H:\\Temp\\test-018_reencode.264+H:\\Temp\\test-019_reencode.264+H:\\Temp\\test-020.264+H:\\Temp\\test-021.264+H:\\Temp\\test-022_reencode.264+H:\\Temp\\test-023_reencode.264+H:\\Temp\\test-024.264+H:\\Temp\\test-025.264+H:\\Temp\\test-026_reencode.264+H:\\Temp\\test-027_reencode.264+H:\\Temp\\test-028.264+H:\\Temp\\test-029_reencode.264--default-duration0:24000/1001fps

    gemuxed habe.

    File lässt sich auch ohne Probleme abspielen, das Problem ist nur, dass man nicht mehr wie im ungeschnittenen Original springen kann ohne das Bildfehler auftreten.
    Vor allem wenn ich CUVID als Decoder in LAV Filters deaktiviere.
    Da sich daran nichts ändert, wenn ich den Video stream nach mp4 remuxe, liegt das Problem wohl nicht am Container, sondern an meinen x264 settings. :(

    Wenn ich das Quellmaterial mit MediaInfo analysiere erhalte ich folgendes:


    -> hat jemand eine Idee was ich an den x264 settings ändern könnte damit das Problem nicht auftritt?
    (wie gesagt: lineares Abspielen geht ohne Probleme, egal ob per CUVID oder normalem libav Softwaredecoder)

    Cu Selur

    Ps.: Link zum Original wurde hier gepostet,... (falls jemand will kann ich die geschnittene Version temporär auch irgendwo hochladen und dann Link per PM verteilen)
    PPs.: Hmm,.. Playback mit VLC gibt seltener Artefakte als mit LAV im MPC-BE

    Zitat von Selur


    Da sich daran nichts ändert, wenn ich den Video stream nach mp4 remuxe, liegt das Problem wohl nicht am Container, sondern an meinen x264 settings. :(

    Ich denke, ohne Ausprobieren wird das schwer. Wenn es überhaupt klappt, der original Stream wurde ja vermutlich mit einen anderen H264 Encoder erzeugt.

    Die Profile durchprobieren, von CRF auf CQ Modus wechseln. --force-cfr testen ... mehr fällt mir auf Anhieb nicht ein.

    mfg

    An cfr/vbr liegt es nicht, beide Streams sind cfr (MediaInfo stolpert nur darüber, dass anscheinend beim Original einer der ersten drei timecodes daneben liegt,..).
    cq benutzen macht meiner Ansicht nach gar keinen Sinn, weil dann ja keinerlei Level&Profil Beschränkungen mehr eingehalten werden.

    Idee: Könnte es eventuell an unterschiedlichen sps Werten liegen? (Falls, ja: Wie krieg ich die sps-id eines Streams raus?)

    Cu Selur

    Ps.: bluray-compat hilft auch nicht
    Hab mal Original und Reencode nach mp4 geremuxed und mit "MP4Box -info" angeguckt:

    Code
    G:\Hybrid>MP4Box.exe -info h:\Output\original.mp4* Movie Info *        Timescale 600 - Duration 00:02:20.013        1 track(s)        Fragmented File: no        File suitable for progressive download (moov before mdat)        File Brand avc1 - version 0        Created: GMT Wed Jun 19 20:32:58 2013File has root IOD (9 bytes)Scene PL 0xff - Graphics PL 0xff - OD PL 0xffVisual PL: AVC/H264 Profile (0x15)Audio PL: No audio capability required (0xff)No streams included in root ODiTunes Info:        Encoder Software: Hybrid 2013.06.17.1Track # 1 Info - TrackID 1 - TimeScale 24000 - Media Duration 00:02:20.014Media Info: Language "Undetermined" - Type "vide:avc1" - 3357 samplesVisual Track layout: x=0 y=0 width=1920 height=1080MPEG-4 Config: Visual Stream - ObjectTypeIndication 0x21AVC/H264 Video - Visual Size 1920 x 1080        AVC Info: 1 SPS - 1 PPS - Profile High @ Level 4        NAL Unit length bits: 32        Pixel Aspect Ratio 1:1 - Indicated track size 1920 x 1080        Chroma format 1 - Luma bit depth 8 - chroma bit depth 8Self-synchronized


    -> an der SPS liegt es also vermutlich auch nicht

    Hm, ich hab mal den H264 Stream aus dem Original mittels ffmpeg geholt.

    Neu kodiert (deine Zeile oben verwendet, ohne avs demuxer, andere x264 Version (x264 core:125 r2200M 999b753 / Linux))
    und einfach beide H264 Streams - original und reencoded - mit mkvmerge aneinander gefügt.

    Spielt ohne Probleme und keine Probleme beim Spulen.

    Ich schneide das File an KeyFrames und Reencode dann so, dass ich effektiv ein schneiden an beliebigen Frames habe. (Nutze: MKVCutter; welcher zum Schneiden an KeyFrames mkvmerge verwendet)
    Da sich wie gesagt, das File ja ohne Probleme abspielen lässt wenn man nicht springt, vermute ich, dass da irgendwelche Header nicht richtig aneinander passen.

    Genauer Infos zu MKVCutter findest Du bei: http://forum.selur.de/topic220-mkv-c…e-accurate.html und http://forum.gleitz.info/showthread.php…-264%29-Dateien

    ----
    hab auch mal versucht:
    a. ältere x264 Versionen zu verwenden
    b. b-frames abzustellen
    c. adaptive quantization zu deaktivieren
    hat alles nicht geholfen
    Die noch nicht zusammengefügten Teile lassen sich einzeln auch ohne Probleme abspielen, was vermutlich zu erwarten war, da das lineare abspielen ja auch geht.

    Intra Refresh anstatt IDR hilft auch nicht. :(

    Vielleicht hab ich oben was verpasst ... aber ich könnte mir vorstellen, dass im Video nach dem Schneiden wieder fortlaufender Timecode erzeugt werden muss; bei MPEG2 konnte ReStream so was patchen, und Authoringtools (DVD-Video hier, Blu-ray da) werden das sicher auch tun.

    Zitat von Selur

    An cfr/vbr liegt es nicht, beide Streams sind cfr (MediaInfo stolpert nur darüber, dass anscheinend beim Original einer der ersten drei timecodes daneben liegt,..).

    Die Anfangstimecodes der Quelldatei sehen mir absolut regelmäßig aus. Der H.264-Stream ist hingegen auf "vfr" gestellt - die x264-Ausgabe aber (bei AviSynth-Input) zwangsläufig "cfr".

    Andere Unterschiede:
    Quelle / x264
    sar: - / 1:1
    weightp: - / ein

    100% die gleichen Headerdaten zu erhalten, und das nur mit den Hilfsmitteln MediaInfo, AviSynth und x264cli, dürfte generell sehr schwer bis im Einzelfall unmöglich sein. Selbst x264cli erzeugt teilweise unterschiedliche Daten bei gleichen Einstellungen (dafür gibt es bald die Option --stitchable, welche aber natürlich nur hilft, wenn alle Segmente damit enkodiert werden.)

    Teilweise funktioniert in mkvmerge das "(datei1.h264 datei2.h264)" besser als das "datei1.h264 +datei2.h264", aber so ganz 100% ist das noch nicht. Matroska ist auch eigentlich nicht für wechselnde Headerdaten ausgelegt.

    an weightp liegts nicht hab ich auch schon deaktiviert.
    Kann ich mit x264 Streams erstellen die keine SAR Info habe? (dachte die würde immer geschrieben)

    Zitat

    Teilweise funktioniert in mkvmerge das "(datei1.h264 datei2.h264)" besser als das "datei1.h264 +datei2.h264", aber so ganz 100% ist das noch nicht. Matroska ist auch eigentlich nicht für wechselnde Headerdaten ausgelegt.


    Werde ich mal ausprobieren.

    Zitat von Selur

    an weightp liegts nicht hab ich auch schon deaktiviert.
    Kann ich mit x264 Streams erstellen die keine SAR Info habe? (dachte die würde immer geschrieben)

    Ja, einfach --sar weglassen und der Wert bleibt auf "0", auch wenn es in der Praxis quasi gleichbedeutent mit --sar 1:1 (Wert "1") ist.

    Sollte auch keine Lösung sein (habe auch keine) - wollte nur sagen, daß da noch Unterschiede sind. Das werden auch noch mehr als nur weightp, sar und vfr/cfr sein.

    Ich bekomme es auch nicht hin - zumindest VLC spinnt immer rum, auch wenn LAV (software) damit klarkommt. (Habe vfr/cfr, weightp, sar und chroma-qp-offset angepaßt)

    Vielleicht bringt die kommende Option --stitchable aber doch in einigen Fällen, wie etwa diesem, etwas. Würde es gerne testen, habe aber leider keine Binaries vom Dev-Git. Hat da wer was?

    Ist aber letztlich wohl alles nur rumgefrickel - wenn man das wirklich zuverlässig bauen will, muß man wohl tiefer in die Materie einsteigen und evtl. Header selbst auswerten und mit libx264 arbeiten.

    Ok, ich glaube ich habe es soweit:

    1.
    Quelle durch mkvmerge mit --fix-bitstream-timing-information und --default-duration jagen. (wandelt "vfr" zu "cfr")

    2.
    Neuen Teil encoden:
    Entfernen: --sar 1:1
    Hinzufügen: --weightp 0 --chroma-qp-offset 2 --stitchable
    (Vermutlich reicht schon --stitchable, aber ich wollte es dann trotzdem lieber soweit wie nur möglich angleichen.)

    3.
    Mit mkvmerge muxen. (Habe einfach nur "1.h264 +2.h264" genutzt)


    Downloads:
    x264 dev git build r2343
    Sample der Ausgabe (Erste Minute ist aus der Quelle, alles danach neu kodiert.)

    Wird aber vermutlich keine allgemeingültige Lösung sein - z.B. wenn die Quelldatei mit x264 ohne --stitchable kodiert wurde.

    Vermute bei mir läuft irgendwas schief, wenn ich:

    Code
    mkvmerge --default-duration 0:24000/1001fps --fix-bitstream-timing-information 0:true -o h:\Output\fixed.mkv "f:\MkvCutterTest\Hula Cam w_ Jordan Carver.mkv"


    aufrufe, meldet MediaInfo für den Output:

    Zitat

    Frame rate : 11.990 fps
    Original frame rate : 11.988 fps


    (playback ist aber richtig)
    bin jetzt aber erst mal pennen

    Ja, irgendwie setzt mkvmerge die time_scale des H.264-Streams falsch (24000 anstatt 48000), aber die mkv-timecodes richtig. Hatte das mit den demuxten Daten gemacht und das Problem dabei nicht. Demuxe also erstmal, bis Mosu sich dazu geäußert hat:
    https://trac.bunkus.org/ticket/888

    Warum MediaInfo die mkv-Timecodes hier allerdings nicht zur fps-Berechnung nimmt, weiß ich nicht. Evtl. eine Heuristik PAFF/Progressiv?
    http://forum.doom9.org/showthread.php?p=1633703#post1633703

    Hab jetzt:

    • mit mkvextract audio&video extrahiert
    • mit mkvmerge beides wieder in einen neuen Container gepackt
      -> gibt dann ein file was als cfr mit 23.976fps angezeigt wird
    • das file gesplittet und die GOPs die reencoded werden müssen geencoded mit:
      x264 --profile high --level 40 --vbv-bufsize 25000 --vbv-maxrate 20000 --ref 1 --chroma-qp-offset 2 --weightp 0 --stitchable --min-keyint 1 --keyint 48 --non-deterministic --thread-input --crf 19 --demuxer avs --fps 24000/1001 -o "Pfad zum .264 output" "Pfad zum Input"
    • alles neu gemuxed -> Bildfehler und freezes treten immer noch auf beim Springen

    Cu Selur

    Ps.: "Evtl. eine Heuristik PAFF/Progressiv?" -> glaube nicht, dass mkvmerge aktuell 'PAFF-aware' ist -> siehe: https://forum.doom9.org/showthread.php?p=1631752#post1631752 und folgende,...

    Habs, in dem Aufruf hatte noch ein --bframes 0 gefehlt, dann passt es. :)
    -> die Kombination aus "--weightp 0 --stitchable -bframes 0" hat geholfen

    Vielen Dank an sneaker2 und alle die mit draufgeguckt habe.
    -> hab auch eine neue Version von MKVCutter hochgeladen,..

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden