Was ist mit diesem h264-BluRay-File los?

  • Ich habe eine Folge einer Serie von BluRay mittels MakeMKV runtergezogen. Das MKV ist beim Abspielen völlig ok, aber Mediainfo sagt mir, dass die Bildwiederholrate 25.0029 fps (statt 25.000) ist.

    "Muxe" ich das MKV mit MKVToolnix neu und erzwinge 25.000 fps wird beim neuen MKV das Bild zum Ton 2 Sekunden asynchron. Und das nicht kontinuierlich sondern ab Zeitcode 1:15 Min:sek . Es gibt also eine ganz bestimmte Stelle an der etwas mit dem h264-Stream nicht stimmt. Nämlich genau bei 1:15 min:sek. Avidemux meckert über diese Stelle auch.


    Wenn ich Stücke von vor diesem Zeitcode muxe, ist das Ergebnis genau 25.000 fps. Wenn ich Stücke nach diesem Zeitcode muxe, ist das Ergebnis ebenfalls völlig ok. Nur wenn ich ein Video mit der betreffenden Stelle muxe, kommt irgendwas von 25.00xx fps raus. Es reicht schon nur das h264-raw-Testfile in MKVToolnix zu ziehen und zu muxen. Man sieht das fehlerhafte Ergebnis in Mediainfo.

    Was ist mit dieser Stelle im Testfile los? Kann man die analysieren und vielleicht reparieren?


    https://www.dropbox.com/sh/5i2…NTPAl_sNQDDVwfAwQm3a?dl=0

  • Habe bei dem Test-File widersprüchliche Infos, in Bezug von interlaced und progressive.

    Mediainfo zeigt TFF und mein Authoringprogramm BFF an. Da ich aber keine Interlacekonturen sehe, tippe ich auf progressive.


    Es scheint so, als ob der MKV-Kontainer ein Störsignal im Y-Signal erzeugt. Ich würde es einmal mit einem MOV-Kontainer versuchen.

    MOV unterstützt Audio bis DD 7.1.


    Ich habe dein Test-File, mit meinem Encoder noch einmal dekodiert. Jetzt bewegt sich auch der Indikator für die Zeitdauer des Videoswieder.

    Und das bei allen Softwareplayern. Habe auch die Keyframes mit 1 Schlüsselbild nach allen 25 Bildern, neu berechnen lassen.


    Ob der Fehler damit behoben ist, kannst Du ja einmal testen. Besser bringe ich das momentan auch nicht hin.

    Aber die Software TS-Doctor von unserem Kollegen Schotenhüter, stellt die meisten nicht kompatiblen Streams, wieder zu kompatiblen Files her.


    Da Mediainfo interlace anzeigt, habe ich das File als 25i erstellt. In 25p, liegt mir der Stream auch vor.


    Hier der Downloadlink:

    test__avc_TFF_25i.avc


    Gruß Jo

  • Zitat

    Scan type : MBAFF

    Scan type, store method : Interleaved fields

    Scan order : Top Field First

    MBAFF, sprich da wird pro Makroblock entscheiden ob interlaced oder progressive gespeichert wird.

    Laut den x264 Settings ist es nicht einfach 'fake' interlacing,...

    Wenn es sich um 'mixed content' handelt, kann es sein, dass Da nur wenige Szenen als interlaced zu erkennen sind.

  • Ja, also wenn ich das File selber mit MeGui neucodiere, ist das neue File problemlos in MKV zu packen. Aber ich wollte ein reines Blu-Ray-File nicht umcodieren.

    Ich meine, es liegt daran, dass an der besagten Stelle bei Timecode 0:20 Sekunden, die Bitrate für einen kurzen Moment total einbricht. (es ist ja auch nur eine weiße Buchseite in der Szene zu sehen) Irgendwas gefällt den Playern oder MKV-Muxern daran nicht. Auch FFmpeg muxt das originale File nur mit Fehlern an der Stelle zu mkv. Das Ergebnis ist zwar ein mkv mit genau 25.0000 fps aber an besagter Stelle ruckelt es beim Abspielen. Wenn ich Frame für Frame an die Stelle rangehe und mich durchklicke (wie die Seite umgeblättert wird) fehlen hier Frames.


    Also wenn ich bei 25.0xy fps bleibe, ruckelt an der Stelle nix aber mir kam das komisch vor. Es geht hier eigentlich nur ums Prinzip. Ich wollte nur mal wissen was das soll. Weil es handelt sich schließlich um einen BluRay-Standard-File mit dem die MKV-Muxer nicht sauber klar kommen.

  • Zum Thema MKV kann ich nur soviel schreiben, was man von Edit-Profis hört. Da gab es auch Schwierigkeiten mit MKV.

    Vermutlich wollten die Profis Codecs von Sony und Canon, die ja bekanntlich auch nicht immer konform sind, mit MKV erstellen.

    Jedenfalls waren die Streams mit MKV, zu einigen Schnittprogrammen nicht kompatibel.


    Streams wurden gar nicht erst importiert oder geöffnet, aber mit MOV oder AVI schon. Scheinbar unterstützen die Amis (Schnittsoftware) den Russen-Kontainer nicht so, wie es sein soll.


    Technisch ist MKV besser als MOV, das ist richtig. Das mit dem Störsignal liest sich komisch, stimmt, aber ein Kontainer muss ja auch programmiert werden. Ich glaube nicht, dass MKV keine Programmierfehler aufweist.

    Wenn dann noch ein fehlerhaftes File dazukommt, wird das halt auch so im Kontainer gespeichert.

    Bei mir zeigt das originale AVC-File eine Bitrate von 18148 Kbps an.

    Wenn genau diese Bitrate wieder eingegeben wird, müsste die Bildqualität theoretisch gleich sein, wie die des originalen Streams. Vermute ich einmal.


    Beim ersten Bild sehe ich auch viele Pixel, als 2 Streifen im ersten und zweiten Drittel.

    Sieht aus, als wenn dein Aufnahmemedium nicht schnell genug reagiert hat.

    Hatte ich auch einmal, als ich DV-Material auf einer lngsamen Festplatte aufgezeichnet habe. Bei dir liegt das vermutlich an anderer Stelle.

    Was das soll, das werden dir nur Softwareentwickler schreiben können.

  • Der Kontainer heißt "Matroska", weil er wie die russische Puppe einen vielfältigen Inhalt haben kann. Nicht weil er von einem Russen entwickelt wurde.


    Selbstverständlich muss die Unterstützung eines Kontainers für ein bestimmtes Anwendungsprogramm programmiert werden. Und das ist bei der Komplexität des Matroska-Kontainers sicher nicht einfach. Aber dafür existieren ja schon u.a. die Bibliotheken "libEBML" und "libMatroska". Die könnte man u.U. benutzen, wenn deren Lizenz das zulässt. Das alles ist aber kein Anlass, der Matroska-Spezifikation die Schuld zu geben, wenn die Implementierung nicht korrekt ist, und erst recht nicht, wenn da eigener Code zum Einsatz kommt, der gar nicht vom Matroska-Team stammt.


    Gleiche Bitraten sind grundsätzlich keine Garantie für gleiche Qualität. Zum einen könnte ein anderer oder anders eingestellter Encoder zum Einsatz kommen; zum anderen verschlechtert sich die Qualität mit jeder Generation einer Recodierung weiter.


    Und ... Pro Jo – was redest du über ein "Aufnahmemedium", wenn Matt Kirby doch geschrieben hat, dass er eine Blu-ray-Disk ausgelesen hat?


    Für die Analyse der Videospur fehlen mir leider Mittel (Ablaufverfolgung der Decodierung im Streamparser und Videodecoder) und Zeit. Wenn es allerdings Sprünge in Timecodes und Frameabfolge gibt, dann handelt es sich sicherlich um einen technischen Fehler, aber ich könnte wohl kaum zuverlässig herausfinden, ob der erst beim Auslesen durch makeMKV entstanden ist oder bereits während der Produktion der Blu-ray.

  • Ja, die Serienfolge stammt von einer Kauf-Blu-Ray. Da es sich dabei um den Vorspann einer Serie mit mehreren Teilen handelt, habe ich die anderen Folgen auch gecheckt. Und bei jeder Folge gibt es an dieser Stelle Probleme. Ich habe leider keinen "Roten Fuchs" mehr und kann nur MakeMKV benutzen um die Folgen runter auf HDD zuziehen. Aber ich denke, es ist kein Problem von MakeMKV. Irgendwas stimmt da nicht mit der h264-Codierung.

    Ich habe von den selben Machern auch noch eine andere Serie auf Blu-Ray. Auch da tritt dieser Fehler auf, wenn sich im Bild nicht viel bewegt und die Bitrate stark runtergeregelt wird.

  • Ich würde auch vermuten, dass da u.U. das Ende des Vorspanns in seiner .mts-Datei abgeschnitten ist, und an der Stelle, an der er durch Playlists mit der eigentlichen Folge zusammengefügt wird, sich dann ein unvollständiges Frame befindet. Vielleicht kann man ja die Folgen ohne Vorspann konvertieren.

  • OK, ich konnte mittels "Fuchs" eine Folge als reines m2ts runterziehen. Der Vorspann ist in jeder m2ts-Datei vorhanden. Also nix mit Playlisten und dann aus Teilen zusammenbauen. MediaInfo zeigt beim Originalen M2ts die genauen 25.000 fps an. Packe ich es um in MKV mittels MKVmerge (MKVToolnix) ist das neue File wieder 25.078 fps. Wie gesagt, ich vermute, es liegt an der einen Stelle...

  • Woher die Bezeichnung Matroska kommt, das ist mir schon klar. Ja, das ist auch klar, dass sich mit jeder weiteren Generation die Bildqualität verschlechtert. Das weiß ich nur zu genau, z. Bsp. von einer 3. Kopie eines VHS-Signals.

    Das kann man normalerweise nicht mehr anschauen, aber viele Leute damals störte das trotzdem nicht.

    Da hatten schlechte Camcorder eine Auflösung von nur 2 MHz.


    Aufnahmemedium:

    Da beim ersten Bild Pixel zu sehen sind, vermute ich, dass die Festplatte am Anfang des heruntergezogenen Blu-ray-Streams, einen Hauch Verzögerung hatte. Oder es ist Pfusch von tschechischen Produktionsstätten.

    Es war ja nur eine Vermutung von mir, dass eventuell die HDD zu langsam anlief. Es sei denn, Matt zog den Ausschnitt auf SSD.

    Aber das war nicht das Problem.


    Es gibt auch Leute, die einen AVC-Stream von 12.000 Kbps nochmals auf 8.000 Kbps reduzieren.

    Von einer Qualitäts-Verschlechterung, sieht da niemand etwas. Für mich wäre das nichts.

  • das rippen von digitalen medien verursacht keine analogen fehler.

    wenn die HDD zu lanhsam ist, dann rippt man halt nur mit 0,01x oder weniger, monate lang.

    außerden gibt es einen schreib cache, der die trägheit langsamer laufwerke abfängt.


    digitale fehler können trozden passieren, software/hardware fehler.

    die sollten nicht immer an der exakten stelle sein.


    unter stützt dein rip tool das rohe spiegeln der dateistruktur?

    dann schau dir mal die rohen *.m2ts dateien an und schau ob da auch der fehler auftritt.


    das klingt autoring fehler.

    entweder im video, oder in der blueray playlist...



    "Da beim ersten Bild Pixel zu sehen sind..."

    das klingt als wenn die playlist schnittmarken nicht bei einem kayframe sind.

    das sollte das autoringprogramm und das rip programm kennen.

  • dann schau dir mal die rohen *.m2ts dateien an und schau ob da auch der fehler auftritt.

    Nein, das originale m2ts scheint völlig ok zu sein. Nur wenn ich dieses umverpacke mit mkvmerge, schein irgendwas nicht zu stimmen.


    und dass am Anfang Pixel sind, ist weil ich es einfach durch mkvmerge beim muxen in viele kleine Teile habe splitten lassen um den Fehler einzukreisen. Nochmal: DER FEHLER TRITT AUF, WEIL DIE STELLE BEI TIMECODE 20 SEKUNDEN IRGENDWIE ANDERS IST. Das sieht man ganz einfach beim Bitrate Viewer.

  • und der author von mkvmerge auch...

    jedenfalls klingt es so, dass erst nach dem remuxen der fehler passiert.


    was ich aber auch mal hatte, das videos im mpeg-ts anders behandelt werden, als in anderen kontainern.

    weil die programme einfach fehlerhafte streams erwarten (analog zu dvb-s)


    sind in m2ts fehlerkorrektur daten vorhanden, die dann verworfen werden?


    auch wollt ich mal fragen ob die fehlerstelle im m2ts stream frame für frame konzrolliert wurde?

    ggf auch die audiospur auf ungewöhliche unterbrechungen prüfen...

  • auch wollt ich mal fragen ob die fehlerstelle im m2ts stream frame für frame konzrolliert wurde?

    Ja, mit MPC-HC bin ich Frame für Frame die Stelle durchgegangen, und es sind alle Bilder da.

    Wie gesagt: FFMpeg zeigt beim Muxen zu MKV auch Fehler an der Stelle an.


    ggf auch die audiospur auf ungewöhliche unterbrechungen prüfen...

    Den Ton können wir aussen vorlassen. Weil ich den Fehler auf das reine RawVideo avc(h264) einkreisen konnte.

    Es kann sich auch jeder das Testfile, was oben verlinkt ist downloaden und damit Muxtests anstellen.