[yavdr-ansible] noble vdr 2.6.9 RasPi 4

    • New
    Quote from rell

    Es ist also etwas kompliziert....

    Ja, vor allem, wenn man außer RasPi 4 nichts davon jemals gesehen hat und nichts testen kann.

    Und jetzt das nächste Problem: Ich konnte deinen Patch in meinem git nicht anwenden. Vermutlich irgendwo was geändert, das den "git am" verhindert.

    Also musste ich es Zeile für Zeile von Hand übernehmen, wieder eine mögliche Fehlerquelle.


    Warum hast du das:

    Code
    case AV_CODEC_ID_MPEG2VIDEO:
-                if (codecInfo->hwaccelMPEG2) codecInfo->codec = avcodec_find_decoder_by_name("mpeg2_v4l2m2m");

    rausgenommen ? Dann wird doch der Orchid, der MPEG2 in Hardware (und ohne hwdecice) kann, den normalen MPEG2 Decoder und nicht den V4l2m2m Decoder verwenden. Ist das so gewollt ?

    Aktueller Stand ist in V04, mit VAAPI/RasPi 4 und MPEG2/H.264 habe ich erfolgreich getestet.

    Edited once, last by kfb77 ().

    • New
    Quote from kfb77

    Und jetzt das nächste Problem: Ich konnte deinen Patch in meinem git anwenden. Vermutlich irgendwo was geändert, das den git am verhindert.

    Die Patches bauen auf dem Stand deines V04 von heute nachmittag auf. Die force-pushes sind da prinzipiell sehr ungünstig, da man jedes Mal den ganzen branch wieder holen muss und sich die sha der commits ändern. Daran könnts liegen.


    Quote from kfb77

    Warum hast du das:

    Code
    case AV_CODEC_ID_MPEG2VIDEO:
-                if (codecInfo->hwaccelMPEG2) codecInfo->codec = avcodec_find_decoder_by_name("mpeg2_v4l2m2m");

    rausgenommen ? Dann wird doch der Orchid, der MPEG2 in Hardware (und ohne hwdecice) kann, den normalen MPEG2 Decoder und nicht den V4l2m2m Decoder verwenden. Ist das so gewollt ?

    Ich habe nur versucht, den softhddevice code in deinen einzubauen. Ich weiß nicht, ob mpeg2 hw decoding überhaupt was bringt und habe keinen Überblick, was die einzelnen SoCs können und/oder welches ffmpeg eh auf ein sw fallback zurückgeht. Der RPI4 hat z.B. keinen mpeg2 hw decoder, der RPI5 auch keinem h264 mehr. Bei amlogic ist er im ffmpeg deaktiviert.

    Ich muss mal ein paar Testzeilen Code mit Logs schreiben, um zu sehen, welches SoC wann welchen decoder für welchen codec wählt. Rein zum Überblick...


    Gegenfrage: Warum hast du rein? ;)

    • New
    Quote from kfb77

    Ich bin inzwischen mit den Tests, insbesondere im Vergleich mit MLD, ein wenig weiter gekommen:

    Wenn ich die HD Sender aus der channel.conf lösche, kann ich SD Sender und SD Aufnahmen abspielen (Software Decoded). Sobald ich eine HD Aufnahme (GPU Decoded) abspiele, hängt der VDR.

    Am softhddevice-drm-gles kann es eigentlich nicht liegen, bei MLD funktioniert das. Also kann es nur an den FFmpeg Libs liegen. MLD scheint hier eine spezielle RasPi Version aus Debian zu nutzen.

    Es ist keine spezielle Debian Version, bei der MLD, da wir ja alles selber bauen,

    wir nutzen für ffmpeg aktuelle diese version

    git://github.com/jc-kynesim/rpi-ffmpeg.git;protocol=https;branch=dev/6.0/rpi_import_1


    Gruß,

    Roland


    P.S.: nur der der DEV Server ist auf Debian basis, das ist bei Yocto/Bitbake aber egal

    https://www.minidvblinux.de/

    1x OctopusNet mit 8x DVB-C
    1x Raspberry 4 MLD 6.0 SATIP (softhddevice-drm )

    1x RockPi 4 MLD 6.0 SATIP (softhddevice-drm )

    1x Raspberry 3 mit SATIP MLD 5.4

    1x Raspberry 2 mit STAIPMLD 6.0

    1x Raspberry 1 (staubt gerade so vor sich hin) ;)
    1x ODROID N2+ mit SATIP MLD6

    1x ODROID N2 L mit SATIP MLD6

    1x Zotac CI327 MLD 6.0 SATIP (softhddevice)

    • New
    Quote from rell

    ob mpeg2 hw decoding überhaupt was bringt

    Also zumindest mit VAAPI/CUDA/... ist es langsamer als Software decodiert weil die Zeit für den Transfer GPU ->CPU und das Konvertieren des Pixel Formats hinzukommt.


    Code
    threads 1, hwaccel none    : decode  0.5ms, transfer  0.0ms, read  0.8ms -> sum:  1.3ms, test time    395ms
threads 1, hwaccel vaapi   : decode  0.2ms, transfer  1.6ms, read  0.8ms -> sum:  2.6ms, test time    785ms
threads 2, hwaccel none    : decode  0.4ms, transfer  0.0ms, read  0.8ms -> sum:  1.2ms, test time    361ms
threads 2, hwaccel vaapi   : decode  0.2ms, transfer  1.6ms, read  0.8ms -> sum:  2.6ms, test time    775ms
threads 4, hwaccel none    : decode  0.4ms, transfer  0.0ms, read  0.8ms -> sum:  1.2ms, test time    360ms
threads 4, hwaccel vaapi   : decode  0.2ms, transfer  1.5ms, read  0.8ms -> sum:  2.6ms, test time    773ms

    Ich hatte aber die Hoffnung, das es bei DRM was bringt, wenn Transfer und Pixel Konvertierung weg fällt.

    Quote from rell

    Gegenfrage: Warum hast du rein?

    Tippfehler ? Was meinst du ?

    Edited 2 times, last by kfb77 ().

    • New
    Quote from rfehr

    wir nutzen für ffmpeg aktuelle diese version

    Ja, das ist inzwischen bekannt. Aber das ist doch genau die gemeinte spezielle FFmpeg Version, die inzwischen yavdr für ARM auch nutzt. Halt eben nicht von Debian, aber auch nicht das normale FFmpeg.

    • New

    mpeg2 in Software sollte auf aktueller Hardware kein Problem mehr sein, darum wird von vielen hw decoding gar nicht mehr genutzt. Ob das jetzt generell keine Vorteile bringt oder intern sogar ein fallback nutzt, weiß ich nicht.


    Ja Tippfehler, ich meinte: Warum hast du mpeg2_v4l2m2m implementiert?

    • New
    Quote from rell

    Warum hast du mpeg2_v4l2m2m implementiert?

    Geraten auf Basis dieser Ausgabe:

    Code
     ffmpeg  -decoders | grep mpeg2
 V.S.BD mpeg2video           MPEG-2 video
 V.S.BD mpegvideo            MPEG-1 video (codec mpeg2video)
 V..... mpeg2_v4l2m2m        V4L2 mem2mem MPEG2 decoder wrapper (codec mpeg2video)
 V....D mpeg2_qsv            MPEG2VIDEO video (Intel Quick Sync Video acceleration) (codec mpeg2video)
 V..... mpeg2_cuvid          Nvidia CUVID MPEG2VIDEO decoder (codec mpeg2video)
    • New

    Wo genau verschwindet denn die Zeit, die bei transfer angezeigt wird?

  • Post by rfehr ().

    This post was deleted by the author themselves ().
    • New
    Quote from kfb77

    Ja, das ist inzwischen bekannt. Aber das ist doch genau die gemeinte spezielle FFmpeg Version, die inzwischen yavdr für ARM auch nutzt. Halt eben nicht von Debian, aber auch nicht das normale FFmpeg.

    Das ist das spezielle ffmpeg für den rpi4, mit dieser softhddevice Version.


    Wir nutzen das aber nicht von Debian, sondern bauen es aus den Sourcen selbst.


    git://github.com/rellla/vdr-plugin-softhddevice-drm-gles.git;protocol=https;branch=drm-atomic-gles


    Gruß,

    Roland


    P.S.: es wird bei der MLD 6.xx alles selbest gebaut, aus den Sourcen, keine fertigen Pakete mehr.

    https://www.minidvblinux.de/

    1x OctopusNet mit 8x DVB-C
    1x Raspberry 4 MLD 6.0 SATIP (softhddevice-drm )

    1x RockPi 4 MLD 6.0 SATIP (softhddevice-drm )

    1x Raspberry 3 mit SATIP MLD 5.4

    1x Raspberry 2 mit STAIPMLD 6.0

    1x Raspberry 1 (staubt gerade so vor sich hin) ;)
    1x ODROID N2+ mit SATIP MLD6

    1x ODROID N2 L mit SATIP MLD6

    1x Zotac CI327 MLD 6.0 SATIP (softhddevice)

    Edited once, last by rfehr ().

    • New

    Das ist die Zeit, die der Call braucht.

    Aus FFmpeg Sicht:

    av_hwframe_transfer_data() um die Daten von der GPU zur CPU zu holen.

    sws_scale() um das Pixel Format von NV12 auf YUV420P zu konvertieren, damit ich die Bildanalyse nur in einem Pixel Format machen muss.


    Ich habe das auch mal einzeln gemessen, der überwiegende Teil kommt von av_hwframe_transfer_data().

    Es lohnt es sich mit VAAPI erst ab H.264, weil erst dann die Einsparung vom Decoding größer ist als der Aufwand für den Transfer.

    • New
    Quote from rfehr

    mit dieser softhddevice Version

    Danke, auch bekannt. Da schreibe ich ja gerade (mit Unterstützung vom Autor rell) ab, um das Hardware Decoding für markad auf ARM zum Laufen zu bekommen.

    • New
    Quote from kfb77

    Danke, auch bekannt. Da schreibe ich ja gerade (mit Unterstützung vom Autor rell) ab, um das Hardware Decoding für markad auf ARM zum Laufen zu bekommen.

    Hilft vieleicht wie, wir das ffmpeg bauen ?

    https://www.minidvblinux.de/

    1x OctopusNet mit 8x DVB-C
    1x Raspberry 4 MLD 6.0 SATIP (softhddevice-drm )

    1x RockPi 4 MLD 6.0 SATIP (softhddevice-drm )

    1x Raspberry 3 mit SATIP MLD 5.4

    1x Raspberry 2 mit STAIPMLD 6.0

    1x Raspberry 1 (staubt gerade so vor sich hin) ;)
    1x ODROID N2+ mit SATIP MLD6

    1x ODROID N2 L mit SATIP MLD6

    1x Zotac CI327 MLD 6.0 SATIP (softhddevice)

    • New

    Vielen Dank für das Angebot, aber das ist schon bekannt. Und das Packet ist auch schon in yavdr drin und funktioniert.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login