[Alpha] RPI Ausgabeplugin

Hallo zusammen

Ich habe der Übersicht wegen wieder mal ein Tag erstellt:

2014-11-02: Version 0.0.10
--------------------------
- new:
  - added DTS audio codec support
  - add setup options to control video mode and its behaviour on stream changes
  - set HDMI speaker layout to fix channel mapping for multi channel PCM output
  - support building against external ffmpeg/libav by setting EXT_LIBAV
  - support for >=ffmpeg-1.2 and >=libav-0.8 with resampling
  - setup option for video framing mode in case of incompatible aspect ratio
  - redirect ffmpeg messages to plugin/VDR logs
  - added cppcheck as Makefile target (suggested by Rolf Ahrenberg)
  - reworked setup parameter handling
  - implemented proper command queue for OVG-OSD
- fixed:
  - increased latency target for live mode to 500ms
  - reworked OVG image processing for low level OSD
  - upmix mono audio channels to stereo when using PCM output on HDMI
  - skip non-video packets in StillPicture(), fixes artifacts in PES recordings
  - skip audio substream header for PES recordings with AC3 audio track
  - reworked audio decoding loop and set correct dstSize before resampling
  - avoid flushing OMX video chain twice when calling SetPlayMode(pmNone)
  - skip packets with invalid payload offset in PlayVideo() and PlayAudio()
  - play multiple video PES packets sequentially in StillPicture()
  - updated parameter when setting clock latency target according omxplayer
  - code clean up based on cppcheck's results (thanks to Rolf Ahrenberg)
- known issues:
  - direct switching from fast forward to fast rewind will freeze replay

Download auf vdr-developer.org

Das einzige mir noch bekannte Problem, das ich selber auch nachvollziehen kann, ist der Punkt mit dem Spulen. Da muss ich noch ein wenig Zeit investieren, bevor es die 0.1.0-Beta-Version gibt.

Gruss
Thomas

Zitat von ollo

Ich hätte da aber gleich was zu meckern - ich nutze den "crop" Mode für die Bildanpassung an mein 1440x900 Display. Ohne bleibt sonst oben und unten ein kleiner Rand des Terminals übrig. Seit dem letzten Update wird der eingestelte Mode (crop) initial nicht mehr respektiert, das Bild erscheint im normalen Mode (mit Rand oben und unten). Sobald im Menu den Mode ändere, wobei ich erst einen anderen einstellen muß um dann letzendlich wieder crop zu verwenden, klappt das auch wieder - bis zum nächsten Start des VDR. Da wird wohl was nicht richtig initialisiert?

Meinst du crop in der config.txt?

Kann gut sein, dass diese Einstellung verloren geht, wenn der Mode umgeschaltet wird. Das Umschalten kannst du aber unterbinden, indem du im Plugin-Setup die Optionen "Auflösung" und "Bildwiederholrate" auf "nicht ändern" stellst.

Gruss
Thomas

Hi ollo

Zitat von ollo

Daran ändert sich auch nix, jedenfalls nicht bewusst. Ich beziehe mich auf den Start vom VDR mit dem Plugin bei dieser setup.conf Einstellung und trotzdem wird das Bild eben nicht ge-crop-t?!?

Ah, jetzt ist der Groschen gefallen. Ja, da habe ich tatsächlich bei einem Commit ein File vergessen - ist jetzt gefixt und eingecheckt . Habe mir erlaubt, die 0.0.10 neu zu taggen und das Archiv zum Download zu ersetzen. Vielen Dank für den Hinweis!

Gruss
Thomas

Hallo Patrick

Zitat von vectra130

Aber da entsteht direkt die nächste Frage. Irgendwo hast du was von "cBitmap" und "cPixmap" erwähnt und das es daran liegt das nur einige Skins funktionieren. Hab das nicht so ganz verstanden. Heißt das jetzt das die Skins jeweils angepasst werden müssen oder ist das eine weitere Baustelle bei Dir?

Es gibt verschiedene Arten auf das OSD zu zeichnen:

- Über die Zeichenfunktionen von cOsd, z.B. cOsd::DrawPixel()
Die mitgelieferten Skins nutzen diese Methoden, ebenso der von mir genutzte Skin EnigmaNG. Deshalb habe ich mich bei der Implementation in rpihddevice auf diese Funktionen konzentriert.

- Über eine eigene Pixmap, mit cOsd::CreatePixmap() angefordert und danach z.B. mit cPixmap::DrawPixel()
Pixmaps sind Ebenen auf die der Skin zeichnen kann, und werden vom VDR (bzw. der GPU Implementation) bei einem Flush() der Reihe nach gerendert und übereinander auf das OSD gezeichnet. Komplexere Skins und Skindesigner nutzen diese Möglichkeit, die mir zum Zeitpunkt der Implementation der GPU-Beschleunigung beim rpihddevice nicht bewusst war. Das werde ich nachholen, sobald ich dazu komme - OpenVG unterstützt mehrere Ebenen, so dass sich das aktuelle Design im Plugin relativ leicht anpassen lässt. Bis dahin funktionieren diese Skins wie gewohnt, wenn man die GPU-Unterstützung im Plugin-Setup deaktiviert.

- Direkt über die Pixel in der Hardware, via cOsd::GetBitmap()
Diese Funktion liefert einen Pointer auf die Pixel zurück und lässt den Benutzer diese direkt manipulieren. Diese Funktion ist aber deprecated und sollte nicht mehr verwendet werden, wie in der HISTORY zum vdr 1.7.17 beschrieben. Ausserdem beisst sich das mit einer GPU Implementation, da hier der vdr u.U. gar keinen Zugriff mehr auf die Pixel hat. Denn beim rpihddevice werden die grafischen Elemente als Vektoren über OpenVG auf eine Ebene gezeichnet und dann von der GPU entsprechend auf den Bildschirm gerendert, inklusive Antialiasing und allem was dazu gehört.
Leider benutzt z.B. das Teletext-Plugin diese Funktion, weshalb das mit dem rpihddevice nie funktionieren wird.

Zitat von vectra130

Wäre es deiner Meinung nach auch irgendwann mal Möglich den Skindesigner zu nutzen?

Ja, das steht bei mir als nächstes auf dem Programm.

Gruss
Thomas

Hallo zusammen

Ich habe über die Feiertage den Audio-Teil des Plugins umgeschrieben und auch die Implementation des OMX-Devices angepasst. Ich habe die Änderungen gerade comitted, bei mir läuft der Stand seit einer Woche "produktiv" auf einem A+ im Wohnzimmer (streamdev mit WLAN) sowie auf meiner Entwicklungshimbeere (B-Modell mit satip) soweit fehlerfrei. Mit dem satip-Plugin unterbricht der Stream nach ein paar Stunden, ist aber nach einem Tastendruck z.B. auf OK sofort wieder da - momentan habe ich keine Ahnung, was da schief läuft. Mit streamdev läuft der VDR seit etwa 72h ohne Unterbruch durch.

Beim Audio-Teil habe ich u.a. den Buffer vergrössert und hoffe nun, das die Leute mit Audioproblemen diese nicht mehr haben - allerdings konnte ich diese nie selber nachvollziehen und kann die Auswirkungen schlecht abzuschätzen. Aufgrund des grösseren Audio-Buffers warte ich nun mit dem Setup des Audio-Renders bis alle Samples gespielt wurden, was eine kurze Verzögerung beim Umschalten der Audiospur (ca. 1 Sekunde) nach sich zieht. Alternativ müsste ich den Render flushen, was wiederum den Videostream springen lässt - gerade beim Wechsel z.B von 5.1 auf 2.0 (Werbung während Spielfilmen) fände ich das störend.

Obwohl ich die Änderungen nach bestem Wissen und Gewissen bei mir getestet habe, will ich nicht ausschliessen, dass sich neue Fehler eingeschlichen haben. Ich bin deshalb froh um Rückmeldungen aller Art und danke schon jetzt fürs Testen!

Gruss
Thomas

Zitat von hondansx

Code

audio.c:1100:2: error: 'SwrContext' does not name a type
audio.c: In constructor 'cRpiAudioRender::cRpiAudioRender(cOmx*)':
audio.c:869:3: error: class 'cRpiAudioRender' does not have any field named 'm_resample'
audio.c: In destructor 'cRpiAudioRender::~cRpiAudioRender()':
audio.c:887:13: error: 'm_resample' was not declared in this scope
audio.c:887:23: error: 'swr_free' was not declared in this scope
audio.c: In member function 'int cRpiAudioRender::WriteSamples(uint8_t**, int, uint64_t, AVSampleFormat)':
audio.c:930:8: error: 'm_resample' was not declared in this scope
audio.c:942:53: error: 'swr_convert' was not declared in this scope
audio.c: In member function 'void cRpiAudioRender::ApplyResamplerSettings()':
audio.c:1077:13: error: 'm_resample' was not declared in this scope
audio.c:1077:23: error: 'swr_free' was not declared in this scope
audio.c:1078:26: error: 'swr_alloc' was not declared in this scope
audio.c:1091:23: error: 'swr_init' was not declared in this scope
audio.c: In member function 'virtual void cRpiAudioDecoder::Action()':
audio.c:1339:17: error: 'AVFrame' has no member named 'channels'
audio.c:1340:17: error: 'AVFrame' has no member named 'sample_rate'
Makefile:119: recipe for target 'audio.o' failed
make: *** [audio.o] Error 1

Alles anzeigen

Hast du libav oder ffmpeg installiert? Wenn ja, welche Version?

Gruss
Thomas

Zitat von hondansx

libav 0.8.13 (Raspbian wheezy)

Ok. Libswresample ist nicht länger optional und scheint bei libav-0.8 zu fehlen. Diese müsstest du updaten oder zu ffmpeg wechseln.

Gruß
Thomas