H265 kann der A20 nicht und der HW Deinterlacer ist nicht implementiert. Die MPEG und H264 Sender sollten trotzdem laufen. Das Cubieboard2 schaffte das bei mir damals locker. Mit libvdpau aber noch.
Posts by rell
-
-
Wieviel Speicher hast du für CMA reserviert?
Gruß Andreas
-
-
Habe jetzt mal ca. 8h am Stück mit Deinterlacer laufen lassen: https://pastebin.com/raw/s8FMZaQi
Bis auf ALSA, das sich immer mal wieder beschwert, sehe ich nichts Verdächtiges...
Gruß
Andreas
-
Hast du das mit aktiviertem HW-Deinterlacer getestet? Wie lange ist in etwa "nach einer Weile"?
Ich konnte den Crash ohne Deinterlacer bisher nicht reproduzieren. VDR läuft mit stremdev-client allerdings erst ca. 3h - ohne Umschalten.
Mit Deinterlacer hat er gestern wieder gecrasht. Ich versuch, das wieder hinzukriegen und poste dann die Logs. iirc war das aber eine andere Fehlermeldung als beim ersten Mal.
Wenn etwas zu schnell "weggearbeitet" wird, müsste man eigentlich doch nur warten ohne dass gleich VDR beendet wird? Oder stelle ich mir das zu einfach vor?
Wenn ich für dich was testen soll, sag bitte Bescheid.
Gruß
Andreas
-
Der Stream kommt von einem streamdev-server. CPU Takt kann ich nicht sagen... Ich habe eine standard Kernel-Config und ich hab es noch nicht geschafft, dass ich /sys/devices/system/cpu/cpu0/cpufreq
auslesen kann, da ich das nicht habe... Aber ich würde mal bezweifeln, dass er so langsam taktet, dass die Pakete nicht verarbeitet werden...
-
Das sieht komisch aus:
Audiodaten sind nicht da und Videodaten auch nicht. Es gab aber kein PlayMode 0! Wo kommt das "dequeueing failed" her? Ich kann das in meinem Code nicht finden.
Das kommt von FFMPEG
Warum keine Daten da sind, weiß ich (noch) nicht. Unabhängig davon sollte es aber doch nicht gleich den ganzen VDR zerschießen...
Möglicherweise liegt das Problem aber auch direkt bei ffmpeg.
Gruß
Andreas
-
Zwei Buffer werden eigentlich nur benötigt wenn bewegte Bilder in schneller Folge dargestellt werden sollen. Aktuell nutzt softhddevice-drm nur einen Buffer dazu.
Mit GL habe ich noch nicht gearbeitet. Welche Methoden da zur Verfügung stehen in einen Framebuffer zu schreiben weiß ich nicht. Den Buffer lege ich da an und beschreibe den mit dem was vdr schickt und zeige das an. Vdr sagt dann wenn das OSD wieder geschlossen werden soll.
Ok danke, GLES an sich funktioniert und das mit drm bekomme ich hin, denke ich. Brauch dafür nur mal ein bißchen freie Zeit am Stück.
QuoteDie PKG Config Sachen gehören m. E. im System eingestellt und nicht im Makefile. Die Pfade unterscheiden sich auch bei unterschiedlichen Distributionen.
Ja kommt wieder raus. Aber deshalb ja WIP. Das ist aktuell einfacher für meine Build-Umgebung..
QuoteDas Verschieben bitte nicht. Die video.h wird von mmal und drm genutzt. Da soll auch nur das drin stehen was beide mit dem Rest verbindet.
Ich beziehe mich in openglosd.cpp auf VideoRender/ _Drm_Render ... Daher dachte ich, ich schiebe das kurzerhand in eine Header-Datei, wo es m.E. auch hingehört. Aber wie gesagt, WIP. Ich wills einfach zuerst zum Laufen bringen, dann mache ich mich nochmal über den Code.
QuoteDie Fehlermeldungen brauche ich. Ich habe kein funktionierendes H3 Board und kann das leider nicht testen.
https://pastebin.com/raw/e8Hw0hUp
Ich hab ein bißchen hin- und hergeschalten, und das kommt dann nach einer Zeit. In den Fall RTL SD, also 576i ?
Ich habe noch nicht geschaut, wie/ob ichs reproduzieren kann. Evtl. hilfts ja schon weiter.
Gruß
Andreas
-
... GLES funktioniert schonmal. Prinzipiell.
-
So, ich denke, ich brauche Hilfe von jemanden, der sich mit drm auskennt.
Hier https://github.com/rellla/soft…mits/opiplus-gles_surface liegt der aktuelle Code, der bisher folgendes machen sollte:
- gbm device vom drm filehandle erstellen
- OpenGL OSD Instanz erstellen
- GL/EGL Context erstellen
- gbm_surface und daraus EGLSurface erstellen
- EGLSurface als Textur an einen GLES framebuffer binden
- das OSD mit GLES zusammenbauen und am Ende auf den output framebuffer von oben rendern
Mir fehlt jetzt in jedem Fall noch, das gbm_surface über atomic drm commits auf das entsprechende plane zu bringen. Ich weiß auch nicht, wann/ob man double buffering benötigt.
zillerbaer Kannst du mir hier weiterhelfen, wo der richtige Ort ist, um das zu machen? in video_drm.c habe ich mal kommentierte Codezeilen eingefügt, wo es meiner Meinung nach hingehört, aber wahrscheinlich muss ich auch den buffer vorher richtig herrichten? In drm stecke ich einfach zu wenig drin...
Bin für jeden Tip dankbar!
Gruß
Andreas
PS: Testweise könnte ich ja mal das GLES-OSD in eine png-Datei rendern lassen, um zu sehen, ob die GLES Seite zumindest schonmal funktioniert....
PPS: Bin mir nicht mehr ganz sicher, ob der Deinterlacer astrein läuft. Ich habe hier immer mal wieder VideoFilter Fehlermeldungen und dann verabschiedet sich der VDR. Aber das sehe ich mit später an.
-
https://github.com/rellla/soft…englosd/tree/opiplus-gles
Habe hier mal angefangen, den Code für GLES einzubauen. Kompiliert aber erstmal nur. Werde softhddevice versuchen anzupassen, damit zumindest mal EGL/GLES initiert wird.
OSD per GL rendern sollte ich hinkriegen. Allerdings ist mir noch nicht klar, wie ich das Ergebnis am einfachsten und möglichst ohne memcpy auf das drm osd_plane bekomme. Vielleicht kann mir da jemand einen Tipp geben
Gruß
Andreas
-
Also hier läuft der Deinterlacer. Das Log zeigt mir das VideoFilterInit an und Bild wird flüssig und synchron dargestellt...
Gruß Andreas
-
Kann eigentlich nicht sein. Bei meinen Tests habe ich hier nur ein rotes Bild.
Mit LE auch. Das LE Image soll aber gut laufen. Ich denke das mein Board einen Treffer hat.
Was angezeigt wird, sehe ich heute abend. Bin nur per Remote drauf, aber der Logs zeigen nichts Verdächtiges. Den Post im LE Forum habe ich schon gesehen. Melde mich wieder, wenn ich bestätigen kann, dass es wirklich läuft.
HW Deinterlacing ist aktuell noch abgeschaltet. Ich will Dich bitten da das Kommentarzeichen zu entfernen und zu testen ob es funzt.
Habe ich schon gemacht, siehe oben. Das Log zeigt auch an, dass der v4l2m2m deinterlacer greift.
Gruß Andreas
-
Auch der HW Deinterlacer scheint zu laufen. Es gibt nur noch 0-3 FramesDuped Meldungen und bei interlaced Material werden hier auch deint frames angegeben.
Den HW Deinterlacer musste ich hier noch aktivieren. ffmpeg von hier , 5.8er Kernel mit cedrus-improvements patch.
Live hab ichs (noch) nicht gesehen, aber Fehler kommen auch keine
Ich denke, ich schaue mir jetzt mal das OpenGL/ES OSD an ...
Gruß
Andreas
-
Also, Kontrolle vor Ort: Läuft!!
SD und HD. Mit Ton und synchron, was ich aus dem Kurztest gesehen habe. Top Arbeit, zille!
Kernel und ffmpeg nutze ich noch aus meinem ersten Post. Werde morgen den HW Deinterlacer testen. Dann noch Fernbedienung dran und ab ins Wohnzimmer. Endlich wieder vernünftiges Fernsehen in Sicht... Danke für deine Hilfe soweit.
Gruß
Andreas
-
Jede Menge FrameDuped Meldungen:
https://pastebin.com/raw/kMCVKwfA
Kann dir aber nicht sagen, was das Display anzeigt...
Ich baue mir jetzt mal ein aktuelles ffmpeg mit Deinterlacer neu.
BTW: Sollte https://github.com/zillevdr/vd…blob/drm/video_drm.c#L813 und https://github.com/zillevdr/vd…blob/drm/video_drm.c#L830 nicht (bzw. zusätzlich) FramesDropped und FramesDuped anzeigen?
-
Audio ist der Taktgeber. Nach der Audioclock werden die Bilder synchronisiert. Ich benutze eine USB-Soundkarte. Wie realisierst Du Audio? Hörst Du einen Ton? Passiert das bei SD oder HD Material? Gibt es eine Fehlermeldung?Aktuell gibt es Audio so richtig gar nicht. Ich habe bisher nur einen HDMI Monitor dran. Ich hatte cma und out-of-memory Fehler und jetzt CMA auf 256MB gesetzt. Damit sind die jetzt weg.
Logs für Das Erste HD: https://pastebin.com/raw/7N0pabQY
stderr: https://pastebin.com/raw/Yxr5yFYqLogs für Das Erste SD: https://pastebin.com/raw/E1DN65ub
stderr: https://pastebin.com/raw/5KySf4Gx
Sieht eigentlich vernünftig aus, oder? Vielleicht lags an der CMA Größe.
Ich schau mir das mit dem Ton an, wenn ich wieder ans Gerät kann. Mit alsamixer kann ich jedenfalls auf "H3 Audio Codec" zugreifen, das sollte softhddevice dann auch ausgewählt haben!? Ich werde den Kernel für HDMI Audio patchen und sehen, wie es dann aussieht.
Danke und Gruß
-
Hallo zusammen,
ich möchte an dieser Stelle einen Thread für einen neuen softhddevice Fork öffnen.
Der Code liegt hier: https://github.com/zillevdr/vdr-plugin-softhddevice-drm
Danke an zillerbaer , der das ganze umgesetzt hat.
Diese Version gibt direkt über DRM/DRI aus und nutzt auch hardwarebasiertes Decoding über v4l2-request. Auch ein HW-Deinterlacer ist eingebaut.
Notwendig sind:
- FFmpeg mit v4l2-request Unterstützung (und evtl. Hardware Deinterlacer) z.B. von hier: https://github.com/jernejsk/FFmpeg/tree/deint-v2-prime
- aktueller Kernel mit cedrus improvements patch
Diese Version sollte auf allen Geräten laufen, die über DRM/DRI ausgeben. Die Decodierung übernimmt FFmpeg. Mit der ffmpeg-Version inkl. v4l2-request Unterstützung ist nun auch hardwarebasiertes Decodieren z.B. auf Allwinner SoCs möglich.
Um evtl. mehr Leute dafür begeistern zu können, macht ein Forumsthread auf Dauer mehr Sinn als die ursrpünglichen PMs.
---
Daher gleich wieder meine erste Frage an zille:
Du hast mich auf die ffmpeg Version von https://github.com/jernejsk/LibreELEC.tv/tree/deint und den Kernel Patch https://github.com/LibreELEC/L…cedrus-improvements.patch verwiesen. Kann es sein, dass es daran liegt? Ich würde dann versuchen, die fehlenden Patches mitaufzunehmen - wobei das Grundgerüst ja schon drin ist.
Danke und Gruß
Andreas
EDIT: Jetzt habe ich doch glatt übersehen, dass es doch schon mal einen Post zum Thema gab:
[Tinkerboard] softhddevice-drm
Da das Plugin aber weitereinwickelt wurde und nicht mehr nur fürs Tinkerboard läuft, würde ich vorschlagen, die Diskussion hier fortzusetzen, falls nichts dagegen spricht ...
-
Habe alle 3 hier verlinkten zu Hause. Sind alle drei gut, wobei ich auf alle Fälle mit Kernighan/ Ritchie anfangen würde. Hat sich für sehr leicht gelesen, obwohl englisch. Danach brauchst du wahrscheinlich auch kein anderes C-Buch mehr ...
-
A64, H3, H5, H6.
Die älteren können H265 hardwareseitig nicht.
Gruß
Andreas
