Raspberry Pi 4B Unterstützung

    Zitat von zillerbaer

    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

    Zitat von horchi

    Bei SD ist Bild prima und CPU Last bei 30%

    So soll das sein!

    Zitat von horchi

    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?

    Zitat von horchi

    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
     cat /sys/firmware/devicetree/base/compatible

    nein bei SD passt das Bild


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

    Einmal editiert, zuletzt von 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 github

    Im Log finde ich:


    Code
    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
    CodecVideoOpen: Codec H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 found
CodecVideoOpen: decoder use 4 threads
CodecVideoOpen: decoder use THREAD_SLICE threads


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    Einmal editiert, zuletzt von jsffm ()

    Code
    video: hevc detected
CodecVideoOpen: Codec HEVC (High Efficiency Video Coding) found
CodecVideoOpen: decoder use 4 threads
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 github

    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 github

    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 github

    Die Meldung


    Code
    Nov 30 00:41:20 raspberrypi4 vdr: AlsaSetup: no channel map found for 6 channels, HwChannels 2 > set CodecDownmix
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 github

    Code
    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
    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 github

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


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    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.

    Zitat von jsffm

    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
    --- softhddev.c.s       2020-11-29 14:50:33.308264627 +0100
+++ softhddev.c 2020-11-30 00:53:22.888730502 +0100
@@ -102,7 +102,7 @@

     /// Minimum free space in audio buffer 8 packets for 8 channels
 #define AUDIO_MIN_BUFFER_FREE (3072 * 8 * 8)
-#define AUDIO_BUFFER_SIZE (512 * 1024) ///< audio PES buffer default size
+#define AUDIO_BUFFER_SIZE (2048 * 1024)        ///< audio PES buffer default size
 static AVPacket AudioAvPkt[1];         ///< audio a/v packet


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

    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 github

    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 github

Jetzt mitmachen!

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

Benutzerkonto erstellen Anmelden