Video 50i Geschwindigkeit verändern - Was ist der optimale Schritt um Ruckler zu vermeiden?

  • Hallo Zusammen,


    ich möchte die Abspielgeschwindigkeit eines Videos mit 50i verändern.


    Gibt es eine Möglichkeit den Schritt so zu definieren sodass das Video danach keine Ruckler hat?


    Normale Geschwindikeit = 1
    Neue Geschwindikeit 1.050 > Ruckler
    Neue Geschwindikeit 0.950 > Ruckler


    VG Uli

  • Was ist 50i? 50Hz interlaced? Und jetzt willst Du 52.5Hz bzw. 47.5Hz? Und warum sollte es dann nicht mehr ruckeln?

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Vielleicht hilft ja was in die Richtung.


    http://blog.grio.com/2012/01/f…on-video-with-ffmpeg.html

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Irgend welche Ruckler werden immer auftreten, da der Monitor seine Bildwiederholrate auch nicht in solch feinen Schritten anpassen kann. Oder hast du einen alten Röhrenmonitor?

  • Hi Uli


    ich möchte die Abspielgeschwindigkeit eines Videos mit 50i verändern.


    Gibt es eine Möglichkeit den Schritt so zu definieren sodass das Video danach keine Ruckler hat?


    An deiner Stelle würde ich folgendes versuchen: Eine Sequenz aufnehmen, bei der im Live-Mode das Problem gut sichtbar ist. Danach als Aufnahme abspielen und im rpihddevice-Plugin die Standard-Widergabegeschwindigkeit schrittweise erhöhen/senken bis du einen Wert hast, bei dem die Ruckler auftreten. Den Wert findest du in omxdevice.c auf Zeile 29:


    Code
    int cOmxDevice::s_speeds[2][8] = {
    	{ S(0.0f), S( 0.125f), S( 0.25f), S( 0.5f), S( 1.0f), S( 2.0f), S( 4.0f), S( 12.0f) },
    	{ S(0.0f), S(-0.125f), S(-0.25f), S(-0.5f), S(-1.0f), S(-2.0f), S(-4.0f), S(-12.0f) }
    };


    Wenn du mir sagst, bis zu welchem Wert bei dir die Widergabe flüssig läuft, passe ich das im Plugin gerne an.


    Trotzdem würde mich interessieren, ob das bei dir mit einem andern Display auch auftritt, und ob du ganz bestimmt einen Mode mit 50Hz eingestellt hast. Die Einstellung im Plugin ist dafür keine Garantie, denn die Umstellung erfolgt nur, wenn das Display den Mode auch unterstützt.


    Weiter könntest du noch untersuchen, ob der Deinterlacer allenfalls einen Einfluss hat. Deaktivieren kannst du ihn, indem du in omx.c auf Zeile 254 die Abfrage mit einem "&& false" ausser Kraft setzst:

    Code
    if (cRpiDisplay::IsProgressive() && m_videoFormat.interlaced)


    Alternativ kannst du die Ausgabe auch auf 50i stellen, dann wird der Deinterlacer auch nicht aktiv.


    Gruss
    Thomas

  • Ach hier gehts um RPi? Muss ich überlesen haben. 8o

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Hallo halbfertiger,

    Irgend welche Ruckler werden immer auftreten, da der Monitor seine Bildwiederholrate auch nicht in solch feinen Schritten anpassen kann. Oder hast du einen alten Röhrenmonitor?

    Das wird wohl so sein wie du sagst, Ausgabe an HDMI is 1080p 50hz (fest eingestellt, hdmi_mode=31) Der TV ist ein LED-TV 55" und erkennt auch die 1080p und gibt diese wieder.


    Hallo Thomas,

    An deiner Stelle würde ich folgendes versuchen: Eine Sequenz aufnehmen, bei der im Live-Mode das Problem gut sichtbar ist. Danach als Aufnahme abspielen und im rpihddevice-Plugin die Standard-Widergabegeschwindigkeit schrittweise erhöhen/senken bis du einen Wert hast, bei dem die Ruckler auftreten

    Danke für den Hinweis. Das habe ich bereits getan und ohne Ruckler läuft nur eine Geschwindiket von 1x. Um so höher die abweichenden Werte um so schlimmer die Ruckler.


    Wenn du mir sagst, bis zu welchem Wert bei dir die Widergabe flüssig läuft, passe ich das im Plugin gerne an.

    Ich kann die also gar nicht zu irgendwelchen Werten raten, weil nur die Geschindigkeit 1x ruckelfrei funktioniert.


    Mir erscheint das auch logisch weil der Fernseher eine Wiederholrate von 50Hz hat und das Video dann mit z.B. 50.01Hz abgespielt wird. Da treten die Ruckler natürlich nur bei viel Bewegung (horizontale Kamarafahrten) auf.


    Weiter könntest du noch untersuchen, ob der Deinterlacer allenfalls einen Einfluss hat

    Das kann ich noch testen, schließe es aber eigentlich schon aus, weil die Ruckler vom Livebetrieb in der Aufnahme die ja mit 1x gespielt wird nicht mehr zu sehen sind.


    Hallo Chief,

    Ach hier gehts um RPi? Muss ich überlesen haben.

    spielt das eine Rolle?


    Aber nochmal zu meiner Eingangsfrage, eventuell gibt es ja ne Logik mit welcher man das Video verlangsamen kann um die Unterschiede zwischen TV-Framerate und Video-Framerate optisch zu eleminieren.


    VG Uli

  • Ob das eine Rolle spielt? Irgendwie schon, es macht schon einen Unterschied, ob du was programmieren willst, ob es um einen Livestream geht oder einfach nur ein Video umwandeln willst. Da es hier um RPI geht, bin ich mal raus.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Hi Uli

    Mir erscheint das auch logisch weil der Fernseher eine Wiederholrate von 50Hz hat und das Video dann mit z.B. 50.01Hz abgespielt wird. Da treten die Ruckler natürlich nur bei viel Bewegung (horizontale Kamarafahrten) auf.

    Die Idee der Taktnachführung ist natürlich den Pixeltakt entsprechend anzuheben oder zu senken, damit das Video auch mit Korrektur noch flüssig läuft. Dem Fernseher sollte es dabei egal sein, ob er nun sein Bild mit 50.01 oder 49.99 Hz refresht. (Dass dies beim Raspberry auch wirklich funktioniert, habe ich mir extra nochmals bestätigen lassen )


    Wenn das bei dir nun nicht funktioniert, ist für mich die naheliegenste Schlussfolgerung, dass die Wiederholrate deines Fernsehers nicht mit der des Videomaterials übereinstimmt. Das könnte auch passieren, wenn du den Deinterlacer auf "half rate " stellst und somit die 50Hz des Fernsehers auch nicht mehr passen.


    Natürlich können auch andere Effekte die Ruckler verursachen (CPU Last?) oder im Plugin steckt hier noch ein Fehler. Allerdings hat sich bisher noch niemand beschwert, und mir ist diesbezüglich auch noch nichts aufgefallen.


    Gruss
    Thomas

  • Hallo Thomas,


    danke für deine Hilfe.


    Ich hab mir dein Beispiel aus XBMC mal angesehen und finde folgende Zeuile interessant

    Code
    bool advanced_deinterlace = interlace_method ==  VS_INTERLACEMETHOD_MMAL_ADVANCED || interlace_method == VS_INTERLACEMETHOD_MMAL_ADVANCED_HALF && port_image.format.video.nFrameWidth * port_image.format.video.nFrameHeight <= 576 * 720;


    Wenn ich das richtig interpretiere nehmen die "OMX_ImageFilterDeInterlaceAdvanced" nur bei SD-Videos...


    Außerdem habe ich folgendes Beispiel gefunden:

    Code
    image_filter.nPortIndex = m_omx_image_fx.GetOutputPort();
        image_filter.nNumParams = 2;
        image_filter.nParams[0] = 3;
        image_filter.nParams[1] = 1000000/25;
        image_filter.eImageFilter = OMX_ImageFilterDeInterlaceAdvanced;
    
    
        omx_err = m_omx_image_fx.SetConfig(OMX_IndexConfigCommonImageFilte


    Da wir die Framerate dem Deinterlacer expliziet mitgeteilt. Eventuell hilft es hier die angepasste Framerate mitzuteilen?
    LINK


    Ansonsten finde ich es auch komisch das niemand diese Ruckler hat... Ausschliessen kan ich CPU-Last. Die liegt bei 30%.


    VG Uli

  • Hi Uli

    Wenn ich das richtig interpretiere nehmen die "OMX_ImageFilterDeInterlaceAdvanced" nur bei SD-Videos...

    Ja, habe ich inzwischen auch eingecheckt. Zudem kann man bei XBMC die Deinterlacer-Modi zwischen Advanced/Bob und Normal/Half rate wählen - vielleich bau ich das auch noch ein, aber das hat momentan keine Priorität.


    Da wir die Framerate dem Deinterlacer expliziet mitgeteilt. Eventuell hilft es hier die angepasste Framerate mitzuteilen?

    Das habe ich heute Morgen auch gefunden, aber hier geht es um ein anderes Problem. Da kommt plötzlich der Deinterlacer aus dem Tritt und vertauscht die Halbbilder, was zu einem "etxtrem zittrigen" Eindruck führt. Klaus hat mir eine solche Beobachtung mitgeteilt, selber hatte ich das noch nie. Auch das werde ich in der Form noch übernehmen, mit dem Fast-Mode für HD sollte das Problem vorerst entschärft sein.


    Ansonsten finde ich es auch komisch das niemand diese Ruckler hat... Ausschliessen kan ich CPU-Last. Die liegt bei 30%.

    Versuch doch mal, den Fernseher exakt auf die Framerate des Videomaterials einzustellen. Also 50i für SD/privates HD bzw. 50p für öffentlich/rechtliches HD. Ich habe nochmals in den Sourcen des omxplayers nachgeschaut und dort ist der HDMI-Clock-Sync nur dann aktiv, wenn auch die Refresh-Rate des Displays dem Video angepasst wird. Mit den Erklärungen von popcornmix scheint mir das irgendwie auch logisch.


    Gruss
    Thomas

  • Würde ich gerne. Aber ich frage mich wo ich da was einstellen kann? Ich habe einen Sony W805b 55".


    Bild kann ich einiges einstellen aber nicht die Frequenz oder Auflösung.

    Im Plugin-Setup bei Wiederholfrequenz auf "wie Video" stellen. Im Debug-Log findest du beim Start zudem die Tabelle der unterstützten Modi. Aber die gängigen TV-Formate wird der Fernseher sicher unterstützen.


    Gruß
    Thomas

  • Hallo Thomas,


    also ich hab noch mal die Einstellungen probiert - Leider ohne Erfolg.


    Um diese Micro-Ruckler weg zu bekommen hilft nur den Live-Stream in 1x abzuspielen. Das habe ich jetzt mehrmals getestet.
    Leider hat anscheinen sonst niemand das Problem oder sieht vielleicht diese Ruckler mit anderen Augen...


    Für mich sind diese Störungen aber auch erklärlich.


    Die HDMI-Ausgabe hat immer ein fest definierte Framerate - bei mir 50p (hab aber auch schon andere gestetet)
    Das Video hat z.B. 50 Bilder/sek würde also zu den fest definierten 50 Bilder/sek passen. aber durch die Geschwindigkeitsanpassungf wird das Video auf z.B. 49.25/sek geändert und passt nun nicht mehr zum Ausgang... Bei einfachen Bewegungen fällt das nicht auf, aber bei Kamaraschwenks bekommt man dann Ruckler zu sehen.


    Ich habe jetzt mal die Datei display.c angesehen. Was bedeutet eigentlich die pixel_freq in Zeile 218 / 219?



    Kann hier eventuell eine Anpassung der Ausgangsframerate vorgenommen werden?


    VG Uli

  • Hi Uli

    Die HDMI-Ausgabe hat immer ein fest definierte Framerate - bei mir 50p (hab aber auch schon andere gestetet)
    Das Video hat z.B. 50 Bilder/sek würde also zu den fest definierten 50 Bilder/sek passen. aber durch die Geschwindigkeitsanpassungf wird das Video auf z.B. 49.25/sek geändert und passt nun nicht mehr zum Ausgang...


    Nein - siehe mein Posting vom Dienstagmorgen. Der HDMI-Takt, genauer die Pixelfrequenz, ist ein frei laufender Oszillator. Über einen Regelkreis lässt sich dessen Takt an den Video-Scheduler koppeln, welcher die einzelnen Videobilder, gesteuert vom OMX-Clock, im richtigen Moment an den Video-Render zur Ausgabe schickt. (Hier noch einmal die detaillierte Erklärung )


    Damit lässt sich der Pixeltakt, und somit die Framerate, in einem gewissen Bereich "dehnen" - wie viel das genau ist, kann ich nicht sagen. Stellt nun das Plugin im Live-Betrieb den Takt ein weniger höher oder tiefer, sollte sich der Pixeltakt entsprechend anpassen, vorausgesetzt dieser passt zur Framerate des Videostreams. Der Fernseher wiederum synchronisiert seine Wiedergabe auf die Quelle und läuft dann halt ein klein wenig schneller oder langsamer, entsprechend der Korrektur im Plugin.


    Soweit die Theorie. Wenn du nun Mikroruckler beobachtest, scheint diese Regelung nicht zu funktionieren. Entweder weil die eingestellte Framerate nicht zum Videomaterial passt, oder wegen eines Problems das es nun zu finden und zu lösen gilt… Ich schau mir das an, sobald es mein Zeitplan zulässt.


    Ich habe jetzt mal die Datei display.c angesehen. Was bedeutet eigentlich die pixel_freq in Zeile 218 / 219?

    Siehe oben - die Ausgabe dient lediglich der Information.


    Gruss
    Thomas

  • Hi Uli


    Ich habe mir das Problem kurz angeschaut und kann deine Beobachtungen bestätigen. Ich habe nun auch erfahren, dass beim Raspberry Pi die HDMI-Clockänderung auf 175ppm begrenzt ist, was aber für DVB-Dauerbetrieb reichen sollte.


    Kannst du bitte mal folgende neuen Faktoren testen:


    Damit läuft bei mir der Live-Ticker auf N24 flüssig durch. Ich werde das demnächst noch sauber implementieren und einen Langzeittest starten.


    Gruss
    Thomas

  • Hallo Thomas,


    prima das du es bei dir nun auch reproduzieren konntest.


    Ich glaube allerdings, dass deine Änderung zwar die Ruckler entfernt, aber dadurch Buffer-Underruns enstehen können.


    Zumindest haben meine Tests gezeigt, dass bei so geringer Anpassung der Geschwindigkeit langfristig kein stabiler Betrieb möglich ist.


    Ich habe meine aktuelle Diff mal im anderen Thread gepostet.


    Vielleicht magst ja mal drüber schauen.


    VG Uli

Jetzt mitmachen!

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