KEINE RESYNCS mehr - die universelle Lösung?

Digital Recording
slickwilly2000
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 9. April 2002, 20:03

KEINE RESYNCS mehr - die universelle Lösung?

Beitrag von slickwilly2000 »

Hi

ich beobachte schon seit längerem die Topics mit dem Resync-Problem. So wirklich weiter kommt man aber nicht. Es sei mal dahingestellt, woran es liegt. Zudem kommt hinzu, dass sich irgendwie jeder auf den Schlips getreten fühlt, sobald einer denkt, ihm wird die Schuld in die Schuhe geschoben.

Nun aber zu meinem Problem, dass ja offensichtlich viele Leute betrifft. Bei hohen Datenraten häufen sich die Resyncs.

Ich habe mal nen ganz netten Versuch heute gemacht, den ich hier beschrieben will. Meine Freunde haben mir ihre Boxen geliehen. Es waren also insgesamt 4 Boxen (jeweils Nokia 2xIntel Kabel Avia 600 mit bmon 1.2, 4 wirklich identische Boxen). Als Referenzsender habe ich einfach PremiereSerie ausgewählt, weil hier die Datenraten nicht allzu hoch sind, ca. 2500-4000 kbit/s.
Die Netzwerkkarten waren alle die gleichen, und zwar die mit dem billig Realtek-Chip 8139 drin.
Das Ergebnis war, dass auf 3 Rechnern jeweils 1 resync drin war, nur eine Box hat alles fehlerfrei gestreamt. Programm war auf allen Rechern WingrabZ (habe also mit Neutrino gestreamt). Die Resyncs waren jeweils zu unterschiedichen Zeiten.
Das lässt für mich nur einen Schluss zu, die Box ist Schuld am Dilemma, bzw die Routinen, die verantwortlich sind, den Stream für den PC weiterzureichen. Das Kabelsignal kanns nicht gewesen sein, da ein Resync einer Box nicht gleich ein Resync auf der anderen Box verursacht (zur selben Zeit).



Es wird ja viel probiert, aber wenn ihr mich fragt, dann ist doch die einzige Lösung etwas auf der Box zu veändern. Man kann doch unendlich viel an Grab-Programmen schreiben, die aber nicht die Ursache beheben. Und die Ursache liegt doch daran, dass die Box es nicht schafft, den Stream an den PC weiterzuleiten. Gerade bei hohen Datenraten ist das der Fall. Was nützt mir ein Programm zu schreiben, wenn der Stream schon fehlerhaft ankommt.
Einzig und allein die Behandlung von auftretenden Fehlern kann variert werden. Meiner Meinung nach und das wird mir Elminster sicher bestägigen können, sind die Grab-Programme ausgereizt und an deren Limit angelangt.


Es wurde schon mal vorgeschlagen, eine asynchrone Verbindung zu realisieren. D.h. die Pakete werden auf der Box gecacht. Somit würden keine Pakete mehr verloren gehen.

Ich habe aber leider keine Ahnung von C und bin deshalb auf die Developer angewiesen. Ich bins wirlich leid mit dem Resync-Problem. Hoffentlich nimmt sich einer der Deverloper der Sache an.


Die Hardware-Resourcen der Box müssten doch denke ich ausreichen. Es sind 10mbit half-duplex. Zieht man den Peak ab, so sind es noch ca. 8mbit oder konvervativ 7mbit. Und welcher Provider sendet schon konstant über 7-8mbit? Und selbst wenn hier die Obergrenze erreicht ist, dann müssten wir uns damit abfinden das mit der dbox2 zu realisieren, denn was will man machen, wenn einem die Hardware die Grenzen aufzeigt. Es sollten dann aber wenigstens die Sender gehen, die mit niedrigerer Datenrate senden.
Oder das ganze evtl über UDP (ggrab... gruß an Menzeback :wink: ) machen...


Dann ist mir noch eine Idee eingefallen. Um die Prozessorlast zu senken und damit auch das Risiko, dass Pakete verschwinden, wäre es doch eine Überlegung Wert ein reines Stream-Image zu erstellen, welches jeglichen Schnickschnack wie Playback etc. enthält. Frage an die Developer: Wievel Prozessorlast könnte damit gesenkt werden??




So genug geschrieben, das wurde ja ein richiger Roman.
Ich hab eine einfach mal ganz neutral das beschrieben, was ich so mit dem Streamen an Erfahrungen gemacht habe. Konfigurationsprobleme schliesse ich bei MIR kategorisch aus, weil ich schon so lange und soviel ausprobiert habe und das Streamen sonst auch wirlich gut funktioniert.

Vielen Dank für evtl. Antworten schon mal im voraus
Und bitte seht das Ganze nicht als Lästerung an, sondern als konstruktiven Beitrag. Schliesslich wäre es doch ein Traum resync-frei zu streamen :P . Daher bitte ich auch nur um konstruktive Beiträge und nicht irgendwelche Problemreporte, sondern Lösungsvorschläge, dass die Pakete nicht "abhauen"



Mfg
slickwilly2000
tonsel
Erleuchteter
Erleuchteter
Beiträge: 536
Registriert: Freitag 21. September 2001, 00:00

Beitrag von tonsel »

Hallo,

zufällig arbeite ich zurzeit genau daran. Derzeitiger Stand: ich kann ORB- und MDR-Fernsehen über mehrere Stunden gleichzeitig ohne resyncs streamen (Datenrate ca. 6,5 MBit/s). Gestreamt wird per UDP in getrennte Dateien. Eine Protokoll für verlorene Pakete ist in Arbeit.

Hardware:
Nokia Kabel; 2*I; Avia 500; PC: AM6-k6-300; Linux
slickwilly2000
Interessierter
Interessierter
Beiträge: 56
Registriert: Dienstag 9. April 2002, 20:03

KEINE RESYNCS mehr - die universelle Lösung?

Beitrag von slickwilly2000 »

Hi

kannst du mir mal deine Image-Version mitteilen oder bootest du über netzwerk?? wäre nett, wenn du mir deine boxsoftware zukommen lassen würdest

und noch was, was mir gestern aufgefallen ist. beim streamen habe ich 100% prozessorauslastung, da ist es doch kein wunder, dass resyncs auftreten

mfg
slickwilly2000
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,

@slickwilly2000

> Das Kabelsignal kanns nicht gewesen sein, da ein Resync einer Box nicht gleich
> ein Resync auf der anderen Box verursacht (zur selben Zeit).

wuerde ich auch so interpretieren...

> ein reines Stream-Image zu erstellen..

eine Loesung fuer die Resyncproblematik wird sicher in alle spaeteren Images einfliessen und eine 'verschlankung' bringt imho nicht sehr viel. Playback abzuschalten bringt zB. nix (kannst Du selber testen)....es geht imho nur um die fetten Brocken bezogen auf die Prozessorlast und die sind keventd und streampes und laut den Aussagen der DEV's ist streampes schon ausgereizt und kevendt ist afaik der Event-Handler von Linux und an den traut sich so schnell sicher keiner ran...der wird auch ziemlich optimal sein.

>...die Pakete werden auf der Box gecacht.

und die willst Du dann spaeter, wenn Deine n-Stunden lange StreamingSession beendet ist, nachtraeglich uebertragen? Ich glaube nicht, dass das ein gangbarer Weg ist.

@tonsel

> ich kann ORB- und MDR-Fernsehen über mehrere Stunden gleichzeitig
> ohne resyncs streamen (Datenrate ca. 6,5 MBit/s). Gestreamt wird
> per UDP in getrennte Dateien.

das ist schon eine sehr stramme Leistung von der ich nur traeumen kann! Dafuer muss ich dann wohl auf Linux umsteigen und GGrab benutzen, oder welches Programm kann noch UDP benutzen? Unter Windoof schaffe ich es leider nicht GGrab an's rennen zu bekommen und die beschriebene erforderliche Minimalinstallation von Cygwin klappt bei mir nicht.

> Eine Protokoll für verlorene Pakete ist in Arbeit.

??? ich dachte wenn das Kind schon in den Brunnen gefallen ist, waere es fuer Rettungsversuche zu spaet...und fuer Praevention fehlt mir die technische Phantasie...kannst Du bitte mal grob beschreiben wie das funktionieren soll.

@ slickwilly2000

> was mir gestern aufgefallen ist. beim streamen habe ich 100%
> prozessorauslastung

;-) wir reden seit Wochen ueber diesen Punkt.

ich hoffe darauf, dass die Autoren der Windows-Grabprogramme eine UDP-Erweiterung fuer ihre Programme entwickeln und denke das wir Windoof-User dann da sind wo ihr Linux-User anscheinend schon seid. Auch wenn Gandalfx etwas enttaeuscht von etwa nur 8% geschrieben hat was UDP bringen soll, ist die Umstellung auf UDP aus meiner Sicht, ein sehr wichtiger Schritt in die richtige Richtung der uns alle entscheidend weiterbringt...nur noch Resyncs bei absoluten Spitzenlasten ueber 7500kbit/sec und die gibt's sehr selten oder vielleicht nie?

gruss,
peter

--
Tu erst das Notwendige, dann das Mögliche, und plötzlich schaffst Du das Unmögliche. [Franz von Assisi]
tonsel
Erleuchteter
Erleuchteter
Beiträge: 536
Registriert: Freitag 21. September 2001, 00:00

Beitrag von tonsel »

@ petgun

Ich schreibe gerade an einem eigenen Programm als Ersatz fuer den streampes auf der DBox. Auf der PC-Seite muss ich auch ein eigenes Programm benutzen, da ich eine neues Übertragungsprotokoll verwende.
Zum muxen verwende ich WingrabE - offline muxen

tonsel
Tschups
Einsteiger
Einsteiger
Beiträge: 372
Registriert: Mittwoch 6. November 2002, 09:05

Beitrag von Tschups »

@tonsel

coooollll Ein neuer Ansatzpunkt! Mit einem anderem Protokoll. Wenn ich programieren könnte würde ich auch versuchen diesen Weg zu gehen

Bin gespannt

Cu Tschups
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

Hi,

@tonsel

> Ich schreibe gerade an einem eigenen Programm als Ersatz fuer den
> streampes auf der DBox. Auf der PC-Seite muss ich auch ein eigenes
> Programm benutzen, da ich eine neues Übertragungsprotokoll verwende.

geil, hoert sich sehr interessant an!! Kannst Du mal grob skizzieren wie weit Du da gehst mit dem eigenen (Netzwerk?)Protokoll und was Du alles modifiziert/geaendert/erneuert hast...und welche Konsequenzen das fuer die 0815 Windows-User hat...wird's vielleicht spaeter einen Treiber geben oder bleibt das Deine persoenliche unikate Loesung nur fuer Linux?

> Gestreamt wird per UDP in getrennte Dateien...

getrennte Dateien halte ich sowieso fuer die beste Loesung....das klappt ja mit Wingrab/Ngrab auch, wobei allerdings beim spaeteren offline Muxen die Resyncs an den gleichen Stellen wieder entstehen, was imho an den schon fehlerhaft ankommenden Streams liegt....wie verhinderst Du das? Spezielle Paketgroesse, keine Fehlerkorrektur, kein Handshake, modifizierte Buffer in der Box, tonsel_optimized_streamprotcoll ??..sag bitte mal an wie Du das schaffst.

gruss,
peter

--
Ich habe nichts dagegen zu sterben.
Ich möchte nur nicht dabei sein, wenn's passiert.
(Woody Allen)
tonsel
Erleuchteter
Erleuchteter
Beiträge: 536
Registriert: Freitag 21. September 2001, 00:00

Beitrag von tonsel »

Gegenüber streampes gibt es folgende Änderungen:
- Das Umschalten des TV-Programmes macht udpstreampes
- dabei werden auch gleich die PID's ermittelt und an den PC geschickt
- Es läuft nur nöch ein Dämon für alle Streams, der die die Streams in einen Datenstrom multiplext
- Der Datenstrom wir per UDP übertragen (Paketgröße: MTU=1500 - 24/20 Ip-Header - 8 UDP-Header = 1468 Bytes pro Packet - die MTU kann mit ifconfig anscheinend nicht weiter erhöht werden)
- Der Datenstrom wird auf der DBox in einem Ringpuffer gespeichert, so dass fehlerhafte Pakete nochmal übertragen werden können. Die Anforderung erfolgt nur bei Bedarf, d.h. i.d.R. sehr selten
- Das Handshake (Umschalten, Aufnahemstart, Paketanforderung, Aufnahmeende) wird über einen sicheren TCP-Kanal mittels Textnachrichten realisiert.

Ich hoffe, das ich dieses Projekt über den Jahrswechsel realisieren kann. Auf der PC-Seite werde ich nur ein einfaches Empfangsprogramm für Linux schreiben. Endziel ist ein vollautomatsich DVD-RW-Videorecorder, der möglichst zuverlässig laufen soll.

Wie es scheint, kann mit obigem Ansatz das Problem "avia_gt_dmx: queue x overflow (count: 1)" (Fehlermeldung im DBox_Console Log) entgültig gelöst werden. Das Problem "schlechter Empfang" kann natürlich nur durch optimierung der Verkabelung/Antenne beseitigt werden.

tonsel
Sepp776
Semiprofi
Semiprofi
Beiträge: 1173
Registriert: Samstag 1. September 2001, 00:00

Beitrag von Sepp776 »

@tonsel: hmm, 1500 Byte ist die maximale Paketgröße eines Ethernet-Rahmens. Liegt vielleicht daran?

Hört sich super an mit der Kombination aus TCP/UDP! Klasse...

Ciao,
Sepp.
Philips Sat
Astra 19.2°
petgun
Tuxboxer
Tuxboxer
Beiträge: 5001
Registriert: Montag 11. November 2002, 15:26

Beitrag von petgun »

hi,

@tonsel

herzlichen Dank fuer die genaue Erklaerung!

> Der Datenstrom wird auf der DBox in einem Ringpuffer gespeichert, so dass
> fehlerhafte Pakete nochmal übertragen werden können. Die Anforderung erfolgt
> nur bei Bedarf, d.h. i.d.R. sehr selten

wie gross ist dieser Ringpuffer?

> Auf der PC-Seite werde ich nur ein einfaches Empfangsprogramm für Linux
> schreiben. Endziel ist ein vollautomatsich DVD-RW-Videorecorder, der
> möglichst zuverlässig laufen soll.

also eine eher traurige Nachricht fuer die Windoof-User aber fuer mich eine weitere Motivation, doch endlich mal den Schritt in Richtung Linux zu machen.

> das Problem "avia_gt_dmx: queue x overflow (count: 1)" (Fehlermeldung im
> DBox_Console Log) entgültig gelöst werden

super!...ich hoffe, der User der das hier schon vor vielen Monaten kommuniziert hat bekommt das auch mit, und ebenso, dass Deine Loesung auch allgemein Einzug in die offizielle Entwicklung findet...

Was hat von Deinen Massnahmen am meisten gebracht und wie hoch ist jetzt die maximale Datenrate, bei der Du noch fehlerfrei aufnehmen kannst?

Weiterhin viel Erfolg,
Peter

--
Um klar zu sehen, genügt oft schon ein Wechsel der Blickrichtung.
[Antoine de Saint-Exupéry]
Tschups
Einsteiger
Einsteiger
Beiträge: 372
Registriert: Mittwoch 6. November 2002, 09:05

Beitrag von Tschups »

@Tonsel

>Auf der PC-Seite werde ich nur ein einfaches Empfangsprogramm für Linux schreiben. Endziel ist ein vollautomatsich DVD-RW-Videorecorder, der möglichst zuverlässig laufen soll.

Nicht für Windoof?? :cry: :cry:

CU Tschups
tonsel
Erleuchteter
Erleuchteter
Beiträge: 536
Registriert: Freitag 21. September 2001, 00:00

Beitrag von tonsel »

@ petgun
Die maximale Dauertransferrate scheint bei ca. 9,0 MBit/s zu liegen. Mit dieser Rate konnte ich MDR, ORB und EinsMuXx gleichzeitig für 122 Sek. streamen. Danach ist der Ringpuffer übergelaufen. Die Größe dieses Puffers beträgt 10*256*1468=3670KB. Ein Vergrößerung dieses Ringpuffers bringt nichts, er wird immer nur für wenige Sekunden reichen. Er dient hautsächlich dazu kurze netzwerkseitige Einbrüche abzufangen (z.B. NFS-Zugriffe). MDR + ORB geht mit ca. 6,5 MBit/s über mehrere Stunden. Aber auch in diesem Fall scheinen die Reserven für die TV-Datenratenschwankungen nicht dauerhaft auszureichen. (Ringpuffer läuft früher oder später auch über). Für einen Sender hat man immer genügend Reserven. Die entscheidende Verbesserung scheint letztlich zu sein, dass das Lesen vom DMX und das Senden im Netzwerk asynchron erfolgt. Darüberhinaus scheint es auch von Vorteil zu sein, das nur ein Netzwerk-Sendethread vorhanden ist. Die Datenratensteigerung durch die Verwendung von UDP scheint letztlich klein gegenüber den Schwankungen der TV-Datenraten zu sein.

@Tschups
Das entscheidende Stichwort in diesem Zusamenhang lauten "vollautomatisch", dh.
- der Rechner startet zum Aufnahmezeitpunkt von selbst
- streamt,
- erzeugt das DVD-Image,
- brennt es auch DVD,
- und fährt wieder herunter.
Das läßt sich mit Linux ganz einfach realiseren. Bei Windows fehlt mir dazu schlicht das notwendige Wissen und die entsprechenden Programmiertools.

tonsel