Transportstream und streamts

[tonsel]

Ich will einen Transportstream per streamts aufzeichnen, und zwar mit

wget http://box:31339/1ff,200 -O mein.ts

Zuvor habe ich auf Premiere 1 umgeschaltet.

streamts wird auf der DBox gestartet, es kommen aber keine Daten. Ich habe mit dem Quellcode etwas gespielt -> er bleibt beim ersten read() hängen. Woran kann das liegen?

Ich teste mit einer HEAD-YADD vom 13.09.2003

tonsel

[sir-zock-a-lot]

Hallo,

funktioniert bei mir mit deinem Image klaglos, allerdings nicht auf Premiere, kann ich nicht testen.
"curl" mal probiert ? Ansonsten koennte ein tcpdump bzw. der Output von "strace wget http://box:31339/1ff,200 -O mein.ts" weiterhelfen.

Gruss,
Patrick

[obi]

das geht mit den head treibern momentan nur dann, wenn
- entweder die als TS zu streamenden PIDs nicht als PES zum decoder wandern (-> playback aus oder umschalten auf benachbarten sender)
- oder die zu streamenden PIDs als TS zum decoder wandern (-> modulparameter mode=1 bei avia_gt_napi - in dem fall ist PES streamen waehrend playback nicht moeglich)

automatische umschaltung in SPTS modus bei beginn des streamens steht auf der imaginaeren TODO liste relativ weit vorn.

[tonsel]

@obi
Ohne Playback geht's jetzt!

Ich habe zwischenzeitlich die unbehandelten Daten von "dvr0" per udpstreapes in eine Datei schreiben lassen und mit einem kleinen Analyse-Programm durchgeschaut. Dabei ist mir aufgefallen, dass relative häufig (ca. 1 mal pro 50kB) Transport-Pakete fehlen (anhand des "continuity_counter" im TS-Packet-Header). Trotzdem ist nie der "transport_error_indicator" gesetzt.

Kann man daraus schließen, dass die PES-Streams aus "demux0" auch fehlerhaft wären oder ist das nur irgendein Fehler (im Chip, im Treiber, in meinem Progi??) der sich nicht auf die normalen PES-Streams auswirkt?

Gibt es irgendwo schon einen fertigen Software-Demuxer, der aus diesen Roh-Daten einen PES-Stream macht, den man mit den Daten aus "demux0" vergleichen kann? Hat das vielleicht schon mal jemand gemacht?

tonsel

[obi]

gibts regelmaessigkeiten beim ausbleiben von paketen?

[tonsel]

@obi
War ein Programm-Fehler meinerseits!

Jetzt habe festgestellt, dass immer wieder Pakete dabei sind, die nicht die korrekte Länge (188Byte) haben. Die Durchschnittslänge dieser Pakete ist aber wiederum exakt 188 Byte. Darüber hinaus beginnt das erste Video-Paket immer mit einem PES-Paket-Sync. Daraus schließe ich, dass das nicht die original-Pakete sind, die von Premiere gesendet werden.

Damit dürfte der TS-Paket-Header für Fehlererkennung nutzlos sein. Abspielen kann man diese Streams wegen der nicht normgerechten Paketlänge praktisch ebenfalls nicht

Kannst Du dass bestätigen?

tonsel

[obi]

Jetzt habe festgestellt, dass immer wieder Pakete dabei sind, die nicht die korrekte Länge (188Byte) haben. Die Durchschnittslänge dieser Pakete ist aber wiederum exakt 188 Byte.

weiss nicht ob das evtl. damit zusammenhaengt, dass video und audio im SPTS mode in der selben queue sind. probier mal die treiber von heute. wojo hat was gefixt, was in die richtung zielt.

Darüber hinaus beginnt das erste Video-Paket immer mit einem PES-Paket-Sync. Daraus schließe ich, dass das nicht die original-Pakete sind, die von Premiere gesendet werden.

meinst du PUSI? und wie kommst du zu dem schluss?

Damit dürfte der TS-Paket-Header für Fehlererkennung nutzlos sein.

was wolltest du benutzen? den TEI? der wird vom frontend oder vom sender gesetzt. ich wuesste keinen grund, wieso der demux das aendern sollte oder wieso der header dann fuer dich nutzlos sein soll

Abspielen kann man diese Streams wegen der nicht normgerechten Paketlänge praktisch ebenfalls nicht

mplayer hat sich bisher nicht sonderlich dran gestoert.

[petgun]

...probier mal die treiber von heute. wojo hat was gefixt, was in die richtung zielt...

...kannst Du nicht genauer sagen was mit diesen neuen Treibern zu erwarten ist ?

cu,
peter

[tonsel]

Ich hab' die neue Treiber gerade ausprobiert. Jetzt krieg ich beim beim Aufnehmen der Transport-Streams genau das, was ich will. Alle Pakete sind gleich lang (188 Byte) und vollzählig vorhanden.

Diese Änderung ist für das normale PES-Streamen nicht relevant!

Diese Streams werden jetzt auch von Wingrab, VLC, WindowsMediaPlayer geschluckt. Beim Ton hackt's allerdings noch.

@Obi
Die Payload des ersten Paketes eines Streams fängt immer mit

packet_start_code_prefix (00 00 01)
stream_id (e0, c0 oder bd)

an.

Das war bisher bei allen Transport-Streams so, die ich aufgenommen habe und kann wohl kein Zufall sein. Darüber hinaus war noch nie der "transport_error_indicator" gesetzt (was aber noch kommen kann). Deshalb vermute ich nach wie vor, dass das nicht die gesendeten Pakete sind. Oder hast Du dafür eine andere Erklärung?

tonsel

[obi]

@petgun:
siehe tuxbox-cvs mailing list archiv

@tonsel:
ist doch schoen, dass die pakete am anfang beginnen, oder? was will man mit nem halben? wahrscheinlich wird zurecht auf das PUSI bit gefiltert. das wird aber wohl nur so sein, wenn playback aus ist weil ansonsten kein neuer filter gesetzt wird.
wieso sollte TEI gesetzt sein? stell mal die schuessel so ein, dass die bit error rate fuenfstellig wird, vielleicht hast du dann mehr "erfolg"

[petgun]

@petgun:
siehe tuxbox-cvs mailing list archiv

....das wuerde mir selbst dann nix nuetzen, wenn C++ meine Muttersprache waere ;-)

cu,
peter

[obi]

wjoost 03/10/25 17:45:35

Modified: dvb/drivers/media/dvb/avia avia_gt_dmx.c
Log:
Fix: Only accept complete ts-packets.

englisch reicht imho. ist uebrigens kein C++ sondern C.

[petgun]

wjoost 03/10/25 17:45:35

Modified: dvb/drivers/media/dvb/avia avia_gt_dmx.c
Log:
Fix: Only accept complete ts-packets.

englisch reicht imho. ist uebrigens kein C++ sondern C.

schau jetzt wieder oefters mit rein ;-)

cu,
peter