DVB-Mplex

Hi Frockert

Zitat

Ich möchte Filme im Mpeg2-Format, gestreamt von der Dbox2, in ein TS-Format umwandeln.

So kann/könnte ich sie anschließend wieder über die Dbox abspielen.

Die erstens Tests habe ich mit DVB-Mplex gemacht.

Du benötigst nicht dvb-mplex, sondern wahrscheinliche pes2ts aus den dvb-mpegtools. Ein "normales" MPEG-File ist meist ein PES-File, pes2ts "sollte" einen Transportstream daraus machen.

Ich habe das allerdings noch nie genutzt, also kann ich Dir leider keine weiteren Tips geben.

cheers
doc

Hi Frockert, so trifft man sich wieder!
Habe gerade gemerkt, dass dieser Thread nicht mehr ganz so taufrisch ist wie ich im ersten Augenblick dachte. Ich versuche gerade VDR-Files auf meiner DBox abzuspielen und muss daher TS-Files erzeugen.
Hast du noch einige Erfahrungen mit dem Tool 'pes2ts' machen können? Konkret: Kann man damit auch VDR-Files (das sind glaub ich im Prinzip PS-Files) reingeben und bekommt TS raus? Der Neutrinoplayer spielt TS-Files ja inzwischen problemlos ab. Ich habe erst seit ca. zwei Wochen ne DBox und kenne daher die alten Probleme nicht.

Gruß
jarny

Zitat

Original von jarny
Ich versuche gerade VDR-Files auf meiner DBox abzuspielen und muss daher TS-Files erzeugen.
Hast du noch einige Erfahrungen mit dem Tool 'pes2ts' machen können? Konkret: Kann man damit auch VDR-Files (das sind glaub ich im Prinzip PS-Files) reingeben und bekommt TS raus? Der Neutrinoplayer spielt TS-Files ja inzwischen problemlos ab. Ich habe erst seit ca. zwei Wochen ne DBox und kenne daher die alten Probleme nicht.

Wie weit bist Du gekommen, und mit welcher Software?

Nur in relativ alter Fassung konnte ich http://www.linuxtv.org/cgi-bin…mpegtools/Attic/mpegtools finden (darin wohl PES2TS2 für Audio+Video).

Dort gibt es allerdings auch http://www.linuxtv.org/multiplexer/, was ganz nach dem benötigten on-the-fly-Transcoder von PES (.vdr) nach TS (Streaming-Receiver) aussieht - schon irgendwelche Erfahrungen bzgl. der Systemanforderungen?

Zitat

• output is either a transport stream or a program stream
• input streams may be program streams, paketized elementary streams (PES) and transport stream, in any combination
• streams are kept in sync during multiplex, where possible
• normal real time operation obeys stream timing

Unter http://www.linuxtv.org/mailing…004/02-2004/msg00700.html übrigens folgende Ausführungen direkt von kls zum Thema:

Zitat

> There has already been the move from AV_PES to PES in the past.

AV_PES was a proprietary, non standard format, so changing that was certainly
right. PES on the other hand is AFAIK the recommended format for _storing_
recordings, while TS is the format for _broadcasting_.

> I wonder how Klaus would feel about that?

Changing VDR's recording format to TS is not going to happen.

Alles anzeigen

Hi TEN
Ich hab die Sache mit dem TS-File abspielen auf der DBox einschlafen lassen. Sorry! Im Moment spiele ich bisschen rum wie man mit der DBox per FTP auf einen anderen Rechner (wo ein FTP-Server läuft) streamen kann. Funktioniert im Moment ziemlich gut, hat aber mit dem Thema hier nichts zu tun.
Wenn ich im Februar mehr Zeit haben sollte geh ich vielleicht auch wieder an die Sache ran. Bitte poste hier wenn du irgendwas hinbekommen hast.

Gruß
Jarny

Der Vollständigkeit halber für die nächsten :sucheden ein paar (größtenteils selbsterklärende) Links:
http://www.vdr-wiki.de/wiki/index.php/DBox2
http://www.wurch.de/archives/2004/05/18/nfs-in-linvdr/

Aktuelle dvb-mpegtools - pes2ts[2]:
http://www.metzlerbros.org/dvb/ - zuletzt "LIBDVB 0.5.5 (update 15 September 2004)"
Nach Kompilierung und Installation des kompletten Pakets mit einem Testclip durchgeführte

pes2ts2 /video0/heute_nacht/2004-10-06.23.35.99.99.rec/001.vdr/001.vdr 110 120 > heute2.TS
pes2ts /video0/heute_nacht/2004-10-06.23.35.99.99.rec/001.vdr/001.vdr > heute.TS

waren weder mit der dbox2 noch mit mplayer -vo mpegpes oder xine abspielbar (nur einzelne Bilder und Tonfetzen)...

Für "on-the-fly" übrigens keine Chance, die Konvertierung benötigt jeweils ein Mehrfaches der Laufzeit...

Mit ProjectX muß ich es auf einer anderen (schnelleren) Maschine noch einmal versuchen.

Nun also auch die Erfahrungen mit dem (hier noch nicht ganz rund laufenden) ProjectX:

Die gute Nachricht: Es funktioniert - selbst ZDF-Aufnahmen, deren astronomisch hohe Datenraten sich mit Protokoll-Overhead schon dem 5-Mbit/s-Limit der dbox2-Ethernet-Anbindung nähern, sind von einem per NFS freigegebenen Verzeichnis problemlos abspielbar; Bild und Ton scheinen synchron; auch 10-Sekunden-Sprünge ("Spulen" des dbox2-TS-Movieplayers) funktionieren im Rahmen des Möglichen - nach ein paar Rucklern fängt sich das Bild dann wieder.

Die schlechte Nachricht: Jedenfalls wenn man des WAFs wegen kein Gigahertz-Monster ins Wohnzimmer bringen kann, dauert die Konvertierung von PES nach TS mehr als nur lange ... z.B. bei 400 MHz benötigen 60 Filmminuten (2 GB) ca. 24 Stunden! Falls niemand einen schnelleren funktionierenden Konverter findet, ist der Preis einer unhörbaren dbox im Wohnzimmer also ein "aufgemotzter" Server an anderer (hoffentlich schalldichter und gut gekühlter) Stelle im heimischen Netzwerk - und eine Echtzeitkonvertierung dürfte mit diesem Code selbst bei 3 GHz nicht in Betracht kommen. Sieht so aus, als muß diese Routinen dringend mal jemand von Java nach Assembler portieren... Freiwillige vor!

Hi TEN,

zu deiner schlechten Nachricht: irgendetwas scheint bei dir noch falsch zu laufen. Bei mir läuft ProjectX auf einem PIII 350 und kodiert die PES->TS recht flott um, die Zeiten habe ich noch nicht gemessen (aber auf meinem 1GHz Rechner ist er definitiv schneller als Echtzeit und beim PIII 350 ist er nicht (sehr) viel langsamer). Allerdings benutze ich noch Java 1.4 (für Linux), dass sollte aber auch nicht das Problem sein.

Mit welchen Parametern rufst du ProjectX auf?
und welche Version hast du laufen?

ciao
DonMarti

Zitat

Original von DonMarti
[...]Bei mir läuft ProjectX auf einem PIII 350 und kodiert die PES->TS recht flott um, die Zeiten habe ich noch nicht gemessen (aber auf meinem 1GHz Rechner ist er definitiv schneller als Echtzeit und beim PIII 350 ist er nicht (sehr) viel langsamer). Allerdings benutze ich noch Java 1.4 (für Linux), dass sollte aber auch nicht das Problem sein.

Dem kann ich mich anschließen: 400MHz Maschine, Java 1.3, ProjectX braucht etwa 10 Min. für 3 GB. Allerdings habe ich dieselben Fehlermeldungen beim Starten wie TEN & etwa jedes fünfte Mal wird die GUI nicht gezeichnet.

Zitat

Original von metahawk

Dem kann ich mich anschließen: 400MHz Maschine, Java 1.3, ProjectX braucht etwa 10 Min. für 3 GB. Allerdings habe ich dieselben Fehlermeldungen beim Starten wie TEN & etwa jedes fünfte Mal wird die GUI nicht gezeichnet.

Zur Schande meines PCs muß ich gestehen, daß das wirklich noch ein K6-II@400MHz ist - vermutlich wäre Pentium-III das Minimum moderner Optimierungen... kann also gut sein, daß es schon deshalb auf dieser Maschine ineffizient ist (zu kleine Caches etc.) - vor allem, wenn die Quelldateien vom Netzwerk kommen (das hat zwar jede Menge Reserven, aber so laufen eben alle Daten von der Java-VM bis zu SMB/NFS quer durch alle Interfaces und Protokollschichten).
Vor wenigen Stunden ist ProjectX-v0.82.0.01-20050116.zip erschienen (http://www.oozoon.de/, erlaubt keine Deeplinks - wie wäre denn eigentlich aktuell die ganz offizielle Quelle?), damit treten die Fehlermeldungen nicht mehr auf, und auch das GUI wurde verbessert. Merklich schneller ist es allerdings nicht geworden - wobei ich für die ersten Versuche nur die Voreinstellungen verwende und die Ausgabe auf "to TS" gesetzt habe.
Wie ruft Ihr denn ohne GUI direkt auf dem VDR Euer ProjectX.jar für diese Konvertierung an der Kommandozeile auf?

Hi,

kann schon sein, dass der gute alte K6 etwas überfordert ist.

Zitat

Merklich schneller ist es allerdings nicht geworden - wobei ich für die ersten Versuche nur die Voreinstellungen verwende und die Ausgabe auf "to TS" gesetzt habe.

Ich denke ich benutze auch nur die Standardeinstellungen.

Zitat

Wie ruft Ihr denn ohne GUI direkt auf dem VDR Euer ProjectX.jar für diese Konvertierung an der Kommandozeile auf?

Nach einer Aufnahme lasse ich VDR ein Perl-Skript aufrufen, dass wiederum "/usr/bin/nice -n 10 /usr/bin/java -classpath /usr/local/lib/ProjectX X %s" aufruft. %s sind die entsprechenden *.vdr Dateien die der VDR erzeugt hat und ProjectX in ein TS-File umwandeln soll.
(nice soll nur dafür sorgen, dass der VDR bei 'wichtigeren' Sachen das Wandeln etwas vernachlässigt )
Vermutlich muss man ProjectX einmal mit der GUI starten und die gewünschten Einstellungen vornehmen und dann beenden, es merkt sich dann (hoffentlich) diese Werte (in der X.ini). Beim nächsten Start sollte es die Werte wieder laden.

Da ich aber kein X auf meinem Rechner laufen habe, habe ich ProjectX leicht 'gepachted'.
Folgendes habe ich gemacht. Irgendwo (um Zeile 290?) im File X.java findet sich diese Stelle:

Object[] convertTo = { 
			"demux",
			"to VDR",
			"to M2P",
			"to PVA",
			"to TS",
			"PIDfilter"
		};
	comBox[19] = new JComboBox(convertTo);
	comBox[19].setPreferredSize(new Dimension(100,22));
	comBox[19].setMaximumSize(new Dimension(100,22));
	comBox[19].setSelectedIndex(4);

Die letzte Zeile habe ich verändert. Dort wird das "to TS" als Standard gesetzt. Habe sonst keine Option für die Shell gefunden (kann aber sein, dass ich es nur übersehen habe). Evtl. gibt es aber eine in der neuesten Version ich habe hier die 0.81.8.01 laufen. Anschließend muss man nur noch ProjectX bauen und es kann los gehen.

ciao
DonMarti

Hi!
Ich habe gerade mal probiert ProjectX auf dem LinVDR0.7 ans laufen zu bekommen. Java funktioniert prinzipiell auf der Kiste. Einfache Programme (ohne GUI) laufen auch richtig. ProjectX hab ich auf ner Windowskiste mit dem gleichen SDK (1.4.2) übersetzt und dort läuft es auch. Ich wollte es dann auf dem LinVDR mal starten und bekomme folgende Fehlermeldung:

Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/j2sdk1.4-sun/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1477)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
        at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
        at java.awt.Component.<clinit>(Component.java:506)

Hat jemand ein Tipp für mich

DonMarti: Das Patchen hättest du umgehen können wenn du im x.ini die Zeile wo "p19*demux" in "p19*to TS" umänderst.

Kann man ProjectX überhaupt ohne GUI zum laufen bringen? Ich fänds jedenfalls ziemlich smartl. Alle wichtigen Sachen kann man ja notfalls im Ini-File einstellen.
Gruß
Jarny

Zitat

Original von jarny
Ich habe gerade mal probiert ProjectX auf dem LinVDR0.7 ans laufen zu bekommen.

Na dann willkommen beim gleichen Problem - in diese Richtung wollte ich auch gerade eine Frage posten!
Auf LinVDR (hier noch 0.61 Luzifer_mentox) habe ich Sun's aktuelle jre-1_5_0_01-linux-i586.bin zum Laufen gebracht - das JDK aber nicht (bricht schon beim Entpacken ab, selbst wenn man ihm 6 GB Platz zuweist - habe das nicht weiter verfolgt).

Zitat

Java funktioniert prinzipiell auf der Kiste. Einfache Programme (ohne GUI) laufen auch richtig. ProjectX hab ich auf ner Windowskiste mit dem gleichen SDK (1.4.2) übersetzt und dort läuft es auch. Ich wollte es dann auf dem LinVDR mal starten und bekomme folgende Fehlermeldung:

Code

Exception in thread "main" java.lang.UnsatisfiedLinkError: /usr/lib/j2sdk1.4-sun/jre/lib/i386/libawt.so: libXp.so.6: cannot open shared object file: No such file or directory
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1560)
        at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1477)
        at java.lang.Runtime.loadLibrary0(Runtime.java:788)
        at java.lang.System.loadLibrary(System.java:834)
        at sun.security.action.LoadLibraryAction.run(LoadLibraryAction.java:50)
        at java.security.AccessController.doPrivileged(Native Method)
        at sun.awt.NativeLibLoader.loadLibraries(NativeLibLoader.java:38)
        at sun.awt.DebugHelper.<clinit>(DebugHelper.java:29)
        at java.awt.Component.<clinit>(Component.java:506)

Alles anzeigen

Hier etwas anders, aber in dieselbe Richtung: ProjectX will unbedingt AWT benutzen, dafür muß es X11 initialisieren, was es aber nicht gibt:

Zitat

Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.awt.HeadlessException:
No X11 DISPLAY variable was set, but this program performed an operation which requires it.
at java.awt.GraphicsEnvironment.checkHeadless(Unknown Source)
at java.awt.Window.<init>(Unknown Source)
at java.awt.Frame.<init>(Unknown Source)
at java.awt.Frame.<init>(Unknown Source)
at javax.swing.JFrame.<init>(Unknown Source)
at SUBPICTURE.<init>(SUBPICTURE.java:47)
at X.<clinit>(X.java:81)

Alles anzeigen

Entsprechend steht aber auch in htmls/cli.htm:

Zitat

CL-Interface:
[Optionen] <Quelldatei 1>...[<Quelldatei x>]

Anm:
CL lädt alle GUI Komponenten, ohne diese jedoch anzuzeigen

Wenn man ihm das nicht abgewöhnen kann... (wofür sich bitte "der größte Java-Experte vor dem Herrn" nach http://forum.dvbtechnics.info/forumdisplay.php?f=16 wagt!)

Zitat

Hat jemand ein Tipp für mich

DonMarti: Das Patchen hättest du umgehen können wenn du im x.ini die Zeile wo "p19*demux" in "p19*to TS" umänderst.

Kann man ProjectX überhaupt ohne GUI zum laufen bringen? Ich fänds jedenfalls ziemlich smartl. Alle wichtigen Sachen kann man ja notfalls im Ini-File einstellen.

...hilft wohl nur, LinVDR einen rudimentären X-Server unterzujubeln - der müsste ja auch ohne Zugriff auf die Grafikkarte zu betreiben sein, wenn er ohnehin nichts darstellen soll.

Dazu habe ich allerdings nur folgendes gefunden... vielleicht kommt damit ja jemand weiter:
http://forum.java.sun.com/thread.jspa?threadID=54492&messageID=572543
(es gibt debtool -i xvfb ... aber wie setzt man diesen genau ein?)
http://www.eteks.com/pja/en/
http://forum.dvbtechnics.info/showthread.php?t=947

Sun empfiehlt aber eigentlich:

Zitat

To run our environment with a headless implementation, the follow property may be specified at the java command line:

-Djava.awt.headless=true

Source code should check for headless, so that the exception may be caught gracefully.

Beispiel unter http://java.sun.com/j2se/1.4.2…/AWTChanges.html#headless - das muß ich jetzt aber den Java-Gurus überlassen...

Ich bin mal gespannt, ob dvb.matt da was machen kann.
Hoffentlich muss er nicht großartig seinen Sourcen modifizieren, das wird sich wahrscheinlich nicht lohnen. Schade, dass da nicht von vornherein dran gedacht wurde einen CLI-Modus einzubauen.
Evtl. ist die Sache mit dem XVFB aber auch keine größere Sache. Werds die Tage mal versuchen.

Gruß
Jarny

Hi,

ich habe bei mir ProjectX auch unter Xfvb laufen, da ich auf meinem VDR keinen (richtigen) XServer am laufen habe. Für ne kurze Anleitung siehe u.a.:
http://udrecsuite.sourceforge.…udrec_suite.html#ProjectX

Ich hatte mir den Source von ProjectX auch schon mal angeschaut (darum der Patch ) und befürchte, dass dvb.matt sein Programm komplett umbauen müsste.
Das Problem ist, dass in ProjectX die Konfigurationsdaten direkt in AWT/Swing Klassen gehalten werden. Wenn diese nun angelegt werden wird gleichzeitig versucht (in den tieferen Schichten) entsprechende Grafik-Widgets (im XServer) anzulegen, was leider scheitert wenn kein Server da ist.

ciaoi

Zitat

Original von DonMarti
kann schon sein, dass der gute alte K6 etwas überfordert ist.

Ich scheine aber nicht der einzige zu sein, der noch keinen Pentium-III verwendet
(Tagline war beim Antworten zunächst nicht zu sehen):

Zitat

Original von metahawk
Dem kann ich mich anschließen: 400MHz Maschine, Java 1.3, ProjectX braucht etwa 10 Min. für 3 GB. Allerdings habe ich dieselben Fehlermeldungen beim Starten wie TEN & etwa jedes fünfte Mal wird die GUI nicht gezeichnet.
---
Godzilla [Low Budget Record-Only]: AMD K6/2(400)

Die Fehlermeldungen verschwinden jedenfalls mit ProjectX 0.82 - aber auch bei der Geschwindigkeit gibt es eine Überraschung: Mit derselben Version der Java-JVM unter Windows 98 (nicht einmal offiziell unterstützt, z.T. sieht das GUI dort auch etwas "zerhackt" aus) rennt die Konvertierung auch auf so einer "alten Mühle"! D.h. das gemächliche Arbeitstempo unter SuSE 8.2 liegt wohl nicht an Project X (natürlich wäre in handoptimiertem Assembler fast alles noch um ein Vielfaches schneller ), sondern die Ursache muß irgendeine Macke unter diesem (auch in die Jahre gekommenen) SuSE Linux 8.2 sein, die entweder die Netzwerkfreigabe oder die neue JVM ganz gewaltig ausbremst (oder ist die Linux-JVM für eine andere Architektur optimiert als ihr Windows-Pendant?). Um das im Detail herauszufinden, lohnt es sich aber wohl kaum, ein paar hundert Megabyte der Quellen von Java 1.5 neu zu kompilieren...

Zitat

Original von TEN

Die Fehlermeldungen verschwinden jedenfalls mit ProjectX 0.82 - aber auch bei der Geschwindigkeit gibt es eine Überraschung: Mit derselben Version der Java-JVM unter Windows 98 (nicht einmal offiziell unterstützt, z.T. sieht das GUI dort auch etwas "zerhackt" aus) rennt die Konvertierung auch auf so einer "alten Mühle"! D.h. das gemächliche Arbeitstempo unter SuSE 8.2 liegt wohl nicht an Project X (natürlich wäre in handoptimiertem Assembler fast alles noch um ein Vielfaches schneller ), sondern die Ursache muß irgendeine Macke unter diesem (auch in die Jahre gekommenen) SuSE Linux 8.2 sein, die entweder die Netzwerkfreigabe oder die neue JVM ganz gewaltig ausbremst (oder ist die Linux-JVM für eine andere Architektur optimiert als ihr Windows-Pendant?). Um das im Detail herauszufinden, lohnt es sich aber wohl kaum, ein paar hundert Megabyte der Quellen von Java 1.5 neu zu kompilieren...

Ich habe nochmal auf 0.82 geupdated und die Zeit gestoppt: Es sind eher 30 Min., aber immer noch besser als 24h Ob's an Suse liegt, kann ich nicht sagen, ich habe auf der alten Kiste noch SuSe 8.0 drauf, ich musste nur darauf achten, dass er auch wirklich Java 1.3 nimmt und nicht das von Yast automatisch untergeschobene 1.0 (das musste ich "per Hand" loswerden). Die sporadischen Abstürze von P.X liegen wohl an den PLAFs, metal sollte immer laufen.

Zitat

Original von jarny
Ich bin mal gespannt, ob dvb.matt da was machen kann.
Hoffentlich muss er nicht großartig seinen Sourcen modifizieren, das wird sich wahrscheinlich nicht lohnen. Schade, dass da nicht von vornherein dran gedacht wurde einen CLI-Modus einzubauen.

Es ist vollbracht: http://forum.dvbtechnics.info/showthread.php?t=1427

Zitat

Evtl. ist die Sache mit dem XVFB aber auch keine größere Sache. Werds die Tage mal versuchen.

Siehe oben verlinkten Thread - Du wirst dort bereits erwartet...