[VDR*ELEC] LibreELEC/AMLGX (arm) Probleme/Diskussion

  • Nachdem 576i Aufnahmen mit Kodi richtig abgespielt werden, muss das Problem am Ausgabedevice liegen.

    Ich geh mal auf die Suche...

  • Bin aktuell ratlos. Grundsätzlich sollte MPEG2 mit 576i funktionieren, da auch die Aufnahmen in Kodi einwandfrei abgespielt werden.

    Es macht auch keinen Unterschied, ob bwdif oder kein Deinterlacer aktiv ist. Ich habe das Gefühl, dass bwdif aber grundsätzlich funktioniert.

    Somit bleibt eigentlich nur der Decoder/ffmpeg oder irgendein Problem mit DRM. ffmpeg sollte wegen Kodi grundsätzlich funktionieren.

    Gravierende Unterschiede zum Handling konnte ich bisher nicht finden.

    Bliebe also noch DRM...

    Bild ist erkennbar, hat am rechten Rand einen kleinen Streifen, der richtig dargestellt wird, der Rest ist "gepixelt" und es zeichnen sich wiederholende senkrechte Streifen ab. Für mich sieht das aus, als passt was mit den Formaten (NV12/YUV420P) oder mit einem linestride nicht. Der richtige rechte Rand macht mich da stutzig... Ich versuche später auch mal, einen Screenshot einzustellen.


    zillerbaer

    Könnte das was mit den folgenden Commits zu tun haben? Rein aus deinem Gefühl? Dann würde ich da mal versuchen, was zu reverten...



    Bin für jeden Rat dankbar. Wenn wir diese Sender noch zum Laufen bringen, würde ich LE/AMLGX auf Amlogic als ganz gut benutzbar einstufen.

    Ich werde auch nochmal auf der Wetek2Play testen, evtl. sind die Sachen auch deviceabhängig ...

  • Könnte das was mit den folgenden Commits zu tun haben? Rein aus deinem Gefühl?

    Das fühle ich nicht. :)


    Da geht was mit den Formaten durcheinander. Bwdiff ist ein SW Deinterlacer von FFmpeg. Der kann nur mit YUV420 umgehen. Daraus folgt: Wenn der SW Deinterlacer zum Einsatz kommen soll muss in SW Decodiert werden da der HW Decoder das falsche Format liefert. Ich würde CodecMode auf 2 setzen.

  • Bin hier auf:

    Code
    CoreELEC (community): 20.3-Nexus_devel_20231231102746 (Amlogic-ng.arm)
    Machine model: Hardkernel ODROID-N2Plus
    CoreELEC dt-id: g12b_s922x_odroid_n2plus
    Amlogic dt-id: g12b_w400_b

    unterwegs.


    Möchte von einem dvb-t2 Fernsehbild ein Screenshot machen - per vdr-plugin-screenshot. Aktuell kommt nur ein grünes Bild dabei raus. Auf dvb-c Sendern funktioniert alles.

    ffmpeg ist installiert:

    Wie ließe sich h265 library hier mit einkompilieren?

  • Bin hier auf:

    Code
    CoreELEC (community): 20.3-Nexus_devel_20231231102746 (Amlogic-ng.arm)
    Machine model: Hardkernel ODROID-N2Plus
    CoreELEC dt-id: g12b_s922x_odroid_n2plus
    Amlogic dt-id: g12b_w400_b

    unterwegs.

    Dann ist das der falsche Thread, denn hier gehts um die LibreELEC Amlogic Variante.


    Ansonsten müsste wohl beim Bauen von ffmpeg die richtige Option gesetzt werden. Was braucht grab dazu?

  • Oh, sorry für den Lärm an falscher Stelle.


    Abgesehen davon war ich eh auf dem falschen Weg. Es hat was mit dem Ausgabeplugin zu tun. Das Bild wird aus dem Framepuffer bezogen und da ist es bereits dekodiert (Quelle im extra Thema dazu).

  • So sieht das bei mir z.B. aus. Ohne hw decoder und ohne deinterlacer.

    Bei welcher Komponente sollte ich auf die Suche gegen, bzw. wie könnte ich am besten was ausschließen?

    DRM oder ffmpeg/codec? Am Deinterlacer liegt das m.E. nicht, damit bleibt das Bild so - nur die Frames zittern nicht mehr.

    Wie gesagt, kodi spielt die Aufnahmfn korrekt ab und nutzt das gleiche ffmpeg. Wenn ich richtig liege, wird das video da aber über ein eigenes OpenGL Texture dargestellt und nicht direkt in den Framebuffer geschoben. Daher vermute ich das Problem hier...

    Vielleicht hat ja jemand eine Idee, wona h die Streifen aussehen...

  • Zwischenstand:


    Habe jetzt hier einen RPi4, RPi5 und Odroid N2 und werkle an verschiedenen Fronten...

    Die RPi schauen allgemein besser aus als der Odroid.

    -> Beim 4er funktionieren die h264 Sender einwandfrei, bei mpeg2 "flackert" das Bild (in der oberen Hälfte) "klötzchenartig" bei Bewegungen.

    -> Beim 5er flackert es bei allen Sendern.

    Das betrifft also alles, was mit Software dekodiert wird. Irgendwo auf dem Pfad (SW-)Decoder->(SW-)Deinterlacer->DRM-Ausgabe gibts hier noch ein Problem.


    Beim Odroid ist das wie beim RPi4, aber zusätzlich gibts hier bei mpeg die Fehler aus dem Bild oben.


    Bis auf die Klötzchen ist das Bild bei den Rpis gut, so dass ich das Problem hier eher auf DRM schiebe und der Decoder und Deinterlacer m.E. funktioniert. Entweder liegt es an den Formaten oder aber DRM hat mit dem VSync noch ein Problem. Ich werde als nächstes versuchen, den drm-Commit nonblocking einzubauen, vielleicht kommt die Software nicht hinterher, wenn der fb zu lange geblockt ist.


    Außerdem wäre es interessant, ob es auf dem RPi4 mit der Version von zillerbaer funktioniert, dann sehe ich zumindest, ob ich das Problem eingebaut habe. Bis jetzt bekomme ich aber mit dieser Version noch kein Videobild - habe aber noch nicht nach dem Grund gesucht.


    Bwdiff ist ein SW Deinterlacer von FFmpeg. Der kann nur mit YUV420 umgehen.

    Ungetestet, aber evtl. schafft dieser Commit hier Abhilfe. Daran liegt das Problem oben aber m.E. nicht. Der Deinterlacer bekommt aktuell 1 AV_PIX_FMT_YUV420P-frame und liefert 2 AV_PIX_FMT_NV12-filt_frame.


    Wer gerne mitsuchen und -testen will, darf sich gerne melden ;)

  • VEED - Oops, something went wrong
    The video can not be played at the moment.
    www.veed.io


    Ich hatte ja mal ein Video versprochen... Etwas schlechte Qualität, aber was ich mit Klötzchen meine, sieht man.

    Hat jemand eine Idee, was das sein kann? Ich tappe im Dunkeln.


    PS: Das ist ein 576i Sender auf Rpi4, also alles in Software.

    Edited once, last by rell ().

  • Quote

    This video isn’t ready

    Ask the video creator to sign up and share this with you again to preview.

    VDR1: ACT-620, Asus P8B75-M LX, Intel Core i3-3240, 4 GB DDR3 RAM 1600 MHz, passive Geforce GT1030 von MSI, Sandisk 2TB SSD, 2xWinTV DualHD, Atric-IR-Einschalter. SW: Xubuntu 20.04 auf 64GB Sandisk SSD.

    VDR2: Odroid N2+ mit CoreELEC und Ubuntu in chroot, WinTV DualHD

    VDR3: Tanix TX3 mit CoreELEC und Ubuntu in chroot, WinTV DualHD

  • This video isn’t ready

    Ask the video creator to sign up and share this with you again to preview.

    Hm, bei mir gehts. Was ist denn eine Stelle, wo man ein Video hochladen kann?

  • So, bei der Version von zillerbaer treten dieselben Probleme auf. Weiter gehts...

  • Ich glaube, die Ursache ist gefunden und die 576i Kanäle laufen jetzt auf dem RPi4 grundsätzlich. Ich habe die ständigen av_frame_alloc und av_frame_free mal so geändert, dass gleich beim Start die frames im Rb mit av_frame_alloc angelegt werden und stattdessen mit av_frame_unref gearbeitet wird. Scheint, dass damit weniger auf dem Speicher los ist und die Klötzchen sind weg.

    Jetzt muss ich noch etwas nachdenken, damit das ganze alloc/unref/free sauber wird und mit den Threads klarkommt.

  • Der decoder und deinterlacer auf amlogic funktionieren. Ich habe das frame mal abgegriffen und in Datei geschrieben, siehe Anhang.

    Wenn ich mir die Datei mit rawpixels.net anzeigen lasse, sieht das eigentlich gut aus.


    D.h., dass noch irgendwas auf dem weiteren DRM Pfad nicht passt...

  • Ich mach mal meinen Monolog weiter ;)

    Die Commits, die das Problem auf dem RPi fixen sollten, habe ich reverted. Grundsätzlich weiß ich, woran es liegt, aber ich habe da zu schnell commited und krasse Bugs eingeführt. Ich muss da erstmal nochmal nachdenken und das etwas überarbeiten.


    Auf dem Odroid kommt das Bild aus dem Deinterlacer richtig als NV12 an. Allerdings scheint der drm ein Problem damit zu haben, das ganze hoch zu skalieren. Ich habe etwas mit den Buffer-Größen etc. gespielt und konnte ein "intaktes" Bild auf dem Bildschirm erhalten, wenn auch nicht in richtiger Größe und Lage und gekachelt, aber immerhin mit Y und UV richtig überdeckt. Farben stimmen. Mir ist dann wieder eingefallen, dass ja auch das 720x576er Schwarzbild kein Schwarzbild mehr auf einer 1920x1080er Ausgabe war (https://github.com/rellla/vdr-…4d038eb0064d687f060873631). Ich habe dann kurzerhand die Größe des Buffers auf die Bildschirmgröße eingestellt, was das Problem gelöst hat. Ähnlich vermute ich das Problem beim Video.

    Ich muss also noch etwas herumspielen, aber zumindest ist das Problem jetzt eingegrenzt. Fortsetzung folgt. Wahrscheinlich.

  • Ein nächstes Problem mit Amlogic ist gelöst. 576i läuft jetzt.


    Bleibt noch das "Problem", dass beim Replay-Start auf einem hw-dekodiertem Sender die Helligkeit erst nach ein paar Frames passt und ein paar Klötzchen auftreten. Ist evtl. vertretbar, aber auf Dauer wohl auch nervig. Ich vermute das Problem im Decoder und das schaue ich mir als nächstes an.

    Aber wer testen will, kann das z.B. mit dem Odroid schon mal machen.

  • Zabrimus hat de Patch von RE: [softhddevice] Verständnisfrage pts schon eingebaut, die sync Probleme sind damit bei mir (fast) ganz weg.

    Was noch bleibt ist das Problem mit den Artefakten und der Helligkeit bei den ersten Frames nach dem Umschalten. Das betrifft aber nur den HW Decoder. Evtl. muss man hier ein I-Frame abwarten oder so was in der Art. Bin für einen Tip wieder dankbar ;)

    Wer damit vorerst leben kann, kanns ja mal ausprobieren...

  • Evtl. muss man hier ein I-Frame abwarten

    Es sollte immer mit einem I-Frame gestartet werden! Das beinhaltet ein komplettes Bild. Die anderen Frames haben immer Abhängigkeiten zu anderen Frames weil nur die Veränderungen zu anderen Frames codiert sind.


    Edit: Soweit ich das verstehe nutzt Du meine Vorlage und da wird auf das erste I-Frame gewartet.

Participate now!

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