Rasperry Pi xine plugin

Zitat von ardi

Da kann ich dir im Moment nicht helfen. Da habe ich noch nichts getestet. Vielleicht kann man mit der -A Option was drehen.

Ich habs gefunden, da fehlte eine Bibliothek für ac3

Dafür bleibt vdr-fbfe leider beim Umschalten von einem HD- auf einen SD-Kanal hängen:

[1503] [vdr-fe]    Keypress: LIRC KEY_1
prebuffer=14400 pts
[1502] [input_vdr] wait_stream_sync: discard_index 18498448 != curpos 18460848 ! (diff 37600)
[1502] [input_vdr] queue_blank_yv12: invalid dimensions 0x0 in stream_info !
prebuffer=14400 pts
[1502] [demux_vdr] PMT changed, resetting demuxer
[1502] [demux_vdr] audio stream changed: 00000000 -> 03000000
No accelerated IMDCT transform found
[1500] [input_vdr] fifo_buffer_new...
[1500] [input_vdr] fifo_buffer_new done.
[1503] [lirc]      LIRC: 0000000000001789 00 KEY_9 devinput




[1503] [vdr-fe]    Keypress: LIRC KEY_9
[1503] [lirc]      LIRC: 0000000000001789 01 KEY_9 devinput




prebuffer=14400 pts
prebuffer=14400 pts
[1502] [input_vdr] wait_stream_sync: discard_index 25439784 != curpos 25437904 ! (diff 1880)
[1502] [input_vdr] queue_blank_yv12: invalid dimensions 0x0 in stream_info !
[1502] [demux_vdr] PMT changed, resetting demuxer
[1502] [demux_vdr] audio stream changed: 00000000 -> 03000001
No accelerated IMDCT transform found
[1502] [input_vdr] TCP: fifo buffer full
[1500] [input_vdr] Control stream disconnected
[1500] [input_vdr] Control thread terminated
[1502] [input_vdr] read_block: no data source, returning NULL
[1502] [input_vdr] flush_all_fifos()
[1502] [demux_vdr] DEMUX_FINISHED (input returns NULL with error)

Ach ja: wenn ein Sender das Seitenverhältnis wechselt (z.B. 4:3 -> 16:9), macht vdr-fbfe das nicht mit - auf meinem 5:4 Monitor an dem ich den Raspberry Pi momentan hängen habe wird das 16:9 Material dann auf 4:3 gestreckt.

Hi,

welche Bibliothek bzw. welches Paket hatte bei Dir gefehlt?

Claus

PS.: Für die MLD gibt's nun nen VDR image mit xineliboutput und dem xine-rpi plugin im Download bereich. Testen konnte ich das aber noch nicht, da ich meinen RPI derzeit anderweitig verbaut habe.

Zitat von clausmuus

welche Bibliothek bzw. welches Paket hatte bei Dir gefehlt?

Ich glaube es war die liba52:
https://www.archlinux.org/packages/extra/i686/a52dec/

Hoffentlich wird die Ausgabe über vdr-fbfe noch stabiler, die Entwicklungsversion von XBMC Gotham ist mit xvdr aktuell deutlich zuverlässiger...

Zitat von seahawk1986

Hoffentlich wird die Ausgabe über vdr-fbfe noch stabiler, die Entwicklungsversion von XBMC Gotham ist mit xvdr aktuell deutlich zuverlässiger...

Meine Güte, die Entwicklung ist doch gerade erst losgegangen. Seit doch froh, dass ihr schon was zum rumspielen habt.

Zitat von glotzipapa

Seit doch froh, dass ihr schon was zum rumspielen habt.

Bin ich ja

Habe mir eine sd-karte mit MLD (MLD-3.0.1-rpi_client-2013.05.07_56.tgz) fertig gemacht.
Also streaming client von meinem Server.

Setup über Weboberfläche. Streaming Server IP hat er automatisch gefunden.
Per default ist shutdown Server ausgewählt, das bitte noch ändern.

Ton habe ich bei jedem Sender. Bild allerdings nur bei sd Sendern.
Bild ist eher als Diashow zu verstehen.

Super Ansatz!

Bislang habe ich nur mit XMBC, also xvdr Verbindung gespielt.
Vdr direkt auf dem Pi und Bild per Streaming finde ich besser...

Munter bleiben, Rossi

Zitat von vdr_rossi

Vdr direkt auf dem Pi und Bild per Streaming finde ich besser...

Eine 2. VDR-Instanz auf dem großen VDR und nur vdr-fbfe auf dem RPI finde ich praktischer (wenn man keine lokale DVB-Karte am Client braucht) - über Socket-Activation sollte sich das ja einfach bei Bedarf starten lassen.

Zitat von ardi

vdr-fbfe --aspect

Bei mir wird das Bild jetzt immer unskaliert in der linken obere Ecke dargestellt (egal ob und was ich für aspect angebe), das OSD aber auf den kompletten Bildschirm skaliert. (Die OSD-Skalierung ist auch noch etwas merkwürdig, aktuell scheint da die Skalierung immer um den Faktor 2 erhöht zu werden (bei 1280x720 passt es nicht auf den 1280x1024 Bildschirm).

Zitat von ardi

OSD hat richtige Farbe

Die Farben stimmen jetzt, solange man für das OSD als Farbtiefe LUT8 auswählt. Mit Auto/TrueColor werdem die Farben bei LCARS und ST:TNG noch nicht richtig dargestellt.

Zitat von ardi

OSD - Fehler (z.B. mit ST:TNG) sollten behoben sein (konnte ich nicht testen, da ich den Fehler nicht hatte seahawk1986 bitte mal testen)

Ja, die Fehler bei der Navigation im OSD sind weg

Zitat von seahawk1986

Bei mir wird das Bild jetzt immer unskaliert in der linken obere Ecke dargestellt (egal ob und was ich für aspect angebe), das OSD aber auf den kompletten Bildschirm skaliert. (Die OSD-Skalierung ist auch noch etwas merkwürdig, aktuell scheint da die Skalierung immer um den Faktor 2 erhöht zu werden (bei 1280x720 passt es nicht auf den 1280x1024 Bildschirm).

Hatte ich auch, ich starte deswegen mit den Optionen (--geometry=1920x1080 --aspect=16:9) ... so:

vdr-fbfe -A alsa -V rpi --geometry=1920x1080 --aspect=16:9 xvdr://192.168.179.32

- Bei HD 1080i (Servus-TV HD) gibt es einen Speicherzugriffsfehler.
- Umschalten von SD nach HD klappt nicht, gibt kein Bild, sporadisch kommt der Fehler "Gleitkomma-Ausnahme" und vdr-fbfe beendet sich oder es gibt keinen Fehler auf der Konsole. Ab und an (ich nutze HDMI) schaltet sich der Ausgang ab und der TV meldet --> kein Signal, wenn ich vdr-fbfe beende habe ich wieder ein Bild am HDMI...
- Das scalieren des OSD ist noch nicht optimal und sieht qualitativ schlecht aus. Ist das der Xine-Struktur geschuldet oder kannst du da noch optimieren?
- irgendwie wird das OSD nicht optimal scaliert. Es gibt Unterschiede zwischen 720p - und 567i - Sendern, bei 720p wird das OSD zu groß dargestellt und ich sehe den unteren Teil des OSD nicht mehr...
- autocrop funktioniert hier nicht.
Ich nutze 256MB/256MB.

Vielen Dank für die tollen Fortschritte!

Gruß Uwe

Zitat von Uwe

Hatte ich auch, ich starte deswegen mit den Optionen (--geometry=1920x1080 --aspect=16:9)

Mit "-f" klappt es hier auch mit bildschirmfüllendem Bild (dann muss ich das OSD aber auf 720x576 stellen, da es sonst zu groß dargestellt wird).

Hi vdr_rossi,

das klingt für mich danach, das der xine-rpi Treiber nicht genommen wurde. Das muss ich also mal selber testen, und die Logs anschauen.

Claus

Hi vdr_rossi,

ich hab noch mal nen update gemacht. Es könnte sein, dass es nun doch funktioniert. Teste einfach das neuste Image oder update das lib-xine-rpi Addon.

Claus

Danke clausmuus für das fertige Image.
Werde nacher Zuhause testen.

Nur zum Verständnis, wo kann ich das genau runterladen ? Hatte oben extra den Dateinamen in Klammern geschrieben, bin mir nicht sicher ob das richtig war...

Munter bleiben, Rossi

Zitat von ardi

Mit TrueColor bekomme ich gar kein OSD (auch auf meinem yaVDR 0.4.0 nicht). Ich hab gesehen, dass phintuka diesbezüglich im Jan.2013 was an xineliboutput gedreht hat. Mein xineliboutput-Zeugs (RPI und yaVDR) ist alles vom Dez.2012.
Hast du xineliboutput für RPI selbst gebaut?

Ja, das läuft momentan alles unter Arch Linux (großer Rechner mit extra VDR-Instanz mit xineliboutput - ist die gleiche Version 1.0.7+cvs20130117-1yavdr2~precise wie in vdr-testing bei yaVDR) und der Raspberry Pi läuft mit ArchLinuxARM und dem gleichen Versionsstand.

Zitat von ardi

Das OSD sollte jetzt richtig skaliert sein.

Sehr schön, jetzt werden die Schriften auch richtig schön gezeichnet

Zitat von ardi

Was genau bedeutet "nicht richtig dargestellt"? Farben vertauscht?

Ja genau:
[Blockierte Grafik: https://dl.dropboxusercontent.com/u/960809/Raspberry/TrueColor/DSC00336.JPG]
[Blockierte Grafik: https://dl.dropboxusercontent.com/u/960809/Raspberry/TrueColor/DSC00337.JPG]
[Blockierte Grafik: https://dl.dropboxusercontent.com/u/960809/Raspberry/TrueColor/DSC00338.JPG]
[Blockierte Grafik: https://dl.dropboxusercontent.com/u/960809/Raspberry/TrueColor/DSC00339.JPG]

ardi: In meinem letzten Post zwischen den Zeilen ist es möglicherweise untergegangen, deshalb nochmal als eigenes Posting:
Wann kann man mit einem Sourcecode-Archiv rechnen?