Streamdev und DVB-S2 Streams

Ja, wurde schon an mich herangetragen. Abgesehen von diesem Eintrag im Bugtracker ist das alles aber noch sehr nebulös. Ich selbst habe diese Effekte nicht beim Streaming von DVB-S2-Sender, bin aber noch auf vdr-1.7.2 (Server) und vdr-1.7.0 (Client).

Hallo,

ein Gedanke: Könnte man den von einem Streamdev-Client empfangenen HTTP-Stream mitschneiden, um auszuschließen, dass die Störungen auf einem Bug des Clients oder der Treibers beruhen (z. B. XBMC+VDPAU)?

Gruß
hepi

P.S.: Bzgl. der Bandbreite: Wenn ich über streamdev per 54er-WLAN den Kanal BBC-HD (DVB-S) in XBMC anschaue, habe ich auch andauernde Bildstörungen. Wenn ich es über LAN-Kabel streame, habe ich seltener (alle 15 Sekunden) ganz kurze Bildstörungen.

Zitat

Original von hepi
P.S.: Bzgl. der Bandbreite: Wenn ich über streamdev per 54er-WLAN den Kanal BBC-HD (DVB-S) in XBMC anschaue, habe ich auch andauernde Bildstörungen. Wenn ich es über LAN-Kabel streame, habe ich seltener (alle 15 Sekunden) ganz kurze Bildstörungen.

Das meinst du nicht ernst oder? 16382 kbps Videobitrate + Audio + Protokolloverhead über 54er WLAN, das ist praktisch eher nicht möglich, oder?

Zitat

Original von semerchet

Das meinst du nicht ernst oder? 16382 kbps Videobitrate + Audio + Protokolloverhead über 54er WLAN, das ist praktisch eher nicht möglich, oder?

Wenn Du schon so neugierig fragst: Das WLAN-Setup ist kein produktives Setup für HDTV. Ich nutze es nur zum Testen. Da ich vor kurzem umgezogen bin, sieht meine Wohnungsverkabelung komplett anders aus, und WLAN vereinfacht da Manches, sonst muss ich 10 Meter Kabel durch mehrere Zimmer legen. Wobei 54er-WLAN theoretisch genug Bandbreite für einen Stream mit 16382kbit Video + 256kbit Audio haben sollte, weil es eine Maximalgeschwindigkeit von 55296 kbit hat (theoretisch). Beantwortet das Deine Frage?

Zitat

Das meinst du nicht ernst oder? 16382 kbps Videobitrate + Audio + Protokolloverhead über 54er WLAN, das ist praktisch eher nicht möglich, oder?

wieso soll das nicht möglich sein

ich kann ohne probleme über wlan DiscoveryHD schauen
wenn die gesammtdatenrate nicht über 23 Mbit geht

Zitat

16382 kbps

das wäre ja noch weit darunter

streamdev-server macht einen http-port auf, den du mit dem browser ansufen kannst. da kannst dann deinen kanal aussuchen und einfach auf "speichern" klicken ...

>>>cyber

Hi,

ich habe das Problem auch mit SD-Kanälen (allerdings deutlich seltener als mit HD).

Wenn ein vdr (mit xinelibout) der Client ist, passiert es beim Schalten zwischen Kanälen in ungefähr 30-40% alle Fälle, dass es direkt danach zu Bild- und Tonstörungen kommt. Nach etwa 10 Sekunden setzt sich dann alles störungsfrei fort und es treten nur noch alle paar Minuten einmal kurze Störungen auf.

Was mir noch eingefallen ist: Mein vdr-Server ist eine Dual-Core-Maschine (4850e). Falls es sich tatsächlich um ein Multithreading-Problem handeln sollte, wäre das auf einer Dual-Core-Maschine wahrscheinlich deutlich häufiger sichtbar als auf einer Single-Core-Kiste.

Viele Grüße,
Olli

Oder so z.B.:

vlc http://192.168.1.5:3000/S19.2E-1-1107-17501.ts --sout file/ts:test.ts

Aber ich will nochmal auf das WLAN zurückkommen, bitte nicht schlagen. Dein geschildertes Problem scheint doch mit der Übertragungsrate zusammenhängen, für mich sieht es jedenfalls so aus. Gibt es keine Logfiles?

Allgemein sagt man, dass bei WLAN nur 40% der Bandbreite effektiv genutzt werden können. Die teilt sich dann noch auf mehrere Geräte auf falls vorhanden. Und diese 40% sind der Optimalfall. Wenn man dann noch Entfernung, Wände, nicht perfekte Hardware mitrechnet wird das bei BBC HD aber sehr knapp.

Also ich habe mit Streaming über WLAN vor allem Erfahrungen in einem Einfamilienhaus gesammelt und das hat erst perfekt mit Wireless N funktioniert, also 300MBit und der Möglichkeit die Bandbreite mehreren Empfängern zur Verfügung zu stellen.

Hallo,

Zitat

Original von semerchet
Dein geschildertes Problem scheint doch mit der Übertragungsrate zusammenhängen, für mich sieht es jedenfalls so aus.

Deshalb habe ich's ja beschrieben, um darauf hinzuweisen, dass auch eine unzureichende oder zumindest schwankende Bandbreite zu Problemen führen kann, auch wenn die Verbindung unter Idealbedingungen ausreichende Bandbreite böte. Als Tipp für Leute, die Streamingprobleme haben und nach Ursachen suchen.

Zitat

Original von semerchet
Gibt es keine Logfiles?

Ich habe leider nix zum Vorzeigen.

Zitat

Original von semerchet
Allgemein sagt man, dass bei WLAN nur 40% der Bandbreite effektiv genutzt werden können. Die teilt sich dann noch auf mehrere Geräte auf falls vorhanden. Und diese 40% sind der Optimalfall. Wenn man dann noch Entfernung, Wände, nicht perfekte Hardware mitrechnet wird das bei BBC HD aber sehr knapp.

Ich hatte schonmal mehrere Wochen problemlosen BBC HD Empfang mit einer älteren XBMC-Version (18xxx) über WLAN . Jetzt geht's nicht mehr so gut, kann an vielen Dingen liegen. Ja, wie ich oben schreibe ist WLAN bei mir eine provisorische Lösung. Bei einem Sonderangebot von dLan-Adaptern habe ich vor kurzem zugeschlagen und nutze jetzt so ein dLAN® 200 AVeasy Starter Kit. Damit geht's schonmal deutlich besser.

Gruß
hepi

nein, das liegt nicht am streamen bzw. der verbindung zwischen den clients, und auch nicht an den clients.

-) ich habe hier streamdev-server von e-tobi vdrdevel mit vdr 1.7.7 probiert (alles auf debian lenny und kernel 2.6.29.3 original).

-) ich habe eine DVB-C karte mit zwei HD-Sendern, beide 720p. Die Datenrate ist immer unter 2MByte/sec geblieben.

-) ich habe lokal am Rechner, wo vdr läuft, mit einem Browser den Stream gespeichert. Dann das File über das Netz gezogen --> es hat auch artefakte, wobei die HDD sicher schnell genug war.

-) ich bekomme nur auf TS daten - PS / ES bleiben dunkel. Immer wieder habe ich ein "restarting vdr" während des streamens ohne weiter meldungen im user.log - im dmesg steht hingegen folgendes:

[86890.564133] section handler[13448]: segfault at b4c49000 ip b7d31c1c sp b6fd3f5c error 6 in libc-2.7.so[b7cba000+155000]
[88163.855001] streamdev-lives[14168]: segfault at b4c21000 ip b7d26c1c sp b3fbc30c error 4 in libc-2.7.so[b7caf000+155000]
[88500.181780] section handler[14611]: segfault at b7099000 ip b7dc3c1c sp b7096f5c error 4 in libc-2.7.so[b7d4c000+155000]
[88623.481093] section handler[14814]: segfault at b6f1b000 ip b7c45c1c sp b6f18f5c error 4 in libc-2.7.so[b7bce000+155000]
[88729.954067] streamdev-lives[14892]: segfault at 878a000 ip b7c2cc1c sp b2c1c30c error 6 in libc-2.7.so[b7bb5000+155000]

kann damit jemand was anfangen?

>>>cyber

Erstmal danke für die Samples. Fehler im TS-Stream konnte ich leider bislang keine ausmachen, allerdings sind die beiden Streams grundverschieden :schiel. Aber der Reihe nach:

- Continuity Counter sind alle ok - also keine verlorenen Pakete
- Der Größenunterschied geht in Ordnung. Laut PCR-Timestamp ist die Aufnahme 27s, der Livestream nur 21s.
- Beide Streams enthalten 4 PIDs (PAT, PMT, Audio und Video). Die PID-Nummern sind erwartungsgemäß unterschiedlich, da VDR die Aufnahmen mit PIDs speichert die er sich selbst raussucht.
- Unterschiedlich ist, wie die Audio Spur übertragen wird. In den PMTs der Aufzeichnung steht Typ 0x06 (PES private), im Livestream Typ 0x81 (user private, dazu der Text AC-3)
- Die Verteilung der TS-Pakete bei denen Payload-Unit-Start gesetzt ist, unterscheiden sich stark: In der Aufzeichnung beginnt nach jeweils ca. acht Video-Paketen ein Audio-Paket. Im Livestream hingegen beginnt nach ca. zwei Video-Paketen ein neues Audio-Paket. Dazu passt, dass der Livestream rund viermal soviele Audio-Pakete enthält wie die Aufzeichnung. Offenbar fasst VDR Audio-Pakete beim Aufnehmen zu größeren Paketen zusammen... Ich dachte immer, bei TS-Aufnahmen wird der Stream quasi unverändert abgespeichert???
- Die Verteilung aller TS-Pakete nach PID ist wieder ähnlich. Bei der Aufzeichnung sind die Audio-Pakete auffällig regelmäßig in die Video-Pakete eingestreut.

Alles in allem würde ich behaupten, der TS-Stream ist ok. Ob die darin enthaltenen PES-Daten in Ordnung sind kann ich leider nicht beurteilen. Vielleicht kann sich das mal jemand anschauen, der sich damit auskennt

Zitat

Original von _akku_
Ich versteh nur Bahnhof. Heißt das, dass das Problem nicht im Streamdev ist, sondern im VDR??

Nein. Das heißt eher, dass ich keine Ahnung habe wo das Problem liegt :unsch.

Meine DVB-Kenntnisse beziehen sich in erster Linie auf TS und da ist vordergründig alles in Ordnung. Sollten die Problem irgendwo im Video-Stream selbst oder im Zusammenspiel zwischen Audio- und Video-Stream liegen, muss ich passen. Da fehlen mir die Kenntnisse bzw. kenne ich keine Tools die das Problem selbständig ermitteln könnten.

Meine Hoffnung war, dass eine TS-Aufzeichnung vom VDR weitestgehend dem entspricht, was VDR intern Receivern wie streamdev-server zur Verfügung stellt. Dem scheint aber nicht so zu sein. Von daher lassen sich die beiden Streams nicht einfach vergleichen um dann herauszufinden, welcher Unterschied das Problem verursacht.

dank eines praktikums verstehe ich recht gut was schmirl da sagt

wenn nun aber 4x soviele audio pakete im stream auftauchen, dann ist das doch ein indiz dafür dass zuwenig video pakete ankommen und somit die ruckler entstehen? einfach daher, das zuwenig video material reinkommt?

hatte bis dato aber auch immer gedacht, dass vdr nix am TS macht..

Zitat

wenn nun aber 4x soviele audio pakete im stream auftauchen, dann ist das doch ein indiz dafür dass zuwenig video pakete ankommen und somit die ruckler entstehen? einfach daher, das zuwenig video material reinkommt?

Missverständlich ausgedrückt: Die Anzahl der Audio/Video-TS-Pakete ist gleich (abgesehen von der Differenz die sich aus der unterschiedlichen Länge der Aufzeichnungen ergibt) und auch deren Verteilung. Der Unterschied betrifft die Aufteilung der Audio-Daten in PES-Pakete. Bei der VDR-Aufzeichung kommt nach ca. jedem 8. Video-PES-Paket ein neues Audio-PES-Paket. Im Livestream dagegen schon nach ca. jedem 2.. Im Livestream gibt also 4 mal so viele Audio-PES-Pakete. Da aber die Gesamtzahl der Audio-TS-Pakete gleich ist, müssen die Audio-PES-Pakete in der Aufzeichnung 4 mal so groß sein wie im Livestream.