This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

ts zu m2ts funktioniert nicht mehr
#11
Es scheint etwas Anderes zu sein. Als ich jetzt probierte, lag die Grenze zwischen dem 24.04 und dem 26.04. tsMuxer vom 24 funktioniert, vom 26. nicht mehr. Irgendwas im Audiobereich scheint der Knackpunkt zu sein. Die funktionierende Datei wird mit VLC mit Ton abgespielt, die nicht funktionierende ohne Ton. Die Dateien sind aber auf das Byte genau gleich groß. Ich schicke einen Link zu den Dateien per PN. Müsste selbsterklärend sein. Einmal die originale ts-Datei und die umgepackten Dateien haben das tsMuxer-Datum als Name.
Reply
#12
Hab die Dateien, werde heute Abend oder Morgen drauf schauen können.

Cu Selur
Reply
#13
Okay.
Folgendes Problem: Der Videostream im Sample ist kaputt. Smile
  • weder bei der '2020_04_24_wird_erkannt.m2ts' noch bei der '2020_04_26_wird_nicht_erkannt.m2ts' bekomme ich ein Bild. Habe die Dateien extra in eigene Ordner kopiert damit nicht die Videoplayer nicht irgendwie den Videostream aus einer anderen Datei holen.
  • Die orginal.ts Datei lässt sich zwar abspielen, liefert aber:
    [h264 @ 000001c389450ec0] mmco: unref short failureq=    0B f=0/0
        Last message repeated 1 times
    [h264 @ 000001c389450ec0] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
    [h264 @ 000001c389450ec0] mmco: unref short failureq=    0B f=0/0
        Last message repeated 1 times
    [h264 @ 000001c389450ec0] number of reference frames (0+5) exceeds max (4; probably corrupt input), discarding one
    [h264 @ 000001c389450ec0] Increasing reorder buffer to 2
    am Anfang des Streams
  • egal mit welcher tsMuxeR Version ich einen Remux machen will bekomme ich nur einen kaputt output.
  • Da Hybrid nicht dafür designed/gedacht ist irgendwie kaputte Streams zu deparieren kommt es mit der Datei nicht ordentlich klar.
Sieht für mich aktuell wie ein Problem der Inputdatei aus.

Was klappt ist:
1. die Datei mit mkvToolnix remuxen (einfach laden und als .mkv speichern)
2. die Datei dann mit Hybrid umwandeln.
mkvtoolnix hat ein paar Anpassungen um 'kaputte' Transportstreams zu handeln, was hier wohl reicht. Smile
-> Versuch das mal Smile

Cu Selur
Reply
#14
Danke für die Mühe. Das Wichtigste war für mich zu wissen, woran es liegt, bzw. ob es an Hybrid liegt. Es gibt ja immer so viele Möglichkeiten. Ich habe ja außerdem noch den TS-Doctor, dessen Remux-Funktion es auch nicht hingekriegt hat, ob der Streams reparieren kann. - Also ich dachte die Funktion kann es nicht, weil ich da laufend Offline-Frames in Davinci hatte. Das widerum lag aber wieder an einer fehlerhaften Verabeitung von h264 Dateien in Davinci und wurde mit dem letzten Update von DaVinci behoben. 

mkv wäre keine Option, weil man in Davinci mkv nicht importieren kann. Eine Alternative wäre noch eine komplette Umwandlung in DNxHD aber da scheint mir eine reine ffmpeg-Lösung sinnvoller. Ich brauche das aber auch nicht oft, weil Davinci nur für besondere Nachbearbeitungen brauche. Für die normale Archivierung meiner TV-Aufnahmen reichen der Doctor und Hybrid. Die Umwandlung in mp4 funktioniert ja . Die Probleme gibts nur beim Umpacken in m2ts.
Reply
#15
Der mkv-Umpack-Schritt, legt ja nicht den Zielcontainer fest. Der ist nur da um den Stream zu reparieren.
Einmal repariert kommt Hybrid mit dem Clip ja klar.

Cu Selur
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)