Raspberry Pi 4B Unterstützung

  • Siehst Du die Ursache dafür beim v4l2 Treiber oder bei ffmpeg?

    Die RPi Entwickler zeigen mit den Finger auf Kodi :)

    Entweder Kodi spricht ffmpeg irgendwie komisch an oder ffmpeg reagiert komisch auf Kodis Anfrage. Kann man sich nun aussuchen wer Schuld ist ;) Das Problem wurde noch nicht gefunden, Amlogic z.B. ist seit einem Jahr fertig zum benutzen aber durch den Bug nicht brauchbar.


    Wir sitzen im Moment auch nur da und hoffen das die RPi Fundation das Problem löst und damit auch für z.B. AML das ganze nutzbar macht :)

    Was ja einer der Riesen Vorteile ist wenn alle das Linux api nehmen und keine Hersteller spezifischen Ansätze.

  • zillerbaer

    habe mir einen Raspi 4 mit 8GB RAM bestellt und gestern bekommen.


    Habe nun Raspian buster installiert, den plain vdr nebst satip Plugin und https://github.com/zillevdr/vdr-plugin-softhddevice-drm ohne weitere Make Optionen übersetzt. Alle nötigen libs habe ich erstmal von (libav*, ...) direkt aus der buster Distribution genommen.


    VDR läuft damit und Bild wird angezeigt. Ton kommt noch über Klinke (das wird vermutlich noch eine Raspi Einstellung sein).

    Bei SD ist Bild prima und CPU Last bei 30%


    Bei HD ruckelt das Bild bleibt ab und zu hängen CPU Last dabei ~120%. Das Bild ist dabei 'gezoomed' soll heißen ich sehe einen kleinen Ausschnitt auf die Bildschirmgröße vergrößert.

    Ob ich im Plugin Setup SWDeinterlacer an oder aus mache ändert nichts.


    Was wären nun die nächsten Schritte?


    Danke und Grüße


    Jörg

  • Bei SD ist Bild prima und CPU Last bei 30%

    So soll das sein!

    Bei HD ruckelt das Bild bleibt ab und zu hängen CPU Last dabei ~120%. Das Bild ist dabei 'gezoomed' soll heißen ich sehe einen kleinen Ausschnitt auf die Bildschirmgröße vergrößert.

    Ob ich im Plugin Setup SWDeinterlacer an oder aus mache ändert nichts.

    Ist momentan in SW decodiert da sind Ruckler normal. Warum das gezoomed ist weiss ich momentan nicht. Ist das bei SD auch so?

    Was wären nun die nächsten Schritte?

    Erst wird das aktuellste Kernel gebraucht. Danach die Patches von LE auf FFmpeg. Die Ausgabe brauch ich noch.

    Code
    1. cat /sys/firmware/devicetree/base/compatible
  • nein bei SD passt das Bild


    Code
    1. root@rpi4:~# cat /sys/firmware/devicetree/base/compatible
    2. raspberrypi,4-model-bbrcm,bcm2711

    The post was edited 1 time, last by horchi ().

  • Ich hab auf meinem Pi4 mal auf die Schnelle vdr + softhddevice-drm installiert und einem kurzen Test unterzogen. DVB-T stockt, HD von MagentaTV scheint zu laufen. Morgen seh ich mir das genauer an, interessant ist das für mich nur mit Hevc-Unterstützung.


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Im Log finde ich:


    Code
    1. CodecVideoOpen: No HW codec found!

    Ich nutze die von Raspbian mitgelieferte Version von ffmpeg version 4.1.6-1~deb10u1+rpt1


    Ein Alternative wäre evtl. von https://www.deb-multimedia.org/


    Edit:


    Code
    1. CodecVideoOpen: Codec H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 found
    2. CodecVideoOpen: decoder use 4 threads
    3. CodecVideoOpen: decoder use THREAD_SLICE threads


    vdr-User-# 755 to_h264 chk_r vdr-transcode

    The post was edited 1 time, last by jsffm ().

  • Code
    1. video: hevc detected
    2. CodecVideoOpen: Codec HEVC (High Efficiency Video Coding) found
    3. CodecVideoOpen: decoder use 4 threads
    4. CodecVideoOpen: decoder use THREAD_SLICE threads

    Es wird nur ein Core benutzt, der teilweise auf 100% geht.


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Da bekomme ich nen Abbruch mit [softhddev] audio buffer too small


    Ich dachte der Pi4 unterstützt MMAL nicht mehr.


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • https://www.raspberrypi.org/forums/viewtopic.php?t=268356


    HEVC decode on the Pi4 is through a separate block that is driven by the Linux kernel. I'm just finishing off PR for that - https://github.com/raspberrypi/linux/pull/3505.


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Die Meldung


    Code
    1. Nov 30 00:41:20 raspberrypi4 vdr: AlsaSetup: no channel map found for 6 channels, HwChannels 2 > set CodecDownmix
    2. Nov 30 00:41:20 raspberrypi4 vdr: [softhddev] audio buffer too small

    bekomme ich auch ohne MMAL


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Code
    1. Nov 30 00:41:20 raspberrypi4 vdr: AlsaSetup: no channel map found for 6 channels, HwChannels 2 > set CodecDownmix

    Das ist nur eine Information. Das Audiosignal hat 6 channels und die Soundkarte nur 2. Das Signal wird runter gemixt auf 2 channel.

    Code
    1. Nov 30 00:41:20 raspberrypi4 vdr: [softhddev] audio buffer too small

    Das muß ich mir ansehen. Was spielst Du da ab? Ist das was exotisches? Kannst Du mir das Video zur Verfügung stellen?

  • Das war der Film Carol auf Das Erste von DVB-T, Ton in aac 5.1. Ich habe den nicht aufgezeichnet.


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Zu mmal, h264 wird mit Gpu-Unterstützung abgespielt, hevc garnicht :(


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Die Buffergröße ist seit Johns geblieben. Auch die anderen softhddevice Nachfolger benutzen diese Größe. Ich will die jetzt nicht auf Verdacht vergrößern. Vielleicht hatte das Videomaterial einen Fehler. Wenn jemand den obigen Fehler mit einem Video nachvollziehen kann bitte ich um ein Schnipsel davon.

    Zu mmal, h264 wird mit Gpu-Unterstützung abgespielt, hevc garnicht

    Dann heißt es noch ein bissel Geduld haben.

  • Mit folgender Änderung lief es:


    Diff
    1. --- softhddev.c.s 2020-11-29 14:50:33.308264627 +0100
    2. +++ softhddev.c 2020-11-30 00:53:22.888730502 +0100
    3. @@ -102,7 +102,7 @@
    4. /// Minimum free space in audio buffer 8 packets for 8 channels
    5. #define AUDIO_MIN_BUFFER_FREE (3072 * 8 * 8)
    6. -#define AUDIO_BUFFER_SIZE (512 * 1024) ///< audio PES buffer default size
    7. +#define AUDIO_BUFFER_SIZE (2048 * 1024) ///< audio PES buffer default size
    8. static AVPacket AudioAvPkt[1]; ///< audio a/v packet


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • Ja, um die AUDIO_BUFFER_SIZE geht es. Die hat seit Jahren gereicht. Da softhddevice-drm auch auf HW läuft die nicht so üppig mit Speicher ausgestattet ist will ich gern nachvollziehen was sich geändert hat und nicht pauschal den Wert vergrössern.

  • Was mir noch aufgefallen ist, mit mmal ist das Bild ok, ohne scheint mir nur die linke obere Ecke angezeigt zu werden. Leider mag der grab bei mir nicht.


    vdr-User-# 755 to_h264 chk_r vdr-transcode

  • SD sieht ohne mmal ok aus, betrifft wohl nur HD (720p)


    Edit:


    Bei HD ist das Bild gespreizt.


    vdr-User-# 755 to_h264 chk_r vdr-transcode