Posts by Thinner

    Hi Lord-Grey,


    thanks. I needed a way to switch between inputs of my UTV007-grabber in the past. I've coded some bash scripts triggered by LIRC. While working on it i realized that i have to read whole config (getconfig), modify the input setting and then write whole config back (setconfig). It was not possible to write back changed settings only, because all other config items where resetted to defaults. But that's not a problem if you know about it.


    wbr

    Hi Lord-Grey,


    i've tried setting some hardcoded values to numerator/denominator, but it looks like one can only set FPS that are supported by the V4L2 device drivers for the given resolution and pixelformat.


    See output of v4l2-ctl -d /dev/videoX --list-formats-ext


    For my webcam i can't go lower than 15 FPS because that's the minimum FPS supported.


    wbr


    PS:

    For my internal laptop webcam:

    v4l2-ctl -d /dev/video0 --set-parm 2

    -> Frame rate set to 15.000 fps

    = no chance to set lower values than supported



    For Raspberry Pi Camera v2.1:

    v4l2-ctl -d /dev/video1 --set-parm 2

    -> Frame rate set to 2.000 fps

    = works if supported


    I am really sorry!

    Yes, I meant the setconfig subcommand.

    Hi,


    thank you for the clarification (mistakes happen :) ).


    And also thank you for the extensive revision of the JSON API. I'll play around with it a bit.


    Do you know off the top of your head whether you can now use setconfig to change individual settings or whether a complete configuration is still expected?


    wbr

    Hi,


    I came across some code that I think needs review.


    Please have a look at https://github.com/hyperion-pr…eo/EncoderThread.cpp#L125


    Setting of FlipMode looks messed up. Why is there an exception for BGR24? As far as i know FlipMode is processed in ImageResampler.cpp.


    Please have a look. Thanks.


    wbr

    Hi,


    how about that:



    Drops CPU usage from 40% to 3% if no signal detected.


    wbr

    Hi,


    the method shown in my posts is not suitable for real use because network streaming always involves a delay due to buffering.


    However, it is definitely suitable for repeated and comprehensible tests of image processing.


    wbr

    Update for using latest version:


    -> unload module if loaded, if it doesn't work reboot

    sudo modprobe -r v4l2loopback


    -> uninstall package manager version

    sudo apt remove v4l2loopback-dkms v4l2loopback-utils


    -> install latest version

    sudo apt install raspberrypi-kernel-headers

    git clone https://github.com/umlaeute/v4l2loopback v4l2loopback

    cd v4l2loopback

    (make clean on rebuild)

    make

    sudo make install

    sudo depmod -a

    cd utils

    sudo make install

    v4l2loopback-ctl --version


    -> run

    sudo modprobe v4l2loopback devices=1 video_nr=9 card_label="Virtual-Device9"

    sudo v4l2loopback-ctl set-caps /dev/video9 "YU12:720x576@25/1"

    ffmpeg -i "rtsp://192.168.32.101:554/?avm=1&freq=450&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=660" -f v4l2 /dev/video9



    Hi,


    thanks for this inspiring question.


    You can use v4l2loopback and ffmpeg for that.


    sudo apt install v4l2loopback-dkms v4l2loopback-utils ffmpeg


    -> create a virtual V4L2 device /dev/video9

    sudo modprobe v4l2loopback devices=1 video_nr=9 card_label="Virtual-Device9"


    -> set capture format for the device

    sudo v4l2loopback-ctl set-caps "video/x-raw,format=I420,width=720,height=576,framerate=25/1" /dev/video9

    WARNING: This command did freeze on my system, execute this in desktop environment terminal you can close or screen-session over SSH


    -> use ffmpeg to get your webcam stream and write it to the device

    ffmpeg -i "rtsp://192.168.32.101:554/?avm=1&freq=450&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=660" -f v4l2 /dev/video9



    I had to make sure no reencoding is needed, my RPi Zero 2W isn't fast enough, so i had to set resolution and pixel-format of the device to the ones of input stream. But if you like you can do reencoding:


    ffmpeg -i "rtsp://192.168.32.101:554/?avm=1&freq=450&bw=8&msys=dvbc&mtype=256qam&sr=6900&specinv=0&pids=660" -s 720x576 -r 25 -pix_fmt yuv420p -f v4l2 /dev/video9


    ffmpeg -pix_fmts lists all supported formats. You need to choose a format supported by hyperion.ng and v4l2loopback-ctl. It's a little bit tricky as the names do not match always as you can see below (I420=yuv420p=YU12). For v4l2loopback-ctl they are case sensitive (maybe https://gstreamer.freedesktop.…deotestsrc/?gi-language=c will help).


    Good luck.


    wbr

    Thinner


    PS: This is for version 0.12.5 installed on Raspbian Bullseye, in newer versions v4l2loopback-ctl set-caps has changed, i also tried current version from https://github.com/umlaeute/v4l2loopback but didn't succeed yet.


    @sophie @esprit1711 @all
    Wenn ihr wollte, könnt ihr unter dieser Adresse eine modifizierte Version downloaden und die Auflösung bzw. die Bildrate des V4L2 Grabbers über das WebUI einstellen (wenn der PR build fertig ist).
    Bin leider noch nicht so weit das es PR fertig wäre. Als nächstes soll eine DropDown Variante im WebUI genutzt werden um das Gerät, die Auflösung und die Bildrate auszuwählen.
    Anhand des Videos was ich unten verlinkt habe, kann man gut erkennen das dadurch Ressourcen gespart werden.


    Hi, es wäre wirklich super wenn das Setzen der Auflösung es irgendwann in den master branch schafft. Könntest du bei der Gelegenheit gleich noch ein Eingabe-/Auswahlfeld für das Pixelformat einbauen? Der restliche Code ist ja schon da und wird bereits von hyperion-v4l2 verwendet. Dann wäre die Sache rund.


    Danke
    Thinner

    Hi,


    ich vermute mal auf deinem RPi3 läuft Buster? Hast du da in den letzten Tagen mal ein Update gemacht? Dabei wurden zumindest bei mir Firefox von 60.9.0esr-1~deb10u1+rpi1 auf 68.4.1esr-1~deb10u1+rpi1 und Chromium von 74.0.3729.157-rpt5 auf 78.0.3904.108-rpt1 geupdatet, was einige Probleme bei mir behoben hat.


    Mit den beiden älteren Versionen hatte ich massive Probleme bei der LED-Simulation in hyperion-ng, weil der garbage collector (GC) vom Browser den Speicher nicht freigegeben hat, was zur Folge hatte dass der Pi versucht hat Speicher auszulagern und am Ende stehen geblieben ist. Nachdem ich die ledsim.js überarbeitet hatte, lief es dann stabil. Nach dem Update der Browser vorgestern habe ich den originalen Code nochmal probiert, damit lief es dann auch in den beiden aktuellen Browsern stabil, was bedeutet dass der GC bei beiden überarbeitet wurde.


    Vielleicht erklärt das ja dass es jetzt bei dir läuft.


    Grüße