Bild im Bild/PiP/Channel Mosaic? (z.B. Werbungsende sehen)

[mash4077]

Mist, da gab's doch von Euch Dev's so einen netten Aprilscherz-Thread. Ich finde den nicht mehr...

Gruß
mash

[chkbox]

Meist du den USB Thread von vor 1-2 Jahren? Finde ich auch nicht wieder... Vielleicht hat den wer wegen zu vielen Anfragen gelöscht?

[mash4077]

Den habe ich gefunden:

http://forum.tuxbox-cvs.sourceforge.net ... php?t=5606

aber da gab's auch noch einen, bei dem zum ersten Mal diese imaginäre CPU erwähnt wird...

Gruß
mash

[chkbox]

Wie arbeitet eigentlich der Demux? Kann man denn anweisen, nur eine bestimmte pid an den PPC zu senden? Dann wäre es einfacher die Daten zu rendern...

[Npq]

Hmm, ja natürlich kann man auf eine PID filtern.

Aber was nutzt das, wenn du den gesamten Videodatenstrom parsen mußt?

[chkbox]

Hab mal einen ganz groben Test gemacht:
Software-Decoder ohne Optimierung und PS-MPEG-File auf die Box kopiert. Dann in TGA Dateien umwandeln lassen. Dabei ergab sich etwa alle 10 sec ein Frame. Jetzt bleibt halt zu klären:
Wie stark lässt sich das optimieren? Was passiert wenn nur noch I-Frames decodiert werden? Wieviel einfacher/schwerer ist es, in den FB zu schreiben? Wie implementiert man TS-Streams am Besten und wo kriege ich den möglichst durch GTX/eNX aufbereitet her?

[Npq]

Das Problem ist nicht nur die Dekodierung, betrachte das Gesamtbild:

- Demux löst Interrupt aus, Kernel kopiert Daten vom Demux-RAM in den Userspace in einen Ringpuffer.
- die Anwendung muß die empfangen Daten nach I-Frames parsen
- die Anwendung muß dieses I-Frame dekodieren und nach RGB transformieren. Evtl. könnte man auf die Matrifizierung nach RGB auch verzichten und es direkt über das PIG darstellen, der GTX benutzt dafür allerdings eine komprimierte Form (squashed), der eNX könnte es wohl auch unkomprimiert.

Die Anwendung muß aber wie gesagt die Daten schneller parsen als der Ringpuffer volläuft. Natürlich könnte man während der Dekodierung den Demux abschalten und erst anschließend wieder weiterparsen.

Möglich wäre das sicherlich irgendwie. Du kannst das ja mal probieren.

Aber hierbei ging es ja auch um mehrere Ströme. Wie viele Videoströme man gleichzeitig lesen kann ohne daß es zu Overflows kommt ist mir nicht bekannt, müßtest du auch probieren.

In wie fern man den Dekodiervorgang beschleunigen könnte (Weglassen von nicht relevanten Makroblöcken) ist mir auch nicht bekannt, dafür kenne ich den Vorgang der Dekodierung zu wenig (wie ja auch aus dem anderen MPEG-Dekoder-Thread bekannt sein dürfte. ).

Eigentlich schon eine interessante Sache.

In den FB schreiben ist kein Problem, das ist ein mmap und Neutrino bietet dafür auch eine Klasse an, es muß halt nur RGB sein.

Die Frage "Wie implementiert man TS-Streams am Besten und wo kriege ich den möglichst durch GTX/eNX aufbereitet her?" versteh ich leider nicht ganz.

[rasc]

Die Anwendung muß aber wie gesagt die Daten schneller parsen als der Ringpuffer volläuft. Natürlich könnte man während der Dekodierung den Demux abschalten und erst anschließend wieder weiterparsen.

Möglich wäre das sicherlich irgendwie. Du kannst das ja mal probieren.

Aber hierbei ging es ja auch um mehrere Ströme. Wie viele Videoströme man gleichzeitig lesen kann ohne daß es zu Overflows kommt ist mir nicht bekannt, müßtest du auch probieren.

... also aus den Erfahrungen von dvbsnoop ist da schon mit einem TS mehr als "Ende Gelände"... Der Puffer ist ziemlich da schnell voll (je nach Bandbreite frueher oder spaeter).

Die einzige Möglichkeit waere, wie schon beschrieben, den DMX nach lesen von Daten deaktivieren und dann die TS-pakete parsen, den MPEG strom zusammenstellen und dann nach I-Frames parsen, gucken ob das I-Frame komplett im Datenstrom soweit drin war (wenn nicht -> Pech), dann MPEG dekodieren, Frame transkodieren und in den FB schieben. Danach kann man den DMX wieder starten und das Spiel von neuem beginnen - ggf. auf einer neuen PID.

Wenn man dann aber schon 10 Sekunden pro PID braeuchte, nur fuer die Dekodierung (ohne FB Transformationen, dann haette man bei nur 9 Mosaic-Frames im Ideal-Fall nach 90 Sekunden ein erstes vollstaendiges Mosaic-Bild...

Bei einem kleinen Bild (wegen Werbung) haette man dann halt alle ca. 10 Sekunden ein Bild...


Mhh... aber interessant waere es echt allemal (mal ne Kehrtwendung machen) ;-)

[chkbox]

Ich kenne mich leider noch nicht genau genug mit der tuxbox aus. Aber wie wäre etwas in diese Richtung: Demux / Kernel schreib ständig in den Ringpuffer und immer wenn der Decoder fertig ist, sucht er rückwärts nach dem nächsten I-Frame. Überläufe sollten dann eigenlich nicht stören...

[rasc]

... guck dir z.B. mal bei dvbsnoop das TS bzw. PES lesen an.

im Prinzip ist das nur:
- device öffnen
- PID filter setzen
- "start" sagen
- in einer Schleife lesen
- ggf. sync suchen
- TS bzw. PES header ueberlesen (ist alles in der ISO 13818-1 beschrieben)
- device schliessen

... ist alles keine Hexerei.