You are not logged in.

Dear visitor, welcome to VDR Portal. If this is your first visit here, please read the Help. It explains in detail how this page works. To use all features of this page, you should consider registering. Please use the registration form, to register here or read more information about the registration process. If you are already registered, please login here.

1

Monday, June 29th 2009, 7:43pm

Audio-Aussetzer bei Zenslack und Zendeb

In Zenslack 1.0 und 2.0 sowie in Zendeb auf der Samsung SMT-7020s hatte ich
mich immer ein wenig über gelegentliche Aussetzer (Pausen von ca. 0,1s) im
Ton geärgert.

Mit vdr gemachte Aufnahmen hatten, mit der SMT abgespielt, immer an den
ungefähr gleichen Stellen Audio-Unterbrechungen. Kopierte man die Aufnahmen
jedoch auf einen normalen PC und spielte sie mit VLC ab, waren keine
Aussetzer zu hören, d.h. der Fehler lag nicht nicht bei der Aufnahme,
sondern bei der Wiedergabe.

Zenslack und Zendeb nutzen xineliboutput (Mit top ist der Prozess
als "vdr-sxfe" sichtbar), einen Softwaredecoder, um den DVB-MPEG2-Stream auf
dem TV-Gerät dazustellen. Das bedeutet, dass der 733MHz-Celeron der SMT die
Arbeit der MPEG2-Decodierung bewältigen muss.

Besonders viele Audio-Aussetzer gibt es bei der Serie "CSI Miami" auf RTL. In
dieser Sendung ist die Schnittfolge sehr hoch, und ca 1s nach jedem
Szenenwechsel folgt ein Aussetzer im Ton. Dieses Symptom sprach für
einen "Flaschenhals" in der Übertragungsbandbreite, da MPEG2 am Anfang jeder
Szene das Vollbild überträgt (viele Daten), danach aber nur noch die
Änderungen (wenige Daten), und die Übertragung der vielen Daten des Vollbilds
anscheinend die Bandbreite des Tonkanals zu sehr verringerte..

Nach Experimenten mit verschiedenen I/O-Schedulern, nice-Werten
und Echtzeit-Kernels konnte eine Überlastung der CPU schliesslich
ausgeschlossen werden. Ohnehin lag die gesamte CPU-Auslastung während der
Wiedergabe über vdr-sxfe deutlich unter 50%.

Der Flaschenhals musste also woanders liegen.
Schliesslich habe ich eine Lösung gefunden:

In Zenslack und Zendeb erhält vdr-sxfe die Audio- und Videodaten über die
local loop, Port 37890, per UDP-Protokoll. Die Anweisung, UDP zu verwenden,
wird dem vdr-sxfe-Binary beim Aufruf explizit als Kommandozeilenparameter
übergeben.

Offenbar liegt das Problem bei der Verwendung von UDP.

Vielleicht liesse sich die UDP-Übertragung irgendwie verbessern (ich bin kein
Netzwerk-Experte), aber folgender Wikipedia-Eintrag stimmt mich da eher
nachdenklich
(http://de.wikipedia.org/wiki/User_Datagr…l#Eigenschaften):

"UDP stellt einen verbindungslosen, nicht-zuverlässigen Übertragungsdienst
bereit. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes
Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der
sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft.
Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und
unsortierten Paketen unempfindlich sein oder selbst entsprechende
Korrekturmaßnahmen beinhalten."

Vermutlich verarbeitet das System grosse UDP-Pakete nicht richtig.

Folgender Workaround funktioniert jedoch sehr gut: Ändert man den Aufruf von
vdr-sxfe so, dass statt UDP TCP verwendet wird, so steigt zwar die CPU-Last
auf dem PIII-Celeron um ca. 5% an, dafür gibt es aber auch keine
Audio-Aussetzer mehr.

Wer diesen Workaround vornehmen möchte, sollte folgendermaßen vorgehen:

-----------------------------------------------------
Zenslack (V1.0-rc35, vermutlich auch die anderen Zenslack-Versionen):
Datei /etc/zenslack/runmms.sh editieren - in der Zeile

/bin/sleep 2 & vdr-sxfe --video xv
xvdr://${ZS_VDR_SERV_IP} --aspect=$VDRTVMODE --nokbd --udp --lirc -
-fullscreen --post
tvtime:method=Linear,cheap_mode=1,pulldown=0,use_progressive_frame_flag=1
&> /tmp/sxfe.log

muss "--udp" ersetzt werden durch "--tcp". Nach einem Reboot der SMT ist die
Einstellung aktiv (Restart des VDR reicht dazu nicht aus).

-------------------------------------------------------
Zendeb (0.4.1-Beta, vermutlich auch die Vorgängerversionen):
Datei /etc/zendeb/vdr-sxfe.sh editieren - in der Zeile

vdr-sxfe --video xv
xvdr://127.0.0.1:37890 --aspect=$ASPECTRATIO --nokbd --lirc --tcp --fullscreen
$XINELIBPOST &> /tmp/sxfe.log

muss "--udp" ersetzt werden durch "--tcp".

--------------------------------------------------------------
Möglicherweise können andere VDR-Distributionen ebenfalls von dem Workaround
profitieren. Wer mit Audio-Aussetzern bei vdr-sxfe zu tun hat und es
probieren möchte, kann sich mit

cd /etc
grep -R "vdr-sxfe" *

alle Dateien in /etc, die einen potentiellen Aufruf von vdr-sxfe enthalten,
ausgeben lassen und dort ggf. die Option "--udp" ändern auf "--tcp". Die
UDP-Option des Aufrufs kann auch im xvdr-Argument enthalten sein, z.B.
xvdr:udp://127.0.0.1 - auch in diesem Fall kann das "udp" einfach durch
ein "tcp" ersetzt werden.
Kaum macht man's richtig - schon funktioniert's !

2

Monday, June 29th 2009, 11:25pm

RE: Audio-Aussetzer bei Zenslack und Zendeb

Quoted

Original von denzo0815
Der Flaschenhals musste also woanders liegen.
Schliesslich habe ich eine Lösung gefunden:

In Zenslack und Zendeb erhält vdr-sxfe die Audio- und Videodaten über die
local loop, Port 37890, per UDP-Protokoll. Die Anweisung, UDP zu verwenden,
wird dem vdr-sxfe-Binary beim Aufruf explizit als Kommandozeilenparameter
übergeben.

Offenbar liegt das Problem bei der Verwendung von UDP.

Vielleicht liesse sich die UDP-Übertragung irgendwie verbessern (ich bin kein
Netzwerk-Experte), aber folgender Wikipedia-Eintrag stimmt mich da eher
nachdenklich
(http://de.wikipedia.org/wiki/User_Datagr…l#Eigenschaften):

"UDP stellt einen verbindungslosen, nicht-zuverlässigen Übertragungsdienst
bereit. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes
Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der
sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft.
Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und
unsortierten Paketen unempfindlich sein oder selbst entsprechende
Korrekturmaßnahmen beinhalten."

Vermutlich verarbeitet das System grosse UDP-Pakete nicht richtig.

Ich hätte ja nie gedacht, dass ich meine Kenntnisse in Rechnernetze mal für die VDR-SXFE Ausgabe brauchen könnte ;)
Allerdings verstehe ich nicht wirklich woran das hier liegen könnte.
a) ja, UDP ist zustandslos und unsicher
b) ja, im Internet kann es tatsächlich passieren, dass ein Paket das andere überholt
c) sollte eigentlich keins davon auf einem localhost loop passieren bzw. stören, da ich davon ausgehe, dass hier nach FIFO abgearbeitet wird. Man piped am einen Ende rein und liest es am anderen wieder aus.
d) UDP nimmt man für gewöhnlich, weil es
d1) zustandslos ist
d2) weniger headeroverhead hat
d3) weniger Rechenleistung benötigt, da es ein send end forget Protokoll ist und keine aktive Bestätigung von Paketen verlangt
e) daher kann ich mir aus Netwerkersicht gerade garnicht vorstellen warum das hier ein Problem sein könnte solange der Rechner selbst nicht UDP Paket von sich an sich auf localhost wegwirft, denn dann sollten nach wie vor alle Pakete ankommen und wie du schon gesehen hast, das sogar mit weniger Netzwerklast

Aber vielleicht hat ja auch einer bei der UDP Anbindungsprogrammierung geschlampt und es bei TCP besser gemacht.

Ich werds auf jeden Fall mal austesten, wobei ich mir die Tonaussetzer bisher immer mit zu Hoher Datenrate im DVB-S erklärt habe (ich kenn die eigentlich nur von ARD/ZDF), aber ausprobieren kostet ja nix ;)
Server: Athlon II X2 250 - Asus M3N-H HDMI - 2x1GB RAM - 3TB HDDs -
1 x Digital Devices Cine S2 V6 DVB-S2 (SD Sender im Highband funktionieren mit der Karte nach wie vor unter Linux nicht, unter Windows schon)
3 x Nova Budget (die ich eigentlich durch die Cine S2 mit Erweiterungsmodul ersetzen wollte, leider aber für die SD Sender immer noch brauche)
mit yavdr 0.4.0

Posts: 3,600

Occupation: Admin;Support

  • Send private message

3

Monday, June 29th 2009, 11:36pm

zustandslos
Du meinst verbindungslos :unsch
Siehe auch hier http://www.itwissen.info/definition/lexi…-Protokoll.html
Das andere war meine ich verbindungsorientiert (tcp)
Software: gen2vdr V3 ( Beta8 ) / gen2vdr V2
Hardware: Intel 5200EE - 5N7A-VM - Scythe Shuriken - BeQuiet(Netzteil) - X10-USB Remote
SMT 7020S & P3@900 - Testsystem mit FF und X10-USB Remote
Links für Neueinsteiger

"Jetzt, wo ich weiß wie es geht, versteh ich auch die Gebrauchsanleitung"

4

Tuesday, June 30th 2009, 2:37pm

@Egalus:

Übrigens ist mir gerade ein kleines Problem der 0.4.1-beta1 aufgefallen:
Drückt man die Power-Taste am Gerät kurz, wird zwar VDR gestoppt, aber die SMT wird nicht heruntergefahren.
Ursache: In /etc/zendeb/SMT-powerstate.sh steht die Zeile

/etc/init.d/halt

Dieses halt-Script benötigt aber noch einen Parameter {start|stop}.

Nachdem ich o.g. Zeile geändert hatte in

/etc/init.d/halt stop

klappte auch das Herunterfahren.
Kaum macht man's richtig - schon funktioniert's !

5

Tuesday, June 30th 2009, 3:05pm

Quoted

Original von Mr.N!ce
zustandslos
Du meinst verbindungslos :unsch
Siehe auch hier http://www.itwissen.info/definition/lexi…-Protokoll.html
Das andere war meine ich verbindungsorientiert (tcp)


Nein, ich meine zustandslos, was verbindungslos zwar mit einschließt, aber noch schärfer ist.

In einem UDP Packet gibts als Header eigentlich nur SourceIP:Port und DestinationIP:Port.

In TCP gibts aber daneben noch z.B. eine Sequenznummer und lustige weitere Sachen wie z.B. WindowsSize. Das sind Zustände mit deren Hilfe TCP zum einen die Sicherheit der Übertragung gewährleistet (Acks mit Sequenznummer zum Anzeigen, dass die Daten angekommen sind) zum anderen eine Lastkontrolle durchführt. All das bietet UDP nicht und ist daher zustandslos.
Server: Athlon II X2 250 - Asus M3N-H HDMI - 2x1GB RAM - 3TB HDDs -
1 x Digital Devices Cine S2 V6 DVB-S2 (SD Sender im Highband funktionieren mit der Karte nach wie vor unter Linux nicht, unter Windows schon)
3 x Nova Budget (die ich eigentlich durch die Cine S2 mit Erweiterungsmodul ersetzen wollte, leider aber für die SD Sender immer noch brauche)
mit yavdr 0.4.0

6

Sunday, July 12th 2009, 11:36am

Nachtrag

Seltsam: Neulich konnte ich bei einem Bekannten ein kurzes Stück von CSI Miami auf dessen SMT mit Zenslack 1.0 einwandfrei abspielen - mit UDP-Übertragung. Nur bei meiner SMT gibt es die Aussetzer.

Vielleicht gibt es ja irgendwelche Hardware-Toleranzen, sprich: Ich habe ein Montagsgerät erwischt...
Kaum macht man's richtig - schon funktioniert's !

maro1969

Intermediate

Posts: 439

Location: bei Koblenz

  • Send private message

7

Wednesday, August 5th 2009, 9:59pm

Lob, Dank und Anerkennung für den Tip!! :)
Hat geholfen.

Gruß
Martin
Hat mein Neffe abgestaubt:

Gen2VDR auf Asus M2A-VM/Sempron LE-1100 mit TT-FF und Skystar2 in Thermaltake "Mozart"

Aktuell: WIRD ERGÄNZT