# Bildschirminhalt abfilmen und in Datei speichern?



## Extremefall (17. Apr 2011)

Hallo,
ich würde gerne den (aktiven) Bildschirminhalte abfilmen und anschließend in einer Videodatei (avi, mpg etc.) speichern. Nun habe ich bereits nach meiner Recherche herausgefunden, dass es über JMF gehen sollte. Allerdings blicke ich durch die API nicht durch, da ich noch nicht weiß, welche Klassen ich überhaupt alle dafür benötige. Wisst ihr, welche Klassen für mein Vorhaben benötigt werden? Ist es 
recht einfach mittels der API zu realisieren?

MfG


----------



## Atze (17. Apr 2011)

scheints nicht der einzige mit dem vorhaben zu sein  vielleicht hilft dir das hier weiter

CAPTURE DESKTOP ACTIVITY AS VIDEO File - Java | Dream.In.Code


----------



## Extremefall (17. Apr 2011)

Danke erstmal. So wie ich den Code verstehe, werden damit wohl viele Bilder erzeugt. Diese sollen am Ende zu einer Video Datei zusammengefügt werden. Ist das wirklich der übliche Weg? Geht es nur über den Umweg, erst Bilder zu erzeugen und dann daraus eine Videodatei zu machen? Läuft es dann wirklich flüssig? Wie machen es denn diese Screenrecorder? Gibt es da keine komfortablere Lösung mit Hilfe der API?


----------



## Marco13 (17. Apr 2011)

Naja, "üblich" nicht direkt, aber vergleichsweise einfach - insbesondere mit dem dort auch verlinkten "JPEGImagesToMovie". Der Link ist tot (Umzug zu Oracle...) aber eine websuche liefert noch einige Seiten, auf denen man es noch findet. Bei diesem Beispiel kann man _relativ _ leicht die "Datenquelle" umstellen von "JPEG File" auf "irgendein BufferedImage". (Es ist nicht trivial, aber mit ein bißchen API lesen nd frickeln kriegt man's hin). Leider hatte ich es damit damals aber nicht geschafft, etwas anderes als MOV rauszuschreiben...  Aber vielleicht würde man da auch eine Lösung finden...


----------



## Kr0e (17. Apr 2011)

Einen Film aus Bildern erstellen kann Xuggler hervoragend. Du kannst so ziemlich alle Formate als Output nutzen.
Die Screenshots machst du mit Robot.createScreenCapture. Die Methode ist aber lahm natuerlich, da es keine hardwarebeschleunigte Methode ist. Du kannst mit Java keinen Echtzeitfilm mit 30 FPS aufnehmen. Dafuer brauchst du DirectX-KnowHow unter Windows z.B.
Ein kleines Beispiel: Ich habe eine Aufloesung von 1280*1024 und jeder Screenshot braucht etwa 120 ms. Du wirst also keine 10 FPS hinkriegen... Aber sofern das nicht schlimm ist, ist das schnell erledigt ;-)

Gruss,
Chris


----------



## Extremefall (18. Apr 2011)

Ich wollte damit eigentlich meine Videos abfilmen, die auf einer CD sind. Geht es wirklich nicht mit Java? Schließlich kann man doch wohl auch Videos in Echtzeit wiedergeben?


----------



## Marco13 (18. Apr 2011)

Ganz klar: Wenn man so eine Funktion nur _verwenden_ will, nimmt man sich ein Programm, das das kann. Sowas selbst zu implementieren ist so ein absurd hoher Aufwand, das macht wirklich keinen Sinn...


----------



## Kr0e (18. Apr 2011)

Hmm, ich wuerde nicht sagen, dass das ein Absurd-Hoher-Aufwand ist.. Aber Java ist schlicht und einfach nicht das richtige Werkzeug fuer derart native Angelegenheiten. Mit C# ist das mit Vorwissen an einem Tag durchaus schaffbar... Den Film mit DirectShow erstellen und abfilmen mit der DirectX Schnittstelle. Dann geht das fix, aber bei Java muesstest du jetzt erstmal iwelche Wrapper suchen und natuerlich waere es dann total sinnfrei, dass in Java zu machen, da Java eben plattformunabhaengig sein soll und es durch solche Spirenzien eben nicht mehr ist. 

WEnns dir nur ums Ergebnis geht, geb ich Marco13 vollkommen Recht...

Gruss,

Chris

PS: Du hast aus der Tatsache, Filme in Echtzeit abzuspielen gefolgert, dass es moeglich ist, Videos in Echtzeit aufzunehmen...  DAs sind vollkommen verschiedene Angelegenheiten... Es gibt da so ein paar Mankos: Die Screenshots sind nicht in direkten Puffern gespeichert und man kann verwendete Images nicht wieder neu beschreiben. DAs erzeugt massiven Overhead durch das staendige erneute Beantragen von Puffern. Gleiches Rechenexempell: 1280*1024*4 = 5,2 MB. Dann noch mal 30 fuer fluessiges Abspielen macht also 30 * 5,2 = 157 MB pro Sekunde. Das belastet den GC immens. Und da die Puffer nicht direkt(nicht nativ!) sind, ergeben sich vollkommen unnoetige Kopiervorgaenge. Bei C# saehe es so: DirectX Puffer erstellen -> Bild einlesen -> DirectX Puffer an DirectShow uebergeben und in Film speichern -> Den gleichen Puffer verwenden um das naechste Bild zu erstellen. Das alles passiert dann hoechstwahrscheinlich hardware beschleunigt. Meine Rechnung ist aber fuer heutige Aufloesungen eh nicht mehr realistisch also rechne das am Besten mal 4


----------

