mkv : Laufzeit verdoppelt nach mkvmerge

  • Morgen zusammen !
    Ich bräuchte eure Hilfe bei einem kleinen Problem ! :hm:


    Folgendes Szenario :


    Ich habe einen 1:1 rip meiner BD. Abgelegt als BDMV Struktur.


    Ich demuxe mit tsmuxer den .h264 stream (1920x1080i bei 25fps), sowie den DTS stream (6 Kanäle / 48khz). Bei der Überprüfung beider streams mit MediaInfo bekomme ich die korrekte Laufzeit für beide angezeigt; hier 45 min.


    Danach setze ich diese mit mkvmerge wieder zusammen. Beim einladen melde ich den .h264 als 25fps stream an.


    Das fertige mkv hat laut MediaInfo nun aber eine Laufzeit von 90 min !?! Alle anderen Daten sind nach wie vor korrekt (1920x1080i,DTS mit 6 Kan. ...).
    Bei der Wiedergabe mit meinem Dune läuft der Film nun tatsächlich auch halb so schnell. Als info am Dune kann ich noch erkennen, das besagtes mkv allerdings immer noch als 25fps gemeldet wird.


    Woher kommt die halbierung der Wiedergabe Geschwindigkeit ? Hat jemand eine Idee, oder ähnliches schon einmal gehabt ?
    Ich bin für jeden Tip dankbar !
    A.D.B.

  • Ihr traut mir nicht, gell ? :D
    Neinnein, Danke für die Antwort ! Ich kann nur leider jetzt auf die schnelle diese Info nicht nachliefern.


    Mittlerweile habe ich in einem anderen Forum (PocornHour) gelesen, das die Auswertung von MediaInfo bzw. tsmuxer bei interlaced .h264 streams fehlerhaft sein soll. Das heisst, es werden 25 fps als progressive angezeigt, obwohl richtig eigentlich 50 fps(interlaced) währen. WorkAround sollte sein, beim mkvmerge einfach 50 fps angeben. Ich werde dies heute Abend ausprobieren, und melde mich dann noch einmal !

  • Selbstverständlich vertrauen wir dir. Deshalb wollen wir ja auch ausschließlich nur die technischen Daten des Videos.
    __


    Es ist schon ein Unterschied, ob 50 Vollbilder pro Sekunde angezeigt werden, oder 50 Halbbilder, miteinander im Interlacing verwoben, 25 Vollbilder pro Sekunde ergeben.


    Rohe H.264-Videostreams enthalten selbst leider oft keinen Hinweis darauf, welche Framerate sie haben, das wird oft nur im Kontainer hinterlegt, in dem sie aufbewahrt werden.

  • Hallo LigH,
    wie Du schon geschrieben hast, schlägt hier die Erkennung fehl, ob Halbbilder oder Vollbilder vorliegen.
    mkvmerge nimmt anscheinend stur an, das Vollbilder angegeben werden, in seiner DropDown Box. Dies führt dann zu meinem "Zeitlupen Effekt".
    Wenn man allerdings hier einfach den Parameter 50 angibt (wird nicht angeboten!), dann stimmt die Zeitliche Abfolge natürlich wieder.
    Schade ist, das mkvmerge dies nicht selber erkennnt; immerhin listet es den Video Stream ja als 1920x1080i <- auf !


    Danke noch einmal an LigH !
    Gruß
    A.D.B.

  • Ist dennoch eine interessante Sache.


    Bei MPEG2 gab es zwei unterschiedliche Methoden, Interlaced-Video zu speichern: Üblich war v.a. "Frame-orientiert, interlaced", aber auch "Field-orientiert" war möglich. In beiden Fällen wird der Inhalt der Halbbilder mehr oder weniger unabhängig und nacheinander gespeichert, aber anscheinend bezogen sich die weiteren Angaben dann entweder auf "verwobene Vollbilder" einerseits (25 Frames pro Sekunde, interlaced), oder auf separate Halbbilder als Bezugseinheit andererseits (50 Fields pro Sekunde).


    Dass so was nun auch bei MPEG4-AVC möglich sein sollte, könnte ich ohne Studium der Spezifikationen wohl nicht ausschließen... aber es würde sich sicherlich lohnen, im englischen doom9-Forum mal darüber zu reden. Oder hier mosu dazuzuholen.

  • Mkvmerge erkennt bei AVC überhaubt keine Frameraten. Die müssen immer angegeben werden und der User wird auch in einer Popup-Box darauf hingewiesen. Und bei Fieldkodierten Streams (z.b Sony PAL AVCHD Streams) muss dann natürlich 50 angegeben werden (da ja neben der Framerate das Field Picture Flag auch nicht ausgelesen wird).

  • Und bei Fieldkodierten Streams (z.b Sony PAL AVCHD Streams) muss dann natürlich 50 angegeben werden (da ja neben der Framerate das Field Picture Flag auch nicht ausgelesen wird).


    Aha ... also 1. existieren solche "field-basiert encodierten AVC-Streams" überhaupt, und 2. können sie gar nicht erkannt werden, wenn es rohe AVC-Streams sind?


    Dann kannst du das ja vielelicht auch hier beantworten.


    Und dann wäre wohl besser gewesen, direkt von M2TS nach MKV umzumultiplexen (mit gdsmux), statt zwischendurch Rohdaten auszugeben...

  • zu 1. kA
    zu 2.
    Die Framerate ist, zumindest bei x264 codiertem Material, im RAW-Stream mit drin. Bei einigen meiner Encodings von 25fps/24fps/23,976fps Material hat MediaInfo jeweils die richtige Framerate angezeigt und mplayer hat es korrekt abgespielt. mkvmerge dagegen geht immer von 25fps aus, was mich bei meinem ersten Mal mit 24fps Material fast einen ganzen Nachmittag gekostet hab bevor ich gemerkt hab, dass die Asynchronität an der falschen Framerate lag.

  • Zitat

    Und dann wäre wohl besser gewesen, direkt von M2TS nach MKV umzumultiplexen

    ....Mkvmerge unterstützt keine TS oder M2TS als Sourcen...

    Zitat

    Die Framerate ist, zumindest bei x264 codiertem Material, im RAW-Stream mit drin.

    Vorhanden schon, nur Mkvmerge kann damit nichts anfangen und fragt deshalb den User. Wird dies ignoriert wird von 25 fps ausgegangen.

    Zitat


    Sie fügen der Zieldatei eine AVC/h.264 Elementardatei hinzu. mkvmerge kann aus solchen Dateien nicht die Anzahl der Bilder pro Sekunde ableiten. Deshalb müssen Sie diesen Parameter auf der Seite 'Formatspezifische Optionen' selber setzen.Wenn Sie das nicht tun, so nimmt mkvmerge 25 BPS an.Diese Nachricht wird nur einmal angezeigt, es sei denn, Sie haben die Warnungen bzgl. falscher Benutzung im Einstellungsdialog aktiviert.


  • Vorhanden schon, nur Mkvmerge kann damit nichts anfangen und fragt deshalb den User. Wird dies ignoriert wird von 25 fps ausgegangen.


    Einen kleinen Schönheitsfehler hat mkvmergeGUI dennoch: fügt man mehrere Roh-AVC zu einem Video zusammen, kommt nach 'Muxen starten' ab der zweiten AVC jedesmal der Warnhinweis, obwohl logischerweise die Framerate nur beim ersten Video einstellbar ist. Das Ergebnis ist jedoch korrekt.

  • Hallo zusammen !
    Danke für die zahlreichen Erklärungen / Anmerkungen !


    Weil hier die Frage aufkam, ob es diese Art von AVC stream überhaupt gibt, hier die Quelle, wo ich sie gefunden habe : Link www.amazon.de/Wildes-Russland-…rie-Blu-ray/dp/B002PI1KZ4 (Ich hoffe, ich darf das ??!)


    Einer meiner Vorredner erwähnte, das mkvmerge die genaue Art nicht erkennen konnte. Mit "erkennen" meinte ich, das er diese Info aus dem Header vom avc stream auslesen konnte, und auch korrekt anzeigte innerhalb der GUI von mkvmerge. Zu einem richtigen Bewerten wäre es dann ja wohl nur noch ein kleiner Schritt (denke ich).


    Gruß
    A.D.B.

  • Du könntest folgendes mal versuchen:
    1. mit tsMuxeR aus mehreren m2ts Dateien eine machen
    2. mit Hybrid das ganze Remuxen (Audio&Video Handling auf passthrough (all) und als Output eine .mkv Datei wählen)
    Hybrid sollte mit MediaInfo die Framerate auslesen und entsprechend später beim Multiplexen mit mkvmerge die Framerate hoffentlich richtig angeben.


    Cu Selur

  • Hi


    ich hab ein ähnliches Problem.


    Aufnahme per IPTV => .ts => das demuxe ich mit tsmuxeR nach h264, mpa => vorher die passenden Sekunden zum Schneiden rausgesucht und somit gleich mit schneiden lassen (ohne Schneiden das gleiche Problem). Jetzt möchte ich daraus ein "untouched" ;) mkv machen. Also mkvtoolnix aufgemacht. Dateien rein - Warnung gelesen. Ich stelle also auf 50fps.


    Jetzt probe schauen - es ruckelt wie sau.


    mediainfo MKV:


    mediainfo TS:


    Abschließend hab ich mit tsmuxer nur "geschnitten" und ein neues .m2ts / .ts erstellen lassen. Hier hab ich komischerweise kein BILD im mpc-hc. Nur der Windows Mediaplayer oder VLC zeigen ein Bild!? Muss ich net verstehen oder?


    Also die Frage:
    Wie bekomme ich ohne reencode das File zu einem mkv (hier kann ich das File benennen, Untertitel dazupappen [forced, normale] usw.) was nicht ruckelt? Bzw. wie bekomme ich das mit tsmuxer geschnitte in mpc-hc angezeigt?


    Gruß

  • Hi


    dann bekomme ich es aber nicht geschnitten - und zudem ist das file "instabil" ... kann nicht durchzappen und das bild bleibt stehen - keine spezielle Stelle. Aber es ruckelt nicht!


    Wenn ich h264ts-cutter das orginal-TS schneide, hab ich statt 1,7GB nur noch 0,8GB über (ich schneide ca. 100mbyte weg) ... also muss ich es demuxxen ... die Cut-Werte hol ich mir aus h264ts-cutter und trage diese dann beim cutten in tsmuxer ein - beim demuxxen. Ich wandel nach .ts (das File geht dann nicht in mpc-hc) ... Wenn ich dieses "neue" .ts dann mit gdsmux nach mkv wandel scheint es zu klappen .... dolle geschichte ;) ... wobei ich schon 1-2 mpc-hc-crash tamit hatte ... kurios.


    Was mir aber einfällt - das ist erst mein 2. IPTV-File (Entertain) was ich bearbeite. Das erste war von ArteHD und wurde imho mit der Testversion von TSDoctor gecuttet?!. Das aktuelle ist von ArteSD und TSDoctor hab ich net mehr. Das ArteHD-File kann ich problemlos mit mkvtoolnix nach mkv umpacken. Gebe dort 50fps an und go. Synchron, Flüssig, voll zapbar. Werde das morgen mal näher testen - da läuft ne 2h-Aufnahme auf ArteHD - da ich kein TSDoctor mehr habe, werde ich das also genauso angehen müssen wie ich es mit dem SD-File vorhatte. Mal gucken wie es das ist. Repariert TSDoctor ein file auch gleich? So ähnlich wie projectx?


    Gruß


    PS: ÖR-SD werde ich künftig weiter mit DVB-C aufnehmen => mpeg2 (leichter zu verarbeiten) und bessere Bildqualität ... an ÖR-HD via DVB-C komm ich derzeit nicht ran :|

  • Hi


    hab gestern mal TSPE ausprobiert. Das erkennt auch Fehler im Stream (angeblich) und FIXED die auch (ANGEBLICH!). Die Betohnung liegt auf angeblich. Wenn im Stream was repariert wird, sieht man das bei mpeg2 (via projectx) ja daran das man kurz einen Bildfehler oder Tonaussetzer hat - aber sonst keine Beeinträchtigung. Bei TSPE sieht man das daran das nen riesen Log geschrieben wird wo fehler REPARIERT wurden - springt man diese an, steht der Player ... absturz. Im Orginal-File übrigens das gleiche Problem. Tolle Reparatur :|


    Ein Stream wurde tatsächlich repariert ... an der Stelle wo der Fehler aufgetaucht war, gabs ne Bildstörung (wie bei mpeg2) ... nur lustigerweise sehe ich das defekte Bild jetzt alle 10-15sek in den Folgenbildern - so als kurzen Flash ;)


    Beim anderen Stream wo mir die Vorgängerversion fehler en masse ausgespuckt hatte, wurde mir mit der neusten Alpha-Version kein Fehler rausgeschmissen ... also dem Tool trau ich net :| ... bisher konnte ich auch keine Fehler erkennen - wirklich repariert?!


    Wie zuverlässig ist TS-Doctor den? Was macht das teil den mit defekten Stellen? Ich kanns leider nicht testen - Trial ist rum :| ... hatte es damals einmal gestartet - ein File durchgejagd - gefiel mir überhaupt nicht - danach nicht mehr benutzt (allerdings auch nichts mehr aufgenommen).


    Gibbet den Freewaremässig etwas was mir sagen kann ob ein h.264-Stream ok ist und wenn nicht, an welchem Zeitindex ein Fehler ist?


    Gruß



    PS: TS Doctor ist geil - gerade aufm anderen PC versucht zu starten ... Lizenz ist bereits am 31.12.1899 abgelaufen :| nach Installieren "Datumsfehler" ... super

  • Hi


    naja h264ts_cutter hat bei mir keinerlei fehler erkannt :| hat geschnitten und ab fehler ging das chaos los ... so wurde dann aus einem 1,7GB-File ein 0,8GB-File (wobei ich nur paar Sekunden vor und nach dem Film weggeschnitten hatte) - was zudem nicht wirklich abspielbar war :|


    Naja muss ich mal gucken wie ich ts doctor auf dem anderen PC gestartet bekomme ...


    Edit: TS Doctor zum laufen bekommen ... tja .. ich überprüfe den Stream: KEIN Fehler :( ... ich lasse den Stream neu schreiben - es wird gesäubdert => wenn ich jetzt an die defekte Stelle springe ... erstmal starke Bildfehler und danach asynchron ..


    Gruß