[GELÖST] vdr-xineliboutput nach vlc: kein Ton bei http, Artefakte bei rtsp

Hallo,

Ich habe vdr mit vdr-xineliboutput auf Gentoo (kernel 2.6.18-r6) laufen. Der vdr-Rechner läuft die ganze Zeit mit 95% idle, leidet also nicht unter Überbelastung.

Ich verbinde mit vlc 0.8.6.a von Windows XP Home über WLAN mit 48Mbit/s zum vdr-Server. Der Windows-Server läuft beim vlc-Empfang mit 90% idle (vlc braucht mit deinterlacing 10%, ohne deinterlacing nur 4%). Die Übertragungsrate im Wlan bei laufendem Streaming liegt bei 3Mbit/s.

Benutze ich im vlc als Verbindungs-URL "http://<mein vdr-server>:37890 bekomme ich ein sehr gutes ruckelfreies Bild, aber keinen Ton.

Benutze ich als Verbindungs-URL "rtsp://<mein vdr-server>:37890" bekomme ich den Ton, aber das Bild hat permanent Block-Artefakte.

Der Stream ist doch aber derselbe, der da über den Port 37890 vom xineliboutput-Plugin zur Verfügung gestellt wird.

Weiß jemand, wie ich über http den Ton im vlc oder über rtsp das ganze artefakt-frei bekomme?

Den caching-Parameter habe ich schon ausprobiert (0,1200,2000), das hat aber alles keinen Unterschied gemacht.

dideldum

So, ich habe mal ein paar mehr Tests gemacht.

Wenn ich den Windows-Rechner mit 100Mbit-Ethernet-Kabel verbinde, ist die Artefakt-Bildung mit rtsp deutlich reduziert (aber nicht weg). Da könnte man schließen, dass das WLAN der Schuldige ist. Aber da vlc mit der http-url keine Artefakte hat, kann das ja eigentlich nicht sein.

Nächster Test: Auf einem Linux-Laptop (Ebenfalls Gentoo, kernel ist aber suspend2-sources 2.6.19-r2) habe ich vdr-xineliboutput installiert. Dieser Laptop hat nur eine 11Mbit-Wlan-Karte!!! Auf diesem Rechner läuft "vdr-sxfe -V xv -A arts xvdr:tcp://<mein vdr-server>:37890" völlig ruckelfrei und ohne Artefakte mit Ton. Über 11Mbit Wlan. Das Problem liegt also offenbar nur im vlc. Ich habe den vlc unter Linux nicht ausprobiert (da funktioniert das vdr-sxfe schließlich wunderbar, warum also wechseln...). Unter Windows funktioniert er jedenfalls nicht wie erwartet.

Aber vielleicht kann mir jemand von Euch ja einen Tip für den Windows-VLC geben.

Oh, das ist natürlich jetzt eigentlich das falsche Forum (schließlich ist nicht das vdr-xineliboutput-plugin das Problem). Für Hilfe wäre ich trotzdem dankbar...

dideldum

Also, jetzt habe ich den Klops schlechthin:

Wenn man eine ganz bestimmte Webseite (www.adblue.de) öffnet, dann wird der Stream im VLC plötzlich völlig ruckelfrei, und es kommen fast keine Artefakte mehr vor.

Normalerweise sah mein VLC-Meldungsfenster bei rtsp so aus:

-snip
main warning: late picture skipped (13287)
ps debug: force SCR: -32364249
main warning: late picture skipped (4544)
main warning: late picture skipped (2864)
ps debug: force SCR: -32172249
main warning: late picture skipped (23293)
main warning: late picture skipped (3323)
main warning: late picture skipped (5839)
ps debug: force SCR: -31980249
main warning: late picture skipped (4067)
main warning: late picture skipped (2275)
main warning: late picture skipped (9097)
ps debug: force SCR: -31788249
main warning: late picture skipped (7066)
main warning: late picture skipped (2451)
main warning: late picture skipped (1801)
ps debug: force SCR: -31596249
main warning: late picture skipped (5795)
main warning: late picture skipped (3898)
ps debug: force SCR: -31404249
main warning: late picture skipped (2425)
main warning: late picture skipped (8906)
main warning: late picture skipped (2980)
ps debug: force SCR: -31212249
main warning: late picture skipped (19029)
main warning: late picture skipped (5797)
ps debug: force SCR: -31020249
main warning: late picture skipped (-485)
main warning: late picture skipped (2184)
ps debug: force SCR: -30828249
main warning: late picture skipped (21523)
main warning: late picture skipped (1547)
ps debug: force SCR: -30636249
main warning: late picture skipped (128)
main warning: late picture skipped (3910)
--snip

Also unglaublich viele "late picture skipped"-Meldungen. Ich habe Bloomberg mit einer ziemlich konstanten Rate von 3Mbit/sec laufen. Die Laufschrift springt dauernd und die Artefakte kommen sehr häufig vor.

Und jetzt das Log, wenn ich im Firefox gleichzeitig die Seite www.adblue.de aufmache:

--snip
ps debug: force SCR: 97619751
ps debug: force SCR: 97811751
ps debug: force SCR: 98003751
ps debug: force SCR: 98195751
ps debug: force SCR: 98387751
ps debug: force SCR: 98579751
main warning: backward_pts != current_pts (-40000)
ps debug: force SCR: 98771751
ps debug: force SCR: 98963751
ps debug: force SCR: 99155751
ps debug: force SCR: 99347751
ps debug: force SCR: 99539751
ps debug: force SCR: 99731751
ps debug: force SCR: 99923751
ps debug: force SCR: 100115751
ps debug: force SCR: 100307751
ps debug: force SCR: 100499751
ps debug: force SCR: 100691751
ps debug: force SCR: 100883751
ps debug: force SCR: 101075751
ps debug: force SCR: 101267751
ps debug: force SCR: 101459751
ps debug: force SCR: 101651751
ps debug: force SCR: 101843751
ps debug: force SCR: 102035751
ps debug: force SCR: 102227751
ps debug: force SCR: 102419751
ps debug: force SCR: 102611751
main warning: buffer is 47188 in advance, triggering downsampling
ps debug: force SCR: 102803751
ps debug: force SCR: 102995751
--snip
ps debug: force SCR: 209939751
ps debug: force SCR: 210131751
ps debug: force SCR: 210323751
ps debug: force SCR: 210515751
ps debug: force SCR: 210707751
ps debug: force SCR: 210899751
main warning: vout synchro warning: pts != current_date (-40000)
main warning: backward_pts != dts (79989)
main warning: backward_pts != current_pts (79989)
main warning: vout synchro warning: pts != current_date (-79989)
ps debug: force SCR: 211091751
ps debug: force SCR: 211283751
ps debug: force SCR: 211475751
ps debug: force SCR: 211667751
ps debug: force SCR: 211859751
ps debug: force SCR: 212051751
ps debug: force SCR: 212243751
ps debug: force SCR: 212435751
ps debug: force SCR: 212627751
ps debug: force SCR: 212819751
ps debug: force SCR: 213011751
ps debug: force SCR: 213203751
ps debug: force SCR: 213395751
ps debug: force SCR: 213587751
ps debug: force SCR: 213779751
ps debug: force SCR: 213971751
ps debug: force SCR: 214163751
ps debug: force SCR: 214355751
ps debug: force SCR: 214547751
ps debug: force SCR: 214739751
ps debug: force SCR: 214931751
ps debug: force SCR: 215123751
ps debug: force SCR: 215315751
ps debug: force SCR: 215507751
ps debug: force SCR: 215699751
ps debug: force SCR: 215891751
ps debug: force SCR: 216083751
ps debug: force SCR: 216275751
ps debug: force SCR: 216467751
ps debug: force SCR: 216659751
ps debug: force SCR: 216851751
ps debug: force SCR: 217043751
ps debug: force SCR: 217235751
ps debug: force SCR: 217427751
ps debug: force SCR: 217619751
--snip

Überhaupt keine "late picture"-Meldungen mehr, die Laufschrift läuft ruhig wie im normalen Fernsehen. Ganz selten mal gibt es Artefakte bzw. Bildzucken (offenbar immer bei den sync-Fehlermeldungen).

WIE BITTESCHÖN KANN EINE WEBSITE DAS VERHALTEN VON VLC SO VERÄNDERN?

Hat jemand eine Idee?

dideldum

Mein Problem betrifft ja aber nicht vdr-sxfe, sondern VLC unter Windows, der über rtsp unglaublich ruckelt, weil frames verloren gehen, und über http hat er den perfekten stream, aber keinen sound. Wenn man aber die bestimmte Webseite auf Windows parallel zum VLC öffnet, kommt der rtsp-stream viel besser rüber. Trotzdem hätte ich lieber den http-stream zwischen vdr-xineliboutput und VLC, aber da ist ja kein Ton. Und genau dafür hätte ich gern eine Lösung, wenn jemand sie weiß.

Mit der neuesten Version 0.8.6c des VLC ist der Ton mit http jetzt auch da. Nachdem dieser offensichtliche Bug im VLC jetzt also behoben ist, kann ich http als Übertragung nutzen und jetzt funktioniert der WLAN-Stream vom VDR auf Linux über Fritz!Box zu Windows mit VLC einwandfrei. Sogar 7MBit/sec-Streams kommen über die WLAN-Verbindung (trotz WPA-Verschlüsselung!) einwandfrei.

Mit rtsp ruckelt es nach wie vor. Ich habe AVM darüber informiert, das Problem scheint mir in der Paket-Behandlung der Fritz!Box zu stecken.