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
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
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.
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.
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...
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.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Announcement: there is an English version of this forum on 
Thread beobachten
Seitenaufteilung abschalten