"Stockendes" Video beheben

  • Ich erkenne da nicht viel Stocken, das meiste sieht für mich ziemlich flüssig aus. Ausnahme vielleicht bei 2:34, wenn der Gefoulte aufsteht, da sehe ich im Vollbild etwas, das an "Tearing" erinnert, also dass ein Bildwechsel mitten im Bildaufbau des Monitors passiert. Da sollte man diese Szene vielleicht mal langsam analysieren, ob das ein Problem des Materials oder der Wiedergabe ist. Kann ich aber im Moment nicht.

  • Schließe mich LigH an, kann auch nichts stotterndes erkennen. Kannst Du uns einen Hinweis geben an welcher Stelle Du das siehst?

    Vielleicht mal einen anderen Player benutzen (VLC, MPC-HC,Pot-Player......). Fragmentierte Festplatte, Hintergrundprogramme, Virenscanner.... können das Abspielen auch beinflussen.

  • Das ist Material, das sicher ursprünglich mal 50Hz interlaced war (also 50 Halbbilder hatte) Nun ist es aber 25p. (also nur 25 Vollbilder)

    Dann ist das normal, dass es nicht mehr so flüssig wirkt. Da kann man aber nicht mehr viel machen, ausser das Material, wenns von VHS stammt, nochmal zu capturen und zwar indem man alle Halbbilder mitnimmt.

  • Ich habe mir den Stream mit den VLC- und MPC-Playern angesehen. Es wird alles flüssig abgespielt. Die Bewegungen des Balls sind ebenfalls flüssig.

    Bei Zeit 2:44, ist ein gewisses „ruckeln“ zu erkennen.

    Um die Spielsituation besser zu erkennen, schalten die Sender bei Zeitlupe meistens auf langsamere 12- oder 15 Bilder/s um.

    Das wird dann als ruckeln wahrgenommen. Keine Sorge, das ist so in Ordnung.

    Es sieht so aus, als wäre das Video mit „Blend“ in progressive erstellt worden. Ab und zu erkennt man noch Interlacestreifen.

    Hatte ich aber auch schon mit Yadif.

    AVI für MP4:

    Hat man vor, SD-Filme als mp4 zu archivieren, dann muss ein SD-AVI mit 16-235 zu 0-255 konvertiert werden. Erst dann zu mp4 wandeln.

    MP4 ist ein RGB-Codec mit 0-255. Deswegen sind ca. 98% der Filme auf YT falsch erstellt, da nicht auf 0-255 konvertiert wurde.

    Auch die RGB-Farben könnten clippen.

    Ob YT automatisch auf 0-255 konvertiert, weiß ich nicht. Da verlasse ich mich lieber auf meine korrekt erstellten Streams.

    Der Tipp von Bogilein mit dem Vierenscanner war gut. So wie Matt Kirby, sehe ich das auch.

  • AVI für MP4:

    Hat man vor, SD-Filme als mp4 zu archivieren, dann muss einSD-AVI mit 16-235 zu 0-255 konvertiert werden. Erst dann zu mp4 wandeln.

    MP4ist ein RGB-Codec mit 0-255. Deswegen sind ca. 98% der Filme auf YT falscherstellt, da nicht auf 0-255 konvertiert wurde.

    Auch die RGB-Farben könntenclippen.

    So viel Blödsinn auf einmal hab ich ja schon lange nicht mehr gelesen...

    1. MP4 ist ein Container, kein Codec.

    2. Alle MPEG-Videocodecs – MPEG1, MPEG2, MPEG4-(A)SP, MPEG4-AVC, HEVC – unterstützen den YUV-Farbraum, weil der effizienter encodiert werden kann als RGB, indem man Eigenschaften der menschlichen Augen ausnutzt.

    3. MPEG4-AVC unterstützt auch Video in vollem Farbumfang. Üblich ist aber weiterhin der reduzierte Farbumfang aus den Standards der Fernsehtechnik. Dafür gibt es aber mehr als eine Umrechnungsmatrix von YUV zu RGB: In Zeiten von MPEG1 und MPEG2 mit SD-Auflösung war Rec601 verbreitet, seit den HD-Formaten wird jedoch Rec709 verwendet, und HEVC unterstützt sogar hohen Dynamikumfang mit Rec2020.

    4. Wenn Videos auf Videoportalen falsch aussehen, dann liegt das nicht daran, dass sie nicht in RGB konvertiert wurden, sondern eher dass sie während einer vorherigen Bearbeitung in RGB konvertiert wurden und dann vor dem Hochladen falsch neu encodiert wurden. Mit so teuren kommerziellen Programmen wie Adobe Premiere kann man hier mehr falsch machen als mit kostenlosen AviSynth-Skripten...

  • Ja, MP4 ist ein Kontainer, kein Codec. Mit MPEG-4 meint man allgemein AVC, und dieser Codec ist normalerweise RGB bei HD 1080.

    Das muss nicht immer auf die Goldwaage gelegt werden. Es kommt auf den Camcorder an, ob RGB oder YUV verarbeitet wird.

    Da lohnt ein Blick in die Bedienungsanleitung.

    RGB ist meistens bei hochwertigen Geräten (Profi-Bereich) der Fall. Aber qualitätsmäßig, ist da kein Unterschied mehr festzustellen.

    Bei wirklich guten Geräten. Das wollte ich damit ausdrücken. Deine PC-GK ist ja auch bestimmt auf 0-255 eingestellt.

    Darum verlang z. Bsp. YT Streams in diesem Bereich. RGB mit 16-235, habe ich noch nie irgendwo gelesen. Aber das hast Du ja nicht geschrieben.

    Mit teuren Schnittprogrammen, kann man eigentlich auch nichts falsch machen. Ausgenommen die Farben werden nicht angepasst.

    Entweder man exportiert mit YUV oder mit RGB. Konsumer SD-Material ist immer YUV.

    Habe seit 38 Jahren noch nie erlebt, dass Konsumer-SD von Amateuren in RGB war. Im Profi-Bereich gab es Sony Betacam und von Panasonic M II.

    Diese, glaube ich, waren kurzzeitig mit RGB-Anschlüssen und 4:2:2 Interfaces bestückt. Danach bekamen diese auch YUV-Anschlüsse.

    Die Bänder liefen nur 2 Stunden und kosteten damals um die 400 DM. Das ist heute alles technisch weit überholt.

    Nochmals zu Punkt 4:

    Es ist schon wichtig, ob man 16-235 oder 0-255 hat. Nach den korrekten Helligkeitswerten richtet sich auch die Farbintensität.

    Es können auch Farbverschiebungen auftreten. Ich kenne umgekehrte Fälle von RGB zu YUV.

    Bei RGB waren es Streams mit korrekter roter Farbe, bei YUV war rot dann orange. Alles schon erlebt. Das ist meine Meinung.

    Deine anderen Ausführungen sind mir auch bekannt.

  • Nein, AVC ist nicht "im Allgemeinen RGB". Ganz und gar nicht. "Main Profile" und "High Profile" sind YUV 4:2:0. Zumindest wie die Daten digital gespeichert sind. Wie Abspielgeräte das decodieren, bevor sie Signale an Fernseher ausgeben, hat damit nichts zu tun. Wenn du ein Abspielgerät hast, das HDMI oder RGB-Anschlüsse hat, dann kann das durchaus RGB-Signale ausgeben. Es ist richtig, dass Composite, S-Video und Euro-SCART üblicherweise bei älteren SD-Abspielgeräten eher moduliertes YUV ausgeben. Aber moderne HD-Abspielgeräte können auch älteres SD-Material zu RGB decodieren. Das ist unabhängig davon, dass das Main-Profile von MPEG2 und MPEG4 digital als Datei auf dem Datenträger YUV 4:2:0 speichert.

  • Danke für deine Erklärungen. Ja, das ist richtig.

    Zum Beispiel bei SD-Sat-Receivern, kann man das Bildsignal auswählen, ob man FBAS/- Y/C- oder RGB haben möchte.

    Dass HD 1080 immer RGB sein soll, stand einmal in einer Tabelle eines Camcorder-Herstellers.

    Wahrscheinlich gingen die von der Qualität ihrer Profi-Camcorder aus. Ich habe das nur weitergegeben, kommt nicht von mir.

    Ich habe mich auch gewundert, dass lt. dem Schreiben HD 720p auf einmal YUV sein soll. HDV mit 1440x1080 wieder RGB.

    Wenn ich das so nicht gelesen hätte, könnte ich das ja nicht schreben.

    Komisch ist nur, wenn ich aus dem Schnittsystem YUV-Streams mit korrekten 16-235 exportiere und dann mit dem Encoder zu MP4 mit H.264 komprimiere, dass dann 0-255 herauskommt. Das ist auch der Fall mit direkten H.264- und x264-Codecs, ohne Container.

    Zum Glück bietet die Encodersoftware Filter an, mit denen man auf 16-235 korrigieren kann. Das komprimierte Material ist dann auch wirklich 16-235.

    Um die Helligkeitswerte abgleichen zu können, braucht man aber ein extra Messtool, das die Helligkeit der einzelnen Pixel misst.

    Mich würde interessieren, wie sich andere gute Encoder verhalten. Aber das, dürfte hier jeden egal sein.

  • Entschuldigt bitte die sehr späte Reaktion. Wir haben zu Hause Nachwuchs bekommen und die Freizeit ist auf annähernd Null gerutscht.

    Das Video stockt bei mir im Grunde über die gesamte Laufzeit. Es ist nicht so, dass das Bild für 1 Sekunde still steht oder so aber die Bewegungen sind stockend, nicht so fließend wie man es normalerweise gewöhnt ist. Ich habe das sowohl am PC mit dem VLC Player als auch an meinem LG SmartTV, so dass ich nicht davon ausgehe, dass es am Abspielgerät liegt.

    Das bei youtube hochgeladene Video war nach meinem Gefühl nicht mehr ganz so stark betroffen. Ich weiß also nicht ob youtube das Video noch irgendwie abändert beim Uploaden. Daher habe ich es wieder rausgenommen.

    Mittlerweile scheine ich das Problem mit VideoRedo gelöst zu haben. Hier der Vergleich:

    Originalvideo:

    https://www.file-upload.net/download-13985…iginal.mp4.html

    Mit Videoredo ohne Änderungen remuxed:

    https://www.file-upload.net/download-13985…chRedo.mp4.html

    Der Pixelverlauf im Original sieht merkwürdig aus, die technische Spezifikation hierfür kenne ich nicht. Nach dem Wandeln sehe ich jedenfalls keine Auffälligkeiten.

    [Blockierte Grafik: https://s19.directupload.net/images/200406/un4uykak.jpg]

    [Blockierte Grafik: https://s19.directupload.net/images/200406/itgt6ofe.jpg]

    Erkennt ihr den Unterschied?

  • Die spätere Reaktion ist für uns kein Problem. Wir haben ja noch ein anderes Leben, als Videobearbeitung.

    Bei dem "Pixelverlauf" sehe ich jetzt nur im ersten Moment, dass 1 Pixel nach links verschoben werden müsste. Die Farbe um 25% dämpfen.
    Das alles geht mit VDub.

    Mit dem QuickTime-Player sehe ich, dass die Bildrate beim originalen Video bei Wiedergabe von 24 bis 26 Bilder/s reicht.
    Ich vermute, daher kommt das Ruckeln.


    Mit VDub auf 25,00 Bilder/s konvertieren, dann müsste der Stream flüssig laufen.
    Aber das hat ja VideoRedo schon auf die richtige Bildrate gewandelt. Nach VideoRedo wird von 24,67 - 25,33 Bilder/s angezeigt.


    Ich gehe davon aus, dass das nur dieses eine Video ist, das ruckelt.

    Ich würde das originale Interlace-Video erst zu korrekten 25 Bilder/s konvertieren, und dann erst deinterlacen.
    Dann ist der Ton auch besser synchron. Dein "Originalvideo" ist aber bereits deinterlaced.


    Ich habe mir einmal dein Testvideo so erstellt, wie ich das machen würde. Alle Bilder laufen einwandfrei flüssig und sind konstant 25 Bilder/s.
    Da muss irgendwas nicht von deinen Wiedergabe-Geräten gepasst haben.

    Am unteren Bildrand noch 2 Pixel abdecken, dann sieht man überhaupt kein "Jitter" mehr.

  • Ich habe eine ganze Reihe von Videos, die betroffen sind. Leider liegen sie mir nur in dieser Form vor, also bereits deinterlaced.

    Bin froh, dass VideoRedo die Bildrate automatisch anpasst ohne dass es zu Qualitätsverlusten führt. In der Vorschau sind in unregelmäßigen Abständen graue Pixel zu sehen, außerdem ist in diesen Bereichen die Zeitachse durcheinander. Im obigen Fall "0,00/0,02/grau/0,03/0,06/0,06/0,02/0,07..." - ist vermutlich das, was du mit "um 1 Pixel nach links verschoben" beschreibst.

    EDIT: So ganz zufrieden bin ich mit dem VideoRedo Ergebnis doch nicht. Habe mehrere Videos auf diese Art remuxed und am SmartTV getestet. Eins lief plötzlich in doppelter Geschwindigkeit, bei mehreren anderen gab es Nachzieheffekte wenn der Ball in bewegung war.

    @ProJo Du sprachst davon, man könnte die Videos mit VDub auf 25,00 Bilder/s konvertieren. Wäre es dir möglich den Vorgang zu schildern?

    Einmal editiert, zuletzt von Mifsud (7. April 2020 um 14:12)

  • Selbstverständlich kann ich dir den Bildkonvertierungsvorgang beschreiben.
    Für den MPEG-4-Kontainer braucht man dazu VDub 2. Im obigen Reiter auf Video klicken, dann erscheint etwas unten "Video frame rate control".
    "No change" bei "Source rate adjustment" so lassen.

    Aber bei "Frame rate conversion" auf "Convert to fps" klicken und 25 fps eingeben, und auf OK.
    Jetzt wird konstant auf 25 Bilder/s ausgegeben. Bei mir war das noch flüssiger, als mit VideoRedo. So hatte ich zumindest den Eindruck.


    Das Bild kann man mit dem Filter 6-axis color correction (Anton) abgleichen.
    Hier hat man die Möglichkeit, die Farben getrennt zu regeln.


    Graue Pixel sehe ich bei VDub jetzt nicht, aber vielleicht hast Du bessere Augen als ich. Es kann auch sein, dass das VideoRedo anzeigt.
    Normalerweise sind das weiße Pixel, aber das ist eigentlich nur bei DV-Material der Fall.
    Gute Schnittsysteme haben dazu einen Filter, mit dem man das beheben kann. Bei mir heißt dieser "Pixel Fixer".


    Ich vermute, dass die grauen Pixel VideoRedo, aufgrund der nicht korrekten Bildrate erzeugt.
    Daher würde ich zuerst mit VDub die richtige Bildrate von 25 Bilder/s erzeugen, und dann erst mit VideoRedo weiterverarbeiten.
    Ich kann nur hoffen, dass es danach keine grauen Pixel mehr gibt. Ich wüsste jetzt keine Vorgehensweise, wie der Fehler zu beheben wäre.


    Ich meinte einen Farbpixelversatz von -1 nach links, dann wären die Bildkonturen fast ohne Farbsaum.


    Eine doppelte Geschwindigkeit, kann mit dem Shutter des Camcorders zusammenhängen. Das nuss man dann nachträglich manuell korrigieren.
    Ein Nachzieheffekt kann auch vom Shutter einer Cam stammen, aber auch wenn schlecht deinterlaced wurde.


    Wenn alle deine Files schon in MPEG-4 und deinterlaced vorliegen, dann ist das mit ziemlicher Sicherheit nicht mehr zu reparieren.
    Dazu bräuchte man das originale AVI-Video in interlace.

    Mifsud_Jo_Video-frame-rate-control-25B.png

  • Selbstverständlich kann ich dir den Bildkonvertierungsvorgang beschreiben.
    Für den MPEG-4-Kontainer braucht man dazu VDub 2. Im obigen Reiter auf Video klicken, dann erscheint etwas unten "Video frame rate control".
    "No change" bei "Source rate adjustment" so lassen.


    Aber bei "Frame rate conversion" auf "Convert to fps" klicken und 25 fps eingeben, und auf OK.
    Jetzt wird konstant auf 25 Bilder/s ausgegeben. Bei mir war das noch flüssiger, als mit VideoRedo. So hatte ich zumindest den Eindruck.

    Soweit umgesetzt. Wenn ich anschließend unter "Save as..." als mp4 (Auswahl: "MP4 (MPEG-4 Part14) (*.mp4)" abspeichern möchte, kommt folgende Fehlermeldung:

    [Blockierte Grafik: https://s12.directupload.net/images/200408/xrfk837b.jpg]

    Filter habe ich zunächst keine gesetzt, unter Compression "Uncompressed RGB/YCbCr) belassen.

    Welcher Codec ist sinnvoll um bei der Datei einzig die Bildrate auf 25 zu ändern oder sie ansonsten unnötig zu verändern?

  • Komisch, bei mir klappt es. Habe auf dem Büro-PC VDub2 32 Bit, Version 41493. In der Fehlermeldung steht PCM.
    Scheinbar liegt hier ein Problem mit dem unkomprimierten Ton (1536 Kbps, 48kHz) vor. Versuche einmal den Ton auf AAC 320 Kbps einzustellen.
    Bei Uncompressed RGB/YCbCr, muss aber auch der PCM-Ton in VDub2 gehen. Steht Audio eventuell auf 44.1 kHz?


    Ich kann mir den Fehler nicht erklären. 25 Bilder/s sollten eigentlich bei jedem Codec funktionieren.
    Zur Anschauung, lade ich dir einmal meinen erstellten Stream hoch.


    GladbachOriginal_25B_Jo_mp4.avi


    Um der Sache näher zu kommen, könntest Du einmal einen Screenshot von den Einstellungen mit dem H.264-Codec in MP4 machen.
    Dann kann ich dir vielleicht weiterhelfen. Bei "Force keyframes every" 25 frames einstellen.

  • Also irgendwas mache ich falsch. Ich will aus der .mp4 wieder eine .mp4 Datei machen und nur die Bildrate auf 25 Bilder/s setzen. Der Rest wie Bitrate und Größe der Datei sollte ja in etwa gleich bleiben. (siehe das VideoRedo Resultat). Daher sehen meine Einstellungen wie folgt aus:

    [Blockierte Grafik: https://s12.directupload.net/images/200410/wt82p56k.jpg]

    Anschließend unter "Save as.." .mp4 ausgewählt.
    [Blockierte Grafik: https://s12.directupload.net/images/200410/g28lia78.jpg]

    Bei besagter Einstellung kommt die obige Fehlermeldung. Lasse ich den Haken beim Ton testweise aus, pummt VDub mir die .mp4 auf mehrere GB auf und erstellt die Datei mit 124 Mbit/s.

    Ist mein Einstellungsfehler bereits im ersten Schritt drin, weil "uncompressed RGB/YcBcr" gar nicht bedeutet, dass die Ursprungsbitrate beibehalten wird?


    Wähle ich im ersten Schritt "x264vfw - H.264/MPEG -4 AVC codec" aus, sehen meine Einstellungen so aus:

    [Blockierte Grafik: https://s12.directupload.net/images/200410/phc8newk.jpg]

    [Blockierte Grafik: https://s12.directupload.net/images/200410/gesb923t.jpg]

    [Blockierte Grafik: https://s12.directupload.net/images/200410/jup6i5ga.jpg]

    PS: Lass dich bitte nicht von den Dateinamen irritieren. Ich habe nicht immer drauf geachtet das gleiche Ausgangsvideo zu verwenden.

    2 Mal editiert, zuletzt von Mifsud (10. April 2020 um 11:33)

  • Du kannst doch in einer MP4-Datei nicht einfach sonstwas speichern. Erst recht nicht unkomprimiertes Audio und Video. Bei dem MP4-Container muss man sich schon an MPEG-Spezifikationen halten. In MP4 erlaubte Videoformate wären z.B. MPEG4-ASP (was der DivX- oder Xvid-Codec speichern) oder MPEG-4-AVC (was der x264-Codec speichert) oder HEVC (was der x265-Codec speichert). Aber unkomprimiertes RGB ist unkomprimiertes RGB und riesig. Und es bedeutet nicht "das Originalvideo unverändert", sondern "das dekomprimierte Video".

    Wenn man das Originalvideo erhalten wollte, müsste man den Verarbeitungsmodus im "Video"-Menü auf "Direct Stream Copy" stellen. Ich bezweifle aber, dass VirtualDub2 dann auch im MP4-Container speichert. Es gibt da merkwürdige Einschränkungen aufgrund der Schnittstelle, mit der Codecs und Multiplexer darin verwaltet werden.

    Mit VirtualDub2 kann es notwendig sein, das Material neu zu komprimieren. Möglichst wieder in einem effizienten Videoformat (z.B. x264 als Videocodec und AAC als Audiocodec).

    Wenn man weitgehend verlustlos von MP4 nach MP4 kopiere wollte und dabei nur die Video-Framerate auf einen festen Wert setzen will (VFR to CFR), bietet mir eine Google-Suche nach mp4 convert vfr to cfr eine Menge Vorschläge an, dies z.B. mit ffmpeg an der Eingabeaufforderung zu versuchen (wofür auf ein paar GUIs erhältlich sind), oder mit HandBrake (was im Grunde einen ffmpeg-Kern verwendet).

  • Wenn man wieder MP4 haben will, dann muss man den x264-Codec auswählen, was Du ja schon richtig gemacht hast.

    Nur dein Ratefactor mit 6.0 ist zu hoch.

    Hier genügen 16.0 vollkommen. Dann hat deine Datei so um die 230 MByte. Vorausgesetzt der Ton wird mit FFMPEG AAC und 192 Kbps komprimiert.
    Uncompressed wäre hier falsch. Bei Audio "Full processing mode" die Compression einstellen.


    Versuche bitte einmal folgende Einstellungen:

    Mifsud_Jo_Video-frame-rate-control-25B.png

    Video-Codec:

    GladbachOriginal_Jo_x264-Videocodec.png

    x264 Configuration:

    GladbachOriginal_Jo_x264-config_16.png

    Video-Compressor:

    GladbachOriginal_Jo_x264_Compressor.png

    Wenn es jetzt nicht funktioniert, dann weiß ich auch nicht mehr weiter. Erst mit VideoRedo weiterarbeiten, wenn es mit VDub2 klappt.

    Ich kann nur hoffen, dass deine Filter in den richtigen Ordnern für 32- und 64 Bit liegen.

    Viel Glück.

Jetzt mitmachen!

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