[RPI Ausgabeplugin] Knacken

Zitat von reufer

Anders bei DTS, hier läuft nur Pass-Though flüssig...

Auch das ist mittlerweile widerlegt - mein Test hat gehakt, weil der Durchsatz über NFS zu gering war, um den Bluray-Stream schnell genug zu liefern.

Ich habe nun einen Ausschnitt auf die SD-Karte kopiert, und 5.1 DTS läuft auch als Stereo-Downmix über die Klinke absolut ohne Ruckeln und Knacksen, sogar mit aktivierten Untertiteln, die pixelweise skaliert und ins OSD geschrieben werden müssen. Die CPU-Last des vdr liegt dabei etwa bei 65%, davon gehen etwa 40% auf den Audio-Decoder (gemessen mit "top", Shift-H).

Mal schauen, welche Schräubchen NFS bietet, woran man drehen kann...

Gruss
Thomas

Zitat von reufer

Mal schauen, welche Schräubchen NFS bietet, woran man drehen kann...

Da würde ich mich dann sehr über einen neuen und ausführlichen Thread zu dem Thema freuen. So mit Benchmarks und so?

Gerald

Zitat von reufer

Mal schauen, welche Schräubchen NFS bietet, woran man drehen kann...

http://lucatnt.com/2013/09/avo…xbmc-on-the-raspberry-pi/

Also bei mir funktionieren diese Einstellungen sehr gut:

Auf der Clientseite:

In der /etc/sysctl.conf

vm.min_free_kbytes = 16384

In /etc/fstab

server:/video 	/video      	nfs 	rw,noauto,vers=3,rsize=32768,intr,noatime,wsize=32768,async         	0   	0

Auf der Serverseite:

In der /etc/default/nfs-kernel-server

RPCNFSDPRIORITY=19

VG Uli

Hi Uli

Zitat von binduli

Auf der Clientseite:
In der /etc/sysctl.conf

Code

vm.min_free_kbytes = 16384

[...]

Auf der Serverseite:
In der /etc/default/nfs-kernel-server

Code

RPCNFSDPRIORITY=19

Alles anzeigen

Darf ich fragen, wie du darauf gekommen bist?

Gruss
Thomas

Hallo Thomas,

vm.min_free_kbytes = 16384

Ich hatte beim Backup meiner SD-Karte öfter die Meldung

eth0: kevent 2 may have been dropped

Und da habe ich obige Lösung in Foren gefunden. Subjektiv verbessert das auch den kompletten Netzwerkverkehr. Zumindest beim Spulen in Aufnahmen habe ich hier eine Verbesserung festgestellt.

RPCNFSDPRIORITY=19

erhöht die Prioität des NFS-Server was sich durch Tests ebenfalls positiv auf das Abspielen von Aufnahmen am NFS-Mount ausgewirkt hat.
Besonders dann wenn simultan mehrere Aufnahmen liefen (HD)

VG Uli

Hallo Uli

Vielen Dank für die Erklärungen! Werde ich mal ausprobieren...

Zitat von binduli

Code

RPCNFSDPRIORITY=19

erhöht die Prioität des NFS-Server was sich durch Tests ebenfalls positiv auf das Abspielen von Aufnahmen am NFS-Mount ausgewirkt hat.
Besonders dann wenn simultan mehrere Aufnahmen liefen (HD)

Ist dein Server denn auch ein Raspberry?

Gruss
Thomas

In /etc/default/nfs-kernel-server steht:

# Runtime priority of server (see nice(1))
RPCNFSDPRIORITY=0

Wenn ich es richtig verstehe soll das "see nice(1)" heißen das sich die Werte wie bei nice verhalten. das heißt das du mit der 19 eine sehr NIEDRIGE Priorität eingestellt hast.

Gruß Patrick

Hallo Thomas,

nein, Ich habe ein DN2800MT Board mit Digital Devices Karten am laufen. SSD als Systemplatte und eine WD Red 3TB als Datenplatte. Was hast du im Einstaz?

Was mir über lange Tests noch aufgefallen ist und viel im Live TV bringt.

In Datei omxdevice.c:

// speed correction factors for live mode, taken from omxplayer
int cOmxDevice::s_speedCorrections[5] = {
    	S(0.999f), S(0.9995f), S(1.000f), S(1.0005), S(1.001)
};

Ohne diese Änderung habe ich immer wieder Bild-Ruckler im LiveTV (Keine Ton-Ruckler). Mit dieser Einstellung nur noch selten.
Es scheint als wäre der urspüngliche Korrektursprung zu groß und erzeugt somit ein Bildruckeln.

Ich weiß jetzt nicht ob dass auch anderweitige Auswirkungen hat, aber für mich passt diese Einstellung gut.

VG Uli

Hallo Patrick,

du hast Recht,

es fehlt das Minus davor..

VG Uli

Hi Uli

Zitat von binduli

Was mir über lange Tests noch aufgefallen ist und viel im Live TV bringt.

In Datei omxdevice.c:

Code

// speed correction factors for live mode, taken from omxplayerint cOmxDevice::s_speedCorrections[5] = {
S(0.999f), S(0.9995f), S(1.000f), S(1.0005), S(1.001)
};

Ohne diese Änderung habe ich immer wieder Bild-Ruckler im LiveTV (Keine Ton-Ruckler). Mit dieser Einstellung nur noch selten.
Es scheint als wäre der urspüngliche Korrektursprung zu groß und erzeugt somit ein Bildruckeln.

Ich weiß jetzt nicht ob dass auch anderweitige Auswirkungen hat, aber für mich passt diese Einstellung gut.

Alles anzeigen

Ich habe keine Ahnung, welche Faktoren notwendig sind - ist die Korrektur zu schwach, tritt früher oder später ein Buffer-Über- oder -Unterlauf auf. Wenn der VDR damit aber 24h durchläuft, stehen die Chancen gut… oder du baust dir eine Ausgabe ein, welche m_latency überwacht.

Ansonsten habe ich kein Problem, die Faktoren anzupassen.

Zitat von binduli

nein, Ich habe ein DN2800MT Board mit Digital Devices Karten am laufen. SSD als Systemplatte und eine WD Red 3TB als Datenplatte. Was hast du im Einstaz?

Ok. Ich habe mich nur gefragt, wie die Änderung am Server den Raspi-Client beeinflusst. Selber benutze ich entweder eine VM oder den Server im Keller. Das ist irgend ein stromsparender Intel-Core - genaue Bezeichnung müsste ich raussuchen.

Gruss
Thomas

Hallo Thomas,

ich habe mal am Wochenende etwas mit der Anpassung der Wiedergabegeschwidigkeit (m_omx->SetClockScale) rumgespielt.

Und es ist tatsächlich so das Veränderungen hier Ruckler im Bild erzeugen können.
Nun Ist mein Ziel dies zumindest zu minimieren, weil wenn ich es ganz auschalte dann erzeuge ich (wie du schon erwähnt hast)
Buffer Under / Overruns.

Gibt es eine Möglichkeit die aktuelle Buffergröße rauszufinden (Methode)?
Kann man die Buffergröße erhöhen (welche Variable)?

Vielen DANK

Uli

Hi Uli

Zitat von binduli

Gibt es eine Möglichkeit die aktuelle Buffergröße rauszufinden (Methode)?
Kann man die Buffergröße erhöhen (welche Variable)?

Wie gross die Buffergrösse im VDR ist kann ich nicht sagen, das müsste man in den Sourcen nachschauen. Ziel ist es, dass der VDR im Live-Mode gar nicht buffern muss, und die Differenz zwischen der PTS des gerade vom VDR angelieferten Pakets und der aktuellen Wiedergabezeit konstant ist.

Diese Latenzzeit wiederum sollte möglichst kurz sein, damit beim Umschalten auf einen andern Kanal möglichst keine Zeit bis zur Wiedergabe vergeht, aber der Video-Scheduler genügend Frames vorrätig hat, um diese flüssig auszugeben. Mit dem aktuellen Wert kann ich Video-only-Kanäle sowohl in HD und SD (getestet mit ZDF HD und Sat 1 SD) fliessend wiedergeben. Mit Audio kann die Latenzzeit kleiner sein, weil dann diese Zeitstempel als Referenz dienen und das Decodieren weniger Zeit in Anspruch nimmt, bzw. kein Scheduler vorgeschaltet ist, der die Ausgabe verzögert.

Gruss
Thomas

Ich verfolge dieses Thema schon einige Zeit und versuche rauszufinden was bei mir anders ist als bei euch. Ich habe nämlich noch nie dieses beschriebene Knacken wahrgenommen. Meine Ohren sind sehr gut, und der RasPi tut seinen Dienst im Schlafzimmer. Dort müsste man es abends bei absoluter ruhe erst recht hören.

Zitat von binduli

Gibt es eine Möglichkeit die aktuelle Buffergröße rauszufinden (Methode)?
Kann man die Buffergröße erhöhen (welche Variable)?

Nach dieser Aussage ist mir eingefallen das ich seit ewigkeiten einige Patche nutze die verschiedene BUFFER beeinflussen. Vielleicht hilft ja einer davon:

diff -uNr vdr-plugin-streamdev/common.h streamdev/common.h
--- vdr-plugin-streamdev/common.h       2014-03-30 22:19:07.851050854 +0200
+++ streamdev/common.h  2014-03-23 20:10:48.053619651 +0100
@@ -29,7 +29,7 @@
 #define Dprintf(x...)
 #endif


-#define MAXPARSEBUFFER KILOBYTE(16)
+#define MAXPARSEBUFFER KILOBYTE(256)


 /* Service ID for loop prevention */
 #define LOOP_PREVENTION_SERVICE "StreamdevLoopPrevention"

diff -uN vdr-2.0.6.orig/dvbplayer.c vdr-2.0.6/dvbplayer.c
--- vdr-2.0.6.orig/dvbplayer.c  2013-03-08 14:44:19.000000000 +0100
+++ vdr-2.0.6/dvbplayer.c       2014-03-23 20:11:29.653618675 +0100
@@ -198,7 +198,7 @@


 // --- cDvbPlayer ------------------------------------------------------------


-#define PLAYERBUFSIZE  MEGABYTE(1)
+#define PLAYERBUFSIZE  MEGABYTE(100)


 #define RESUMEBACKUP 10 // number of seconds to back up when resuming an interrupted replay session
 #define MAXSTUCKATEOF 3 // max. number of seconds to wait in case the device doesn't play the last frame

diff -uN vdr-2.0.6.orig/recorder.c vdr-2.0.6/recorder.c
--- vdr-2.0.6.orig/recorder.c   2014-02-21 10:21:30.000000000 +0100
+++ vdr-2.0.6/recorder.c        2014-03-23 20:13:41.973615565 +0100
@@ -10,7 +10,7 @@
 #include "recorder.h"
 #include "shutdown.h"


-#define RECORDERBUFSIZE  (MEGABYTE(20) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE
+#define RECORDERBUFSIZE  (MEGABYTE(50) / TS_SIZE * TS_SIZE) // multiple of TS_SIZE


 // The maximum time we wait before assuming that a recorded video data stream
 // is broken:

Habe keine Ahnung ob einer davon was damit zu tun hat, aber vielleicht hilft es ja.

Meine config.txt sieht folgendermaßen aus:

gpu_mem_512=128
hdmi_force_hotplug=1
#sdtv_aspect=3
#hdmi_force_edid_audio=1


arm_freq=1000
core_freq=450
isp_freq=450
sdram_freq=450
over_voltage=6
force_turbo=1
disable_overscan=1
hdmi_drive=2

Ansonsten wüsste ich nicht was ich zum Vergleich noch posten könnte. Bin aber gerne bereit mit weiteren Vergleichswerten zu helfen.

Gruß Patrick

Hallo Patrick,

ich muss sagen mit der aktuellen GIT-Version habe auch ich kein Knacken mehr.

Allerdings gibt es im LIVE-TV immer wieder Micro-Ruckler bei Bewegungen. Die kommen nicht vom Deinterlacing, da die aufgenommene Variante dieses Verhalten nicht zeigt.

Es liegt vielmehr an der Ampassung der Wiedergabegeschwindigkeit im Live-Betrieb, um einen Buffer-Underun/Overrun zu verhindern.

Um so niedriger die Anpassung um so geringer die Ruckler. Bei der Wiedergabegeschwindigkeit 1x habe ich keine Ruckler mehr.

Ich spiele momentan an verschiedenen Varianten herum um die Wiedergabegeschwindigkeit anzupassen und würde bei Erfolg mal nen Patch zum Testen posten (Wenn das für Thomas i.O ist)

VG Uli

Zitat von binduli

Ich spiele momentan an verschiedenen Varianten herum um die Wiedergabegeschwindigkeit anzupassen und würde bei Erfolg mal nen Patch zum Testen posten

Gerne!

Hast du denn die Ruckler auch mit einem anderen Display? Und stimmt die Framerate mit der des Videomaterials überein?

Gruss
Thomas

Hallo Thomas,

Hab den Patch mal in einem neuen Thread gepostet. Bitte verzeihe eventuelle Fehler in der Software, denn dies sind meine ersten Erfahrungen in C.

Ansonsten ist es so das ich es an meinen 55" LED-TV und an einem Computer-Bildschirm getestet habe.
Ausgabe ist 1080p mit 50Hz. Ich kann zu 100% sagen das die Ruckler an der Wiedergabe-Geschwindikeit liegen. Denn dann passt das Verhältnis der Framerate auch nicht mehr zur Bildfrequenz des TVs
Auffallen tut das aber nur bei meist seitlichen Bewegung, extrem bei Fußballspielen. Wahrscheinlich auch nur bei großen TVs...

VG Uli

RPI mit 2.1.6, rpihddevice 0.0.10, nicht overclocked, ethernet (nicht wifi). installiert laut anleitung vom wiki als client der uebtre streamdev video vom VDR server (fetter PC) bekommt. vm.min_free_kbytes=16384. Anschluss via HDMI an TV direkt, audio/video. RPI firmware 3.12.34+.

Laeuft alles "prima", ausser das bei bestimmten Sendern (*) es zu aussetzern kommt, da wird dann das Bild kurz (1/4 sek) grau und baut sich wieder auf. Ton knackst nicht, fehlen aber wohl kurze segmente. Und der Ton wird dadurch halt mehr und mehr asynchron. Wenn ich so ein programm aufnehme (auf dem server), und dann ueber NFS auf dem RPI abspiele, dann habe ich da drin Audioaussetzer., aber keine Bildaussetzer. Wenn ich dieselbe VDR aufnahme auf dem RPI mit omxplayer abspiele spielt das problemlos, bild/ton, synchron. Das scheinen also wirklich hausgemachte Probleme des VDR zu sein. Mal wild geraten, warum dass bei live/aufzeichnung unterschiedlich wirkt: Bei live scheint er auf den Ton zu synchronisieren. Verliert Ton, hat zuviel Bild, ueberspringt Bild, das fuehrt zum Bildfehler. Bei Wiedergabe von Aufzeichnung werden keine Bilder uebersprungen, also Tonaussetzer.

Die Programme bei denen das passiert sind die "ZDF" HD Kanaele. Beid denen sagt rpihddevice: 1280x720@100i. Die ARD HD Kanaele machen 1280x720@50p und keine Probleme. SD sowieso nicht.

Noch witziger: Wenn ich den RPI boote auf ein Programm mit solchen Problemen, dann laeuft es danach prima, und der VDR verbraucht ca 95% CPU, unabhaengig vom Kanal. Nach einiger Zeit , > 10 min und ich glaube auch bloss erst nach Umschalten geht der VDR auf ca. 25%..30% CPU runter, und dann fangen die Probleme an.

was das wohl ist...

Zitat von te36

RPI mit 2.1.6, rpihddevice 0.0.10, nicht overclocked, ethernet (nicht wifi). installiert laut anleitung vom wiki als client der uebtre streamdev video vom VDR server (fetter PC) bekommt. vm.min_free_kbytes=16384. Anschluss via HDMI an TV direkt, audio/video. RPI firmware 3.12.34+.

Kannst du mal mit der git-Version testen? Im Audio-Bereich habe ich eine Änderung rückgängig gemacht, welche die Performance beeinträchtigt hat.

Zitat von te36

Laeuft alles "prima", ausser das bei bestimmten Sendern (*) es zu aussetzern kommt, da wird dann das Bild kurz (1/4 sek) grau und baut sich wieder auf. Ton knackst nicht, fehlen aber wohl kurze segmente. Und der Ton wird dadurch halt mehr und mehr asynchron. Wenn ich so ein programm aufnehme (auf dem server), und dann ueber NFS auf dem RPI abspiele, dann habe ich da drin Audioaussetzer., aber keine Bildaussetzer. Wenn ich dieselbe VDR aufnahme auf dem RPI mit omxplayer abspiele spielt das problemlos, bild/ton, synchron. Das scheinen also wirklich hausgemachte Probleme des VDR zu sein. Mal wild geraten, warum dass bei live/aufzeichnung unterschiedlich wirkt: Bei live scheint er auf den Ton zu synchronisieren. Verliert Ton, hat zuviel Bild, ueberspringt Bild, das fuehrt zum Bildfehler. Bei Wiedergabe von Aufzeichnung werden keine Bilder uebersprungen, also Tonaussetzer.

Die grauen Übergänge kommen dann, wenn der H.264-Decoder neu startet, was auch bei Empfangsproblemen passieren kann. Warum das bei einer Aufnahme anders rum sein soll, kann ich dir nicht sagen. Aber ich würde mir so eine Problemaufnahme gerne mal anschauen, kannst du mir die irgendwie zugänglich machen? Ein kurzer Ausschnitt von der Stelle bei der der Ton aussetzt reicht völlig.

Im übrigen sollte auch bei fehlerhaften Streams Bild und Ton immer synchron sein, wobei immer der Ton den Takt vorgibt. Fehlen also Audio-Frames, so springt die Wiedergabe an der entsprechenden Stelle und die Videoframes dazwischen werden verworfen. Das funktioniert natürlich nur wenn genügend Daten gepuffert sind, dürfte sich also bei Live-TV anders äussern.

Zitat von te36

Die Programme bei denen das passiert sind die "ZDF" HD Kanaele. Beid denen sagt rpihddevice: 1280x720@100i. Die ARD HD Kanaele machen 1280x720@50p und keine Probleme. SD sowieso nicht.

Dass die ZDF-Kanäle als interlaced erkannt werden ist ein Firmware-Bug - funktionieren alle andern Kanäle problemlos?

Gruss
Thomas

Git macht leider keinen Unterschied.

Sind exakt nur die Kanaele bei denen das rpihddevice 720i100 erkennt. Die ARD Kanaele werden als 720p50 erkannt und laufen prima. Habe sonst noch nicht versucht andere HD Kanaele zu finden. SD geht alles prima.

VLC von anderen Rechnern spielt die ZDF Kanaele prima via http:///vdr-server:3000/ ab. Habe aber auch mal die Aufzeichnung vom VDR von lokaler SD abspielen lassen, Tonaussetzer. omxplayer, keine Aussetzer.

Funktionieren bei Dir die Kanaele ohne Probleme ? Wenn ja, dann muss das ja irgendein merkwuerdies Installationsproblem bei mir sein.. *seufz*