Transport Stream mit WinGrabZ 0.81 aufnehmen

[slickwilly2000]

Hi

seit der Version 0.81 von Elminster soll es ja möglich sein, den Transport-Stream direkt auf die Platte zu schreiben. Doch ich find die Option nicht??

Es gibt lediglich die Funktion den Transport-Stream in einen Programm-Stream umzuwandeln! Bin ich zu blöd oder einfach nur zu blind??


wie kann ich den Transport-Stream selbst aufnehmen??

hier ein zitat von tmbinc:
>>
es bietet erstmals die funktion, einen TS in ein PS zu konvertieren.


geeignete hardware und software vorrausgesetzt, bekommt man dann wirklich NULL (!!!) resyncs (ok, beim filewechsel schon *g*)
>>



Für eine Antwort wäre ich sehr dankbar.


mfg
slickwilly2000

[Evolution100]

Hi
hier ein zitat von tmbinc:
>>
es bietet erstmals die funktion, einen TS in ein PS zu konvertieren.


geeignete hardware und software vorrausgesetzt, bekommt man dann wirklich NULL (!!!) resyncs (ok, beim filewechsel schon *g*)
>>

Ähmmm tmbinc schrieb doch konvertieren!! nicht aufnemen!!

vielleicht bin auch ich hier falsch informiert!


Evo

[Rudi Ratlos 4711]

Das setzt ja wohl erstmal voraus, daß wir einen TS überhaupt grabben können. Nachdem das AFAIK der komplette Datenstrom eines Transponders (gemuxt) ist (mit 6-8 Programmen plus Radio), werden da wohl schon 30Mbit/s Bandbreite gebraucht.

Das dürfte unsere Box nicht können. Das Statemnet bezog sich wohl auch mehr auf die Dreambox....

RR4711

[Hopper2304]

Den TS streamen geht auch mit der dbox. Allerdings muss man die PIDs auswählen, die man haben will und verschlüsselte Pakete werden nicht entschlüsselt. Ansonsten zum streamen des EPGs und der diversen DVB Tabellen und des Videotextes gehts.

wget http://dbox:31339/<PID>,<PID>,<PID>,...

Die PIDs im Format %04X (0001 0010 00EF) angeben, maximal 8 durch Komma getrennt.

Aber wie gesagt, die CAM kann die Pakete nicht entschlüsseln, da selbige vorher angezogen werden, und Playback darf nicht die zu streamende video PID / audio PID anzeigen.

Um den gesamten TS zu streamen braucht man 40 MBit/s, was auf der dbox aber nicht über ein 10 MBit/s Netzwerk gehen kann.

[slickwilly2000]

Hi

danke für die Antwort Hopper2304

Ich hab das mal versucht und geht auch wunderbar.
Aber bist du dir sicher, dass das dann der TS ist??

Das gleiche habe ich mal auf einem verschlüsselten Kanal versucht, und das geht genauso. Wenn ich den TS hinterher mit WingrabZ 0.81 in einen PS-Stream umwandel, dann geht das ganze auch. Also sind die verschlüsselten Pakete doch entschlüsselt.

Und nochwas. Selbst dort treten beim Muxen Fehler auf, was aber im Widerspruch mit der Aussage tmbinc steht:

>>
geeignete hardware und software vorrausgesetzt, bekommt man dann wirklich NULL (!!!) resyncs (ok, beim filewechsel schon *g*)
>>

Wäre klasse, wenn du Licht ins dunkle bringen würdest

Wie lautet denn die Syntax bei wget, damit das ganze in eine Datei auf der Festplatte gespeichert wird?? Ich hab bisher nur Getright dafür vergewaltigt (nicht lachen )



bye
slickwilly2000

[Hopper2304]

Also bei meinen Tests bin ich darauf gekommen, dass die Hauptursache für resyncs die dbox ist, spezieller das Programm 'streampes', dass einfach durchs Senden der Pakete an mein Notebook solange keine Pakete vom Demux empfangen kann und diese verliert. Nach Weihnachten werde ich mal versuchen, eine asynchrone Version zu erstellen, die die Pakete solange zwischencacht. Denn die dbox empfängt alle TS-Pakete fehlerfrei.

Zum entschlüsselten Stream. Gesendet werden wirklich die reinen TS-Pakete (188 Bytes jedes, signiert mit 0x47). Die CAM entschlüsselt auch nur TS-Pakete deren PID sie erhalten hat. Mehr gibt's nicht bei der Entschlüsselung. Einen TS-Stream (signiert durch eine PID), der einen Stream an Keys enthält und der eigentliche TS-Stream mit den "Nutzdaten", Video, Audio etc. An die CAM werden diese Infos gesendet und mehr ist seitens der Treiber nicht nötig. Es könnte also sein, dass die Daten doch erst nach der CAM abgezogen werden, aber die CAM teilweise nicht den Befehl zur Entschlüsselung erhalten hat. Ich werde das mal testen...

Und da wir gerade dabei sind: 'streamts' hat einen dämlichen Bug. Zur Synchronisation, um also wirklich an einem TS-Paket zu beginnen, sucht dieses nach 0x47. Das ist aber nicht gerade treffsicher. Besser wäre nach 'FF FF FF 47' zu suchen, da "halbe" Pakete mit FF aufgefüllt werden und es immer mal "halbe" Pakete gibt.