[Prototyp] RPI Ausgabeplugin

Hallo Thomas und Tim
Bei mir kommt es gelegentlich zu "packet not accepted in Transfermode"
Dann ruckelt es kurz. Da könnte der MAXRETRIES schon helfen.
Die frage ist halt warum nimmt das plugin manchmal das packet nicht an.
Aber was bei mir wesentlich häufiger vorkommt sind micro Ruckler bei sd sendern.
Ohne Meldungen im Log. Wollte auch schon mit den Buffer spielen hatte aber keine
Ahnung wie oder wo.
Und beim abspielen von Aufnahmen über cifs hab ich diese micro Ruckler vermehrt.
Der ton ist aber nicht gestört.
tim
Wie äusern sich diese aussetzer bei dir?
Thomas
Hab jetz auch dynamic memmory Split aktiv und immer 216MB Ram verfügbar.
Bleiben 40 MB für GPU minus 16 MB die frei sind da sonst mehr Speicher angefordert werden müsste.
Das kommt mir ein bischen wenig vor.

Mfg Thomas

Hi Thomas,

Zitat von reufer

Danke fürs Feedback. Ein paar Fragen dazu:

- Weshalb gibst du beim Aufsetzen des Tunnels vom Clock zum Audio-Render ein Timeout an?

mhh, das war ein Test, analog zu dem Timeout bei eVideoSchedulerToVideoRender. Ich hatte das Gefühl, dass es den Ton etwas zuverlässiger gemacht hat. Aber da ich leider auch keine tiefer gehenden Kenntnisse habe, welche Art Tunnel das ist, und ob es dort zu einem Problem kommen kann, muss Du am Ende entscheiden, ob das Sinn macht.

Zitat

- In VDR 2.0.3 wurde MAXRETRIES auf 20 gesetzt, warum bei dir nun ausgerechnet auf 100?

Aufgrund dieses Postings von Klaus (bzw. wegen des Zitats innerhalb seines Postings), dass es im 1.7er VDR so war:

http://www.vdr-portal.de/board…be-mit-ff-sd/#post1145913

Bei 2.0.1 war es eben noch bei 5. 20 wird vermutlich ausreichen. Dass ich das geschrieben habe, war nur für den Fall, dass jemand auch gerade mit 2.0.1 probiert. Dann muss man es halt mind. auf 20 setzen.

Zitat

- Wie kommst du auf die Werte bei den Audio- und Videobuffern? Zumal die Anzahl Videobuffer gar nicht gesetzt wird, da ich den Default-Wert vom Decoder nur lese, um die Anzahl der freien Videobuffer zu kennen.

Ja, ich weiss, habe ich ja geändert (param.nBufferCountActual = m_freeVideoBuffers statt m_freeVideoBuffers = param.nBufferCountActual). Im vompclient wird es so gemacht:

In audioomx:

port_def_type.nBufferCountActual=2;
port_def_type.nBufferSize=max(port_def_type.nBufferSize,50000); // for transcoder important

In videoomx:

port_def_type.nBufferCountActual=100;
port_def_type.nBufferSize=max(port_def_type.nBufferSize,200000); // for transcoder important

Mit dem Audiobuffer-Wert auf 2 bekomme ich aber noch Audioaussetzer, deshalb habe ich das am Ende auf 11 gesetzt. Was jetzt (fast) problemlos ist. Man bekommt von Zeit zu Zeit nochmal ein Stocken, aber das hat der vompclient auch. Ist somit aus meiner Sicht gleichwertig zu sehen.

Viele Grüße

Tim

Hallo Thomas,

Zitat von googles

tim
Wie äusern sich diese aussetzer bei dir?

also wenn ich nichts ändere, habe ich ganz extreme Audio-Aussetzer und Video-Aussetzer, wo das Bild dann kaputt ist und erst nach und nach wieder die richtigen Farben und Konturen hat (bis der nächste Keyframe da ist). Dann kommt es vereinzelt auch vor, dass der gesamte Stream stehen bleibt. Dann muss man umschalten, damit er wieder anläuft.

Mit den einzelnen Änderungen (MAXRETRIES und RETRYWAIT habe ich leider erst sehr spät bemerkt und geändert) habe ich mich langsam an immer weniger Aussetzer heran getastet. Durch die höhere Anzahl Puffer sind zunächst die Aussetzer mit den Problemen bis zum nächsten Keyframe weggegangen. Dann gab es ab noch immer kurze Stockungen. Am Ende bin ich zu den Werten, die ich gepostet habe, gekommen. Aus meiner subjektiven Sicht scheinen sie die Probleme zu minimieren. Aber vielleicht könnt Ihr ja auch mal spielen.

Viele Grüße

Tim

Zitat von reufer

Hi Tim

Das ist eine ganz andere Baustelle und macht definitiv keinen Sinn.

Ok, dann nehme ich das wieder raus, und gucke mal ob ich dann wieder mehr Aussetzer habe (oder dann eben wahrscheinlich nicht).

Zitat

Die Struktur param wird ein paar Zeilen zuvor gelesen - solange du diese nicht wieder zurück in den Decoder schreibst, ändert sich an der effektiven Anzahl der Buffer gar nichts.

Ja, das habe ich doch gemacht:

-       m_freeVideoBuffers = param.nBufferCountActual;
+        param.nBufferCountActual = m_freeVideoBuffers;

Und vorher:

+       m_freeVideoBuffers = 100;

Zitat

Der Wert 2 ist für alte PES-Aufnahmen und ein paar spezielle Sender definitiv zu wenig, das habe ich Ende Dezember schon geschrieben. Mit Werten >=3 waren die Probleme bei mir weg, aktuell nutze ich 8 Audio-Buffer.

Mit welchen Werten auch immer, aber solch massive Probleme wie du sie scheinbar hast, konnte ich bei mir nie beobachten. Das Erhöhen der Buffer mag hier die Symptome lindern, ist aber meiner Meinung nach nicht die Lösung. Wenn du uns also ein wenig mehr über deine Umgebung schreibst, könnten wir dir vielleicht besser helfen...

Ok, also ich habe einen VDR mit der TT-6400 Full-featured Karte und streamdev als Server. Der Raspberry-VDR connected dann im wesentlichen mit streamdev als Client. Sonst habe ich keine Besonderheiten. Ich nutze die Raspbian-Distro mit diesen Werten:

disable_overscan=1
hdmi_force_hotplug=1
force_turbo=1
arm_freq=900
core_freq=400
gpu_mem=384
gpu_freq=350
sdram_freq=450
decode_MPG2=0xXXXXXXXX
decode_WVC1=0xXXXXXXX

Das Raspberry ist ein neuerer mit 512 MB RAM. Der VDR Aufruf sieht dann so aus:

vdr --port=2001 -s /_config/vdr/vdrshutdown -v /video -c /_config/vdr -P epgsync -P remotetimers -P svdrpservice -P 'remote -i /dev/input/libcec-daemon' -P rpihddevice -P streamdev-client

Gleichzeitig läuft der libcec-daemon.

Was kann ich noch schreiben?

Viele Grüße

Tim

Hallo Tim
Solche Probleme wie du konnte ich auch noch nicht sehen.
Warum brauchst du soviel gpu mem?
Wenn deine epg.data zu groß wird (bei mir am Server 40 mb)
Und der Raspberry swappen muss läuft nichts mehr, konnte ich selber beobachten als ich die vom Server kopiert hab bis der Vdr bereinigt hat.
Schau mal nach ob bei "free" swap bei Null bleibt.
Ich habe momentan 256 Mb und bei 128Mb Split wird es manchmal echt eng.
Mfg
Thomas

Hi Thomas,

Zitat von googles

Solche Probleme wie du konnte ich auch noch nicht sehen.
Warum brauchst du soviel gpu mem?
Wenn deine epg.data zu groß wird (bei mir am Server 40 mb)
Und der Raspberry swappen muss läuft nichts mehr, konnte ich selber beobachten als ich die vom Server kopiert hab bis der Vdr bereinigt hat.
Schau mal nach ob bei "free" swap bei Null bleibt.
Ich habe momentan 256 Mb und bei 128Mb Split wird es manchmal echt eng.

Alles anzeigen

ja, gut das sollte ich wirklich noch mal prüfen. Die Einstellungen habe ich für xbmc auch durch Probieren so eingestellt. Wenn ich xbmc als Client für einen FullHD Film verwende und aus dem Netz streame (allerdings über NFS, das scheint das beste Protokoll zu sein [bei xbmc] mit den geringsten Wacklern), dann haben einige Filme immer an der selben Stelle kurz gehakt mit Meldung "Buffering". Das hatte ich mit der großen gpu_mem Einstellung ziemlich weg bekommen.

Ich werde es bei Gelegenheit mal runter setzen und testen.

Viele Grüße

Tim

Hallo

Ich habe jetzt meinen Raspberry mit 512MB bekommen. Und läuft jetzt besser. hatte beim Apspielen der Aufnahme über cifs fast keine Fehler mehr.
Was ich aber noch über den 256MB PI testen konnte spielt auch heufiger zugriff auf die SD eine große rolle.
Hatte testweise das system auf USB Installiert und festgestellt dass der Stick alle 3 sekunden blinkte. Lief aber über usb schon mal besser.
Dann habe ich gesucht wer ständig auf die SD zugreift. Der übeltäter war das OsdTeletext Plugin als ich das deaktiviert hatte lief es auch über die SD Karte besser.
Werde vieleicht log und epg.data auch auf sd auslagern, dann sollten sie SD zugriffe nahezu 0 sein.
Kann jetzt aber nicht sagen ob das nur bei meine 256MB RPi liegt.
Das Plugin macht jetzt richtig Spaß vielen Dank Thomas
Bin schon auf eine neue Version gespannt

mfg Thomas

ich habe seit mehreren Tagen MLD als Client laufen.
Aufzeichnungen laufen alle ganz gut. Live habe ich bei z.B. Kika HD das Problem das alle 1-2 Minuten das Bild mal kurz grau wird und sich wieder aufbaut. Wobei der Ton weiter läuft.

Da ich streamdev benutze, werden die meisten gleich StreamFilter sagen:
Bei mir steht es auf:
streamdev-client.StreamFilters = 0

Im Logfile steht nichts.

Was könnte es noch sein?

ich habe nun festgestellt das er auch mit den Aufzeichnungen von Kika HD nicht klar kommt.
Damit ist das streamdev plugin als Fehlerquelle ausgeschlossen.

reufer macht es Sinn das ich Dir eine Datei zur Verfügung stelle?

Hallo zusammen

ich hab mir jetzt großteils den 30 Seitigen Thread nochmals zu gemüte geführt - bin aber immer noch nicht ganz schlau daraus geworden was folgende Frage angeht:

Welche FFMPEG Version und welche libav Version zu nehmen sind ?

Die von Raspian (via Paket) - oder via Source und Compilieren ?

Bei FFMPEG schreibt reufer 1.0.7 oder 1.0.8
Bei libav bin ich mir überhaupt nicht klar denn hier schreibt er in einem Post "xxx könnte funktionieren".

Irgendwie war ich auch der meinung dass beides aus dem ffmpeg paket kommt ?

Zudem würde mich interessieren mit welcher VDR Version das aktuell am besten läuft ?

CU
GTR

Ich habe alles benötigte über Pakete installiert und es läuft perfekt
Also die von Raspian via Paket

Hallo zusammen - hallo Reufer

danke für deine Erklärung !

Ich hatte bisher eigentlich immer mit dem Sundtek Treiber (Netzwerk Modus) getestet und hier sehr hohe CPU Lasten erreicht - teilweise so hoch dass RPI an seine Grenzen gekommen ist.
Eigentlich schade da die Sundtek Netzwerk-Geschichte ansonsten SUPER läuft - auch auf anderen Clients aber der RPI scheint dafür einfach zu schwach zu sein.

Hatte dann gestern mal nen Streaming Server mit STreamdev aufgesetzt und siehe da - das läuft ja wesentlich besser ... (Filter aus)

Nur eins passiert bei mir immer wieder auf dem Server - bin mir aber nicht sicher ob das mit dem RPI zusammen hängt:

"Ring Buffer overflow" - es handelt sich hier um eine Fehlermeldung des Streamdev Server Plugins....

Im gleichen Athemzug kommt es dann zu "Aussetzern" oder einem kompletten Bildabsturz.

CU
GTR

Hi,

wo's gerade angesprochen wird:
Ich hab gestern mal meine beiden DVB-T Stiks am RPI verglichen. Der Sundtek produziert eine deutlich höhere System Last. Der Load beträgt beim TV Schauen ohne weitere Aktivität im Mittel um die 0.9 geht aber gerne auch mal auf über 2 hoch. Mein billiger Noname Stick erzeugt nen Load von 0.5 ohne extreme Abweichungen nach oben. Die Empfangsqualität vom Sundtek ist allerdings deutlich besser, keine Aussetzer oder grobe Artefakte. Der Noname hat immer wieder Empfangsprobleme mit Aussetzern und Artefakten. Beide Sticks betreibe ich über ne Dachantenne. Die mitgelieferten Zimmerantennen sind nahezu unbrauchbar.

Claus

@Reucher

ich weiss jetzt nicht ob das schon gemeldet wurde:

Habe gestern mal die aktuelle Version eingespielt - beim Abspielen von alten PES aufnahmen kommt es zu folgendem problem:

Startet man die Wiedergabe und "Springt" mit den beiden mittleren Farbigen Tasten sagen wir mal 5 minuten vor dann bleibt das playback auf "pause" stehen. man muss dann 1x auf "vorspulen" drücken und die Wiedergabe startet.

CU
GTR

Hallo

das ging ja fix ... .-)

Dann hätte ich noch 2 Fragen / Anregungen:

1: Console - Das Bild überlagert ja die "konsole" - also alles was so an Text-Ausgabe auf der Konsole ist - immer wenn das Bild kurz weg ist sieht man die Konsole (Text) das ist jetzt nix dramatisches - aber irgendwie stört´s - kann man die Konsole nicht einfach "schwarz" überlagern ?

2: ich hab sehr viele alte PES aufnahmen - da sind auch viele alte Filme im 4:3 Format dabei - die werden dann entsprechend im 4:3 Format abgespielt - mich stören da schon die schwarzen Balken links und rechts - aber wenn die Konsole zudem noch nicht leer ist ist dann links und rechts vom Bild "TEXT"...
Könnte man das einstellbar machen dass das Bild auf 16:9 gedehtn wird ? (so wie in anderen Augabe Plugins)

3: Ich hab immer wieder mal "segmentation Fault" und Absturz - kann ich hier noch was machen um die Stabilität zu verbessern ?

Wie gesagt - ist beides im aktuellen Stadium nix wichtiges - wollte es nur mal anbringen.

Ansonsten: TOLLE ARBEIT !

Gruß GTR

Zitat

Ich hatte bisher eigentlich immer mit dem Sundtek Treiber (Netzwerk Modus) getestet und hier sehr hohe CPU Lasten erreicht - teilweise so hoch dass RPI an seine Grenzen gekommen ist.

Hm ich hab beim Sundtekstick (einer ist dran) auch den Netzwerkmodus an

und die CPU-Last ich jetzt nicht besonders hoch vielleicht 50%

Welche Version vom PI hast du den

256MB/512MB | CHINA/UK - Version ??