Hi,
wenn ich dann irgendwann dazu komme, werd ich ne völlige andere "Pufferstrategie" ausprobieren.
Aber weil es wegen des "WAF"-Faktors fast unmöglich ist, an der Box zu testen, kann das noch recht lange dauern.
Deshalb hier einmal die Theorie dazu, falls einer es vor mir realisieren kann (will):
1. wichtig ist die größe des DEMUX-Buffersm ! Da sollte ein relativ kleiner Wert gewählt werden (im Gegensatz zu dem wie's jetzt ist), um dem Phänomen, das PauleFoul beobachtet hat, Rechnung zu tragen -> könnte sein, daß ein
neuerwrite solange hängt bis der Puffer entgültig leer ist obwohl die Daten eigentlich sofort reinpassen würden !?
Ich rechne mal mit einer idealen Größe von 16-32 KB, die im Weiteren auch als
Segment-Größe bezeichnet werden soll, weil sie für den weiteren Verlauf eine tragende Rolle spielt.
2. Dann muß noch ein extra Thread für's Lesen (Reader) plaziert werden, wobei die Verbindung zw. ihm und dem Schreiben ins
dvr-device (Writer) über eine "Pointer-Queue" gekoppelt wird.
Die Queue hat dann 3 Level, einmal für wenn genug drin ist (high-water), dann wenn's fast zu Ende geht (low-water) und noch einen ungefähr in der Mitte oder im oberen Drittel (optimal-water).
Die Queue wird gefüttert mit Pointer auf allokierte Speicherbereiche (RAM) die genau die oben erwähnte
Segment-Größe haben !
3. Beim Startvorgang sollte der "Writer" erst mal schlafen. Der "Reader" füllt jetzt die Queue wie folgt bis zum "high-water":
-> allokiere jeweils ein Segment
-> fülle dies mit Daten via Netzwerk
-> reihe das Segment in die Queue ein
Wenn dann genug Segmente in der Queue drin sind (high), kann der Reader schlafen gehen, aber weckt vorher den Writer auf
4. Der Writer kann jezt ein Segment nach dem anderen aus der Queue holen in das dvr-device schreiben und den durch das Segment belegte Speicher wieder freigeben.
Sobald er bemerkt, daß die Queue unter den "optimal"-Level fällt, weckt er den Reader, so daß nun beide werkeln können und die Queue vor sich hin wabbert.
5. Schlafen geht der Reader also immer nur bei "high", der Writer immer nur bei "low". Für's Wecken gilt erstmal: Reader weckt Writer bei "high" (evtl. auch schon bei > "optimal") und Writer weckt Reader bei <= "optimal".
6. Beim minutenweisen Springen wird die Queue kmpl. geleert und es geht wieder los wie im "Startfall".
Die Queue-Geschichte sollte neu geproggt werden, das geht mit OO prima (evtl. mach den Code dazu demnächst), damit kein unnötiger Balast drin ist.
Die Thread Synchronistaion geht wie üblich über "Mutex" und "Conditions"...
Diese Konzept schlummert jetzt schon eine Weile in meinem Kopf, aber komme halt einfach nicht dazu, es zu realsieren - vor allem weil das Testen mit der Box wegen "WAF" unmöglich ist.
Egal wie's ausgeht, in jedem Fall hat man den Gewinn, daß der MP rechtzeitig in einen definierten Pausezustand (Bild anhalten und ne Puffern Box angzeigen) bringen kann, bis die Queue wieder einen vernünftigen Level hat.
Das geht deshalb, weil man ja über den Low-Level feststellen, kann, daß der Writer zu schnell ist. Man wählt für low am Besten 2 aus, dann kann man noch einmal in den dvr-Buffer einschreiben, bevor man dan den Demuxer/Decoder anhält, kann evtl etwas zeitkrtisch werden bei 16-32k Segmentgröße.
Aber das ist dann später sowieso experimentell festzulegen, welche Werte für das "Queue-Controlling" usw. am Besten sind
Hoffe, ich hab nix vergessen. Aber prinzipiell läuft so ne "Wabber-Queue" prima, hab da bei anderen Projekten gute Erfahrung gemacht.
na dann viel Spaß beim diskutieren !
- GMo -
. Vielleicht kannst Du Dich ja mal zu der Vermutung "konkurrierende Schreib-/Lesezugriffe mit UDP" äußern....auch wenn sie totaler Quatsch sein sollte...
