Underrun beim Befuellen des Demux erkennen?

[jw]

Hallo!

Ich versuche mich gerade mit der Wiedergabe von Live-Streams auf def dbox (also die dbox als Streaming-client). Dabei bin ich unter anderem ueber folgendes Problem gestossen:

Die Bitrate von ARD schwankt sehr stark. Es kommt haeufig vor, dass die 10MBps, die das Netzinterface der dbox hergibt, ueberschritten werden. Wenn diese hohe Datenrate ueber laengere Zeit anhaelt, laeuft der Empfangspuffer und der Kernelpuffer leer (ist soweit logisch) und der Demuxer faengt an zu stottern (etwa jede Sekunde ein Standbild).

Das dumme ist nun, dass dieses Stottern nicht mehr aufhoert, selbst wenn die Datenrate wieder sinkt. Erst wenn das demux-device geschlossen und neu geoeffnet wird, laeuft die Wiedergabe wieder normal.

Die Frage ist nun, wie kann ich erkennen, dass dieser Puffer-Unterlauf aufgetreten ist, damit ich den demuxer schliessen und neu oeffnen kann?

[petgun]

Die Bitrate von ARD schwankt sehr stark. Es kommt haeufig vor, dass die 10MBps, die das Netzinterface der dbox hergibt, ueberschritten werden.

..so eine hohe Datenrate hatte ich noch nie. Welcher Sender der ARD soll das sein?

[jw]

Die Bitrate von ARD schwankt sehr stark. Es kommt haeufig vor, dass die 10MBps, die das Netzinterface der dbox hergibt, ueberschritten werden.

..so eine hohe Datenrate hatte ich noch nie. Welcher Sender der ARD soll das sein?

Auf Astra Program 28106. Waehrend die Durchschnittsrate normalerweise zwischen 5 und 7 MBps liegt, gibt es immer wieder Spietzen, die deutlich hoeher liegen:

Code: Alles auswählen

Nov  3 19:04:09 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3893
Nov  3 19:04:10 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3725
Nov  3 19:04:11 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3800
Nov  3 19:04:12 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3730
Nov  3 19:04:13 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3579
Nov  3 19:04:14 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3580
Nov  3 19:04:15 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3489
Nov  3 19:04:16 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3149
Nov  3 19:04:17 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3562
Nov  3 19:04:18 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3676
Nov  3 19:04:19 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 4910
Nov  3 19:04:20 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5610
Nov  3 19:04:21 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5423
Nov  3 19:04:22 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5589
Nov  3 19:04:23 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5384
Nov  3 19:04:24 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5484
Nov  3 19:04:25 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5093
Nov  3 19:04:26 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 4582
Nov  3 19:04:27 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 4920
Nov  3 19:04:28 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 4712
Nov  3 19:04:29 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5406
Nov  3 19:04:30 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5043
Nov  3 19:04:31 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5033
Nov  3 19:04:32 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 4855
Nov  3 19:04:33 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5468
Nov  3 19:04:34 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5224
Nov  3 19:04:35 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5051
Nov  3 19:04:36 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5526
Nov  3 19:04:37 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 5079
Nov  3 19:04:38 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 4346
Nov  3 19:04:39 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3839
Nov  3 19:04:40 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3522
Nov  3 19:04:41 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3890
Nov  3 19:04:42 dvb1 /usr/local/bin/dvbserver[16478]: stats:28106 3955

Die letzte Zahl einer Zeile ist die Anzahl der TS-Pakete seit der letzten Ausgabe. Nimm mal als Beispiel oben die Zeile von 19:04:20: 5610*188 ==> 1054680 Bytes in einer Sekunde.

[petgun]

Nimm mal als Beispiel oben die Zeile von 19:04:20: 5610*188 ==> 1054680 Bytes in einer Sekunde.

..aber es sind trotzdem 'nur' ca 8,4 Mbps und das haut imo auch ueber laengere Zeit mit NFS und gutem Netzwerk selbst mit der Box und dem 10MBit Nadeloehr noch hin...bei mir jedenfalls.

[jw]

Nimm mal als Beispiel oben die Zeile von 19:04:20: 5610*188 ==> 1054680 Bytes in einer Sekunde.

..aber es sind trotzdem 'nur' ca 8,4 Mbps und das haut imo auch ueber laengere Zeit mit NFS und gutem Netzwerk selbst mit der Box und dem 10MBit Nadeloehr noch hin...bei mir jedenfalls.

Aehm, diese 8.4Mbps sind _netto_. Da kommen dann noch TCP/IP/Ethernet-haeder und sonstiges low-level-Gelumpe hinzu. Die 10 bei 10BaseT gibt die Bruttorate an.

Und ich habe auch schon 5800 gesehen (den obigen Ausschnitt habe ich nur exemplarisch auf die Schnelle aus der logdatei rausgeholt).

Wie auch immer, die Diskussion geht an der Kernfrage vorbei. Die Kernfrage lautet: wie kann man feststellen, dass beim Fuettern des demux ein underflow aufgetreten ist?

[petgun]

..kann ja alles sein, aber ich habe keine 'demux underflows'....es sei denn ich versuche einen HDTV-Sender aufzunehmen. Du weisst, dass Du die Ringbuffergroesse erhoehen kannst, oder? Versuch mal 'Anzahl der Ringbuffer=80'...bei mir stehen die inzwischen wieder auf default=20 und habe seit Monaten keine Abbrueche.

Astra Program 28106

..gibt's dafuer auch einen sprechenden Namen?

[ChakaZulu]

hi,

er will nicht aufnehmen, sondern

Ich versuche mich gerade mit der Wiedergabe von Live-Streams auf def dbox (also die dbox als Streaming-client).

ciao,

ChakaZulu

[jw]

..kann ja alles sein, aber ich habe keine 'demux underflows'....es sei denn ich versuche einen HDTV-Sender aufzunehmen. Du weisst, dass Du die Ringbuffergroesse erhoehen kannst, oder? Versuch mal 'Anzahl der Ringbuffer=80'...bei mir stehen die inzwischen wieder auf default=20 und habe seit Monaten keine Abbrueche.

Wie und wo stelle ich die Ringbuffer des demux ein?

Astra Program 28106

..gibt's dafuer auch einen sprechenden Namen?

Hatte ich doch geschrieben: ARD (auch DasErste genannt). Bei anderen Programmen habe ich diesen Effekt noch nicht beobachtet.

[jw]

er will nicht aufnehmen, sondern

Ich versuche mich gerade mit der Wiedergabe von Live-Streams auf def dbox (also die dbox als Streaming-client).

Danke fuer die Klarstellung!

[PauleFoul]

ARD sendet hohe Datenraten??

Ein Wunder ist geschehen...


Gruß
____Paule

[Npq]

Moin, bei der Wiedergabe wird der Demux nicht benutzt (also die Hardware), sondern direkt über den Clipmode in den Avia geschrieben.

Dieser füllt intern einen Ratebuffer und es ist vermutlich so, daß man den nicht ungestraft leer laufen lassen darf.

Das Handling des Puffers macht die Firmware des Avia und die verhält sich nicht immer kooperativ.

Hmm, müßte man gucken, ob man diese Info da irgendwo her bekommt.

[jw]

Moin, bei der Wiedergabe wird der Demux nicht benutzt (also die Hardware), sondern direkt über den Clipmode in den Avia geschrieben.

Aha! Bedeutet das, dass es dafuer garkeinen Unterschied machen sollte ob ich ucode-0014 oder 00f0 verwende?

Dieser füllt intern einen Ratebuffer und es ist vermutlich so, daß man den nicht ungestraft leer laufen lassen darf.

Ja, das habe ich gemerkt Wie gross ist denn dieser Ratebuffer?

Das Handling des Puffers macht die Firmware des Avia und die verhält sich nicht immer kooperativ.

Hmm, müßte man gucken, ob man diese Info da irgendwo her bekommt.

In erster Naeherung wuerde es evtl reichen zu erfahren ob der Puffer im Kernel leergelaufen ist. Ich konnte aber in der DVB-API nichts finden was mir diese Information liefert.

[gmo18t]

Moin, bei der Wiedergabe wird der Demux nicht benutzt (also die Hardware), sondern direkt über den Clipmode in den Avia geschrieben.

Dieser füllt intern einen Ratebuffer und es ist vermutlich so, daß man den nicht ungestraft leer laufen lassen darf.

Das Handling des Puffers macht die Firmware des Avia und die verhält sich nicht immer kooperativ.

Hmm, müßte man gucken, ob man diese Info da irgendwo her bekommt.

bin jetzt ein wenig unsicher - ist das wirklich so ?
Bisher hab ich mich nie näher damit beschäftigt, in welchem Maße die 'Hardware'
am Demultiplexen des Streams beteiligt ist.
Der Movieplayer benutzt ja folgende Devices:

• DVR
  DEMUX (jeweils Audio und Video)
  AUDIO
  VIDEO

Jedenfalls bei aktiviertem SPTS-Mode muß das DEMUX device entsprechend konfiguriert werden, z.B. die PES-Filter für die entspr. Audio/Video pids müssen gesetzt werden ...
Und auch der "(soft)Reset" des DEMUX devices mit 'DMX_STOP/DMX_START-ioctls' hat entscheidenden Anteil daran, wenn es darum geht, eine 'stotternde' Wiedergabe zu bändigen.

Geschrieben werden die Stream-Daten dann aber auf das DVR device. Aber wie das nun intern mit dem DEMUX device genau verdrahtet ist, hab ich noch nicht recherchiert.

Nun gibt es da noch den 'DMX_SET_BUFFER_SIZE-ioctl', der (angeblich?) die Größe des Streambuffers festlegt, in den man (per DVR device) schreiben kann. Der ist offenbar fifo artig ausgelegt, d.h. man kann da solange "unblockierend" mit einer Teilmenge der eigentlichen Puffergröße drauf schreiben, bis er gefüllt ist ...

Das ist zwar so nicht im offziellen Movieplayer geproggt, aber ich nutze das Verhalten in meiner Experimentierversion schon einige Zeit mit genau darauf abgestimmtem coding:

Code: Alles auswählen

//-- device reset needs buffer refill --
if (ctx->refillBuffer) 
{
	fprintf(stderr, "[mp] buffering ... \n");
	ctx->refillBuffer = false;
	nB = ctx->nBuffers;
}	
else
	nB = 1;
				
for (int i=0; i<nB; i++)
{
	//-- read 1 packet into input buffer --
	if(ctx->isStream)
		rd = gStreamer->readStream(ctx->dvrBuf, PF_BUFBLK_SIZE, TIO_READ_DEFAULT);
	else
		rd = read(ctx->inFd, ctx->dvrBuf, PF_BUFBLK_SIZE);
					
	ctx->pos += rd;
	if(rd != PF_BUFBLK_SIZE) break;
		
	//-- transfer input buffer to demuxers queue -> this should block only as long as  -- 
	//-- the queue is full and queue processing is paused. After "softreset" the queue --
	//-- processing is paused(!), but the queue is expected to be empty at all :-)     --
	//-- In this case demuxer hast to be started again (see below).  								   -- 
	write(ctx->dvr, ctx->dvrBuf, rd);
}

//-- after "softreset" DMX devices has to be started here --
//-- to let the demuxer continue queue processing ...     --
mp_startDMX(ctx);	// starts only if stopped !
...

hier wird im Start bzw. device-reset Fall der DMX/DVR buffer mit der Gesamtgröße 'ctx->nBuffers * PF_BUFBLK_SIZE' erst mal komplett aufgefüllt, indem 'nB' auf 'ctx->nBuffers' gesetzt wird und demnach die 'for-Schleife' entsprechend oft durchlaufen wird - wohlgemerkt blockiert hierbei der write-Befehl nicht, obwohl die DEMUX devices noch "gestoppt" sind.

Danach beginnt das Abspielen durch starten (DMX_START) des DEMUX devices. Das Nachfüllen des Puffers ist nun lediglich davon abhängig, wie schnell Datenblöcke (jeweils der Größe 'PF_BUFBLK_SIZE') übers Netz gelesen werden können:

Bei niedrigen Datenraten wird der Puffer in der Regel immer voll sein, so daß sogar der write-befehl eine Zeitlang blockieren könnte (bis wieder genügend Platz im Puffer vorhanden ist).

Bei kurzzeitiger hoher Datenrate wird er mal mehr oder weniger leer werden und bei anhaltend hoher Datenrate wird er dann komplett leer laufen.

Das mit dem "Blockieren/nicht Blockieren" beim write ist für das optimale Einlesen der daten (per Netzwerk) bedeutsam -> es wird halt nur dann nix gelesen, wenn der Puffer sowieso voll ist !
Ansonsten hängt das Programm immer schön im 'read'.
deshalb ist es auch nicht erforderlich, den Lese/Schreibvorgang durch Aufteilung in verschiedene Threads voneinander zu entkoppeln.

Im offiziellen Movieplayer verhält sich der Lese/Schreibvorgang zwar im Grunde genommen genauso, nur ist das Coding in dieser Beziehung erstens (noch) nicht so übersichtlich und enthält zweitens nicht die Möglichkeit die Gesamtgröße des Puffers während der Laufzeit zu variieren: ist halt ein spezielles Feature vom streamer, der je nach Quellmaterial (z.B. in Abhängigkeit der Bitrate), vor dem Abspielbeginn eines Films einen Puffer mit einer passenden Größe durch den Movieplayer einstellen lassen kann ...

(noch ne kleine Anmerkung zwischendurch: Prinzipiell gibt's jeweils für Audio und für Video einen eigenen device-Puffer. Aber für's TS-Abspeilen wird lediglich der für Video benötigt ...)

Natürlich hab ich auch schon mit verschiedenen Größen bei diesem Puffer experimentiert (was ja mit dem streamer auch ganz einfach ist). Dabei zeigt sich - wie zu erwarten - bei großem Puffer dauert das Starten/Wiederanlaufen des Films (nach z.B. minutemweisem Springen) entsprechend länger.

Wäre die Puffergröße nun fix eingestellt, würde die Anlaufzeit bei allen Filmen, also auch bei denen mit moderaten Bitraten unnötig lange dauern -> deshalb hab ich das eben "laufzeitvariabel" gemacht.

Leider ist mir bei meinen Tests aber auch aufgefallen, daß das Vergrößern des Puffers nicht unbedingt deutliche Verbesserungen beim "Entruckeln" von Movies mit hohen Bitraten bringt, d.h. wenn die durchnittliche Rate eben mehr als 10MBit ist, kann man das Leerlaufen des Puffers logischerweise nicht verhindern, aber ...

... um wieder an die Intention dieses Postings anzuknüpfen: Wenn man feststellen könnte daß ein "Leerlaufen" droht, könnte man durch automatisches (kurzes) Pausieren den Puffer wieder nachfüllen ohne daß der Film weiterruckelt, auch wenn dann keine kritische Bitrate mehr folgt !

Nun wieder zurück zum "Demux, der beim Abspielen nicht verwendet wird": Ich hab das so in Erinnerung, daß dies nur der Fall ist beim Abspielen im "PES"-Mode !
Also wenn Audio und Video getrennt vorliegen, müssen (können) die Audio/Video Decoder devices direkt beschickt werden.
Aber im Moment bin ich mir nicht mehr so sicher (@npq) ?

- GMo -

[mash4077]

.-

[Npq]

Mit der "Hardware" meinte ich den Demultiplexer-Teil des Demux (also Ucode)

Ok, im gewissen Sinne benutzt man den Demux schon. Man schreibt die Daten ins Demux-RAM, setzt die internen Zeiger für den/die Ringpuffer (Queues) und löst damit den Transfer zwischen Demux und Avia aus.

Die Größe des Puffers für die SPTS-Daten bleibt die gleiche wie sie auch im normalen Betrieb ist. Der Wert dafür ist im Code statisch festgelegt und kann nicht on-the-fly geändert werden (den genauen Wert müßte ich nachsehen)

Es handelt sich dabei wie erwähnt um Demux-RAM und nicht um das normale RAM der Box (wird allerdings in den normalen Adressraum abgebildet).

Man schreibt also nicht wirklich direkt ins Avia-RAM, sondern über den Umweg des Demux-RAM.

Man kann die Größe der Puffer experimentell vergrößern, muß dann allerdings andere Puffer verkleinern.

[jw]

Hallo!

Als allerserstes moechte ich mich bedanken fuer die Menge an Informationen die du (und Npq) hier bringst. Es wird wohl etwas dauern, bis ich das alles verstanden und verarbeitet habe. Trotzdem moechte ich jetzt schon antworten (auch auf die Gefahr hin dass einiges von dem was ich jetzt schreibe keinen Sinn ergibt), allein um die Diskussion aufrecht zu erhalten. Fuer den Fall dass ich hier groben Unsinn schreibe, moechte ich mich schon einmal im Vorraus entschuldigen
Leider ist das Posting sehr lang geworden. Trotzdem moechte ich euch bitten es komplett zu lesen.

Moin, bei der Wiedergabe wird der Demux nicht benutzt (also die Hardware), sondern direkt über den Clipmode in den Avia geschrieben.

Dieser füllt intern einen Ratebuffer und es ist vermutlich so, daß man den nicht ungestraft leer laufen lassen darf.

Das Handling des Puffers macht die Firmware des Avia und die verhält sich nicht immer kooperativ.

Hmm, müßte man gucken, ob man diese Info da irgendwo her bekommt.

bin jetzt ein wenig unsicher - ist das wirklich so ?
Bisher hab ich mich nie näher damit beschäftigt, in welchem Maße die 'Hardware'
am Demultiplexen des Streams beteiligt ist.
Der Movieplayer benutzt ja folgende Devices:

• DVR
  DEMUX (jeweils Audio und Video)
  AUDIO
  VIDEO

Ich haette wohl erwaehnen sollen, dass ich weder neutrino noch movieplayer verwende. Hintergrund ist, dass das ein reiner Streaming-client werden soll. In den Zimmern, wo das Teil zum einsatz kommen soll ist kein Koax verlegt. Neutrino ist in diesem Fall nicht wirklich nuetzlich. Mein Ziel ist also, eine komplett eigenstaendige Applikation zu schreiben.

Jedenfalls bei aktiviertem SPTS-Mode muß das DEMUX device entsprechend konfiguriert werden, z.B. die PES-Filter für die entspr. Audio/Video pids müssen gesetzt werden ...
Und auch der "(soft)Reset" des DEMUX devices mit 'DMX_STOP/DMX_START-ioctls' hat entscheidenden Anteil daran, wenn es darum geht, eine 'stotternde' Wiedergabe zu bändigen.

Mein Vorgehen ist in Etwa so (details snipped):

Code: Alles auswählen

open_ts_stream_via_http();
start_http_reader(); /* in einem eigenen Thread */
sleep(3); /* reader thread fills 3 seconds in ringbuffer */

dvr  = open_device (DVR_NAME,   0, O_NONBLOCK | O_WRONLY);
dmxa = open_device (DEMUX_NAME, 0, O_NONBLOCK | O_RDWR);
dmxv = open_device (DEMUX_NAME, 0, O_NONBLOCK | O_RDWR);
adec = open_device (AUDIO_NAME, 0, O_NONBLOCK | O_RDWR);
vdec = open_device (VIDEO_NAME, 0, O_NONBLOCK | O_RDWR);

ioctl (vdec, VIDEO_CLEAR_BUFFER);
ioctl (adec, AUDIO_CLEAR_BUFFER);

set_demux (dmxv, vpid, DMX_PES_VIDEO);
set_demux (dmxa, apid, DMX_PES_AUDIO);

ioctl (adec, AUDIO_SET_BYPASS_MODE, ac3 ? 0UL : 1UL);

ioctl (adec, AUDIO_PLAY);
ioctl (vdec, VIDEO_PLAY);
ioctl (adec, AUDIO_SET_AV_SYNC, 1UL);
ioctl (dmxa, DMX_START);
ioctl (dmxv, DMX_START);

while (buffer_not_empty()) {
    write (dvr, blah, blah);
}

Die Frage ist nun, wo ich die DMX_STOP einbauen muss (aehm, ja. in der Schleife natuerlich ) und anhand welchen Kriteriums diese ausgefuehrt werden sollen.

Geschrieben werden die Stream-Daten dann aber auf das DVR device. Aber wie das nun intern mit dem DEMUX device genau verdrahtet ist, hab ich noch nicht recherchiert.

Da das das normale linuxtv-API ist, wuerde ich da erst einmal nicht wirklich ein Problem vermuten.

Nun gibt es da noch den 'DMX_SET_BUFFER_SIZE-ioctl', der (angeblich?) die Größe des Streambuffers festlegt, in den man (per DVR device) schreiben kann.

Vor knapp einem Jahr habe ich auf linuxtv die Info bekommen, dass dieser ioctl wohl (noch?) nicht implementiert ist. Siehe http://www.linuxtv.org/mailinglists/lin ... 00049.html

Der ist offenbar fifo artig ausgelegt, d.h. man kann da solange "unblockierend" mit einer Teilmenge der eigentlichen Puffergröße drauf schreiben, bis er gefüllt ist ...

Das ist seltsam. Wie oben zu sehen ist, oeffne ich alle devices nonblocking. Trotzdem kommt der write() erst zurueck wenn alles geschrieben wurde, selbst wenn ich mehrere megabytes zum Schreiben uebergebe.

Das ist zwar so nicht im offziellen Movieplayer geproggt, aber ich nutze das Verhalten in meiner Experimentierversion schon einige Zeit mit genau darauf abgestimmtem coding:

Code: Alles auswählen

 /* snipped */

Das mit dem "Blockieren/nicht Blockieren" beim write ist für das optimale Einlesen der daten (per Netzwerk) bedeutsam -> es wird halt nur dann nix gelesen, wenn der Puffer sowieso voll ist !
Ansonsten hängt das Programm immer schön im 'read'.
deshalb ist es auch nicht erforderlich, den Lese/Schreibvorgang durch Aufteilung in verschiedene Threads voneinander zu entkoppeln.

Mein erster Ansatz sah auch so aehnlich aus. Allerdings musste ich feststellen dass es einen _erheblichen_ Unterschied macht, ob man eine Datei via NFS oder einen live-Stream wiedergibt. Die NFS-Datei nimmt es nicht wirklich uebel wenn du mit dem read() nicht schnell genug hinterherkommst. Dann wird halt mit einigen Millisekunden Verspaetung wiedergegeben. Beim live-stream macht es aber ploetzlich einen erhebliche Unterschied. Wenn du da mit dem Lesen nicht hinterherkommst, dann muessen Daten (auf dem Server) einfach weggeschmissen werden, denn der SAT wartet nicht :-/ Beim Live-Stream hast du zu fressen was da kommt in der Geschwindigkeit wie es kommt.

BTW: Da du threads erwahnst: normalerweise meide ich Threads wie der Teufel das Weihwasser. Aber hier konnte ich erst mit threads ueberhaupt eine halbwegs brauchbare Wiedergabe zustandebringen.

Im offiziellen Movieplayer verhält sich der Lese/Schreibvorgang zwar im Grunde genommen genauso, nur ist das Coding in dieser Beziehung erstens (noch) nicht so übersichtlich und enthält zweitens nicht die Möglichkeit die Gesamtgröße des Puffers während der Laufzeit zu variieren: ist halt ein spezielles Feature vom streamer, der je nach Quellmaterial (z.B. in Abhängigkeit der Bitrate), vor dem Abspielbeginn eines Films einen Puffer mit einer passenden Größe durch den Movieplayer einstellen lassen kann ...

Hilft nicht wirklich weiter. Zum Einen ist die Bitrate, die im Stream angegeben ist meist falsch. Andererseits schwankt
die Bitrate (speziell bei ARD) erheblich. Obwohl die Durchschnittliche Rate bei 4..7 MBps liegt, kommen duchraus Spitzen oberhalb der 10MBps vor.

(noch ne kleine Anmerkung zwischendurch: Prinzipiell gibt's jeweils für Audio und für Video einen eigenen device-Puffer. Aber für's TS-Abspeilen wird lediglich der für Video benötigt ...)

Hmmm... Ich schreibe beides ins dvr device. Oder meinst du was anderes hier?

Natürlich hab ich auch schon mit verschiedenen Größen bei diesem Puffer experimentiert (was ja mit dem streamer auch ganz einfach ist). Dabei zeigt sich - wie zu erwarten - bei großem Puffer dauert das Starten/Wiederanlaufen des Films (nach z.B. minutemweisem Springen) entsprechend länger.

Kommt drauf an... Wenn man es so macht wie in meinem Beispiel oben (sleep(x)) dann ist der Anlauf immer gleich lang, ganz gleich wie gross der puffer oder die Bitrate ist. Trotzdem verwende ich einen verhaeltnissmaessig grossen Puffer (zur Zeit 8MB). Der Grund ist das dynamische Verhalten. Hier mal ein (extremes) Beispiel: Nimm mal den Fall an, dass der Puffer mit 2MByte Daten mit 2Mbps Bitrate gefuellt ist. Diese Daten abzuspielen (also den Puffer zu leeren) wird ca 8 Sekunden dauern. Wenn jetzt die Datenrate der neu ankommenden Daten (die du ja fressen musst, denn bei live-stream wartet der server nicht) sprungartig auf 10MBps ansteigt, wird zunaechst immer noch nur mit 2MBps geleert. Der Puffer muss erst einmal knapp 10Mbytes zusatezlich aufnehmen koennen. erst dann wird mit 10MBps geleert. Erst nachdem ich _disen_ Zusammenhang verstanden habe, konnte ich live-streams von ARD _halbwegs_ akzeptabel wiedergeben.

Wäre die Puffergröße nun fix eingestellt, würde die Anlaufzeit bei allen Filmen, also auch bei denen mit moderaten Bitraten unnötig lange dauern -> deshalb hab ich das eben "laufzeitvariabel" gemacht.

Aehm, IMHO bin ich ueber _diese_ Huerde schon laengst hinaus. Siehe oben.

Leider ist mir bei meinen Tests aber auch aufgefallen, daß das Vergrößern des Puffers nicht unbedingt deutliche Verbesserungen beim "Entruckeln" von Movies mit hohen Bitraten bringt, d.h. wenn die durchnittliche Rate eben mehr als 10MBit ist, kann man das Leerlaufen des Puffers logischerweise nicht verhindern, aber ...

... um wieder an die Intention dieses Postings anzuknüpfen: Wenn man feststellen könnte daß ein "Leerlaufen" droht, könnte man durch automatisches (kurzes) Pausieren den Puffer wieder nachfüllen ohne daß der Film weiterruckelt, auch wenn dann keine kritische Bitrate mehr folgt !

Ja, aber:
1. Allerste Voraussetzung ist, dass man das ueberhaupt erkennen kann.
2. Verlangsamung der Wiedergabe (entspricht deiner Idee der wiederholten kurzen Pausen) war auch meine erste Idee. Ich bin mir aber nicht sicher ob das wirklich eine gute Idee ist. Man kriegt dadurch schliesslich einen immer groesseren gap gegenueber dem originalen live-stream. Und wenn es dann (aus welchem Grund auch immer) trotzdem abreissen sollte, dann verpasst man durch diesen gap laut murphy die spannendste Szene.

Ich tendiere dazu den demuxer neu aufzusetzen, wenn man einen underrun erkennt. Aber Voraussetzung fuer jegliche Korrektur (fuer welche man sich auch immer entscheidet) ist immer noch, dass man den Underrun erkennen kann.

Nun wieder zurück zum "Demux, der beim Abspielen nicht verwendet wird": Ich hab das so in Erinnerung, daß dies nur der Fall ist beim Abspielen im "PES"-Mode !

Also ich muss ganz ehrlich gestehen, dass ich durch diese vielen Modes mehr als nur verwirrt bin. Man findet dazu immer nur bruchstueckhafte Infromationen. Schoen waere eine Zusammenfassung, welche Modes existieren und was sie bewirken.

Also wenn Audio und Video getrennt vorliegen, müssen (können) die Audio/Video Decoder devices direkt beschickt werden.

Ich kann audio/video trennen oder zusammenmuxen, wie es benoetigt wird. Damit habe ich ueberhaupt kein Problem. Das Dumme ist, dass ich nirgendwo eine Info finde, wie ich das anzuliefern habe ohne den Demuxer zu verwirren :-/

[gmo18t]

Die Größe des Puffers für die SPTS-Daten bleibt die gleiche wie sie auch im normalen Betrieb ist. Der Wert dafür ist im Code statisch festgelegt und kann nicht on-the-fly geändert werden (den genauen Wert müßte ich nachsehen)

na aber was wird dann für ein Puffer mit dem "DMX_SET_BUFFER_SIZE-ioctl" eingestellt ?
Der hat ja irgendwie schon einen Einfluß auf das Abspielverhalten.

... aber wäre nett, wenn Du die Code-Stelle mit diesem "ominösen" SPTS Puffer finden könntest. Würd ich mir gern mal ansehen, ob da noch was rauszuholen wäre (obwohl der ganze Demux Kram ist ja doch ein echtes "Biest" und leider bekommt man sowieso nie den klaren Durchblick wegen des "ucode Nirwanas" ...

- GMo -

[jw]

ARD sendet hohe Datenraten??
Ein Wunder ist geschehen...

Worauf gruendet sich denn die Weisheit die dich zu dieser Schlussfolgerung bewegt?

Da ich den ARD-Transponder komplett zerpflueckt und Gigabytes an debug-Informationen generiert (einige wenige Zeilen von diesen Gigabytes kannst du weiter oben im Thread begutachten) und ausgewertet habe, bilde ich mir ein zumindest ansatzweise zu wissen wovon ich schreibe. Es waere nett wenn du zumindest grob umreissen koenntest welche Erkenntnisse deiner obigen Weisheit zugrunde liegen.

BTW: Wenn man ueber dieses Forum quer liest, stoesst man immer wieder ueber Leute, die mit ARD Probleme haben. Bislang wurde meist gemutmasst, daas die Probleme bei den ucodes zu suchen sind. Nachdem ich mich in den letzten Wochen mit live-stream Problemen speziell bei ARD befasst habe, halte ich es nicht fuer unwahrscheinlich, dass die Probleme mit den stark schwankenden Bitraten (speziell auf ARD) zu tun haben.

[petgun]

Nachdem ich mich in den letzten Wochen mit live-stream Problemen speziell bei ARD befasst habe, halte ich es nicht fuer unwahrscheinlich, dass die Probleme mit den stark schwankenden Bitraten (speziell auf ARD) zu tun haben.

ja, die Bitraten schwanken sehr stark und oft mit hohen Spitzen, aber sie sind imo nicht so hoch, dass es mit NFS Direktaufnahme zwangslaeufig zu Abbruechen kommen muss...ich nehme auch seit Monaten fast nix anderes auf und habe keine Probleme damit. Zur Wiedergabe kann ich nix sagen da ich kein TV habe und somit den Movieplayer nicht nutze.

[jw]

ja, die Bitraten schwanken sehr stark und oft mit hohen Spitzen, aber sie sind imo nicht so hoch, dass es mit NFS Direktaufnahme zwangslaeufig zu Abbruechen kommen muss...ich nehme auch seit Monaten fast nix anderes auf und habe keine Probleme damit.

Hoffentlich nimmt es mir niemand uebel, dass ich mich wiederhole: Es macht einen grossen Unterschied ob man aufnimmt oder ob man einen live-stream wiedergibt.

Bei einer Aufnahme ist es dem NFS-Server vollkommen gleichgueltig, ob die Bits mit der korrekten Bitrate einlaufen. Der NFS-Server wartet gerne. Das ist leicht in den Griff zu kriegen, indem man auf der Sender-Seite den Puffer gross genug macht um diese Bitratenspitze zu ueberbruecken. 1MB Puffer auf der Senderseite reicht um 8 Sekunden 11MBps zu puffern. Wenn die Bitrate wieder sinkt, kann der Puffer wider _schnell_ und _vollstaendig_ geleert werden, da das Leeren des Puffers auch bei niedrigen Stream-Bitraten mit 10MBps erfolgen kann. Sinkt die Rate also auf 5MBps, kann der Puffer innerhalb von 2 Sekunden wieder vollstaendig geleert werden. Das Ganze skaliert auch wunderbar: 2MB Puffer koennen 16 Sekunden 11MBps ueberbruecken.

Bei der Wiedergabe ueber NFS sieht es aehnlich aus: Der Empfangspuffer kann mit 10MBps gefuellt werden, auch wenn die Datenrate des Streams deutlich geringer ist. Wenn also die Bitrate steigt, dann ist der Puffer normalerweise voll und kommt bei einer Spitze voll zum Tragen. Sobald die Bitrate wieder sinkt, kann er in kuerzester Zeit wieder gefuellt werden. Auch hier kann man einfach durch Vergroesserung des Puffers laengere Bitratenspitzen ueberbruecken.

Anders sieht es aus, wenn man einen Live-Stream wiedergibt. Da kann der Puffer auf der Empfangsseite nur mit der Geschwindigkeit gefuellt werden, mit der die Daten vom Satellit kommen. Will man Daten fuer 8 Sekunden im Empfangspuffer haben, dann bezahlt man das mit 8 Sekunden Warten beim Zappen! Will man Zapping-Zeiten von 1 Sekunde kann man den Puffer nur eine Sekunde lang mit der Streambitrate (die normalerweise deutlich geringer als 10MBps ist) befuellen. Und man kann den Puffer auch spaeter nicht vollmachen, da der Stream-Server die Daten eben nicht schneller liefern kann als sie vom Satelitten kommen. Man kommt also nie in den Genuss einer groesseren Datenreserve, es sei denn man akzeptiert lange zapping-Zeiten. Entsprechend gering ist also die Reserve die man fuer Bitratenspitzen zur Verfuegung hat.

[petgun]

hi,
danke, das ist jetzt mal eine Erklaerung die ich nachvollziehen kann...ich will ja hier auch nicht nerven in Deinem Thread. Natuerlich bearbeite ich auch oefters mal die Aufnahmen vom ARD-Transponder...mit ProjektX...da kommt dann zB. so was raus:

Code: Alles auswählen

.
-> Video: fr/ ct/ 1p/ cg/ og/ dg -> 47947/ 1/ 0/ 3996/ 0/ 0
-> Videolänge: 47947 Bilder in 00:31:57.880
-> GOP Zusammenfassung: min. 12, max. 36 Felder; enthält Halbbilder
-> durchschnittl. nom. Bitrate 3234926bps (min/max: 1356400/8603600)
.

..ich kann mich an keine max. Bitrate > 9500000 erinnern...und ich halte die ermittelten Werte von PX fuer richtig.

viel Erfolg,
peter

[PauleFoul]

Also ich hab ja von ARD schon einiges aufgenommen und lass die
auch immer auf Fehler und Datenraten analisieren. So hohe Werte
hab ich bei ARD noch nie gesehen. Die sind eigentlich bekannt dafür
dass die Datenraten völlig im Keller sind.
Man muss ja nur mal schauen was die alles auf einen Transponder
pressen...


Gruß
____Paule

[Npq]

na aber was wird dann für ein Puffer mit dem "DMX_SET_BUFFER_SIZE-ioctl" eingestellt ?
Der hat ja irgendwie schon einen Einfluß auf das Abspielverhalten.

Also, es gibt einen DVR-Puffer, welcher defaultmäßig auf 10*188*1024 Bytes gesetzt wird. Dieser kann nicht verändert werden, wird bei der Wiedergabe auch nicht benutzt, sondern nur bei der Aufnahme (Lesen aus DVR).

Es gibt allerdings auch einen Puffer pro (dev/demux-)Filter. Dieser kann mit dem DMX_SET_BUFFER_SIZE-ioctl geändert werden und wird per Default mit 8196 Bytes angelegt.

Wohin beim Upstream (Box->PC) geschrieben wird, wird beim Setzen des Filters festgelegt:
DMX_OUT_TAP -> demux0-Filter-Puffer
DMX_OUT_TS_TAP -> dvr-Puffer

Bei der Wiedergabe über den MPEG-Dekoder sollte das aber wie erwähnt alles keine Rolle spielen.

Ich werd' mir das aber nochmal genauer ansehen.

... aber wäre nett, wenn Du die Code-Stelle mit diesem "ominösen" SPTS Puffer finden könntest.

Da ist eigentlich nichts ominöses dran, dafür schreibt man einfach in den ersten Ringpuffer, der entweder Video- oder eben Video/Audiodaten aufnimmt.

Das eigentliche Problem dürfte allerdings das Zusammenspiel Avia-Ratebuffer/Dekoder sein. Hört sich so an, als würde der Dekoder keine Pause beim Restart einlegen (also warten bis genug Daten da sind), sondern immer wieder versuchen, zu dekodieren. Dabei läuft er dann ins Leere.

Eigentlich müßte das aber eine Rückmeldung vom Dekoder geben (Puffer leer), evtl. wird die im Treiber nicht abgefangen, hmm.

Da müßte dann ein Neustart erfolgen.

[jw]

Natuerlich bearbeite ich auch oefters mal die Aufnahmen vom ARD-Transponder...mit ProjektX...da kommt dann zB. so was raus:

Code: Alles auswählen

.
-> Video: fr/ ct/ 1p/ cg/ og/ dg -> 47947/ 1/ 0/ 3996/ 0/ 0
-> Videolänge: 47947 Bilder in 00:31:57.880
-> GOP Zusammenfassung: min. 12, max. 36 Felder; enthält Halbbilder
-> durchschnittl. nom. Bitrate 3234926bps (min/max: 1356400/8603600)
.

..ich kann mich an keine max. Bitrate > 9500000 erinnern...und ich halte die ermittelten Werte von PX fuer richtig.

Ich sehe hier keinen Widerspruch. Diese 8.6MBps sind _Netto_. Wenn man noch den Overhead fuer TCP, IP, Ether, CSMA/CD hinzunimmt, ist man sehr schnell oberhalb der 10MBps (das ist ja die Brutto-Rate).

Hinzu kommt die Frage, was du aufgezeichnet hast. Es kommt durchaus vor dass ueber viele Stunden hinweg relativ moderate Bitraten gesendet werden.

[jw]

Es gibt allerdings auch einen Puffer pro (dev/demux-)Filter. Dieser kann mit dem DMX_SET_BUFFER_SIZE-ioctl geändert werden und wird per Default mit 8196 Bytes angelegt.

Aber wieso schreibt write() trotz O_NONBLOCK die Daten immer vollstaendig hinaus selbst wenn mehr als 1MByte uebergeben werden? Da muss doch irgendwo ein grosser Puffer existieren?

Wohin beim Upstream (Box->PC) geschrieben wird, wird beim Setzen des Filters festgelegt:
DMX_OUT_TAP -> demux0-Filter-Puffer
DMX_OUT_TS_TAP -> dvr-Puffer

Leider ist das in der dvbapi nur sehr rudimentaer dokumentiert . Ich bin davon ausgegangen, dass ich zum dekodieren DMX_OUT_DECODER nehmen muss. Ist das falsch? Was sind denn die genauen Unterschiede?

Bei der Wiedergabe über den MPEG-Dekoder sollte das aber wie erwähnt alles keine Rolle spielen.

Ich werd' mir das aber nochmal genauer ansehen.

Waere toll!

... aber wäre nett, wenn Du die Code-Stelle mit diesem "ominösen" SPTS Puffer finden könntest.

Da ist eigentlich nichts ominöses dran, dafür schreibt man einfach in den ersten Ringpuffer, der entweder Video- oder eben Video/Audiodaten aufnimmt.

Das eigentliche Problem dürfte allerdings das Zusammenspiel Avia-Ratebuffer/Dekoder sein. Hört sich so an, als würde der Dekoder keine Pause beim Restart einlegen (also warten bis genug Daten da sind), sondern immer wieder versuchen, zu dekodieren. Dabei läuft er dann ins Leere.

Hmm, wird da wirklich ein Restart ausgeloest? Durch was? Watchdog?

Eigentlich müßte das aber eine Rückmeldung vom Dekoder geben (Puffer leer), evtl. wird die im Treiber nicht abgefangen, hmm.

Da müßte dann ein Neustart erfolgen.

Ich denke es wuerde Sinn machen write() einen Fehler melden zu lassen.