Hallo, möchte eine Animation aus ca. 3000 Einzelbildern erstellen. Framerate wären 25fps. Die Einzelbilder sind schwarz/weiss (keine Graustufen) im Format 640x480. Das Ganze soll am Ende in ein übliches Videoformat münden, wie z.B. *.mp4 und möglichst wenig Datenvolumen haben. Das Besondere an der Animation: Sie beginnt und endet mit jeweils einem Bild, das 2sec. angezeigt wird und die 3000 Bilder dazwischen unterscheiden sich jeweils nur in einem einzigen Pixel! Mit animierten Gifs habe ich dbzgl. schlechte Erfahrungen gemacht, weil da bereits mit paar Bildern gewaltige Datenmengen entstehen. Welche Software leistet was ich will? Sven
FFMPEG kann sowas: https://hamelot.io/visualization/using-ffmpeg-to-convert-a-set-of-images-into-a-video/
Hallo Sven, da kann ich dir als einfachste Lösung Davinci Resolve an die hand legen. https://www.blackmagicdesign.com/de/products/davinciresolve/ Ist etwas zu viel des Guten. Aber Du kommst damit am schnellsten ins Ziel. Wenn deine Bilder fotlaufen Nummeriert benannt sind, werden diese als Zusammengehörig erkannt, wenn Du diese importierst. Für deine Zwecke reicht ein 15 Minuten Workflow Tutorial auf Youtube. Stichworte wären: -Project Settings -Import Media -Deliver
Die meisten machen das mit den Windows Movie Maker. Der ist sogar für Lau. Anleitungen wie man es macht gibts über Freund Google.
Sven S. schrieb: > Mit animierten Gifs habe ich dbzgl. schlechte Erfahrungen gemacht, weil > da bereits mit paar Bildern gewaltige Datenmengen entstehen. Das ist auch am besten in mindestens 2 Schritte zu zerlegen. Erst einen gigantisch grossen Film machen und dann nach Bedarf aufs gewünschte Format komprimieren.
Sven S. schrieb: > Das Besondere an der Animation: Sie beginnt und endet mit jeweils einem > Bild, das 2sec. angezeigt wird und die 3000 Bilder dazwischen > unterscheiden sich jeweils nur in einem einzigen Pixel! Ich hoffe mal, dass dieser eine Pixel nicht in der verlustbehafteten Kompression dann untergeht. Notfalls weniger stark komprimieren. Müsstest du halt mal ausprobieren.
Nano schrieb: > Notfalls weniger stark komprimieren. Müsstest du halt mal ausprobieren. Das ist der springende Punkt, denn es soll eben keine verlustbehaftete Komprimierung stattfinden. Wenn zu Beginn 50 mal das gleiche Bild angezeigt werden soll, dann wird ein Bild angezeigt und 2 Sekunden gewartet. Das soll die "Komprimierung" leisten. Ebenso am Ende der Animation. Bei den 3000 Einzelbildern, die sich IMMER nur durch ein einziges zusätzliches Pixel vom vorigen Bild unterscheiden, wird das erst Bild als Indexbild 120 Sekunden lang angezeigt. Die "Komprimierung" setzt bei jedem weiteren Bild nur ein Pixel in das Indexbild. So die Theorie.
Sven S. schrieb: > Das ist der springende Punkt, denn es soll eben keine verlustbehaftete > Komprimierung stattfinden. Das schliesst aber deine Prämisse aus: Sven S. schrieb: > Das Ganze soll am Ende in ein übliches Videoformat > münden, wie z.B. *.mp4 und möglichst wenig Datenvolumen haben. Geht also nicht. Selbst Formate wie Digi-Beta oder vergleichbare Broadcast Formate (XDCAM etc.) komprimieren, wenn auch nicht sichtbar. Aber sowas kommt deiner Forderung noch am ehesten entgegen.
Sven S. schrieb: > Nano schrieb: >> Notfalls weniger stark komprimieren. Müsstest du halt mal ausprobieren. > > Das ist der springende Punkt, denn es soll eben keine verlustbehaftete > Komprimierung stattfinden. > > Wenn zu Beginn 50 mal das gleiche Bild angezeigt werden soll, dann wird > ein Bild angezeigt und 2 Sekunden gewartet. Das soll die "Komprimierung" > leisten. Ebenso am Ende der Animation. > > Bei den 3000 Einzelbildern, die sich IMMER nur durch ein einziges > zusätzliches Pixel vom vorigen Bild unterscheiden, wird das erst Bild > als Indexbild 120 Sekunden lang angezeigt. Die "Komprimierung" setzt bei > jedem weiteren Bild nur ein Pixel in das Indexbild. > > So die Theorie. In dem Fall würde ich an deiner Stelle mal gucken ob es alte Formate aus dem Spielebereich gibt, die das leisten. Denn gerade bei alten DOS Spielen hat man nur nen Hintergrund gesetzt und dann ein paar Sprites vor dem Hintergrund verschoben. Und so etwas brauchst du jetzt als Videocodec. Guck dir mal Bink und Smacker an, ob die das können. MPEG-2 und AFAIK auch MPEG-4 ASP und AVC hat zwar vollwertige Zwischenbilder, die dem einen Bild, das bei dir lange angezeigt werden soll, am nächsten kommen, aber ich glaube nicht, dass es über 2 s Lang referenziert und somit wiederverwendet werden kann. Dafür wurde MPEG-2 nicht gemacht. Außerdem ist MPEG-2 mit MPJEG verlustbehaftet. Ebenso MPEG-4 ASP und ACC.
Korrektur: Nano schrieb: > Ebenso MPEG-4 ASP und AVC. Wobei AVC was anderes verwenden, als MPJEG. Mir ging es jetzt nur um das verlustbehaftet. Die Daten für DOS Spieleanimations mussten früher jedenfalls auf wenige Disketten passen und wenn man das nicht mehr Hand jedesmal neu kodieren wollte, wird man sich da wohl nen firmeninternen Codec gebaut haben.
Ach ja und MNG solltest du dir auch mal anschauen: https://de.wikipedia.org/wiki/Multiple-Image_Network_Graphics
Nano schrieb: > Guck dir mal Bink und Smacker an, ob die das können. Bezüglich der beiden: https://en.wikipedia.org/wiki/Bink_Video https://en.wikipedia.org/wiki/Smacker_video
Matthias S. schrieb: > Geht also nicht. Was mich wundert, denn es soll doch Formate geben, deren Komprimierung darauf beruht, dass nur der Unterschied zum vorigen Bild abgespeichert wird. In meinem Fall also nur ein Pixel. Besser kann man eine Datenreduktion doch kaum hinbekommen. Dann: Wenn ich in einem 10 minütigen Video nur ein einziges Bild anzeige, dann hat das Video am Ende zig. MB? Vielen Dank auch für die Links, werde ich mir mal anschauen.
Eben mal mit den animierten Gifs experimentiert. Ein S/W Screenshot im Format 640x480 hat im Bildformat *.png 6.4kB. Dieses Bild dann 10 mal dupliziert (0-9.png) und ein animiertes GIF erzeugt. Positiv: Es findet keine verlustbehaftete Komprimierung statt :-) Kein Pixel ist "untergegangen". Negativ: 10-fache Datenmenge, obwohl ich nur ein Bild sehe :-( Auf die Idee, in der Animation nur ein Bild anzuzeigen und 10 Sekunden zu warten ist offensichtlich noch keiner gekommen. Wenn man das nun auf 3000 gleiche Bilder ausdehnt, hat man eine "Animation" mit 20MB, die aus einem einzigen Bild besteht. Datenreduktion geht irgendwie anders. Wobei die 10-fache Datenmenge nicht ganz stimmt, denn seltsamerweise hat das animierte GIF ca. 10% weniger Datenvolumen als 10 Einzelbilder. Das Ganze mit 20 Einzelbildern wiederholt, der gleiche Effekt.
Sven S. schrieb: > Negativ: 10-fache Datenmenge, obwohl ich nur ein Bild sehe :-( Dann ist das Tool mit dem Du das animierte Gif erstells zu blöd IMHO. Verwende mal was anderes.
Sven S. schrieb: > Das ist der springende Punkt, denn es soll eben keine verlustbehaftete > Komprimierung stattfinden. Dann ist es Zeit FFV1 zu erwähnen (geht mit FFMPEG aus der 1. Antwort): https://en.wikipedia.org/wiki/FFV1
Hier gibt es eine Liste verlustfreier Videokomprimierungsverfahren: https://en.wikipedia.org/wiki/List_of_codecs#Lossless_video_compression Nudel einfach deine Bildsequenz durch alle aufgelisteten Codecs und nimm den, der die kürzeste Datei erzeugt. Sven S. schrieb: > Das Besondere an der Animation: Sie beginnt und endet mit jeweils einem > Bild, das 2sec. angezeigt wird und die 3000 Bilder dazwischen > unterscheiden sich jeweils nur in einem einzigen Pixel! Das ist so speziell, dass sicher keiner der obigen Codecs darauf optimiert ist. Was spricht dagegen, selber ein Videoformat zu entwerfen und einen entsprechenden Codec zu programmieren? So ein Format könnte bspw. folgendermaßen aussehen:
1 | - Startframe als Komplettbild (bspw. im PNG-Format) |
2 | |
3 | - für alle weiteren Frames: |
4 | Position (3 oder 4 Bytes, je nach Auflösung, big endian) und Farbe |
5 | (3 Bytes) des sich gegenüber dem Vorgänger-Frame ändernden Pixels |
6 | oder 0xff (1 Byte), wenn der Frame identisch zu seinem Vorgänger ist |
Das ist leicht zu implementieren, und jeder Frame außer dem ersten benötigt maximal 7 Bytes, was dem Optimum sehr nahe kommen dürfte.
Yalu X. schrieb: > Sven S. schrieb: >> Das Besondere an der Animation: Sie beginnt und endet mit jeweils einem >> Bild, das 2sec. angezeigt wird und die 3000 Bilder dazwischen >> unterscheiden sich jeweils nur in einem einzigen Pixel! > > Das ist so speziell, dass sicher keiner der obigen Codecs darauf > optimiert ist. Was spricht dagegen, selber ein Videoformat zu entwerfen > und einen entsprechenden Codec zu programmieren? So ein Format könnte > bspw. folgendermaßen aussehen: Ganz im Gegenteil. Fast jeder Codec arbeitet mit Blockbildung. Einfach gesagt das Bild wird in Blöcke unterteilt und dann werden die Änderungen in den einzelnen Blöcken durchgeführt. Sehr gut zu erkennen bei einen Instabilen Streaming. Dann sind von de Bild noch Quadrate da und der Rest ist weg/hängt bis zum nächsten Masterbild. In den Fall oben muss man halt nur den passenden Block austauschen. Was die Sache verlustfrei sehr klein macht. Wenn man das Video unkomprimiert abspielt, brauch man je nach Auflösung richtig fette Hardware. Das sind immerhin 50/60 Bilder pro Sekunde. Denk mal drüber nach @ To.
Jim M. schrieb: > Sven S. schrieb: >> Negativ: 10-fache Datenmenge, obwohl ich nur ein Bild sehe :-( > > Dann ist das Tool mit dem Du das animierte Gif erstells zu blöd IMHO. > Verwende mal was anderes. Das Tool ist das eine, das Abspielen das andere. Ich lese eben, dass bei den animierten GIFs eben nur Einzelbilder wiedergegeben werden, ähnlich dem Daumenkino. Was will ein Abspieltools mit dem Bildunterschied zum Indexbild anfangen? Zu den Codecs: Ich habe immer noch Einzelbilder, wie will ich einem Codec Einzelbilder anbieten? M.W. will man da ein Videoformat sehen. Das einzige mir bekannte Format, was man mit Einzelbildern füttern kann, ist GIF. Auch habe ich noch kein Konvertierungstool gesehen, das aus einem animierten GIF ein Video erstellt. Yalu X. schrieb: > Was spricht dagegen, selber ein Videoformat zu entwerfen Da reichen meine Kenntnisse nicht aus. Und die Animation sollte auch weitergegeben werden können. Dazu sollte es schon ein gängiges Format sein. Schlaumaier schrieb: > Das sind immerhin 50/60 Bilder pro Sekunde. Nicht bei einer Animation, da reichen auch 25 Bilder pro Sekunde und weniger.
Sven S. schrieb: > Da reichen meine Kenntnisse nicht aus. Und die Animation sollte auch > weitergegeben werden können. Dazu sollte es schon ein gängiges Format > sein. Verlustfreie Videoformate (mal abgesehen von animated GIFs) sind nicht gängig. Deswegen ist nicht garantiert, dass jeder Videoplayer von Hause aus einen Codec dafür mitbringt.
Christoph Z. schrieb: > Sven S. schrieb: >> Das ist der springende Punkt, denn es soll eben keine verlustbehaftete >> Komprimierung stattfinden. > > Dann ist es Zeit FFV1 zu erwähnen (geht mit FFMPEG aus der 1. Antwort): > https://en.wikipedia.org/wiki/FFV1 Das könnte die Anforderungen des Threadstarters in der Tat erfüllen, denn da steht: "FFV1 is not strictly an intra-frame format; despite not using inter-frame prediction, **it allows the context model to adapt over multiple frames**. This can be useful for compression due to the very large size of the context table, but can be disabled to force the encoder to generate a strictly intra-frame bitstream."
Schlaumaier schrieb: > Yalu X. schrieb: >> Sven S. schrieb: >>> Das Besondere an der Animation: Sie beginnt und endet mit jeweils einem >>> Bild, das 2sec. angezeigt wird und die 3000 Bilder dazwischen >>> unterscheiden sich jeweils nur in einem einzigen Pixel! >> >> Das ist so speziell, dass sicher keiner der obigen Codecs darauf >> optimiert ist. Was spricht dagegen, selber ein Videoformat zu entwerfen >> und einen entsprechenden Codec zu programmieren? So ein Format könnte >> bspw. folgendermaßen aussehen: > > Ganz im Gegenteil. Fast jeder Codec arbeitet mit Blockbildung. Einfach > gesagt das Bild wird in Blöcke unterteilt und dann werden die Änderungen > in den einzelnen Blöcken durchgeführt. Ja, aber da sind es nur wenige Frames zwischen den Vollbildern. Bei MPEG-2 sind es, wenn ich mich nicht irre, glaube 8 Zwischenschritte, dann wieder ein Vollbild. Bei 25 fps musst du also schon 3 Vollbilder speichern. Eine Relation zwischen diesen 3 Vollbildern, ein Bezug von dem der Codec "Kenntnis" hat, gibt es nicht und der wäre hier nötig, nur dann könnte man auch Platz sparen. So ein Codec wäre auch etwas komplexer. Aber dafür wurden die meisten Videocodecs nicht entwickelt, weil man eben im Normalfall Bilder erwarten kann, bei dem sich deutlich mehr ändert als nur ein Frame.
Sven S. schrieb: > Eben mal mit den animierten Gifs experimentiert. Ein S/W Screenshot im > Format 640x480 hat im Bildformat *.png 6.4kB. Dieses Bild dann 10 mal > dupliziert (0-9.png) und ein animiertes GIF erzeugt. > > Positiv: Es findet keine verlustbehaftete Komprimierung statt :-) > Kein Pixel ist "untergegangen". > Negativ: 10-fache Datenmenge, obwohl ich nur ein Bild sehe :-( Das es mit GIF nicht klappt, hat du doch schon oben gesagt. Versuch mal die anderen. APNG und MNG, sowie BINK und Smacker. Achte auch darauf, dass viele der Codecs noch einmal viele verschiedene Einstellungsmöglichkeiten haben. Besonders MNG ist hier sehr komplex, was übrigens auch dazu führte, dass die Browser die Unterstütztung für MNG beendeten. > Auf die Idee, in der Animation nur ein Bild anzuzeigen und 10 Sekunden > zu warten ist offensichtlich noch keiner gekommen. Ich denke schon dass es so etwas schon gab. Es wäre aber möglich, dass es das nie zu einem offenen Codec geschafft hat. Wie ich schon oben geschrieben habe, brauchten gerade die Spielehersteller zur Zeiten von DOS, EGA und VGA, sowie Diskettenlaufwerke Lösungen um eine animierte Introszene platzsparend auf eine Diskette unterzubringen. Das kann man im Programmcode hartverdrahted kodieren oder man könnte auch einen Codec dafür schreiben, so dass es für verschiedene Spiele wiederverwendbar ist. Guck dir also mal die Sierra und LucasArts Adventurespiele an, ob die nicht solche proprietären Lösungen verwendet haben. Und wenn ja, dann guck dir die ScummVM Engine an, denn die wird sie dann implementiert haben.
H.264 kann das Gewünschte ziemlich sicher (3000 Bilder mit minimalen Unterschieden klein und S/W verlustfrei speichern), andere moderne Codecs bestimmt auch. Die Frage ist nur ob man einen Encoder findet der das von Haus aus kann. Das Format bietet genug Möglichkeiten, nur kein Encoder wird darauf ausgelegt sein sowas zu nutzen.
ich schrieb: > H.264 kann das Gewünschte ziemlich sicher (3000 Bilder mit > minimalen > Unterschieden klein und S/W verlustfrei speichern), andere moderne > Codecs bestimmt auch. > Die Frage ist nur ob man einen Encoder findet der das von Haus aus kann. > Das Format bietet genug Möglichkeiten, nur kein Encoder wird darauf > ausgelegt sein sowas zu nutzen. Glaube ich nicht. H.264 wurde für Hardwarechips gemacht, damit man auf billigsten einfachen leistungsschwachen Geräten trotzdem noch die Videos darstellen kann. Eine Hardware, die so schlau ist, dass sie sich das Vollbild von vor n Sekunden einer variablen Zeitangabe merken kann, ist weitaus komplexer, als eine Hardware, die immer das gleiche macht. Also eine Handvoll Zwischenbilder und dann wieder ein neues Vollbild.
Lies dir das hier mal durch: https://en.wikipedia.org/wiki/Group_of_pictures Du brauchst also einen Videocodec mit variabler GOP size die man möglichst groß wählen kann.
Nano schrieb: > Eine Hardware, die so schlau ist, dass sie sich das Vollbild von vor n > Sekunden einer variablen Zeitangabe merken kann, ist weitaus komplexer, > als eine Hardware, die immer das gleiche macht. Also eine Handvoll > Zwischenbilder und dann wieder ein neues Vollbild. Jetzt hast du dich disqualifiziert, schon mal in die H.264 Spec geschaut? Und verstanden wie Referenzbilder funktionieren? (Kleiner Tipp, es gibt Long Term References die genau das machen, hier aber gar nicht gebraucht werden) Ich würde mich sogar fast darauf einlassen zu beweisen das es geht, wenn Sven S. seine Bilder zur Verfügung stellt baue ich vielleicht übers Wochenende einen validen H.264 Baseline Stream daraus...
Schau mal nach fli bzw. flc Die konnten das mal ganz gut. Ob es dafür noch Player gibt, keine Ahnung.
Schau dir auch mal FLIC an: https://en.wikipedia.org/wiki/FLIC_(file_format) Im Git Repository von ScummVM findest du eine ganze Liste an möglichen Animations- und Videoformaten: https://github.com/scummvm/scummvm/tree/master/video
ich schrieb: > Nano schrieb: >> Eine Hardware, die so schlau ist, dass sie sich das Vollbild von vor n >> Sekunden einer variablen Zeitangabe merken kann, ist weitaus komplexer, >> als eine Hardware, die immer das gleiche macht. Also eine Handvoll >> Zwischenbilder und dann wieder ein neues Vollbild. > > Jetzt hast du dich disqualifiziert, schon mal in die H.264 Spec > geschaut? Irrtum und Nein. Ich benutze hier einfach die Logik. Ein Video zeigt in der Regel etwa 25 fps, manchmal auch 60 fps an, darauf sind die Codecs optimiert. Was man macht sind wie oben im GOP Link beschrieben, Vollbilder und dann Unterschiede, also Zwischenschritte aus kleineren Teilen. Nur ist der Abstand meist nicht groß, denn du brauchst dafür einen Zähler und ein Zähler kostet Transistoren in der Hardware. Für 8 Zwischenbilder zum nächsten Vollbild reicht dir ein 3 Bit breiter Zähler. Mit einem 4 Bit breiten Zähler sind 2^4= 16 Zwischenschritte möglich. Mit einem 6 Bit breiten Zähler wirst du 99,7 % der Nutzungsfälle abgedeckt haben, für die man den Codec nutzen möchte. Wenn du aber 2 min überbrücken willst, dann muss der beim maximal möglichen von 60 fps schon 13 Bit breit sein, nämlich 2^13 = 8192, denn 2 min 60 sec 60 fps = 7200 Schritte. Das sind dutzende an zusätzlichen Transistoren die du auf so einem Kleinstembeddedchip unterbringen möchtest und der Chip soll sau billig und möglichst nichts kosten. Billig heißt hier, man muss Fläche einsparen. Also entschlackt man den Codec und limitiert die Anzahl der Zwischenbilder auf eine kleinere Größe. Und somit hast du dich disqualifiziert.
ich schrieb: > Ich würde mich sogar fast darauf einlassen zu beweisen das es geht, wenn > Sven S. seine Bilder zur Verfügung stellt baue ich vielleicht übers > Wochenende einen validen H.264 Baseline Stream daraus... Du kannst das hier ja mal als H.264 downloaden: https://www.youtube.com/watch?v=XIMLoLxmTDw Deiner Logik nach dürfte das gesamte Video nicht größer als sagen wir mal 200 kByte sein und die 200 kByte sind schon recht großzügig gewählt.
Nano schrieb: > H.264 wurde für Hardwarechips gemacht, damit man auf billigsten > einfachen leistungsschwachen Geräten trotzdem noch die Videos darstellen > kann. Die HW-Kompression der leistungsschwachen Geräte ist meist deutlich geringer als die SW-Kompression mit x264 & co. bei gleicher Qualität.
Uwe R. schrieb: > Nano schrieb: >> H.264 wurde für Hardwarechips gemacht, damit man auf billigsten >> einfachen leistungsschwachen Geräten trotzdem noch die Videos darstellen >> kann. > > Die HW-Kompression der leistungsschwachen Geräte ist meist deutlich > geringer als die SW-Kompression mit x264 & co. bei gleicher Qualität. Es geht um die Decoder, die müssen billig und günstig in Hardware zu produzieren sein.
Ich habe gesagt, der Codec ist dazu in der Lage, nicht das die üblichen Encoder sowas geschickt erzeugen können. Außerdem, so schlecht ist das YouTube Video gar nicht, durchschnittlich <30 Byte pro Frame sind jetzt nicht katastrophal viel, auch wenn es natürlich zu viel für "nur" Schwarz ist. Hier fällt noch was anderes auf, im mp4 Container hat das Filmchen (ohne Ton) 37,1 MiB, der reine H.264 (Annex B) Stream nur 24,3 MiB. Es geht also gleich mal ein gutes Drittel für den MP4-Container drauf... (kein Wunder bei diesem Spezialfall, darauf ist der ja nicht optimiert)
Sven S. schrieb: > Zu den Codecs: Ich habe immer noch Einzelbilder, wie will ich einem > Codec Einzelbilder anbieten? M.W. will man da ein Videoformat sehen. Das > einzige mir bekannte Format, was man mit Einzelbildern füttern kann, ist > GIF. Auch habe ich noch kein Konvertierungstool gesehen, das aus einem > animierten GIF ein Video erstellt. NEIN. Du musst in der Regel 2 Runden drehen. Runde 1 : Alle Einzelbilder werden zu einen RAW-Video zusammen gefügt. Runde 2 : Das RAW-Video wird nun mit einen Kompressionsprogramm mit Hilfe eines Codecs zusammen gefügt. Wer schon mal Super-8-Filme OHNE Flackern digitalisiert hat weiß das. ;) Hier eine Anleitung wie ich das machen würde. Dann spart man den Speicherplatz für Runde 1. https://www.spacelapse.net/de/Zeitrafferfotografie_Tutorials/Einzelbilder_zu_Zeitrafferfilm_zusammenfuegen.html Virtual Dub (mod) ist sowieso das beste Programm was es gibt für Video-Bearbeitung. Man muss aber damit umgehen können.
Sven S. schrieb: > möchte eine Animation aus ca. 3000 Einzelbildern erstellen. Framerate > wären 25fps. Die Einzelbilder sind schwarz/weiss (keine Graustufen) im > Format 640x480. Das Ganze soll am Ende in ein übliches Videoformat > münden, wie z.B. *.mp4 und möglichst wenig Datenvolumen haben. Einen für diese Anwendung optimalen Kompressor wird es wohl nicht von der Stange geben. Aber wenn das Ergebnis in einem MP4-Container abgelegt werden soll, wäre es überaus sinnvoll einen Kompressor zu wählen, der gut und problemlos in den MP4-Container passt. Also z.B. H.264 oder H.265. > Das Besondere an der Animation: Sie beginnt und endet mit jeweils einem > Bild, das 2sec. angezeigt wird und die 3000 Bilder dazwischen > unterscheiden sich jeweils nur in einem einzigen Pixel! Alle modernen Videokompressoren entfernen Redundanz sehr gut. Genau dafür wurden sie schließlich geschaffen... > Welche Software leistet was ich will? Jede, die moderne Kompressoren benutzen kann und den MP4-Container unterstützt. Was denn sonst?
Zaubern kann natürlich auch H.264 nicht, 8 Byte wäre wohl das Minimum pro Frame bei reinem Standbild 640x360, nur 19 Bit davon sind "Bilddaten", der Rest Header. Die gelegentlich erforderlichen Vollbilder (üblich sind heute alle 10s) sind natürlich größer, je nach Bildinhalt (<1KiB bei reinem Schwarz). Das gilt auch nur bei einem reinen H.264 Stream, sobald noch ein Container wie MP4 darum kommt werden die Header immer größer. Bei solchen "seltsamen" Filmen geht das meiste eh für die Header drauf, normalerweise fallen die halt nicht auf sobald die Frames größer ein paar 100 Byte sind. Damit kann der 10h YouTube-Film nicht wirklich kleiner als 7MiB sein, dafür sind die 24,3 MiB gar nicht soo schlecht.
Schlaumaier schrieb: > Du musst in der Regel 2 Runden drehen. > Runde 1 : Alle Einzelbilder werden zu einen RAW-Video zusammen gefügt. > Runde 2 : Das RAW-Video wird nun mit einen Kompressionsprogramm mit > Hilfe eines Codecs zusammen gefügt. OK, werde ich mal testen. Bei 3000 Bildern a. 640x480 wären das ca. 115 MB. Bin mal gespannt, welche Datenmenge am Ende entsteht. Und es darf natürlich kein Pixel untergehen. Momentan läuft das Ganze mit ein paar Zeilen Basic. Nach CLS schreibe ich in einer Schleife mit PLOT x,y die einzelnen Pixel. Dafür benötige ich 6000 Byte für die x/y-Koordinaten. Dann noch zwei s/w-Bilder am Anfang und am Ende und fertig. Für diese Animation müsste ich allerdings einen Interpreter mit liefern, den sich die Leute installieren müssten. Geht natürlich gar nicht.
Sven S. schrieb: > Schlaumaier schrieb: >> Du musst in der Regel 2 Runden drehen. >> Runde 1 : Alle Einzelbilder werden zu einen RAW-Video zusammen gefügt. >> Runde 2 : Das RAW-Video wird nun mit einen Kompressionsprogramm mit >> Hilfe eines Codecs zusammen gefügt. > > OK, werde ich mal testen. Bei 3000 Bildern a. 640x480 wären das ca. 115 > MB. Hast du flic inzwischen ausprobiert? Oder mal gemacht, was dir oben schon empfohlen wurde. Einfach mal alle verfügbaren Codecs durchtesten? Nimmt dazu die libavcodec Bibliothek und ein passendes Programm, dann hast du auf einen Schlag dutzende unterstützte Codecs, die du durchtesten kannst. https://de.wikipedia.org/wiki/Libavcodec
Sven S. schrieb: > Für diese Animation müsste ich allerdings einen Interpreter mit liefern, > den sich die Leute installieren müssten. Geht natürlich gar nicht. Genau das ist auch das Problem beim Video: Wenn es tatsächlich einen optimalen Codec für das Problem geben sollte, hilft dir das echt garnix. Denn er wird bei den potentiellen Rezipienten erstmal nicht verfügbar sein. D.h.: dein Video wird hübsch klein, aber fast niemand kann es sehen...
Nano schrieb: > Ich benutze hier einfach die Logik. > Ein Video zeigt in der Regel etwa 25 fps, manchmal auch 60 fps an, > darauf sind die Codecs optimiert. Nicht alles, was logisch klingt, ist richtig. h.264 weiss nichts von fps. Der h.264 Elementardatenstrom rechnet nur mit Frames. Mit welcher konstanten/variablen Rate die codiert/angezeigt werden, ist völlig egal. Erst der übergeordnete Layer, der da einen Stream (PES, TS, MOV, ...)( drausmacht, packt da noch irgendwie einen Timestamp dazu. Das einzige, wo die fps mit eingehen können, ist die Bestimmung der Komprimierungskoeffizienten anhand der der gewünschten Bitrate. Damit ist es kein Problem, auch mit h.264 unregelmässige Frameraten zu erzielen. Man braucht eigentlich ausser am Anfang auch keine richtige GOP (also Vollbild/IDR). Wenn man nicht seeken will und es auch keine Übertragungsfehler gibt, reicht einmal ein IDR-Frame und dann nur noch P-Frames. B brauchts nicht. Das geht so stunden/tagelang mit P-only ohne Degradierung des Bilds. Für den aktuellen Fall wäre das also das Mittel der Wahl. Da flackert dann auch nichts bei ungünstiger Wahl der IDR-Frame-Kompression.
Sven S. schrieb: > Momentan läuft das Ganze mit ein paar Zeilen Basic. Nach CLS schreibe > ich in einer Schleife mit PLOT x,y die einzelnen Pixel. Dafür benötige > ich 6000 Byte für die x/y-Koordinaten. Dann noch zwei s/w-Bilder am > Anfang und am Ende und fertig. > > Für diese Animation müsste ich allerdings einen Interpreter mit liefern, > den sich die Leute installieren müssten. Geht natürlich gar nicht. Schon mal was von JavaScript gehört? Da werden ganze PDF interpreter oder Apple II Emulatoren (inkl. Basic) ausgeliefert. Wir drehen uns im Kreis... FFMPEG kann aus einem Haufen Bildern ein Video machen und FFMPEG kann sehr viele Codecs: https://stackoverflow.com/questions/24961127/how-to-create-a-video-from-images-with-ffmpeg Wie schön öfter gesagt wurde, viele Videobearbeitungsprogramme können mit Ordnern voller Bilder umgehen, weil das ein übliches "Video"Format in der Filmindustrie ist.
Schlaumaier schrieb: > Runde 1 : Alle Einzelbilder werden zu einen RAW-Video zusammen gefügt. Für den ersten Test habe ich mal ein paar RAW-Bilder erzeugt und abgespeichert. Nun kann VirtualDubMOD mit den Bildern nichts anfangen. Was nicht wirklich verwundert, denn das sind 38400 Byte reiner Bildinhalt ohne jede weitere Information. Ein Bild könnte ebenso 1280x240 haben, das würden ebenfalls 38400 Byte ergeben. Was muss man wo dazuschreiben, damit es ein RAW-Bild wird?
Sven S. schrieb: > Schlaumaier schrieb: >> Runde 1 : Alle Einzelbilder werden zu einen RAW-Video zusammen gefügt. > > Für den ersten Test habe ich mal ein paar RAW-Bilder erzeugt und > abgespeichert. Nun kann VirtualDubMOD mit den Bildern nichts anfangen. > Was nicht wirklich verwundert, denn das sind 38400 Byte reiner > Bildinhalt ohne jede weitere Information. Ein Bild könnte ebenso > 1280x240 haben, das würden ebenfalls 38400 Byte ergeben. > > Was muss man wo dazuschreiben, damit es ein RAW-Bild wird? Das ist die falsche Frage. Liegt vermutlich daran, dass Schlaumaier diese falsche Begrifflichlichkeit überhaupt erst in's Spiel gebracht hat. Der meinte eigentlich: unkomprimiertes Video. Das ist nicht "Raw", sondern hat natürlich mindestens irgendeinen Header, der das Bildformat beschreibt. Im Falle von VirtualDubMod also typisch einen AVI-Header. Und wie du richtig erkannt hast, muss er eben dieses Format irgendwo her bekommen. Und das geschieht bei VirtualDubMod sehr wahrscheinlich dadurch, dass die Bilder im *.bmp-Format vorliegen müssen. Das enthält dann u.A. einen BitmapImageHeader, der im Übrigen später dann ganz magisch nahezu unverändert im AVI-Header wieder zu finden ist. ;o) Du mußt also vor deine rohen Bilddaten einen BitmapFileHeader und einen BitmapInfoHeader schreiben, natürlich jeweils mit passenden Werten befüllt. Optional kannst du auch noch eine Palette mit zwei RGBTriple-Einträgen hinzupacken, wenn du deine monochrome Bitmap nicht in Schwarz/Weiß, sondern in zwei anderen Farben erscheinen lassen willst. Eigentlich ist auch für die Bilddaten selber noch eine Sache zu beachten (Alignment), aber bei den gegebenen Dimensionen ist das automatisch passend erfüllt, weil 640 freundlicherweise durch 32 ganzzahlig teilbar ist. Eine Beschreibung aller genannten Strukturen kannst du hier finden: https://de.wikipedia.org/wiki/Windows_Bitmap
Erst mal vielen Dank für deine ausführliche Beschreibung. Also habe ich mal meinen BILDINHALT in die Zwischenablage kopiert, in MS-Paint importiert, als Monochrom-Bitmap abgespeichert und mir das Bild dann im HEX-Editor angeschaut. Also ich sehe den Header und eine gewisse Ähnlichkeit, was die Beschreibung im Wiki angeht. Mit Erstaunen sehe ich am Ende des Bitmaps nochmals 14 Byte, die sicher nicht dem Bildinhalt zuzuordnen sind. Von einem Datenblock am Ende der Bilddaten lese ich im Wiki nichts. Oder sehe ich den Wald vor Bäumen nicht? Dann sehe ich die Menge der Bilddaten nicht an Adresse 2, sondern an Adresse 3, dazu der Hinweis im Wiki "unzuverlässig" ?? Verstehe auch nicht wirklich, wieso das Ganze so kompliziert sein muss. Ich habe eine Auflösung von 640x480 und das Bild ist monochrom. Wozu der ganze Flotz :-(
Also doch noch ein Versuch: Das Bildformat mit Hex AA gefüllt und über die Zwischenablage in MS-Paint kopiert und als Monochrom-Bitmap abgespeichert. Das Bild dann im Hex-Editor angeschaut. Diesmal hörte die Datei auch mit AA auf. Mit AA grenzt sich die Bildinformation eindeutig vom Header ab, was bei 00 oder FF nicht unbedingt der Fall ist. Denn der Header endete hier mit 00 (entspricht schwarz) und FF (entspricht weiß) im Wechsel :-( Dann einfach den Header (hier 62 Byte) vor die Bildinformation setzen und die erzeugte Datei *.bmp nennen. Das Bild wird nun von allen gängigen Grafiktools akzeptiert.
Mittlerweile konnte ich mit VirtualDub einige Mustervideos erstellen. Es fällt auf, dass viele Codecs vom VLC-Player nicht abgespielt werden können. Also wertlos. Am Ende blieb Xvid und H.264, die meine monochromen Einzelbilder verlustfrei komprimieren. Wobei H.264 nur 38-47% Volumen produziert. Konkret benötigt mein aus 3.000 Bildern bestehendes Video unter H.264 um 600 kB. Etwas seltsam ist, dass die gleiche Anzahl Bilder mehr Volumen erzeugen, wenn das Video mit geringerer Framerate (100, 50 und 25) erzeugt wird. Ich sehe 553, 609 und 636 kB. Macht irgendwie keinen Sinn.
Ich hänge die Bilder (nur mit JPEG probiert) erstmal mit mencoder (mplayer) zu einem MJPEG-Film (im AVI-Container?) zusammen, der komprimiert erstmal nix. Da ist dann schon die Framerate im Header und jeder Player kann das abspielen und jeder gute Videoeditor/Konverter/Encoder nimmt die als Quelldatei zur Weiterverarbeitung.
Habe u.a. ein RAW-Video mit 2GB erzeugt und das dann kreuz und quer genudelt. Von den bisherigen 600kB für 3000 Bilder blieben die Ergebnisse weit entfernt. 200 Byte braucht es offensichtlich jedes mal, um im nächsten Bild ein weiteres Pixel einzuschalten. Was das Tempo der Konvertierung angeht, bleibt VirtualDub ungeschlagen. Ich sehe da durchgängig den Faktor 10 in der Geschwindigkeit.
Sven S. schrieb: > Was das Tempo der Konvertierung angeht, bleibt VirtualDub ungeschlagen. > Ich sehe da durchgängig den Faktor 10 in der Geschwindigkeit. Meines Wissens sind bei dem Programm die entsprechenden Routinen in Assembler geschrieben. Dann rennt es eben.
640x480 auf das doppelte (oder dreifache) vergrößern: 640x480 -> 1280x960 -> 1920x1440 ->2560x1920... dadurch wird der eine Pixel ein 2x2, 3x3 oder gar 4x4 großer Pixelfleck. Über den kann man dann einen H264 Codec im TwoPass legen. Ich würde denken, dass man da mit >2000kBit/s gute Resultate bekommen kann. Ein 1x1 Pixel wird bei verlustbehafteter Kompression untergehen, den vergößerten Pixelhaufen kann man jedoch gut sehen... Mir fällt jedenfalls kein handeslüblicher Monitor/Fernseher ein, der ein 480x640Pixelbild ohne Antialiasing darstellen kann. (Bei FullHD 1920Pixel, ist dein Einzelpixel zwar 3 Pixel breit, aber 2,25 Pixel hoch) Camcoder
Sven S. schrieb: > Mittlerweile konnte ich mit VirtualDub einige Mustervideos erstellen. Es > fällt auf, dass viele Codecs vom VLC-Player nicht abgespielt werden > können. Also wertlos. > > Am Ende blieb Xvid und H.264 I told you so... > die meine monochromen Einzelbilder > verlustfrei komprimieren. Nein, das tuen sie natürlich nicht. Sowohl Xvid als auch H.264 sind natürlich verlustbehaftete Codecs. > Wobei H.264 nur 38-47% Volumen produziert. > Konkret benötigt mein aus 3.000 Bildern bestehendes Video unter H.264 um > 600 kB. Das ist doch für 2 Minuten Video schon ein recht gutes Ergebnis... > Etwas seltsam ist, dass die gleiche Anzahl Bilder mehr Volumen erzeugen, > wenn das Video mit geringerer Framerate (100, 50 und 25) erzeugt wird. > Ich sehe 553, 609 und 636 kB. Macht irgendwie keinen Sinn. Das liegt daran, dass du nicht verstehst, wie diese Codecs funktionieren... Daran wird auch liegen, dass du die 600kB bei dem Material nicht nennenswert unterbieten kannst. Zumindest mit H.264 im MP4-Container sollte deutlich weniger drin sein, wenn man den Encoder und den Muxer passend konfiguriert. Noch ein Tip: VirtualDub ist schick, um erstmal überhaupt ein Video aus den Enzelbildern zu erzeugen. Für diesen Schritt sollte man einen verlustfreien Codec nehmen. Im einfachsten Fall "raw". VirtualDub ist aber weniger schick, um dieses Video dann bestmöglich in einem aktuellen Format zu komprimieren und optimal in einen aktuellen Container zu packen. Dazu ist es schlicht viel zu alt. Dafür nutzt man andere Software. Leider hat die dann erstens typisch keine brauchbare grafische Benutzeroberfläche und läuft zweitens eher nur widerwillig unter Windows, wenn überhaupt...
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.