2 Sekunden Bild Delay am grabber?

  • Guten Morgen,

    Ich nutzte ein Hyperion setup für hdmi quellen.Es besteht aus einem stk1160 grabber, splitter, hdmi2av wandler.

    Aktuell bekomme ich zwar ein relativ flüssiges Bild, allerdings mit einem delay von 2 Sekunden(zum tv bild); was natürlich nicht so viel spass macht...
    Ist das bei euch auch so?

    Danke

    Jbos

    Einmal editiert, zuletzt von jbos (30. Dezember 2013 um 08:12)

  • Hallo

    meine config:

    Mein Startup



    achja, das bild wird in 720x576 dargestellt. im fbdev.

    jbos

    Einmal editiert, zuletzt von jbos (30. Dezember 2013 um 14:57)

  • Treiber infos:

  • Hallo, nach langem testen und probieren.... mit folgendem aufruf habe ich kein delay mehr im mplayer...

    Code
    sudo  mplayer -tv buffersize=100:channel=0:device=/dev/video0:input=2:driver=v4l2:width=72:height=57:outfmt=uyvy:norm=PAL -vm -vf scale tv://

    ich hoffe jemanden anderem mit dem gleichem problem hilfts.

    Jbos

  • ok, perfekt ist es noch nicht, ... die ursache war die begrenzung auf 15fps... bzw jegliches post processing.

    nun habe ich jedoch das problem kaputer halbbilder, bzw ein flackern im bild. das bekomme ich zwar mit einem deinterlance weg - nur eben mit 2 sekunden lag....

    ich teste weiter...

  • Hallo,
    mein aktuelles setup ist schon fast gut.... ich habe jetzt mplayer2 installiert und fahre mit -fps 24.95 mit etwa 500ms delay, ohne flickern am grabbed stream...

    mal sehen ob man diese 500ms auch weg bekommt ohne erneut kapute halbbilder zu erhalten...

    guten rutsch

  • jbos: Wie hast du das Problem letztlich in den Griff bekommen? Hab bei mir auch gut zwei Sekunden Verzögerung.

    Experimentieren mit den Parametern des mplayers hat bei mir leider nix gebracht. mplayer2 verursacht Bildfehler, die man auch an den LEDs sieht :s

  • hallo,

    aktuell verfolge ich die option mit directfb als video output das problem zu lösen. die performance ist eindeutig besser, auch hier existieren bildfehler - jedoch in deutlich geringerem maße... soweit so gut... einziges problem... directfb swapped rot/blau....

    sind wir wirklich die einzigen mit diesem Problem?

  • Hi,

    bei mir existiert das Problem auch. Da ich allerdings noch in der Aufbauphase bin ist das (noch) nicht dringend für mich. in meiner Werkstatt sieht das mit den LEDs schon ganz gut aus, farbwerte gehören noch angepasst ... und der lag eben auch, sonst darf das Ganze so nicht ins Wohnzimmer ;O)

    Der delay / lag liegt bei geschätzten 1 - 1,5 Sekunden.

    Viele Grüße

    Patrick

  • Hallo Zusammen,

    ich möchte dem Thwma etwas mehr substanz geben und meine Erkentnisse zusammenfassen.

    Zunächst mein Setup. Ich nutze den stk1160 grabber, da dieser vom v4l2 treiber unterstützt wird. v4l2 ist zudem im aktuellem kernel enthalten... dem entsprechend ist die installation plugnplay.

    Als image nutze ich das aktuellste offzielle raspbian (dez.2013).

    Das Problem: Die tutorials zum ambilight beschreiben stehts im mplayer aufruf etwas wie "width=72:height=54" die idee dahinter ist den stream bereits im grabber herunter zu skalieren und damit den usbbus und unser pi zu entlasten.

    Leider funktioniert das nicht, das bild kommtstehts in pal auflösung ins pi. Die Ursache liegt im Treiber, der aktuelle v4l2 supported diese parameter nicht, der Vorgänger "easycap treiber" schon.

    D.h. es gibt erstmal keine Möglichkeit die daten zu begrenzen.

    Ohne Postprozessing ist das Bild jedoch mit 25 fps im mplayer flüssig -und im sync. Leider reicht aber offensichtlich die Bandbreite des usb nicht aus konstant stabile 25 fps zu liefern. Weshalb ein flickernbzw kaputte halbbilder sehen.

    Diese lassen sich durch reduktion der fps auf mplayer seite, durch skallierung, bzw durch interlancing entfernen; mit dem tradeoff dass das bild etwa 2Sekunden verzögert wird.

    aktuell beste lösung ist m3iner meinung nach der einsatz von mplayer2

    sudo mplayer -tv buffersize=1024:channel=0:device=/dev/video0:input=2:driver=v4l2:outfmt=rgb16:norm=PAL -vo directfb tv://

    folgende /root/.directfbrc


    pi@raspberrypi ~ $ sudo cat /root/.directfbrc
    mode=768x576
    hardware
    pixelformat=RGB16
    disable-module=linux_input

    nun ist directfb nicht perfekt und tauscht rot und blau... um das zu lösen, i der hyperion config als colorspace statt rgb einfach bgr angeben, und die leds sind wi3der korrekt.

    delay ist sichtbar aber unter 500ms.

    minimale bildfehler gibt es auch, aber deutlichst reduziert.


    grüße

    Einmal editiert, zuletzt von jbos (13. Januar 2014 um 12:50)

  • Hallo,

    da die minimalen Bildfehler trotzdem, (vorallem bei langsamen bildern) sehr genervt haben,... habe ich weiter und weiter probiert... letztlich habe ich einen Weg; wie oben beschrieben, + die abtastrate der bilder in hyperion auf 6Hz reduziert.

    Jetzt klapts!

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!