Forum: PC Hard- und Software Video aus Einzelbildern erstellern, wie machen?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Marek N. (bruderm)


Bewertung
2 lesenswert
nicht lesenswert

von Filmschneider (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Schlaumaier (Gast)


Bewertung
-6 lesenswert
nicht lesenswert
Die meisten machen das mit den Windows Movie Maker.

Der ist sogar für Lau.  Anleitungen wie man es macht gibts über Freund 
Google.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ach ja und MNG solltest du dir auch mal anschauen:
https://de.wikipedia.org/wiki/Multiple-Image_Network_Graphics

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Sven S. (Gast)


Bewertung
3 lesenswert
nicht lesenswert
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.

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Jim M. (turboj)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Schlaumaier (Gast)


Bewertung
-4 lesenswert
nicht lesenswert
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.

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Yalu X. (yalu) (Moderator)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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."

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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...

von malsehen (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schau mal nach fli bzw. flc
Die konnten das mal ganz gut.
Ob es dafür noch Player gibt, keine Ahnung.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Uwe R. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von ich (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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)

von Schlaumaier (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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.

von c-hater (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
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?

von ich (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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.

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Nano (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von c-hater (Gast)


Bewertung
-2 lesenswert
nicht lesenswert
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...

von Georg A. (georga)


Bewertung
1 lesenswert
nicht lesenswert
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.

von Christoph Z. (christophz)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
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

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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 :-(

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von batman (Gast)


Bewertung
2 lesenswert
nicht lesenswert
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.

von Sven S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.