Videoschnitt
Moderator: Patrick
Da bin ich vermutlich zu "klassisch" veranlagt. Irgendwie habe ich durchaus nach einem ZIPtool auf dem HD-Install gesucht, aber da war keiner. Und dann ist das nächste nicht, daß ich auf der riscosoopen Seite schaue, sondern direkt bei "bekannten" Seiten. Irgendwie finde ich die ROOL Seite unübersichtlich - keine Ahnung warum.
Das nächste was mir noch eingefallen wäre, wäre dann !InfoZIP gewesen.
( Habe früher(TM) eigentlich die Demos etc. ja immer nur ausgepackt und das i.a. dann mit dem !ArcFS2. Das war irgendwie anwenderfreundlicher als das Spark und hat(te) so ein schönes Icon ! )
Technisch ist das SparkFS wahrscheinlich schon der coolste Packer, aber da es nie "geöffnet" worden ist, hat sich da niemand in die Entwicklung mit reingehängt. Das Modulkonzept ist schon klasse, aber taugt nichts, wenn da niemand Module extra anbietet.
Ist bißchen wie bei ArtWorks, wo auch kein "Markt" für Zusatzmodule entstanden ist.
Was ich allerdings auch SEHR cool finde, ist das SQUASH Module.
Das packt aber leider nur Einzelfiles und läßt Directories außen vor. Ich glaube, wenn es das noch gekonnt hätte, gäbe es auf RISC OS das als allgemeinen Packer-Standard. Leider ist mir da auch nicht wirklich klar, inwieweit das abwärtskompatibel ist, oder ob die neuen Varianten "anders" funktionieren, d.h. ob man ein squashed File dann auf einem A3000 geöffnet bekommt, wenn man es mit ROS 5.24 gepackt hat.
Vielleicht sollte man mal eine Packerseite machen, wo die Sachen gesammelt drauf sind. Es gab da bestimmt noch ein paar witzige andere Ansätze, die leider alle nach und nach verloren gehen. Demos und Games hatten oft ein eigenes LZWH (ö.a.) Modul dabei, was man im Normalgebrauch auch noch nie gesehen hat.
Das nächste was mir noch eingefallen wäre, wäre dann !InfoZIP gewesen.
( Habe früher(TM) eigentlich die Demos etc. ja immer nur ausgepackt und das i.a. dann mit dem !ArcFS2. Das war irgendwie anwenderfreundlicher als das Spark und hat(te) so ein schönes Icon ! )
Technisch ist das SparkFS wahrscheinlich schon der coolste Packer, aber da es nie "geöffnet" worden ist, hat sich da niemand in die Entwicklung mit reingehängt. Das Modulkonzept ist schon klasse, aber taugt nichts, wenn da niemand Module extra anbietet.
Ist bißchen wie bei ArtWorks, wo auch kein "Markt" für Zusatzmodule entstanden ist.
Was ich allerdings auch SEHR cool finde, ist das SQUASH Module.
Das packt aber leider nur Einzelfiles und läßt Directories außen vor. Ich glaube, wenn es das noch gekonnt hätte, gäbe es auf RISC OS das als allgemeinen Packer-Standard. Leider ist mir da auch nicht wirklich klar, inwieweit das abwärtskompatibel ist, oder ob die neuen Varianten "anders" funktionieren, d.h. ob man ein squashed File dann auf einem A3000 geöffnet bekommt, wenn man es mit ROS 5.24 gepackt hat.
Vielleicht sollte man mal eine Packerseite machen, wo die Sachen gesammelt drauf sind. Es gab da bestimmt noch ein paar witzige andere Ansätze, die leider alle nach und nach verloren gehen. Demos und Games hatten oft ein eigenes LZWH (ö.a.) Modul dabei, was man im Normalgebrauch auch noch nie gesehen hat.
Sieht ja schon wie ein echte VideoAnwendung aus - wenn man als Uneingeweihter da drauf guckt versteht man nix ... Trim, Crop, ASS, SRT, PiP
Ich denke 1024x786 als Minimum anzunehmen ist sicher OK. Es wird wohl kaum jemand mit einem A4000 Videos schneiden - auch wenn es wahrscheinlich mit dem ffmpeg dann sogar ginge.
So Sachen wie QUIT haben aber auf gar keinen Fall was in einem Fenster zu suchen (zumal es ja den Close Button gibt, hoffentlich mit Sicherheitsabfrage), weil man da immer zufällig dann draufklickt, wenn man gerade noch die letzten 2 Änderungen machen will, kurz bevor die ungespeicherte 3 Stunden währende Bearbeitungssession endet.
Sowas ist ein absolutes Totschlagargument für ein Tool - wenn man was bearbeitet und dann zufällig alles weg sein kann, wegen kleiner Unaufmerksamkeit. Das ist wie ein Texteditor, der Stackfehler anzeigt, indem er einfach abstürzt - anstelle vorher zu schauen, ob genug Platz da ist.
Ich denke 1024x786 als Minimum anzunehmen ist sicher OK. Es wird wohl kaum jemand mit einem A4000 Videos schneiden - auch wenn es wahrscheinlich mit dem ffmpeg dann sogar ginge.
So Sachen wie QUIT haben aber auf gar keinen Fall was in einem Fenster zu suchen (zumal es ja den Close Button gibt, hoffentlich mit Sicherheitsabfrage), weil man da immer zufällig dann draufklickt, wenn man gerade noch die letzten 2 Änderungen machen will, kurz bevor die ungespeicherte 3 Stunden währende Bearbeitungssession endet.
Sowas ist ein absolutes Totschlagargument für ein Tool - wenn man was bearbeitet und dann zufällig alles weg sein kann, wegen kleiner Unaufmerksamkeit. Das ist wie ein Texteditor, der Stackfehler anzeigt, indem er einfach abstürzt - anstelle vorher zu schauen, ob genug Platz da ist.
Danke für die Rückinfo.
Mit Quit und Cancel bin ich mir nicht sicher/nicht gnz zufrieden. Cancel ist derzeit ohne Funktion und wird wohl wegfallen. Was will ich abbrechen. Solange ich mich "im Fenster" befinde, passiert nichts weiter und wenn ich via Cut oder Encode usw. ffmpeg auf die Reise schicke bin ich raus...
Quit ist aktuell mein "Killer". Der Macht elles dicht, was eventuell noch offen sein könnte (FFPlay, Stream...).
Die Knöpfe sind aber mein geringstes Problem
Trim, Crop, Ass... sind durchaus übliche Begriffe. Irgendwann wird es mal ein Manual geben... Bis dahin "Finger weg" wenn Du keine Ahnung hast
Mit Quit und Cancel bin ich mir nicht sicher/nicht gnz zufrieden. Cancel ist derzeit ohne Funktion und wird wohl wegfallen. Was will ich abbrechen. Solange ich mich "im Fenster" befinde, passiert nichts weiter und wenn ich via Cut oder Encode usw. ffmpeg auf die Reise schicke bin ich raus...
Quit ist aktuell mein "Killer". Der Macht elles dicht, was eventuell noch offen sein könnte (FFPlay, Stream...).
Die Knöpfe sind aber mein geringstes Problem
Trim, Crop, Ass... sind durchaus übliche Begriffe. Irgendwann wird es mal ein Manual geben... Bis dahin "Finger weg" wenn Du keine Ahnung hast
Na, das wird ja ein richtiges Großprojekt. 76MB Download !
Ich habe es mal ausprobiert. Letztlich stalled es den RPCEmu einfach nur - und dann hängt der fest. Aber das Fenster öffnet sich und Menus etc. gehen, bis man das Video lädt. Danach geht gar nix mehr.
Vielleicht kann ich trotzdem was hilfreiches beitragen ...
eine Anwendung möchte eine SharedUnix Lib haben in v 1.07 - das ist aber nicht mit dabei. Und wenn man schon alles ins ZIP wirft dann kann man das auch noch dazutun. (Mich stört das nicht - ich hab das da und weiß um die Story mit den vielen unterschiedlichen CLibs, aber jemand ders einfach so ausprobieren will und dann schon dort scheitert kommt gar nicht bis ins Fenster.)
Das zweite, was mir passiert ist: Wenn man das !Movie Tool startet bevor man das !Batch Tool angeschaltet hat (die FFMPEG Sachen waren doppelt geklickt), dann meckert die App rum daß Memory zu wenig sei "Insuffizient Memory". Das wird auch nicht besser, wenn man den RAM Balken im Taskmanager maximal aufieht. Wenn aber das !Batch Tool schon läuft, funktioniert zumindest der Start schonmal und man bekommt das Fenster wie in Deinem Bild. Da ist die Fehlermeldung nicht gut - besser wäre irgendwie sowas wie, daß man die anderen Tools alle schon anhaben muß, mitzuteilen.
Werd' wahrscheinlich am WE nochmal damit rumprobieren.
Mal sehen, ob es da mehr sagen mag. Allerdings ist das wahrscheinlich sowieso ein wenig ambitioniert in einer Emulation auf einem nicht mehr ganz taufrischen Rechner Videobearbeitung auszuprobieren.
Ich habe es mal ausprobiert. Letztlich stalled es den RPCEmu einfach nur - und dann hängt der fest. Aber das Fenster öffnet sich und Menus etc. gehen, bis man das Video lädt. Danach geht gar nix mehr.
Vielleicht kann ich trotzdem was hilfreiches beitragen ...
eine Anwendung möchte eine SharedUnix Lib haben in v 1.07 - das ist aber nicht mit dabei. Und wenn man schon alles ins ZIP wirft dann kann man das auch noch dazutun. (Mich stört das nicht - ich hab das da und weiß um die Story mit den vielen unterschiedlichen CLibs, aber jemand ders einfach so ausprobieren will und dann schon dort scheitert kommt gar nicht bis ins Fenster.)
Das zweite, was mir passiert ist: Wenn man das !Movie Tool startet bevor man das !Batch Tool angeschaltet hat (die FFMPEG Sachen waren doppelt geklickt), dann meckert die App rum daß Memory zu wenig sei "Insuffizient Memory". Das wird auch nicht besser, wenn man den RAM Balken im Taskmanager maximal aufieht. Wenn aber das !Batch Tool schon läuft, funktioniert zumindest der Start schonmal und man bekommt das Fenster wie in Deinem Bild. Da ist die Fehlermeldung nicht gut - besser wäre irgendwie sowas wie, daß man die anderen Tools alle schon anhaben muß, mitzuteilen.
Werd' wahrscheinlich am WE nochmal damit rumprobieren.
Mal sehen, ob es da mehr sagen mag. Allerdings ist das wahrscheinlich sowieso ein wenig ambitioniert in einer Emulation auf einem nicht mehr ganz taufrischen Rechner Videobearbeitung auszuprobieren.
Die Downloadgröße resultieet natürlich daraus, daß der Kram drumherum und ein Beispiel "innendrinne" ist. Mein Teil ist das Geringste daran
RPCEmu geht nicht wirklich. Die ffmpeg Versionen sind nicht kompatible und wer an einem Rechner sitzt, auf dem RPCEmu brauchbar läuf, der hat mit Sicherheit bessere Alternativen als mein Frontend.
Was bei mir auf meiner "Diensthure" und RPCEmu geht ist MovieCentre starten und das Demoprojekt öffnen (Dauert, nicht ungeduldig werden. SYS OS_GBPB ist grottelahm auf RPCEmu) und damit spielen. Bis zur Erstellung der Obeys. Alles was ffmpeg aufruft geht Krachen. Ist beim Batch-tool ähnlich.
Auf meinem RPCEmu läuft 5.24. BS Versionen unter 5.24 habe ich nicht getestet. Bei 5.24 ist die richtige SharedULib etc. dabei.
Ab Iyonix könnte was gehen (ausser Untertitel) weil Chris Gransdens ffmpeg erst ab Beagleboard läuft...
Ab Beagleboard sollte es deshalb funktionieren. Habe selbst an der kleinen Pandora (wie Beagleboard) am BeaglexM, am RPi ab V2B, MX6/minim und Titanium getestet. Die Rechner mit SATA Platte sind deutlich im Vorteil, gerade bei der Erstellung eines eigenen Projektes. Besser erstmal kurze Filmchen probieren. Die Vorschau ist noch eine meiner Problemzonen.
Next sollte größer sein. 640MB (Standard wenn man ein System selbst aufsetzt) ist für ChangeFSI zu klein. Darüber läuft die Vorschauerstellung im Hintergrund, weil ich bin zu doof die mit ffmpeg erzeugten jpegs direkt in ein Fenster zu zaubern. Ich brauche ein Sprite, was ich "on the fly" im Hintergrund erzeuge. Mein Next steht auf 4096MB. Kann man zur Not auch erstmal im Taskmanager aufziehen. Ich bin gerade nicht sicher ob ich im BatchTool was setze.
Das Batchtool "braucht" man eigentlich nur wenn man ein Video erwischt, was nicht "sauber" ist. Auf RPCEmu nutze ich das nicht. Streams fallen mir da ein. Internet hat in der Regel keine korrekte timeline, DVB Streams haben oft reichlich "Füllmaterial" dabei... HD Filme gehen zwar theoretisch aber die Player sind da auch auf dem Titanium überfordert.
Die Tools sind unabhängig voneinander. Ausser Next fällt mir nix ein. Habe gerade jetzt zwischendurch noch einmal unter RPCEmu... kann ich erstmal nicht nachvollziehen. Das Batch-tool tut nix. Welches RPCEmu mit welchem OS?
Bitte die Reihenfolge der Schritte sinnvoll wählen. Ich prüfe noch nicht wirklich vollumfänglich gegen. Z.B. macht CreateASS nur Sinn, wenn man vorher eine SRT erstellt wurde.
Hab schon überlegt ob ich die Knöpfe die erst funktionieren wenn..., erst erstellt werden wenn... so ähnlich wie in der alten Version die "Toolbutton".
Na schauen wir mal. Aktuell bin ich selbst mit einer "handgefeilten" Obey schneller
RPCEmu geht nicht wirklich. Die ffmpeg Versionen sind nicht kompatible und wer an einem Rechner sitzt, auf dem RPCEmu brauchbar läuf, der hat mit Sicherheit bessere Alternativen als mein Frontend.
Was bei mir auf meiner "Diensthure" und RPCEmu geht ist MovieCentre starten und das Demoprojekt öffnen (Dauert, nicht ungeduldig werden. SYS OS_GBPB ist grottelahm auf RPCEmu) und damit spielen. Bis zur Erstellung der Obeys. Alles was ffmpeg aufruft geht Krachen. Ist beim Batch-tool ähnlich.
Auf meinem RPCEmu läuft 5.24. BS Versionen unter 5.24 habe ich nicht getestet. Bei 5.24 ist die richtige SharedULib etc. dabei.
Ab Iyonix könnte was gehen (ausser Untertitel) weil Chris Gransdens ffmpeg erst ab Beagleboard läuft...
Ab Beagleboard sollte es deshalb funktionieren. Habe selbst an der kleinen Pandora (wie Beagleboard) am BeaglexM, am RPi ab V2B, MX6/minim und Titanium getestet. Die Rechner mit SATA Platte sind deutlich im Vorteil, gerade bei der Erstellung eines eigenen Projektes. Besser erstmal kurze Filmchen probieren. Die Vorschau ist noch eine meiner Problemzonen.
Next sollte größer sein. 640MB (Standard wenn man ein System selbst aufsetzt) ist für ChangeFSI zu klein. Darüber läuft die Vorschauerstellung im Hintergrund, weil ich bin zu doof die mit ffmpeg erzeugten jpegs direkt in ein Fenster zu zaubern. Ich brauche ein Sprite, was ich "on the fly" im Hintergrund erzeuge. Mein Next steht auf 4096MB. Kann man zur Not auch erstmal im Taskmanager aufziehen. Ich bin gerade nicht sicher ob ich im BatchTool was setze.
Das Batchtool "braucht" man eigentlich nur wenn man ein Video erwischt, was nicht "sauber" ist. Auf RPCEmu nutze ich das nicht. Streams fallen mir da ein. Internet hat in der Regel keine korrekte timeline, DVB Streams haben oft reichlich "Füllmaterial" dabei... HD Filme gehen zwar theoretisch aber die Player sind da auch auf dem Titanium überfordert.
Die Tools sind unabhängig voneinander. Ausser Next fällt mir nix ein. Habe gerade jetzt zwischendurch noch einmal unter RPCEmu... kann ich erstmal nicht nachvollziehen. Das Batch-tool tut nix. Welches RPCEmu mit welchem OS?
Bitte die Reihenfolge der Schritte sinnvoll wählen. Ich prüfe noch nicht wirklich vollumfänglich gegen. Z.B. macht CreateASS nur Sinn, wenn man vorher eine SRT erstellt wurde.
Hab schon überlegt ob ich die Knöpfe die erst funktionieren wenn..., erst erstellt werden wenn... so ähnlich wie in der alten Version die "Toolbutton".
Na schauen wir mal. Aktuell bin ich selbst mit einer "handgefeilten" Obey schneller