File laden

[Mad0x]

Ich und mein Kollege haben ein grosses Problem. Wir versuchen eine File zu laden (also ein Video) und diese dann mithilfe des ProcessBuilders abzuspielen.
Der Code sieht bisher so aus:

import java.io.IOException;


class Player {
InputStream  Video = (getClass().getResourceAsStream("Video/Intro.wmv"));
	public static void main (String[] args) throws IOException {

ProcessBuilder VideoPlayer = new ProcessBuilder("cmd.exe", "/c","Video/Intro.wmv" );
VideoPlayer.start();
}

Das Video wird in Eclipse problemlos abgespielt, aber sobald man das Ganze als .jar-Datei exportiert hat, findet er die Datei nciht mehr. Was machen wir falsch?
Wie laden wir eine File richtig, dass diese dann mitexportiert wird und gefunden werden kann?

PS: Eclipse slebst zeigt an, dass die Datei mitexportiert wird.

 

[genodeftest]

Du brauchst dieses Video doch überhaupt nicht zu laden, übergib einfach den Dateipfad dem Systemeigenen Videoplayer. Das funktioniert am besten über

Desktop.getDesktop().openFile()

, diese Lösung ist auch halbwegs Platformunabhängig.

Euer 2. Problem ist der Pfad. Dazu gibts hier verschiedene Posts, nutzt doch bitte die Foren-Suche!

 

[SE]

Ich vermute mal ganz stark das dies ein CROSS-Thread aus dem java-forum.org ist der diesem hier vom Wortlaut verdammt änlich ist. *Wenn ichs noch recht im Kopf hab geht es um irgendwelche Naruto-AMV's.*
Da ich "da drüben" nicht dazwischen reden wollte *weils mir einfach zu stumpf ist* versuch ich dir hier mal dein Problem etwas zu verdeutlichen :
Du schreibst eine Klasse welche nichts weiter tut als einen externen Prozess mit einem Parameter startet. Dieser Parameter ist ein Dateipfad. Soweit ist das ja alles kein Problem.
Was du hier aber schon grundlegend falsch machst : du bereitest dich darauf vor eine Resource einzulesen ... was du überhaupt nicht musst. Und dann versuchst du den externen Prozess mit einer abstrakten Pfadangabe zu starten obwohl dieser noch nicht mal einen absoluten Pfad zur Datei hat.

Was zu tun ist :

-Datei aus JAR extrahieren ... das ist wichtig damit das System das Video überhaupt finden kann. Es reicht nun mal nicht nur das JAR als ZIP-Archiv anzugeben wenn der Player nicht in der Lage ist eine solche Datei zu lesen und zu verarbeiten.
-Nutzen der Klasse Desktop ... warum du unbedingt eine Console startest und hoffst das das System die CMD-Erweiterungen aktiviert hat um zu erkennen das ein bestimmter Datentyp mit einer bestimmten Anwendung ausgeführt werden soll ... das ist zu unsicher. Als Beispiel könnte ich einfach diese Erweiterung deaktivieren und die CMD würde mich fragen was sie denn mit dem File tun soll.
-Sich gedanken über die Sinnhaftigkeit machen ... ganz erlich : ich verstehe immer noch nicht was dieser Unfug soll. Warum packst du ein Video-File mit einer Start-Klasse *die wie gesagt fehlerhaft ist* in ein JAR und hoffst dass "das irgendwie schon hinhaun wird" ? Warum lieferst du nicht einfach das Video-File aus ? Hast du Angst vor irgendwelchen Urheberrechtsverletzungen ? Glaub mir ... die hast du so oder so ... egal wie du ein solches File verbreitest.

Naja ... vielleicht schaffst du es ja noch mir den Sinn dahinter irgendwann zu erläutern ... aber so wie es jetzt ist ist es einfach nur OVERKILL nach dem Motto : ich tu es weil ich es kann ... anstatt einfach das Video zu verschicken ... aber naja ... mache mal wie du denkst.

 

[Mad0x]

Ich vermute mal ganz stark das dies ein CROSS-Thread aus dem java-forum.org ist der diesem hier vom Wortlaut verdammt änlich ist. *Wenn ichs noch recht im Kopf hab geht es um irgendwelche Naruto-AMV's.*
Da ich "da drüben" nicht dazwischen reden wollte *weils mir einfach zu stumpf ist* versuch ich dir hier mal dein Problem etwas zu verdeutlichen :
Du schreibst eine Klasse welche nichts weiter tut als einen externen Prozess mit einem Parameter startet. Dieser Parameter ist ein Dateipfad. Soweit ist das ja alles kein Problem.
Was du hier aber schon grundlegend falsch machst : du bereitest dich darauf vor eine Resource einzulesen ... was du überhaupt nicht musst. Und dann versuchst du den externen Prozess mit einer abstrakten Pfadangabe zu starten obwohl dieser noch nicht mal einen absoluten Pfad zur Datei hat.

Was zu tun ist :

-Datei aus JAR extrahieren ... das ist wichtig damit das System das Video überhaupt finden kann. Es reicht nun mal nicht nur das JAR als ZIP-Archiv anzugeben wenn der Player nicht in der Lage ist eine solche Datei zu lesen und zu verarbeiten.
-Nutzen der Klasse Desktop ... warum du unbedingt eine Console startest und hoffst das das System die CMD-Erweiterungen aktiviert hat um zu erkennen das ein bestimmter Datentyp mit einer bestimmten Anwendung ausgeführt werden soll ... das ist zu unsicher. Als Beispiel könnte ich einfach diese Erweiterung deaktivieren und die CMD würde mich fragen was sie denn mit dem File tun soll.
-Sich gedanken über die Sinnhaftigkeit machen ... ganz erlich : ich verstehe immer noch nicht was dieser Unfug soll. Warum packst du ein Video-File mit einer Start-Klasse *die wie gesagt fehlerhaft ist* in ein JAR und hoffst dass "das irgendwie schon hinhaun wird" ? Warum lieferst du nicht einfach das Video-File aus ? Hast du Angst vor irgendwelchen Urheberrechtsverletzungen ? Glaub mir ... die hast du so oder so ... egal wie du ein solches File verbreitest.

Naja ... vielleicht schaffst du es ja noch mir den Sinn dahinter irgendwann zu erläutern ... aber so wie es jetzt ist ist es einfach nur OVERKILL nach dem Motto : ich tu es weil ich es kann ... anstatt einfach das Video zu verschicken ... aber naja ... mache mal wie du denkst.

Wir gingen das Problem ähnlich an, wie wir es mit den Bildern getan haben. Dort wird, meines Wissens nach, ein Bild so geladen, sodass es danach auch in einer "Runnable JAR-File" geladen werden kann und nicht nur in der Entwicklungsumgebung selbst. Ich glaube, du meintest, dass das Programm in eine einfache .jar-Datei (also in etwa gleichzusetzten mit einer .zip-Datei, wenn ich dich richtig verstanden habe) exportiert wird. Und um irgendwelche Ängste wegen den Urherberrechtverletzung geht es mir eigentlich gar nicht, da das Programm auch gar nicht für die Verbreitung gedacht ist...

Zur Sicherheit frage ich nochmal, um Missverständnisse zu vermeiden. Wie erwähnt haben wir das gleiche auch schon mit Bildern gemacht, diese werden dann so geladen:

ImageIcon bild2 = new ImageIcon(getClass().getClassLoader().getResource("Bilder/bild.jpg"));

Das Bild befindet sich nun in dem Ordner "Bilder" in unserem Project: Die Datei wird, innerhalb sowie ausserhalb der Entwicklungsumgebung, gleaden. Mit Videos sollte dies nun ganz ähnlich klappen oder lege ich da schon grundlegend falsch?

 

[SE]

Erstens : NEIN !
Ich kenne den Unterschied zwischen einem "JAR" und einem "runnable JAR" ... und zwar ist das lediglich die Zeile "Main-Class" im Manifest ... nicht mehr und nicht weniger ...

Zweitens : JAIN !
Du liegst nicht grundlegend damit falsch ein Video so laden zu wollen wie du es mit einem Bild getan hast ... das Problem ist viel mehr die fehlende Verarbeitungsmöglichkeit in Java ... von der Spiecher-Begrenzung mal ganz abgesehen.
Es gibt in Java keinen dierekt verwendbaren Video-Player dem du einfach so ein File oder InputStream übergibts und dann sowas wie play() aufrufst. Java kann sowas nur mit Audio-Daten ... und auch hier nur mit sehr wenigen Formaten wie .au .wav .snd . Auch müsstest du dafür sorgen das das Jar mit genug Heap gestartet wird ... das heißt mindest die Größe des Videos + die Größe der Player-Lib + ein paar MB für TMP-Daten + den Heap den die VM selbst braucht ... macht also z.B. bei nem 100MB Video und ner sehr kleinen Lib gut schon mal 150MB - 200MB ... je nach dem wie viel die Lib frisst.

Ich wollte ja noch nicht mal sagen das es komplett unmöglich ist ... nur so wie du es versucht hast geht es nun mal nicht. Davon abgesehen war dein Beispiel was du hier gepostet hast weit von dem entfernt was du eigentlich vor hast ... daher auch unsere falsche Ansicht in punkto CMD.

Was nun der Sinn dahinter sein soll erschließt sich mir zwar immer noch nicht ... vor allem wenn es nur um EIN File geht ... aber naja ... das muss ich wohl auch nicht verstehen.