Beiträge von Matt Kirby

    Ich habe das Problem schon im Kodiforum gepostet. Da haben 2 Leute und ich die Sendung "Verrückt nach Meer" aufgezeichnet. Neuerdings ist der Delay nicht mehr so stark. Letztens "messe" ich nur noch einen Delay von -40ms aber immerhin. Jedenfalls hatte meine Sataufnahme, eine andere Sataufnahme und eine Kabelnetzaufnahme jeweils den Selben Delay. Nämlich -40 ms. Die Folge aus der Mediathek war ok. Da war der Ton vielleicht sogar 60 ms zu spät.

    Habe es mit TAW getestet - das selbe Ergebnis!

    Die Hand ist noch in der Luft, da klatscht es schon. Du kannst es vielleicht selber nachstellen. Wenn du ein bisschen mit dem Pause-Button am Player rumspielst. Einfach mal in der Millisekunde das Video anhalten wo der Kapitän die Hand senkt. Schnell Pause drücken. Du wirst den Ton hören und das Bild zeigt die Hand in der Luft.

    ...

    Life Übertragung

    Äh nein das meinte ich nicht. Es ging nicht um LiveSendungen sondern um normales TV-Schauen. Ohne Timeshift oder eigene Aufnahme von HDD.

    Die Sendungen, die es betrifft, waren Aufzeichnungen der ARD und kamen bei denen aus der Konserve. Ich glaube, dass es bei mir keinen Unterschied gibt zwischen Sendungen der ARD, die ich linear schaue und denen die ich selber auf eigene HDD aufgenommen habe.

    Ich weiß jetzt schon, dass es ein Kampf gegen Windmühlen wird, aber ich probier's trotzdem mal.


    Mir ist beim "Das Erste HD" schauen öfter mal aufgefallen (bei einigen Sendungen), dass der Ton einige ms zu früh kommt. Jemand klatscht in die Hände, jemand haut auf den Tisch und der "Knall" ist hörbar, da hat die Aktion noch gar nicht stattgefunden. Ich weiß, dass heutige TVs und Soundtketten Delays haben können. Ich habe meine Delays alle mit einem Testvideo gecheckt und daran liegt es nicht. Der Fehler ist auch am PC zu sehen mit verschiedenen Playern.

    Bei anderen Sendern ist alles ok. Es ist einfach so, dass bei bestimmten ARD-Sendungen der Ton einfach zu früh kommt. Und das mit ca. 100-130 ms. Das ist ein Wert den ich sehe aber wohl 90 % von den Normalzuschauern eben nicht. Bei 50 fps sind das ca. 5-6 Frames Versatz. An den Lippen merkt man es z.B. nicht, nur bei ganz prägnanten Szenen.

    Nun habe ich heute die Sendung "Verrückt nach Meer" aufgezeichnet. Einmal mit einem SAP/IP-Server und TVheadend als rohen TS-Stream. (passthrou)

    Und einmal über eine andere Sat-Leitung auf die Festplatte meines Panasonic-TVs auch als rohen TS-Stream.


    Ich habe beide TS-Streams an bestimmten Szenen mit 2 Videoschnittprogrammen und 3 verschiedenen Playern getestet. Der Ton ist einfach 100 ms zu früh.

    Also 2 Streams die aus ganz unterschiedlichen Quellen stammen haben den selben Fehler.

    Dann habe ich mir die heutige Folge aus der Mediathek runtergeladen. Und da ist alles ok. Der Ton kommt sogar vielleicht 60 ms zu spät. Aber das sehe ich so einer Quelle wie der Mediathek nach.


    Mir ist das bei "Das Erste HD", "RBB HD" aufgefallen. Auch bei Sendungen von "Dieter Nuhr" am Donnerstag Abend. Kann das sein, dass die ARD-Sender da was falsch machen (über SAT) ?

    Hallo,


    ein Bekannter arbeitet mit Aegisub hauptsächlich um Untertitel zu übersetzen. Für uns ist das immer noch DAS Tool der Wahl. Mit Subtitle Edit editiere ich nur die Zeiten aber die Live-Videovorschau finde ich da nicht so gut gelöst. Nun hat er einen neuen Windows 10 Home (64 bit) PC mit Nvidia Grafikkarte und Aegisub weigert sich irgendein Video anzuzeigen. Es wird geöffnet, indiziert und der Ton ist auch zu hören, im Videofenster wird auch das richtige Seitenformat eingestellt aber das Videofenster bleibt einfach grau. Nichts hilft. Wir haben Aegisub 32, 64 bit, portabel und die 3.2.2 und die neuste 8xxx ausprobiert. Wir haben FFMpegsource oder avisynth in den Einstellungen versucht. Nix - das Videofenster bleibt grau. Wenn man Play drückt, wird auch etwas abgespielt, der Ton und der Cursor bewegen sich aber kein Bild. Ausserhalb von Aegisub läuft das Video mit VLC, MPC-HC oder Windows Mediaplayer.

    Die neuesten Nvidia Treiber sind installiert. Es wurden auch verschiedene Videos probiert - alles ohne Erfolg.


    Hat jemand ne Idee?

    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.

    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.

    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...

    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.

    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.

    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