[Prototyp] RPI Ausgabeplugin

Hi,

Zitat von reufer

Sowas ist bei mir noch nie passiert - kannst du das irgendwie bewusst reproduzieren?

mhh, ich habe jetzt immer mit einer bestimmten Aufnahme getestet, die besonders hakelig war. Aber auch da passiert es nur sporadisch. Ich werde mal versuchen das noch etwas einzugrenzen.

Zitat

Danke für den Tipp, aber ich denke nicht, dass es daran liegt. Denn der Buffer Stall tritt auch auf, wenn der VDR pausiert ist und der Reset nach einem Buffer-Stall ist nicht das eigentliche Problem, sondern dessen Lösung.

Aus einem mir noch nicht gänzlich erklärbaren Grund muss ich für ein StillImage das Videopaket mehrmals an den Decoder schicken - inzwischen vermute ich, dass erst dann der Clock richtig anläuft. Sobald dann ein decodiertes Frame bis zum Video-Render durchgeflutscht ist, bleiben die restlichen wohl im Decoder, da deren PTS identisch ist. Werde das aber noch genauer analysieren...

Ja, ich meine ja genau, wenn man auf Pause drückt. Im Original pausiert es bei mir kurz und wird dann resetet und läuft solange weiter bis der Puffer leer ist, pausiert dann dort, weil der Puffer nicht nachgefüllt wird. Mit dem Patch bleibt es sofort pausiert stehen und bei play gibt es kurz Artefakte und dann bei etwas 4 Sekunden später läuft die Wiedergabe wieder einwandfrei.

Naja zumindest funktioniert es so bei mir, ich habe z.B. auch nicht das Problem, dass so viele Frames an den Dekoder geschickt werden müssen. Ich habe es jetzt mal auf "ParseVideoCodec(Data, Length) == cVideoCodec::eMPEG2 ? 1 : 1;" reduziert und dennoch habe ich ein korrektes Standbild bei Pause (getestet allerdings nur h.264, noch kein mpeg2)...

Oder verstehe ich da was miss?

Viele Grüße

Tim

Zitat von reufer

Aus einem mir noch nicht gänzlich erklärbaren Grund muss ich für ein StillImage das Videopaket mehrmals an den Decoder schicken - inzwischen vermute ich, dass erst dann der Clock richtig anläuft. Sobald dann ein decodiertes Frame bis zum Video-Render durchgeflutscht ist, bleiben die restlichen wohl im Decoder, da deren PTS identisch ist. Werde das aber noch genauer analysieren...

das war bei der PVR350 genauso. Da habe ich es so gelöst:

for (int i = MIN_IFRAME / Length + 1; i > 0; i--) {
			WriteAllOrNothing(fd_out, buf, blen);
			usleep(1); // allows the buffer to be displayed in case the progress display is active
		}

wobei MIN_IFRAME mit 400000 definiert ist
ist

Hi Thomas,

Zitat von reufer

Ich glaube, wir haben uns tatsächlich missverstanden und bezüglich Pause hast du Recht: Hier habe ich tatsächlich übersehen, dass der Buffer-Stall anspricht und die Wiedergabe erneut startet! Das wird wohl auf einen Workaround hinaus laufen, wie du ihn vorgeschlagen hast.

StillImage() ist aber was anderes. Während bei der Pause einfach nur der Takt angehalten wird, kriegt StillImage() ein komplettes Frame zum anzeigen und muss sich im Fall von OMX darum kümmern, dass dieses sofort zum VideoRender gelangt. Hier scheint es nicht möglich zu sein, ein einzelnes Frame vom Decoder bis zum Render durchlaufen zu lassen, weshalb ich den for-loop eingebaut habe.

ja, das zeigt nur, dass ich keine Ahnung habe.

Ok, also zum Pausieren während einer Wiedergabe wird nur "Freeze" benutzt, ja? Wann wird denn dann StillImage() benutzt? Ich hatte wirklich gedacht, dass Dein known issue:

- StillImage() will cause buffer stall

der Fehler beim Pausieren in der Wiedergabe ist. Na ok, bleibt nur noch die Frage, wozu StillImage() nun ist...

Viele Grüße

Tim

Hallo Thomas

Zitat von reufer

Bei SD klemmt's hier aber noch - es kommt immer zum "buffer stall" (3=RTL, 4=Sat1, 5=Pro7)

Das kann ich bei mir nicht nachvollziehen. Allerdings vermisse ich die Audio-Traces - hast du die absichtlich gekürzt, oder fehlt da wirklich der Ton? Das von dir beschriebene Verhalten liesse sich erklären, wenn Audio-Pakete kommen, aber vom Parser verworfen werden. In dem Fall würde der Clock gestartet, aber es kommen nie Audio-Frames beim Render an die den Takt nachführen. Dann würden die decodierten Video-Frames im Scheduler "verhungern", d.h. ein Buffer-Stall wird detektiert.

Worüber schaust du denn fern? (Sat, Kabel, ...?)

Ich schaue per Sat & streamdev mit dem RasPi fern. Wenn ich Umschalte, dann kommen auch Bild und Ton, aber nach kurzer Zeit (kleiner 1min) bleibt das Bild stehen und der Ton ist weg. Das ganze ist (leider) sehr reporduzierbar.

Ich spiele mal noch ein bischen rum und gebe wieder Bescheid....

Gruß, ollo

Ich habe bei Kika HD auch immer noch aussetzer. Bild und Ton ist kurz weg. Kommt nach ca 1 Sekunde wieder. Passiert alle 1-2 Minuten.
Im Logfile sehe ich aber trotz -l3.7 nichts.

Hallo Thomas,

Vielen Dank für das super Plugin!

SD Sender funktionieren bei mir jetzt mit 0.0.8 ohne Probleme
HD Sender (z.B. ARD und ZDF) setzen alle paar Minuten für 1-2 Sekunden aus (Bild und Ton).
Leider ist wie bei decembersoul nichts im Log zu finden.

Viele Grüße
Tobi

So sieht es bei mir aus:

grep streamdev /etc/vdr/setup.conf 
streamdev-client.HideMenuEntry = 0
streamdev-client.LivePriority = 1
streamdev-client.MaxPriority = 99
streamdev-client.MinPriority = -99
streamdev-client.NumProvidedSystems = 1
streamdev-client.RemoteIp = 192.168.1.2
streamdev-client.RemotePort = 2004
streamdev-client.StartClient = 1
streamdev-client.StreamFilters = 0
streamdev-client.Timeout = 4

Habe aktuell MLD mit dem 0.0.8 laufen.

Hallo Thomas,

Zitat von reufer

Für mich klingt das so, als hättest du Filter-Streaming bei Streamdev aktiv... kann das sein? Denn mein Setup ist das selbe, und z.B. ProSieben läuft bei mir einwandfrei, auch über längere Zeit.

Gruss
Thomas

Inzwischen läuft's, es lag an meinen overclocking settings in der config.txt. Per default klappt's prima

Übrigens läuft es (bei mir) auch mit Filter-Streaming, wenn man den Timeout hoch setzt - siehe hier:

VDR streaming client und Kanäle mit Regionalfenstern

Gruß, ollo

So sehen meine Settings aus:

cat /mnt/system/config.txt 
#hdmi_mode=20
#hdmi_group=1
sdtv_mode=2
sdtv_aspect=3
disable_splash=1
gpu_mem=128
kernel=boot/kernel
initramfs boot/initrd
cmdline=boot/cmdline


decode_MPG2=0x123456789
decode_WVC1=0x123456789
arm_freq=800
core_freq=
sdram_freq=
over_voltage=

Hi,

Zitat von decembersoul

So sehen meine Settings aus:

Code

cat /mnt/system/config.txt 
#hdmi_mode=20
#hdmi_group=1
sdtv_mode=2
sdtv_aspect=3
disable_splash=1
gpu_mem=128
kernel=boot/kernel
initramfs boot/initrd
cmdline=boot/cmdline


decode_MPG2=0x123456789
decode_WVC1=0x123456789
arm_freq=800
core_freq=
sdram_freq=
over_voltage=

Alles anzeigen

ich sehe, dass Du den hdmi_mode nicht setzt. Das mache ich auch nicht, weil er dann auf diesen Mode festgenagelt ist und xbmc beim Abspielen von bspw. 1080p,24hz nicht auf diesen Modus wechseln kann. Der Default beim booten ist allerdings 1080p,60hz. Was für Fernsehen halt nicht so optimal ist. Daher habe ich dann auch immer wieder Ruckler. Ich setze vor dem Start vom vdr mit:

tvservice -e "CEA 31"

den Modus auf 1080p,50hz.

Vielleicht bringt das ja was?

Viele Grüße

Tim

Hallo Zusammen,

ich verzeifel gerade ein wenig beim Bau des Plugins. Bisher habe ich die libav.org Pakete verwendet. Hier wird aber immer wieder betont das mit den ffmpeg.org Codecs gearbeitet wird.

Also wollte ich mir auch die Mühe machen und das ganze neu durchzudrehen.

• Raspbian
• ffmpeg 1.0.8
• vdr2.0.5
• rpihddevice 0.0.8
• streamdev latest git

Als erstes gab es ein remove der Pakete libavcodec-dev und libavformat-dev und deren 53er Varianten.

Ich habe erst das ffmpeg gebaut, direkt auf dem Raspi. Dazu habe ich die Flags von reufer auf Seite 30 genommen. (Abzüglich der Flags fürs Cross compiling)

Danach gings an VDR und Plugins per make && make install.

Das ist auch alles ohne Probleme durchgelaufen, jedoch startet der VDR nicht.

vdr: /usr/lib/libavcodec.so.54: symbol av_asprintf, version LIBAVUTIL_51 not defined in file libavutil.so.51 with link time reference

Wäre super wenn mir jemand ein wenig helfen könnte. Ich nahm an das die libavcodec und libavutil beide durch das ffmepg erzeugt werden und dann auch zueinander passen müssten. Oder sind das Reste der libav.org Pakete. Kriegt man das irgendwie heraus?

Gruß,

Jarv

Hallo Tim,

danke für den Hinweis mit
tvservice -e "CEA 31"
damit kam es bis jetzt zu keinen Bild- und Tonaussetzer mehr!

Über die folgende Einstellungen in config.txt habe ich den "CEA 31" mode ohne tvservice festgelegt:
hdmi_group=1
hdmi_mode=31

Gruß
Tobias

Hi Tobias,

Zitat von ooin

danke für den Hinweis mit
tvservice -e "CEA 31"
damit kam es bis jetzt zu keinen Bild- und Tonaussetzer mehr!

Über die folgende Einstellungen in config.txt habe ich den "CEA 31" mode ohne tvservice festgelegt:
hdmi_group=1
hdmi_mode=31

Alles anzeigen

schön, dass ich helfen konnte. Der Unterschied zu der config.txt ist halt, dass man den Mode im laufenden Betrieb dann nicht ändern kann!

Da ich auch manchmal xbmc verwende und ein Film mit 24fps dann wieder mit 50hz sch... aussieht, ist das halt blöd. Der xbmc kann die Modi selber wechseln, aber eben nicht, wenn Du es in der config.txt fixierst.

Deshalb nehme ich "tvservice", dann bleibts dynamisch.

Viele Grüße

Tim