Live streaming von einer DBox auf ne andere

[gmo18t]

Hi,

Edit:
Da ich nur in einem Raum Kabelanschluß habe, war das Anschauen von digitalen FTA Kanälen auf einem 2ten
TV in einem anderen Raum bisher nur möglich mit Hilfe einer analogen Funkübertragung, aber mit den üblichen
Komforteinbussen.

Glücklicherweise sieht's mit der Netzwerkverkabelung besser aus - die ist in jedem Raum verfügbar .
Edit:

Deshalb hab ich mir ne 2te Box (Sagem Kabel) zugelegt, die das Anzeigen des Live-Programm übernehmen soll.
Nun leider bietet die Tuxbox-Software bisher nicht die Möglichkeit eine DBox als Live-Streaming Client für ne andere
DBox zu benutzen.

Aber dem ließ sich ja abhelfen ...

Habe zu diesem Thema den movieplayer modifiziert und eine erste Version mit folgendem Lösungsansatz erstellt:

Der Zugriff auf die Live-Daten erfolgt über die grab Schnittselle am Port 31339 (streamts) der "Server-DBox" mittels
eines per popen() gestarteten "wget -O - ..." auf der Client-DBox.

Im movieplayer werden diese Daten in eine speziellen Puffer eingelesen aus dem dann ein weiterer Thread
paralell die Daten abholt und an das DVR device weitergibt ...

Damit nun der Movieplayer weiß, welche PIDs (welchen Kanal) er streamen soll, wurde das TS Fileplayback
aufgebohrt -> Neben "plain" TS Files können nun auch spezielle Files (erkennbar durch ein magic am File-Anfang)
benutzt werden, deren Inhalt den gewünschten Server sowie die PIDs genauer spezifiziert, d.h sie entält Daten mit
denen der wget-Aufruf zur Laufzeit entsprechend zusammengestellt wird.

Also nach dem "Probing" des Input-Files wird die entsprechende Zugriffsstrategie gewählt - entweder Lesen aus
der Datei direkt oder Lesen von der popen() Pipe. Dies läßt sich mit der gleichen "Engine" lösen, da nach
dem Öffnen der Quelle das Füllen und Auslesen des Puffers in gleicher Weise erfolgen kann (macht die Sache
auch übersichtlicher).

Leider mußte der TS Fileplayback Teil im movieplayer stark umgestrickt werden, da sowohl das Füllen als auch
das Auslesen des Puffers in zwei separaten Threads mit entsprechender Synchronisation erfolgt, damit
ruckelfreies Abspielen gewährleistet ist. In diesem Zusamenhang hab ich auch erstmal das PES Abspielen abge-
zwackt.
Beim Abspielen von "plain" TS Files hat sich aber im Prinzip nix geändert, bis auf die FF und REW Funktionalität,
die noch nicht wieder implementiert ist. Pause und Springen gehen aber.

Beim Live.-Streaming sind natürlich Pause und Springen nicht möglich.

Da im Original movieplayer die Auswahl von Audiospuren ein recht neues Feature ist, hab ich das auch noch nicht
integriert ...

Für das Livestreaming wird im Normalfall nun für jeden Kanal ein entspr. File angelegt, so daß das "Zappen" über die
Home-Taste und dem Filebrowser wie üblich funktioniert. Diese Funktionalität geht dato heute schon prima
ohne Ruckeln.

Zusätzlich sollte auch das Zappen per Up/Down-Taste funktionieren, da alternativ zu je einem File pro Kanal auch
nur ein File mit einer Liste aller zu streamenden Kanäle verwendet werden kann...
Leider gibt's damit aber noch einige Probleme.

Trotzdem, die Infrastruktur dafür ist schon mal vorbereitet, was dann auch später genauso verwendet werden kann
zum Verarbeiten von "Playlisten", d.h. Files die selbst eine Liste von zu spielenden TS-Files enthalten, wobei auch
hier die Navigation per Up/down möglich wäre, bzw. das "nahtlose" Abspielen von mehreren TS-Files hintereinander ohne
Benutzereingriff.

Insgesamt hab ich aber ein paar Sachen noch nicht optimal im Griff. So reicht es für einen Kanalwechsel (Zappen)
nicht, daß ich ein neues wget nur mit anderen PIDs aufsetzte, sondern ich muß vorher auf der Server-DBox via
HTTP-Interface ein "zapto?..." auf den entspr. Kanal machen. Logisch ist das ja nur, wenn ein Kanal in einem
anderen Transponder liegt, aber bei gleichem Transponder sollte dies nicht nötig sein -> wer weiß dazu was ?

Folge davon: die Reaktion auf das "zapto?..." benötigt ein wenig Zeit, so daß der neue Kanal auf der Client-DBox
erst mehrer Sekunden verzögert gewechselt werden kann, jedenfalls laß ich den Client mit "sleep(2)" ein
wenig warten, bevor er mit dem neuen wget grab beginnt.
Oder kann ich gefahrlos sofort nach dem "zapto?..." ein grab aufsetzen ohne das die Server-DBox ins
Straucheln gerät ?

Nun, das war's erstmal was ich grob vorstellen wollte. Vielleicht hat jemand ja Interesse daran. Deshalb hier
auch die Sourcen (movieplayer.cpp/.h) für diejenigen, die sich das mal genauer anschauen wollen:
http://lvempeg.sourceforge.net/test/movieplayer-new.tar

Achso, so sollte eine Streaming File aussehen:

Code: Alles auswählen

#DBOXSTREAM X1=wget -q -O - http://192.168.xxx.xxx:31339/;0x100;0x101;0x1002300a1

die ";" sind gewollt, damit ich die Einzelteile besser trennen kann, die letzte Zahl ist die Id, die für's Zappen auf
der Server-DBox verwendet wird, also mit "wget .../control/zapto?0x1002300a1".
... und wichtig jede Zeile mit '\n' abgeschlossen.
oh je, fällt mir noch ein -> das zapto ist noch hardverdrahtet im Source. Aber das mach ich noch im Laufe
des Tages ...


- GMo -

[gagga]

Die proprietären Files mit den Magics sind noch nicht mal nötig, da man die vpid und apids problemlos aus einem TS Stream rausparsen kann (siehe find_all_avpids oder so). Siehe auch die Möglichkeit wie beim VLC die apids/vpid herausgefunden wird.

^^^
Das ist natürlich Unsinn was ich da geschrieben habe. Einfach ignorieren...

[gmo18t]

Hi,

hab das Format des livestream files abgeändert, so daß nun auch das
"zapto" dynamisch gebaut wird.

Beispiel:

Code: Alles auswählen

#DBOXSTREAM
P1=192.168.xxx.xxx;31339;0x100;0x101;0x10023001a

Kurzbeschreibung:
#DBOXSTREAM => magic zur Erkenung des Typs
P1 => Programmname (beliebig)
192.168.xxx.xxx => Server IP (oder auch Name)
31339 => Server Port auf dem streamts lauscht (dezimal)
0x100 => Video PID (hexadezimal)
0x101 => Audio PID (hexadezimal)
0x10023001a => tsid/onid/sid aus services.xml (hexadezimal)

Unter dem download link von oben steht nun die aktuelle Version, die
auch compilierbar/lauffähig ist.

- GMo -

[gmo18t]

Hi,

@gagga:
klar, aber ich brauch vpid/apid ja, um den Stream "hereinzuholen" als Argument für wget
-> zu diesem Zeitpunkt sind halt noch keine Daten da !

Falls es im ersten Moment aussieht als würde ich hier einen VLC-Ersatz basteln, so ist dies
nicht (ganz) richtig. Denn diese Lösung benötigt keinen PC-Server sondern es kommunizieren
nur zwei DBoxen miteinander. Aber falls es schon eine Lösung für mein Problem gäbe,
nur her damit ...

Sicherlich könnte man das "popen() Verfahren" auch für andere Streamingsachen verwenden,
falls z.B. irgendwann ffmpeg brauchbares TS Format liefert, könnte sowas vorstellbar sein:

Code: Alles auswählen

popen("ssh meinserver ffmpeg <quelle irgendein format> <ziel stdout im TS Foemat>");

- GMo -

[gagga]

Jo. Habe schon gemerkt, daß mein Posting Dummsinn warund habe es entsprechend editiert
Wie wäre es denn das live dbox streaming als separaten Menüpunkt zu machen und damit auch im separaten Code, so daß es keine Einschränkungen im eigentlichen TS FILE Playback gibt.

Was auch noch interessant wäre, wäre die pids direkt über das HTTP Interface der anderen Box zu erfragen. OkOk, vielleicht ein wenig oversized...

[gmo18t]

Hi,

@gagga:
wär schon prima, wenn ihr das livestreaming in den movieplayer code reinnehmen könntet,
Aber das gänzlich vom TS Playback zu trennen wäre wahrscheinlich zu ineffizient, da ja
weite Teile sowohl für "plain" TS als auch für "livestreaming" gleich sind.
Im Moment kann ich noch nicht genau sagen, wie das mit meiner Zeit hinhaut, aber
wenn ich noch ein bisschen damit rumexperimentieren, kann ich wohl die bisherige
Funktionalität des movieplayers beim TS abspielen auch abdecken.

Dann könnte man einfach mal den PES Kram ganz rauswerfen und enstprechend aufräumen
den VLC-Teil so lassen wie er ist und den TS Playback durch den neuen Code ersetzen.

Das PES Abspielen sollte man erst mal hinten anstellen und komplett neu designen.
Falls die Hardware der DBox es zuläßt, zwei getrennte PES Streams zu schlucken (geht ja
wahrscheinlich nicht inm SPTS mode, oder ?), dann könnte man einen speed optimierten
demuxer für für verschiedenen mpeg Formate machen (mein Spezialgebiet) -> vielleicht
verkraftet das die DBox-CPU ...
Die andere Variante des onthefly remuxens in TS ist sowieso viel komplizierter und ne
Nummer zu groß für die DBox (meine Meinung).

Ist jetzt mal so ne erste Idee und hängt davon ab wieweit ich meinen Code noch optimieren
kann, so daß er überhaupt ein würdiger Ersatz wäre...

Im Moment scheint es noch zu früh, um sich für die ein oder andere Lösung zu entscheiden.

- GMo -

[petgun]

@gmo18t,gagga

viel Erfolg ! Den TS-Stream auf der Box VLC-kompatibel zu machen ist wohl nicht so einfach, oder?

cu,
peter

[sanaia]

[...]nur zwei DBoxen miteinander. Aber falls es schon eine Lösung für mein Problem gäbe, nur her damit ...

karte aus der einen box rausnehmen und in die andere reinstecken ?

ansonsten - streng genommen ist das ansehen von P. auf einem anderem gerät als dem, in dem die karte steckt, illegal - noch illegaler als der empfang von P. mit neutrino sowieso schon ist - und da ist es völlig wurst wie hoch die datenmenge ist, die durchs netz geschickt werden muss, um genau das zu erreichen. Insofern glaube ich nicht, dass sich wirklich jemand hinsetzen würde um das zu implementieren - denn erstens braucht man das für FTA nicht, zweitens ist es illegal, und drittens würde man das nicht so machen

Live streaming an sich ist ja keine schlechte idee, nur von einer dbox zu einem - wie auch immer gearteten - anderen clienten, das halte ich für rechtliches sumpfland ...
Man liefert dem henker doch nicht noch den hanf, aus dem der einem dann den strick dreht ...

PS: es gibt bereits eine transparente lösung im CVS für das stream-to-file problem die ohne jegliches aufbohren funktioniert - und die steckt im MP3 player. Muss man sowas in einem programm (neutrino) denn ein halbes dutzend mal in verschiedenen versionen implementieren ? Um dem movieplayer livestreaming beizubringen reicht vermutlich ein simples

Code: Alles auswählen

#include <driver/netfile.h>

[gagga]

Nein. Reicht nicht.

[gmo18t]

Hi,

@sanaia: hab eigentlich nix Neues erfunden, sondern nur fundamentale Komponenten (Funktionen) zu einer
entsprechenden Lösung verdrahtet. Die Netzwerkkomunikation übernimmt "wget", Lesen und Schreiben wird
mit fread und fwrite gemacht.

Außerdem habe ich das Ganze so in den Movieplayer integriert, um die wesentlichen Teile zum Abspielen von
Videos mitnehmen zu können und somit meines Erachtens den maximalen Synergieeffekt erziehlt.

mit den Komponenten aus "netfile.h" müßte ich ähnlichen Aufwand betreiben ...

Eine 100%ige Adaption vom mp3 streaming ist leider aufgrund der wesentlich höheren Datenrate, die beim video-
streaming auf 10MBit adapter mit lowspeed CPU sowieso der Knackpunkt ist, nicht so einfach möglich.

Den rechtlichen Aspekt hast du korrekt erkannt. Aber da ja niemand eine solche Funktionalität braucht, wird sie
auch niemand verwenden und damit tut auch niemand was unrechtes ...

Trotzdem werd ich mein Eingangsposting ein wenig entschärfen, damit keiner auf dumme Gedanken kommt.

- GMo -

[sanaia]

@gagga: woran scheiterte es denn ? Die integration von netfile in den movieplayer stand sowieso noch auf meiner TODO liste, nur der pictureviewer steht noch davor.

Eine 100%ige Adaption vom mp3 streaming ist leider aufgrund der wesentlich höheren Datenrate, die beim video-
streaming auf 10MBit adapter mit lowspeed CPU sowieso der Knackpunkt ist, nicht möglich.

da sehe ich keinen unterschied, solange du oberhalb TCP arbeitest. Ich hole die bytes ja auch nicht mit der sandschaufel zu fuß ab. Schlimmstenfalls müsste man den ringpuffer auf ein paar MB vergrößern, das ist aber auch schon alles.

Den rechtlichen Aspekt hast du korrekt erkannt. Aber da ja niemand eine solche Funktionalität braucht, wird sie
auch niemand verwenden und damit tut auch niemand was unrechtes ...

natürlich ... und deshalb benutzt ja auch keiner die CS-technologie ...

[gagga]

Noch einen Thread benutzen nur um TS Files(!) abzuspielen ist IMHO Overhead, der unnötig ist. Wenn man das dann auch noch für PES benutzen wollte hätte man sogar mindestens zwei zusätzliche Threads. Man kann Sachen natürlich kompliziert machen, muß man aber nicht Zumal es ja keinerlei Vorteile von der Funktionalität bringt. Bitte nicht falsch verstehen: Ich finde netfile prima. Ist ja im Endeffekt genau das, was der Movieplayer für VLC playback macht. Aber halt wesentlich besser herausextrahiert Im Movieplayer kommt halt nur noch dazu, daß da noch die ganze Remote Control vom VLC dazukommt, die ja leider nicht so vollständig ist, so daß man nicht noch mehr über den VLC abwickeln könnte.

[sanaia]

Noch einen Thread benutzen nur um TS Files(!) abzuspielen ist IMHO Overhead, der unnötig ist.

netfile macht nur bei streams einen zweiten thread auf - für das stream fetching und den ringpuffer (das ist aber in der neuesten version ebenfalls abschaltbar). Lokale dateien werden mit nahezu NULL overhead bearbeitet. Lediglich der fopen() befehl braucht ein paar taktzyklen länger

Im Movieplayer kommt halt nur noch dazu, daß da noch die ganze Remote Control vom VLC dazukommt, die ja leider nicht so vollständig ist, so daß man nicht noch mehr über den VLC abwickeln könnte.

moment mal - bitte nicht alles durcheinanderbringen. Ich rede nicht davon das konstrukt movieplayer/vlc zu modifizieren, sondern lediglich davon, die funktion 'TS abspielen' netzwerkfähig zu machen. Das sind zwei verschiedene sachen. Netfile würde lediglich den TS stream alternativ von einem server, anstelle von der "lokalen" platte, abholen - nicht mehr aber auch nicht weniger.

[gmo18t]

Hi,

@sanaia: hast schon recht, könnte durchaus mit "netfile" und vergrößertem Ringpuffer gehen.

Aber hab nun eben mal in den "fremden" movieplayer code das livestreaming eingebaut und
mußte erst mal in paar Erfahrungen in Zusammenhang mit dem "Puffern" sammeln
(weil das überhaupt die entscheidende Sache ist).

Wenn ich nun noch den mir unbekannten Code von "netfile" verwendet hätte, wäre das für mich
nicht mehr überschaubar gewesen. Du kennst das viel besser und weißt dann eben schnell wo
man dran drehen kann und wo es hängen könnte ...

Auch die Verwendung von wget hab ich erst mal als Schnelleinstieg ins Auge gefasst und
durchaus offen gehalten, das durch anderes Coding zu ersetzen.

Erstaunlicherweise klappt mein erster Ansatz ja auch schon prima, lediglich mit dem Umschalten
der Kanäle auf dem Server hab ich Probleme (aber das ist ein ganz anderes Thema) ...

Außerdem hab ich bewußt in einem recht frühen Stadium gepostet, um meine Idee zur Diskussion
zu stellen. Wollte eben nur nicht mit leeren Händen dastehen und eben die Machbarkeit mit meiner
"Studie" vorführen.

Wäre also toll, wenn du demnächst auch mit "netfile" und movieplayer experimentieren könntest.
Eventuell passt der von mir modifizierte movieplayer code, um die "netfile" Funktionen mit geringem
Aufwand zu integrieren.

Hauptsache wir bekommen ne optimale Lösung für's livestreaming hin.


- GMo -

[sanaia]

ich gebe ja zu, dass meine programmiertechnik nichts für den informatikunterricht ist - zumindest nicht für das kapitel "Styleguidekonforme, saubere Hochsprachenprogrammierung"

ich werde evtl. nächste woche mal sehen, ob ich ein transportlayer für dbox streams integrieren kann. Das ist sicher kein akt, denn das lässt sich, genau wie shoutcast, einfach auf den http transportlayer 'aufpfropfen'. Ich sah nur bisher nicht die notwendigkeit das zu machen, denn mein development-rechner ist zu langsam für realtime MPEG decoding - wozu sollte ich also mir einen MPEG stream auf den holen

[gagga]

Noch einen Thread benutzen nur um TS Files(!) abzuspielen ist IMHO Overhead, der unnötig ist.

netfile macht nur bei streams einen zweiten thread auf - für das stream fetching und den ringpuffer (das ist aber in der neuesten version ebenfalls abschaltbar). Lokale dateien werden mit nahezu NULL overhead bearbeitet. Lediglich der fopen() befehl braucht ein paar taktzyklen länger

OK. Aber genau dieser eine Thread ist für Files (!) ja unnötig, da NFS ohne diesen Thread ja perfekt funktioniert. Zumal ein Transport über HTTP gegenüber NFS nur Nachteile bringt (z.B. wird man nicht spulen können, nicht jumpen können etc.). Ich fürchte ich verstehe die Zielsetzung momentan nicht so ganz. Welcher Vorteil soll mit netfile für diesen speziellen Fall eigentlich erreicht werden?

Im Movieplayer kommt halt nur noch dazu, daß da noch die ganze Remote Control vom VLC dazukommt, die ja leider nicht so vollständig ist, so daß man nicht noch mehr über den VLC abwickeln könnte.

moment mal - bitte nicht alles durcheinanderbringen. Ich rede nicht davon das konstrukt movieplayer/vlc zu modifizieren, sondern lediglich davon, die funktion 'TS abspielen' netzwerkfähig zu machen. Das sind zwei verschiedene sachen. Netfile würde lediglich den TS stream alternativ von einem server, anstelle von der "lokalen" platte, abholen - nicht mehr aber auch nicht weniger.

OK. Got it Stellt sich mir immer noch die Frage was der Vorteil von HTTP gegenüber NFS sein soll....

[sanaia]

OK. Aber genau dieser eine Thread ist für Files (!) ja unnötig,

hallo ... files werden *nicht* in mehreren threads gelesen ! Die Threadverzweigung wird *nur* bei streams gemacht - und die ist jetzt ebenfalls deaktivierbar, wenn die darüberliegende schicht entweder selber puffert oder den filedescriptor in eine externe lib weitergibt, wo sich netfile nicht dazwischenhängen kann. Der einzige "overhead", der bei lokalen files entsteht, besteht aus einer bedingten sprunganweisung.

Zumal ein Transport über HTTP gegenüber NFS nur Nachteile bringt (z.B. wird man nicht spulen können, nicht jumpen können etc.).

Deswegen steht es ja auch nicht ganz oben auf der prioritätenliste.

Ich fürchte ich verstehe die Zielsetzung momentan nicht so ganz. Welcher Vorteil soll mit netfile für diesen speziellen Fall eigentlich erreicht werden?

direktes abspielen eines TS-streams von einem HTTP-server - oder einer anderen dbox.

[gagga]

OK. Got it. Diesmal wirklich!

[gmo18t]

Hi,

hab jetzt mal einen neuen modifizierten movieplayer release 1.92 (!) hier
(http://lvempeg.sourceforge.net/test/mp-192.tar)
als Source zum Download bereitgestellt.

Der hat folgende Features

- live streaming per description file mit magic #DBOXSTREAM (wie bereits beschrieben)

- playlist per description file mit magic #DBOXPLAYLST, zum Beispiel File mit folgendem Inhalt:

Code: Alles auswählen

#DBOXPLAYLST
/mnt/filme/movie1.ts
/mnt/filme/subdir/movie2.ts
...

- next/previous per up/down Taste, wenn Playlist

- automatisches Abspielen vom nächsten TS-file nach beenden des aktuellen TS-files, wenn Playlist

- Pause und minutenweise springen (nicht im live streaming)

- beim vor/rückspringen wird die Filegrenze geprüft, d.h. kein Beenden mehr beim "zu weit springen".

- Auswahl der Audiospur nachgezogen

Hab das bis jetzt nur auf meinem Simulator getestet, heut Abend test ich auf der DBox
(compilieren läßt's sich jedenfalls).

- GMo -

[sanaia]

@gagga: ich weiss jetzt, weshalb es nicht ging: es geht deshalb nicht, weil der movieplayer open/read/close verwendet, netfile sich aber nur zwischen fopen/fread/fclose und das OS schiebt.

[gmo18t]

Hi,

getestete und fehlerbereinigte Version des modifizierten
movieplayers (1.92) hier:
http://lvempeg.sourceforge.net/test/mp-192.tar

- GMo -

[gmo18t]

Hi,

hatte bisher immer beim minutenweise Springen ab und zu "Schwarzbild" (ist auch beim Original movieplayer so).
Deshalb hab ich in den letzten Tagen ein wenig im Code rumexperimentiert, um dies abzustellen.
Auf meiner Sagem 1xI AVIA600 kommt nun kein Schwarzbild" mehr nach dem Springen ...
(compiliert auf CVS Stand 31.05.2004)

Grundsätzlich hab ich das mit folgender Codesequenz erreicht:

Code: Alles auswählen

...
ioctl(ctx->vdec, VIDEO_FREEZE);
ioctl(ctx->adec, AUDIO_PAUSE);

// warten bis write() auf DVR device beendet
while (ctx->isWriting) usleep(10000);

...
// hier dann seek oder pause oder sonstwas 
// Videodaten Puffer leeren (einfach Flag auf empty)
...

//-- stop DMX devices --
ioctl(ctx->dmxv, DMX_STOP);
ioctl(ctx->dmxa, DMX_STOP);

//-- stop AV devices --
ioctl(ctx->vdec, VIDEO_STOP);
ioctl(ctx->adec, AUDIO_STOP);

//-- setup DMX devices (again) --
ctx->p.input    = DMX_IN_DVR;
ctx->p.output   = DMX_OUT_DECODER;
ctx->p.flags    = 0; //DMX_IMMEDIATE_START;

ctx->p.pid      = ctx->pida;
ctx->p.pes_type = DMX_PES_AUDIO;
ioctl (ctx->dmxa, DMX_SET_PES_FILTER, &(ctx->p));

ctx->p.pid      = ctx->pidv;
ctx->p.pes_type = DMX_PES_VIDEO;
ioctl (ctx->dmxv, DMX_SET_PES_FILTER, &(ctx->p));

//-- start AV devices again --
if (ctx->ac3 == 1)
    ioctl(ctx->adec, AUDIO_SET_BYPASS_MODE,0UL);
else
    ioctl(ctx->adec, AUDIO_SET_BYPASS_MODE,1UL);

ioctl(ctx->adec, AUDIO_PLAY);             // audio
ioctl(ctx->vdec, VIDEO_PLAY);             // video
ioctl(ctx->adec, AUDIO_SET_AV_SYNC, 1UL);   // needs sync again !!!

...
//-- Videodaten Puffer füllen (dauert ein wenig) --
... 

//-- und dann kurz vor dem write() ins DVR: -- 
ioctl(ctx->dmxa, DMX_START);  // audio first !
ioctl(ctx->dmxv, DMX_START);

die aktuellen modif. files (movieplayer.cpp/h) können vom Download, siehe vorheriges Posting,
gezogen werden.

Soweit ich das mit den DVB Devices nun überschauen kann, ist das richtige Timing und die
korrekte Befehlssequenz entscheidend für den sauberen (Neu-)Analuf des Videos.
Vielleicht kann man das auch noch weiter optimieren.

Falls ich da noch irgendwelche Denkfehler drin hab o.ä. bitte melden ...

Weiterhin hab ich noch einen einfachen "parental control" Mechanismus für den Movieplayer
eingebaut, weil Kinder ...

Dazu hab ich einfach den Einsprungpunkt "PES Video abspielen (experimentell)" benutzt,
damit man einen 4stelligen Code per RC eingeben kann. Wenn dieser mit der Referenz
ausgelesen aus "/var/tuxbox/config/mpcode" übereinstimmt wird einfach weiter zur
Funktion "TS File abspielen" gesprungen aber mit gesetztem "parental"-Flag (eine direkte
Auswahl des Menüpunkts "TS File abspielen" ruft die Player Funktion mit gelöschtem
Flag auf).

In der Player Funktion wird dann ein benutzer definierbares Script ("/var/bin/parental.sh")
mit eben diesem Flag als Argument aufgerufen. Dort kann man dann entscheiden, was zu tun ist ...
In meinem Fall hab ich einfach ein mount/unmount auf ein NFS Share gemacht, welches
die FSK > 12 Filme enthält.

Ach so, falls das Videospielen mal hängt oder aus irgendeinem Grund (beim Livestream)
A/V asynchron wird. Kann mit RC Taste "0" ein Softreset ausgelöst werden.

... und was ich noch wissen wollte: hat schon mal jemand den modifizierten movieplayer-code
ausprobiert und wenn ja, welche Erfahrungen gemacht ?


- GMo -

[Soli]

@gmo18t

Habe das mal eingebaut und es funktioniert

Theoretisch/Praktisch kann man auf der Server Box ein anderes Programm schauen wenn es auf dem gleichen Transponder liegt!

Was aber schlecht ist, wenn der stream abbricht, lässt sich die Clientbox nicht mehr bedienen. Vielleicht hast du da noch ne Idee ?

Aber ansonsten super Funktion!..danke

[gmo18t]

Hi,

@Soli:
leider hat das busybox-"wget" keine Möglichkeit nen (venünftigen) timeout zu setzten, d.h eine fread()
kann u.U. hängen bleiben.
Weitere Ursache könnte der reader thread sein, wenn er auf sein "condition" wartet, aber das könnte man
mit pthread_cond_timedwait() lösen.

Wie kommt es bei dir dazu, daß der Stream abbricht ohne "broken pipe", wodurch ja wget auch beendet
würde ?

- GMo -

[Soli]

@gmo18t

wenn man auf der Serverbox ausversehen umschaltet
Aber wenn man auf der Clientbox etwas wartet...kann man wieder die Box bedienen.
Ich habe leider programmiertechnisch wenig ahnung..trotzdem könnte ich mir vorstellen diese Livestreaming Funktion selber öfters zu nutzen.
Du liest bisher die Audio/VideoPids aus der Datei aus. Falls sich die aber bei Sendern ändern kann, müsste man diese immer manuell pflegen ?

Kann die Clientbox nicht die Serverbox fragen wie Audio/VideoPID ist ?
ala http://dbox/control/zapto?getpids

Das man im Prinzip nur die Serverbox mit IP und die KanalNummer oder Name angeben muss.

Praktische Nutzung einer Kabelbox in einen Haushalt ohne Kabelanschluss. Die Box kommt ins Kinderzimmer und darf sich den Videostream zb von einer Wohnzimmerbox oder Schlafzimmerbox holen. Man legt auf der Clientbox ne Art Streamliste an (SuperRTL, Kika ) und die Streams kann man sich dann holen.
Und geht wirklich gut


Kann man eigentlich mehrere Sender in diese Datei reinschreiben und dann per Auswahl auswählen, oder wie bisher je Sender eine Datei mit den entsprechenden Pids und Daten ?