[Alpha] RPI Ausgabeplugin

Zitat von zorbas

What I don't understand is why omxplayer doesn't have this problem, or is it also using ffmpeg-compat?

There has been an api change between ffmpeg 1.0.x and ffmpeg > 1.1.x (an explanation was given here: [Prototyp] RPI Ausgabeplugin) - the plugin author himself uses ffmpeg 1.0.8. I had originally posted my problem including some sound samples here: [Prototyp] RPI Ausgabeplugin

Building with the original Makefile on Arch Linux ARM would build and link everything against ffmpeg 2.2 which causes the sound problems. Using my Patch the plugin is built and linked against ffmpeg 1.0.10:

$ ldd /usr/lib/vdr/plugins/libvdr-rpihddevice.so.2.1.6 | grep ffmpeg-compat
        libavcodec.so.53 => /usr/lib/ffmpeg-compat/libavcodec.so.53 (0xb63a1000)
        libavformat.so.53 => /usr/lib/ffmpeg-compat/libavformat.so.53 (0xb6291000)
        libavutil.so.51 => /usr/lib/ffmpeg-compat/libavutil.so.51 (0xb5fba000)

Zitat von zorbas

And I don't really know what ffmpeg-compat does

This package provides ffmpeg 1.0.10

Zitat von zorbas

After applying this patch I get a "Segmentation fault (core dumped)"

Did you set the environment-variable for pkg-config before calling make?

export PKG_CONFIG_PATH=/usr/lib/ffmpeg-compat/pkgconfig/
make

Zitat von seahawk1986

Did you set the environment-variable for pkg-config before calling make?

Code

export PKG_CONFIG_PATH=/usr/lib/ffmpeg-compat/pkgconfig/
make

I thought I did, but propably didn't

Thanks, now the sound works!

Zorbas

reufer http://ul.to/gevxlout
ein paar Minuten von Pro7 HD.
Man sieht die Probleme eigentlich bei mir direkt am Logo. Korrekt Deinterleaced ist das richtig schön weichgezeichnet. So wies aus dem rpihd-plug kommt hat es Treppchen bei 1080p50hz.
Hoffe das kann man nachvollziehen.
Das mit den Geisterbildern kann ich nur mit 60hz nachvollziehen. Mit 50hz läuft das alles Problemlos.
Was mir gerade noch aufgefallen ist ist, das ich auf den HD+-Sendern immer wieder Audio-dropouts habe. Allerdings tritt das selbe bei Sky HD nicht auf. im Log finde ich exakt die selben Angaben:

TNT Serie HD
May 16 18:10:30 vdrpi vdr: [3324] rpihddevice: set video codec to H264
May 16 18:10:30 vdrpi vdr: [3093] rpihddevice: set audio codec to 6ch AC3
May 16 18:10:30 vdrpi vdr: [3093] rpihddevice: set HDMI audio output format to 6ch AC3, 48.0kHz (pass-through)
May 16 18:10:31 vdrpi vdr: [3092] rpihddevice: decoding video 1920x1080i, enabling deinterlacer
May 16 18:10:33 vdrpi vdr: [3092] rpihddevice: buffer stall!

Pro7 HD+
May 16 18:11:35 vdrpi vdr: [3334] rpihddevice: set video codec to H264
May 16 18:11:35 vdrpi vdr: [3093] rpihddevice: set audio codec to 2ch AC3
May 16 18:11:35 vdrpi vdr: [3093] rpihddevice: set HDMI audio output format to 2ch AC3, 48.0kHz (pass-through)
May 16 18:11:36 vdrpi vdr: [3092] rpihddevice: decoding video 1920x1080i, enabling deinterlacer
May 16 18:11:38 vdrpi vdr: [3092] rpihddevice: buffer stall!

Die Dropouts sind auch sporadisch... muß mal schauen ob ich im Log was kriege wenn er Audiomässig dropped.

Grüsse, PmK

Hallo an alle,

Ich habe ein Paar Probleme die ich nicht ganz nachvollziehen kann.

folgendes kommt im log

May 22 02:03:03 raspbmc vdr: [4698] max. latency time 3 seconds
May 22 02:04:22 raspbmc vdr: [4711] rpihddevice: audio parser skipped 80 of 2928 bytes
May 22 02:05:55 raspbmc vdr: [4716] TS buffer on device 10 thread ended (pid=4698, tid=4716)
May 22 02:05:55 raspbmc vdr: [4715] buffer stats: 513052 (24%) used
May 22 02:05:55 raspbmc vdr: [4715] receiver on device 10 thread ended (pid=4698, tid=4715)
May 22 02:05:55 raspbmc vdr: [4719] receiver on device 10 thread started (pid=4698, tid=4719, prio=high)
May 22 02:05:55 raspbmc vdr: [4720] TS buffer on device 10 thread started (pid=4698, tid=4720, prio=high)
May 22 02:05:56 raspbmc vdr: [4719] rpihddevice: set video codec to MPEG2
May 22 02:09:38 raspbmc vdr: [4720] i/o throttle activated, count = 1 (tid=4720)
May 22 02:09:40 raspbmc vdr: [4720] buffer usage: 70% (tid=4719)
May 22 02:09:41 raspbmc vdr: [4720] buffer usage: 80% (tid=4719)
May 22 02:09:41 raspbmc vdr: [4720] buffer usage: 90% (tid=4719)
May 22 02:09:42 raspbmc vdr: [4720] buffer usage: 100% (tid=4719)
May 22 02:09:56 raspbmc vdr: [4720] TS buffer on device 10 thread ended (pid=4698, tid=4720)
May 22 02:09:56 raspbmc vdr: [4719] i/o throttle released, count = 0 (tid=4719)
May 22 02:09:56 raspbmc vdr: [4719] buffer stats: 2097151 (100%) used
May 22 02:09:56 raspbmc vdr: [4719] receiver on device 10 thread ended (pid=4698, tid=4719)

ich habe sehr oft kurze cca 1 sek. aussetzer.
hat noch jemand von euch sowas ?

Gruss,

Franz

haste das ding übertaktet ??

Lieber Reufer,

werde ich machen. Ich habe den Patch jetzt eingefahren und werde in ein paar Tagen berichten.

Viele Grüße

Tim

Hallo Reufer,

ich habe das Gefühl, dass es jetzt noch zuverlässiger abstürzt. Irgendwie nicht so wie bisher. Der VDR scheint sich nicht "wegzuhängen". Aber das OSD ist nach äußerst kurzer Zeit nicht mehr zu sehen. D.h. der VDR ist noch "blind" bedienbar, aber ich sehe nichts mehr. Das ist jetzt ja nur ein extrem kurzer Test, aber mit meinen sleeps hatte ich jetzt seit Wochen 0 Probleme...

Viele Grüße

Tim

Hi Reufer,

das default Skin ist auch mein default. Ja, also ich benutze nur das default-Skin (also Classic). Ansonsten habe ich:

-P remotetimers -P svdrpservice -P streamdev-client -P fritzbox -P ac3mode -P epgsync -P femon -P 'remote -l /dev/lircd -i /dev/input/libcec-daemon' -P rpihddevice

Viele Grüße

Tim

Lieber Thomas,

Zitat von reufer

Kannst du bitte den angehängten, leicht modifizierten Patch testen? Zudem würde mich wirklich interessieren, wo genau denn der VDR abstürzt oder hängenbleibt - gdb hast du ja scheinbar im Griff. Mich wundert halt, warum ausgerechnet bei dir das Plugin nicht läuft, will aber nicht ausschliessen, dass das ich was übersehen habe…

ich habe den Patch eben eingefahren. Zunächst sah es ganz gut aus, aber dann ist der VDR wieder hängen geblieben. Festzuhalten ist aber, dass es jetzt anders abstürzt. Der VDR hängt nicht mehr auf dem SVDR Port und ist prinzipiell noch bedienbar, aber man sieht eben überhaupt kein OSD mehr.

Ich habe ja schon mal irgendwo im Thread meine Einstellungen gepostet und ich bin mir fast sicher, dass es an den Werten in der config.txt liegt. Ich habe jetzt mal alle Übertaktungen herausgenommen und 256/256 Memory aufgeteilt. Damit läuft er jetzt schon relativ lange stabil. Ich will das gerne auch noch weiter testen und dann einzelne Werte wieder umstellen, um herauszufinden bei welchem es instabil wird.

Das mit dem gdb muss ich ehrlich sagen, war aus Verzweiflung und hat mich ja auch in die richtige Richtung geführt (die sleeps bringen es ja als Workaround erstmal). Aber das war mein erster Versuch mit gdb, daher solltest Du mir etwas mehr Details nennen, was ich machen soll.

Wenn Du Lust hast, kannst Du ja testweise auch mal diese Einstellungen setzen, um zu sehen ob Du mein Verhalten nachstellen kannst. Die Werte sind noch so niedrig, dass die Garantie dabei nicht erlöschen sollte:

force_turbo=1
arm_freq=900
core_freq=400
gpu_mem=312
gpu_freq=350
sdram_freq=450

Viele Grüße

Tim

Ist schon komisch das es immer bei denen Probleme gibt die meinen das ding übertakten zu müssen

takte das ding mal runter und nimm ein ordentliches Netzteil mit mind. 2A

Ein Netzteil mit 2A Ausgang bringt beim Raspberry recht wenig, denn die Platine ist mit einer 750mA Polyfuse vorgesichert...

Wenn es Probleme mit der Stromversorgung gibt, dann hilft eher ein aktiver USB-Hub und USB-Geräte dann konsequent nur an diesem betreiben. Das entlastet den Stromkreis, der über die Polyfuse versorgt wird.

Zitat

Ein Netzteil mit 2A Ausgang bringt beim Raspberry recht wenig, denn die Platine ist mit einer 750mA Polyfuse vorgesichert...

Das ist richtig, aber manche netzteile die laut beschreibung pi geeignet wären sind es nicht weil sie nur ein bruchteil von dem leisten was draufsteht

so hatte ich schon ein 1A netzteil das bei 600mAh schluss machte

(48 led's)

deswegen lieber auf nummer sicher gehen
und joah ein aktiver usb hub ist meiner meinung nach auch pfilcht

wobei bei mir mittlerweile alles an einer Pico psu hängt alles
cubieboard2 +festplatte und 2xtuner und der Pi macht die ausgabe da beim cubie noch nicht alle sender gehen

Zitat von Mreimer

Ein Netzteil mit 2A Ausgang bringt beim Raspberry recht wenig, denn die Platine ist mit einer 750mA Polyfuse vorgesichert...

Ein Netzteil mit einigen Ampere macht schon Sinn, denn die grüne Polyfuse F3 auf der Unterseite ist vom Charakter Träge. Der Nennstrom beträgt 750mA. Erst darüber löst sie aus. Wird der Strom nur ein wenig überschritten, kann es ewig dauern bis sie anschlägt. Erst bei 1,1 Ampere wirkt die Sicherung vollständig. Durch diesen trägen Charakter kann die Himbeere auch kurzzeitig höhere Ströme ziehen, ohne das die Sicherung anspricht. Problematisch ist dabei nur der recht hohe Spannungsabfall über dieser, der dann instabiles Verhalten erzeugt

siehe dazu auch hier --> http://elinux.org/Polyfuses_explained

Übrigens die Sicherungen F1 und F2 sind gegen Null Ohm Widerstände getauscht worden

Das ändert nichts daran, dass ein *richtigs* 1A-Netzteil für den Raspberry reicht. Also nicht so eine Billig-Heizung die schon bei >500mA komische Geräusche macht. Ich habe USB-Netzteile da die die EuP-Richtlinie erfüllen, auch wirklich 1A bringen und kurschlussfest sind.