Mist, da gab's doch von Euch Dev's so einen netten Aprilscherz-Thread. Ich finde den nicht mehr...
Gruß
mash
Bild im Bild/PiP/Channel Mosaic? (z.B. Werbungsende sehen)
-
- Erleuchteter
- Beiträge: 440
- Registriert: Samstag 10. April 2004, 15:17
-
- Tuxboxer
- Beiträge: 4654
- Registriert: Samstag 27. April 2002, 13:19
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
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
-
- Erleuchteter
- Beiträge: 440
- Registriert: Samstag 10. April 2004, 15:17
-
- Senior Member
- Beiträge: 1339
- Registriert: Donnerstag 24. April 2003, 12:12
-
- Erleuchteter
- Beiträge: 440
- Registriert: Samstag 10. April 2004, 15:17
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?
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?
-
- Senior Member
- Beiträge: 1339
- Registriert: Donnerstag 24. April 2003, 12:12
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.
- 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.
-
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
Npq hat geschrieben: 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) ;-)
-
- Erleuchteter
- Beiträge: 440
- Registriert: Samstag 10. April 2004, 15:17
-
- Senior Member
- Beiträge: 5071
- Registriert: Dienstag 18. September 2001, 00:00
... 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.
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.