Forum: PC-Programmierung Speicherplatzbedarf Ton, Bild und Video


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 Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
Hallo allerseits,

Man kann ja beim Programmieren einer Adressverwaltung ziemlich exakt 
abschätzen, wie viel Speicherplatz die Daten einnehmen werden.
Wie verhält es sich aber, wenn Bild und Ton-Daten gespeichert werden 
sollen.
Wovon ist es z. B. Abhängig, wie viel Speicherplatz eine Tonaufnahme 
einnimmt, die man mit einem Mikrofon aufgenommen hat, wie viel ein 
Videofilm oder Bilddatei?

Gruß an alle

von Reinhard S. (rezz)


Bewertung
0 lesenswert
nicht lesenswert
Logischerweise von der Qualität. Auflösung, Abtastrate, Codec. Audio ist 
da noch recht einfach, bei Video ist die Datenrate schon schwankender.

von Torben S. (Firma: privat) (torben_25)


Bewertung
-6 lesenswert
nicht lesenswert
Audiomaterial besteht doch aus einer Menge von Einzelbildern. Die Menge 
der Einzelbilder pro Sekunde multipliziert mit der Auflösung, der 
Farbtiefe und der Dauer reduziert um den Kompressionsfaktor müsste dann 
ja die Größe der Videodatei ergeben.

von Theor (Gast)


Bewertung
2 lesenswert
nicht lesenswert
Torben S. schrieb:
> Audiomaterial besteht doch aus einer Menge von Einzelbildern.
Da habe ich gewisse Zweifel daran. :-)
(OK. Vermutlich nur ein Lapsus).

> Die Menge
> der Einzelbilder pro Sekunde multipliziert mit der Auflösung, der
> Farbtiefe und der Dauer reduziert um den Kompressionsfaktor müsste dann
> ja die Größe der Videodatei ergeben.

Der Kompressionsfaktor ist nicht konstant. Ich gehe soweit zu behaupten, 
dass er es eigentlich bei keinem Komprimierungsverfahren ist.

von Torben S. (Firma: privat) (torben_25)


Bewertung
-2 lesenswert
nicht lesenswert
Theor schrieb:
> Torben S. schrieb:
>> Audiomaterial besteht doch aus einer Menge von Einzelbildern.
> Da habe ich gewisse Zweifel daran. :-)
 Warum? Ist das nicht so?

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Theor schrieb:
>> Torben S. schrieb:
>>> Audiomaterial besteht doch aus einer Menge von Einzelbildern.
>> Da habe ich gewisse Zweifel daran. :-)
>  Warum? Ist das nicht so?

Es würde mich sehr wundern, falls AUDIOmaterial aus BILDERn bestehen 
sollte.

Hingegen hielte ich aus TÖNEn bestehendes Audiomaterial und aus Bildern 
bestehendes VIDEOmaterial durchaus für eine Bestätigung meines 
Weltbildes.

Wie auch immer: Aufstehen, Krönchen zurechtrücken und weiter gehts. :-)

von oszi40 (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Reinhard S. schrieb:
> Audio ist
> da noch recht einfach, bei Video ist die Datenrate schon schwankender.

Es ist ein Unterschied ob die nur 90 Minuten 1000Hz und ein eine total 
blaue Tafel oder ein Fußballspiel mit viel Bewegung und Dynamik 
komprimieren müssen.

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
Ich habe mit Blender eine Szene gerendert und unter den Einstellungen 
festgelegt, dass die Szene als FFMPEG Video decodiert werden soll. 
Alternativ hätte ich auch Einzelbilder erzeugen und später mit Blender 
auch abspielen können. Mein Gedanke war jetzt, dass der Unterschied 
zwischen Einzelbildern und FFMPEG Videos in der Kodierung liegt. Das 
Videomaterial ist sicher H.265 kodiert? Kann mir da irgendwie jemand 
klarheit schaffen? Wie hängen denn die Begriffe Einzelbild, H.265 und 
Videoformate wie AVI zusammen?

: Bearbeitet durch User
von Hennes (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo

Reinhard S. schrieb:
> Logischerweise von der Qualität. Auflösung, Abtastrate, Codec.

Wenn es denn so einfach wäre.
Klar das 4k 60fps Video hat pro Minute einen wesentlichen höheren 
Speicherplatzbedarf als ein wegen seiner "Auflösung" absolut nutzloses 
360p Video auf Youtube und Co.

Aber leider hängt es auch deutlich vom Bildinhalt ab. Bei TV 
Aufzeichnungen (Quelle SAT TV SD und HD) mittels den PC ist zumindest 
bei mir recht klar ersichtlich das Bilder (also meist Animationsfilme) 
die 100% aus dem Computer stammen den geringsten Speicherplatzbedarf - 
bei natürlich gleichen Codec, Auflösung und Datenrate seitens der Sender 
haben.
Danach folgen klassische Zeichentrickfilme (Was wohl aber auch daran 
liegt das diese oftmals noch als klassisches 4:3 Format vorliegen) und 
den größten Speicherbedarf haben dann Realaufnahmen wobei es mir so 
vorkommt als wenn Material was noch analog Aufgezeichnet wurde 
(Insbesondere noch auf chemischen Film) - trotz natürlich Digitalen TV 
Sendesignal - da noch mal ein kleines bisschen  mehr Speicherbedarf hat 
als was digital Aufgezeichnet wurde.

Also:
Video kann man abhängig von Codec und der Datenrate nur ungefähr vorher 
einschätzen - wenn dann die Datenrate Variabel ist (wird leider gern 
gemacht eben um Platz bzw. Bandbreite zu sparen) wird es noch mehr zu 
eine groben Schätzung.

Hennes

von Walter T. (nicolas)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Wie verhält es sich aber, wenn Bild und Ton-Daten gespeichert werden
> sollen.

Man kann es nicht abschätzen. Videodaten werden immer größer, weil die 
Sensoren immer höhere Auflösung und Bildrate schaffen und immer billiger 
werden (->  mehr Videos). Videodaten werden immer kleiner, weil es immer 
bessere Codecs und Filter gibt.

Also implementiert man die Videodatenverwaltung so, dass sie die 
maximalen Speicherplatzgrenzen des Betriebssystems (und eventuell 
zukünftiger Erweiterungen) ausnutzen kann, insbesondere über Block-, 
Datei-, Partions-, Laufwerks-, und sonstige Grenzen hinweg.

: Bearbeitet durch User
von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
Wie verhält es sich aber, wenn man z. B. mit dem Panasonic HC-X 1500 
Camcorder einen 10 Minütigen Film aufnimmt? Die Cam hat eine 
Videoauflösung von 3840x2160@60p.

Ich rechne mal nach...

3840 x 2160 x 10 Minuten x 60 Sekunden x 60 Hz

Das macht 35 GiB. Dann wird darauf ja noch eine Videokompression 
angewand (H.265?). Die könnte das Videomatrial um 50% verringern. Dann 
wäre das video 17,5 GiB groß. Ist das unter einer sehr vereinfachten 
Perspektive richtig?

von Felix U. (ubfx)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Ich rechne mal nach...
>
> 3840 x 2160 x 10 Minuten x 60 Sekunden x 60 Hz
>
> Das macht 35 GiB.
>Ist das unter einer sehr vereinfachten Perspektive richtig?

Wenn GiB für Gibi-Byxel steht, dann ja. Für den Informationsgehalt wäre 
vielleicht noch die Farbtiefe der einzelnen Pixel relevant ;)

: Bearbeitet durch User
von Walter T. (nicolas)


Bewertung
1 lesenswert
nicht lesenswert
Torben S. schrieb:
> Die könnte das Videomatrial um 50% verringern.

Das ist sehr pessimistisch.

Torben S. schrieb:
> Ist das unter einer sehr vereinfachten
> Perspektive richtig?

Wenn die Frage so konkret ist: Probier es aus. Filme mit Deiner Kamera 
1h Fernseher ab. Am besten einen Kanal mit viel Werbung. Danach hast Du 
eine solide Hausnummer.

Ich bin sowieso immer erstaunt, wieviel Datenreduktion selbst beim 
gleichen Codec drin ist. Wenn ich ein 1,4-GB-Video bei Youtube hochlade, 
kann ich es ohne sichtbaren Qualitätsverlust mit ca. 50 MB wieder 
herunterladen. In Adobe Lightroom habe ich noch keinen Parametersatz 
gefunden, der ähnlich gut ist oder nur dicht dran.

Wobei ich allerdings auch davon ausgehe, dass Youtube&Co. die Könige der 
Videokompression sind, weil jedes halbe Prozent viel Geld spart.

: Bearbeitet durch User
von ? DPA ? (Gast)


Bewertung
3 lesenswert
nicht lesenswert
Torben S. schrieb:
> Kann mir da irgendwie jemand
> klarheit schaffen? Wie hängen denn die Begriffe Einzelbild, H.265 und
> Videoformate wie AVI zusammen?

Konvertierprogramme: ffmpeg, avconf, etc.

Containerformate:
 * Video + Audio + Subs + etc.: mp4, mkv, webm, etc.
 * (Hauptsächlich) Audio: ogg, mp3, wav, etc.
 * etc.

Codecs:
 * Video: H.264, H.265, VP9, etc.
 * Audio: AAC, FLAC, Opus, Vorbis, PCM, etc.

Kompressionsarten: Keine, Verlustfrei, Verlustbehaftet

Nicht alle Kombinationen von oben sind möglich. mkv müsste jede 
beliebige Codeckombination unterstützen, webm ist mkv aber mit einem 
Subset erlaubter Codecs, wav, ogg, mp3, mp4, haben glaub ich jeweils 
eine kleinere Auswahl an Codecs, für die definiert ist, wie die darin zu 
speichern sind.

Die Containerformate kümmern sich darum, mehrere Audio, Video, Subtitel, 
etc. Tracks sowie Metadaten zusammenzufassen und zu synchronisieren, 
aber eher selten um die Komprimierung.

Die Codecs kümmern sich darum, die eigentlichen Nutzdaten zu 
repräsentieren, und oft auch zu komprimieren.

Eine Ton/Video/etc. spur codiert in einem Codec kann man oft auch ohne 
Container speichern (z.B. .aac, .flac, etc.), ob das immer geht weiss 
ich jetzt gerade aber spontan nicht.

Die der Kompression in Videocodecs ist mittlerweile relativ Komplex, 
normalerweise werden die Einzelbilder / Frames nicht einzeln 
Komprimiert. So wie z.B. 2 nebeneinander liegende Pixel oft ähnliche 
Farben haben, sind Pixel von aufeinanderfolgenden Frames oft auch 
ähnlich. Heutzutage versucht man auch Translationen, Rotationen, etc. 
vom Bild zu erkennen und zu nutzen, und noch vieles mehr. Häufig werden 
aber von zeit zu zeit auch mal unabhängige vollständige Frames 
inkludiert, so ein Punkt ist dann der Anfang eines neuen Key frames. 
Fürs Streamen / Seeking ist es wichtig, von zeit zu zeit solche zu 
haben.

Torben S. schrieb:
> Wovon ist es z. B. Abhängig, wie viel Speicherplatz eine Tonaufnahme
> einnimmt, die man mit einem Mikrofon aufgenommen hat, wie viel ein
> Videofilm oder Bilddatei?

Das ist nicht trivial zu beantworten. Es hängt stark ob Keine, 
Verlustfreie, oder Verlustbehaftete Kompression verwendet wird, und ob 
sich das Bild schnell & stark verwendet oder nicht.

Keine sind recht trivial, dort ist das Verhältnis normalerweise einfach 
linear.

Verlustfreie Komprimierung ist toll, wenn man Platz sparen will, aber 
keine Kompressionsverluste will. Das könnte z.B. beim häufigen 
Konvertieren und Bearbeiten von Videos sinnvoll sein, wo sich das sonst 
jedes mal immer weiter verschlechtert. Zeit und Rechenleistungsbedingt 
sucht man oft nicht die Perfekte Lösung, das dauert zu lange. Wenn man 
keine Details verlieren will, gibt es aber halt grenzen, wie weit man 
runter gehen kann. Wenn die verfügbare Datenrate stark begrenzt ist, 
kann das Problematisch werden.

Bei den Verlustbehafteten Kompression muss man eigentlich unterscheiden 
zwischen solcher, die nicht bemerkbar sein sollte, und der, die man 
braucht, um noch mehr Speicherplatz zu sparen. Ersteres sind Dinge wie 
das Entfernen von Tonbereichen, die Menschen nicht hören können, oder 
auch reduzieren der Details in dunklen Bildbereichen (welche meistens im 
Hintergrund sind). Letzteres, naja, da reduziert man einfach die 
Details. Wie genau ist jeweils etwas unterschiedlich, aber Audio und 
Video kann man einer Fourier Transform unterziehen, in seine Frequenzen 
zerlegen, und dort kann man dann einfach den Wertebereich und damit die 
Auflösung reduzieren, und entsprechend viele Details gehen dann verloren 
(https://demonstrations.wolfram.com/ImageCompressionViaTheFourierTransform/preview.mp4). 
Bei Bildern und Videos kommt dafür anscheinend oft DCT zum einsatz: 
https://de.wikipedia.org/wiki/Diskrete_Kosinustransformation
Damit kann man dann eigentlich tatsächlich die Kompression der 
verfügbaren Datenrate anpassen, was z.B. bei mp3 oft gemacht wird. Sowas 
wäre dann theoretisch z.B. bei Telefonkonferenzen und Videostreams, aber 
auch Speichermedien mit begrenzter Lesegeschwindigkeit, nützlich. In dem 
Fall ist die Frage dann aber halt weniger wie viel Speicherplatz nimmt 
die Aufnahme nach der Kompression ein, sondern mehr, wie schlecht darf 
es sein, und wie viel Speicherplatverbrauch will man. Obwohl, auch da 
gibt es eine untere Grenze, Frequenz/Detailreichtum ist ja nur eine 
Eigenschaft, neben Grösse und Farbtiefe, auch wenn diese zusammenhängen.

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
Die Farbtiefe steht leider nicht in der Kamera-Spezifikation. Geht man 
da immer von 24 Bit aus?

Wie ist denn jetzt aber der Zusammenhang zu MPEG und Windows-Media-File

Walter T. schrieb:
> Wenn die Frage so konkret ist: Probier es aus. Filme mit Deiner Kamera
> 1h Fernseher ab. Am besten einen Kanal mit viel Werbung. Danach hast Du
> eine solide Hausnummer.

Und mit viel Werbung ist die Wahrscheinlichkeit höher, dass ich mich den 
60 p nähere? Diesbezüglich habe ich die technische Umsetzung in einer 
Kamera noch nicht verstanden. Eine Vermutung ist, wenn sich viel bewegt, 
steigen die FPS? Eine andere: Die Kamera filmt konstant mit 60p.

@DPA Den Artikel klebe ich mir in meinen Schulhefter :)

von Felix U. (ubfx)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Und mit viel Werbung ist die Wahrscheinlichkeit höher, dass ich mich den
> 60 p nähere? Diesbezüglich habe ich die technische Umsetzung in einer
> Kamera noch nicht verstanden. Eine Vermutung ist, wenn sich viel bewegt,
> steigen die FPS? Eine andere: Die Kamera filmt konstant mit 60p.

Die Kamera filmt sowieso mit 60 Hz. Die Frage ist, wie viel davon nach 
der Kompression übrig bleibt.

Guck doch einfach mal in die technischen Daten von deinem Panasonic 
Camcorder, da steht alles relevante drin. Und genauer wirds durch 
ausprobieren auch nicht.

Hier mal zwei kleine Ausschnitte, da wird dir sogar die Bitrate 
angegeben. Was willst du mehr?

MOV: [4:2:0 8-B] UHD 3840x2160 59.94p/50.00p 150M: Durchschnitt 150 Mbps 
(VBR)
und
HEVC: [4:2:0 10-Bit] UHD 3840x2160 59.94p/50.00p HEVC 100M: Durchschnitt 
100 Mbps (VBR)

von Klugscheisser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Der Kompressionsfaktor ist nicht konstant. Ich gehe soweit zu behaupten,
> dass er es eigentlich bei keinem Komprimierungsverfahren ist.

Bei einer Kompression der Amplitude, z.B. u-law, ist das aber so.
Du solltest dringend dein Weltbild erweitern, bevor du solche
Behauptungen aufstellst.

von mahi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Die Farbtiefe steht leider nicht in der Kamera-Spezifikation.
Doch, wenn die Kamera was taugt, steht's drin...

> Geht man
> da immer von 24 Bit aus?

Nein. Bei komprimierten Video kann man quasi davon ausgehen, dass es 
Farbunterabgetastet ist. Das menschliche Auge kann 
Helligkeitsunterschiede besser auflösen als Farben, daher wird die 
Farbinformation reduziert. Beispielsweise bedeutet 4:2:2, dass es zwar 
für jeden Pixel eine Helligkeitsinformation gibt, aber die 
Farbinformation teilen sich zwei benachbarte Pixel. Bei 4:2:0 (was 
üblicherweise bei komprimiertem Video verwendet wird) sind es sogar vier 
Pixel (im Quadrat), die sich die Farbinformation teilen.
Daher sind es bei "normalem" Video 10 bit/pixel, bei HDR/DeepColor 
entsprechend mehr.

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt Faustregeln für gewisse Dateien, Komprimierverfahren , aber 
grundsätzlich kann man damit NICHT planen.

Meine Nikon versucht es. Aber selbst die bekommt bei gleicher 
Einstellung nur Schätzwerte hin.

Der Grund ist das die Komprimierung von Objekt selbst abhängt. Einfach 
gesagt ein Bild von einer weißen Fläche verbraucht weniger als ein Bild 
von einer Landschaft.

Bei den meisten "gängigen" Videoformaten verbraucht der TON wesentlich 
mehr Speicherplatz als das Bild. Der Grund sind die Änderungen die sich 
im Stream ergeben. Und die Anzahl der Masterbilder.

Also vergiss die Planung.

Ton-Faustregel.

128 Bitrate mp3 = 1 min = 1 MB
128 Bitrate wav = 1 min = 10 MB

Bei höheren Werten kann man das angleichen.

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
Schlaumaier schrieb:
> Einfach
> gesagt ein Bild von einer weißen Fläche verbraucht weniger als ein Bild
> von einer Landschaft.

Das ist total interessant. Man denkt, für jedes Pixel stehen z. B. 24 
Bit zur Verfügung, egal, ob ich eine weiße Wand oder eine Landschaft 
fotografiere. Das wirft natürlich neue Fragen auf, aber ich halte mich 
lieber zurück.

Vielen Dank für Eure Hilfe.

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Das ist total interessant. Man denkt, für jedes Pixel stehen z. B. 24
> Bit zur Verfügung, egal, ob ich eine weiße Wand oder eine Landschaft
> fotografiere.

Das ist auch völlig richtig.  Wenn die Software aber ganz viele weiße 
Pixel auf einen Haufen erkennt, dann speichert sie die nicht alle 
einzeln, sondern speichert einfach gesagt. "Jetzt kommen 50 weiße 
Pixel". Das spart Speicherplatz.

Oder was meinst du, warum nicht alle Fotos mit eine Kamera aufgenommen, 
bei gleichen Parametern den gleichen Speicherplatz verbrauchen. ??

OK. Für die Experten hier. Die Komprimierverfahren sind wesentlich 
komplizierter und der Formeln sogar geschützt. Ich wollte nur meine 
Aussage verdeutlichen.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Schlaumaier schrieb:
> Bei den meisten "gängigen" Videoformaten verbraucht der TON wesentlich
> mehr Speicherplatz als das Bild.

Das würde mich eher wundern.

> Der Grund sind die Änderungen die sich im Stream ergeben. Und die Anzahl der
> Masterbilder.

Du meinst die Keyframes.

> Also vergiss die Planung.
>
> Ton-Faustregel.
>
> 128 Bitrate mp3 = 1 min = 1 MB
> 128 Bitrate wav = 1 min = 10 MB

Was soll "128 Bitrate wav" sein? Was du wohl meinst, ist unkomprimiertes 
Audio in CD-Qualität, also 16 Bit Stereo bei 44,1 kHz Samplerate.
Das ergibt ca. 1,4 Mbit/s bzw. gut 10 MByte/min. Die 128 kBit/s des mp3 
sind entsprechend kapp 1/10 davon. Video mit 128 kBit/s wäre höchsten im 
Briefmarken-Format sinnvoll.

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Schlaumaier schrieb:
>> Bei den meisten "gängigen" Videoformaten verbraucht der TON wesentlich
>> mehr Speicherplatz als das Bild.
>
> Das würde mich eher wundern.

Mach das. Die Videos die ich meist schneide (TV-Aufnahmen) mit 
Virtualdub verbraucht das mp3-Format für das Audio bedeutend mehr 
Speicher als das Video.

Kann durchaus sein das sich das bei hochauflösenden Aufnahmen ändert, 
aber ich sprach ja von "gängigen" Formaten.



Rolf M. schrieb:
> Video mit 128 kBit/s wäre höchsten im
> Briefmarken-Format sinnvoll.

Da steht doch deutlich und von dir Zitiert : TONFORMAT

Die Größe eine Videos ist doch unwichtig beim Ton !!!

von Torben S. (Firma: privat) (torben_25)


Bewertung
0 lesenswert
nicht lesenswert
Schlaumaier schrieb:
> Das ist auch völlig richtig.  Wenn die Software aber ganz viele weiße
> Pixel auf einen Haufen erkennt, dann speichert sie die nicht alle
> einzeln, sondern speichert einfach gesagt. "Jetzt kommen 50 weiße
> Pixel". Das spart Speicherplatz.

Das Aufstehen hat sich heute für mich gelohnt.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Schlaumaier schrieb:
> Rolf M. schrieb:
>> Schlaumaier schrieb:
>>> Bei den meisten "gängigen" Videoformaten verbraucht der TON wesentlich
>>> mehr Speicherplatz als das Bild.
>>
>> Das würde mich eher wundern.
>
> Mach das. Die Videos die ich meist schneide (TV-Aufnahmen) mit
> Virtualdub verbraucht das mp3-Format für das Audio bedeutend mehr
> Speicher als das Video.

mp3 ist aber aus heutiger Sicht auch kein besonders effizienter Codec. 
Und es kommt natürlich auch noch drauf an, wie der Ton kodiert ist. Wenn 
das so ein 384-kHz-7.1-Dolby-True-Supderduper-Ultra-Plusquamperfekt in 
30 Sprachen ist, dann kann das natürlich auch irgendwann mal größer 
werden als das Video.

> Kann durchaus sein das sich das bei hochauflösenden Aufnahmen ändert,
> aber ich sprach ja von "gängigen" Formaten.

Gängig ist heute ab Full-HD aufwärts. Vielleicht noch 720p, wenn man 
Platz sparen muss.

> Rolf M. schrieb:
>> Video mit 128 kBit/s wäre höchsten im
>> Briefmarken-Format sinnvoll.
>
> Da steht doch deutlich und von dir Zitiert : TONFORMAT

Wo? Ich sehe da:

>>> Bei den meisten "gängigen" *Videoformaten*

> Die Größe eine Videos ist doch unwichtig beim Ton !!!

Du sagtest, der Ton bräuchte mehr Platz als das Bild bei den meisten 
Videoformaten. Für diese Behauptung ist selbstverständlich wichtig, wie 
viel Platz das Bild braucht. Und es ist in der Regel mehr als 128 
kBit/s.

von Gerald K. (geku)


Bewertung
0 lesenswert
nicht lesenswert
Ich würde als Beispiel für AUDIO die Kapazität einer CD hernehmen. Die 
CD mit 650MB ist für 74 Minuten Audio (WAV-Format ) ausgelegt.

https://de.m.wikipedia.org/wiki/Compact_Disc

Als Beispiel für VIDEO würde ich eine DVD nehmen. Die DVD mit 4,7GB ist 
für ca. 133 Minuten Viedo (MPEG-2) geeignet.

http://www.bbeer.de/diplom/glossar/b_dvd.htm

von IQ130+ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> besteht doch aus einer Menge von Einzelbildern. Die
> Menge
> der Einzelbilder pro Sekunde multipliziert mit der Auflösung, der
> Farbtiefe und der Dauer reduziert um den Kompressionsfaktor müsste dann
> ja die Größe der Videodatei ergeben.

Die 'Einzelbilder' (Frames) haben aber unterschiedliche 
Kompressionsraten:
https://de.wikipedia.org/wiki/P-Frame

von Percy N. (vox_bovi)


Bewertung
0 lesenswert
nicht lesenswert
oszi40 schrieb:
> Fußballspiel mit viel Bewegung und Dynamik komprimieren müssen.

Da dürfte ein Spielfilm mit häufigen Schnitten anspruchsvoller sein 
können.

von Schlaumaier (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> besteht doch aus einer Menge von Einzelbildern. Die
> Menge
> der Einzelbilder pro Sekunde multipliziert mit der Auflösung, der
> Farbtiefe und der Dauer reduziert um den Kompressionsfaktor müsste dann
> ja die Größe der Videodatei ergeben.

Das funktioniert nicht.  Weil du vergisst das Masterbild.  Ein 
Masterbild wird alle X-Bilder erstellt. Alle Bilder die dazwischen sind 
werden nicht Komplett gespeichert, sondern nur die Änderungen zum 
vorherigen. Alle X-Sekunden wird ein neues Masterbild erzeugt, mit ALLEN 
Daten. Dies verhindert das ein Fehler sich durch das ganze Video zieht.

In der Praxis merkt man das, wenn es zu Fragmenten / Würfelbildung kommt 
die plötzlich verschwindet. Sie verschwinden weil das neue Masterbild 
den Stream korrigiert.

von Rolf M. (rmagnus)


Bewertung
0 lesenswert
nicht lesenswert
Percy N. schrieb:
> oszi40 schrieb:
>> Fußballspiel mit viel Bewegung und Dynamik komprimieren müssen.
>
> Da dürfte ein Spielfilm mit häufigen Schnitten anspruchsvoller sein
> können.

Vor allem ein Actionfilm mit schnellen Szenenwechseln und 
"großflächigen" Explosionen. Beim Fußballspiel ändert sich der 
Bildinhalt ja über längere Zeiten eher nur geringfügig.

Schlaumaier schrieb:
> Torben S. schrieb:
>> besteht doch aus einer Menge von Einzelbildern. Die
>> Menge
>> der Einzelbilder pro Sekunde multipliziert mit der Auflösung, der
>> Farbtiefe und der Dauer reduziert um den Kompressionsfaktor müsste dann
>> ja die Größe der Videodatei ergeben.
>
> Das funktioniert nicht.  Weil du vergisst das Masterbild.

Das heißt immer noch Keyframe oder I-Frame.

> Alle Bilder die dazwischen sind werden nicht Komplett gespeichert, sondern
> nur die Änderungen zum vorherigen.

Je nach Codec nicht nur Änderungen zu vorherigen (so genannte P-Frames), 
sondern auch zu zukünftigen Frames (so genannte B-Frames).
https://de.wikipedia.org/wiki/B-Frame

> Alle X-Sekunden wird ein neues Masterbild erzeugt, mit ALLEN
> Daten. Dies verhindert das ein Fehler sich durch das ganze Video zieht.

Es hält vor allem die Degradation des Bildes im Zaum, denn alle 
Unterschiede werden ja auch wieder verlustbehaftet gespeichert, so dass 
das Bild auch ohne Fehler immer schlechter wird, je weiter man sich vom 
letzten Keyframe entfernt.

> In der Praxis merkt man das, wenn es zu Fragmenten / Würfelbildung kommt
> die plötzlich verschwindet. Sie verschwinden weil das neue Masterbild
> den Stream korrigiert.

Oft werden Keyframes geschickterweise an Kamera-Wechseln eingefügt, also 
an Stellen, wo sich sowieso das komplette Bild ändert.

von Klugscheisser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Vor allem ein Actionfilm mit schnellen Szenenwechseln und
> "großflächigen" Explosionen. Beim Fußballspiel ändert sich der
> Bildinhalt ja über längere Zeiten eher nur geringfügig.

Das taeuscht. Insbesondere die detailreiche Darstellung der
Zuschauer und des "winzigen" Balls treibt die Datenrate in
die Hoehe.
Anlaesslich der Meisterschaft, spendierte die ARD immerhin
bis zu knapp 3 MByte/s fuer SD-Aufloesung (720x576).
Ein bommeliger Actionfilm braucht da nur die Haelfte.
Und bei den Privaten dann davon nochmal die Haelfte.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Klugscheisser schrieb:
> bis zu knapp 3 MByte/s fuer SD-Aufloesung
Da meld' ich doch mal leichte Zweifel an.
Datenraten bei SD ueber DVB-S sind eher so 256kBit/sec 
("Ruf'-mich-an-Diashow") ueber 3..5MBit/sec fuer "normale" Qualitaet bis 
zu 7..8MBit/sec, wenn eh' Platz auf'm Transponder ist. Also z.b. ORF1 
aufm ORF-SD-Transponder, wenn keine Landesfenster laufen. Genauso beim 
WDR.

Aber mal davon ab: Wenn man nicht schon vorkomprimierte Daten wie eben 
aus DVB, DVD, BlueRay oder sowas hat, sondern die unkomprimierten direkt 
aus der Kamera, dann kann man bei allen ueblichen, verlustbehafteten 
Codecs einstellen, ob man eher konstante Qualitaet (bei variabler 
Bitrate) oder eher konstante Bitrate (bei variabler Qualitaet) haben 
will. Geht per Transcoder natuerlich prinzipiell auch mit 
vorkomprimierten Daten, aber das Ergebnis wird halt nie besser sein, als 
vorher.

Gruss
WK

von Klugscheisser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Da meld' ich doch mal leichte Zweifel an.

Ist auch nicht der Normalfall. Aber ProgDVB zeigt da durchaus
keine Hausnummern an. Nachgesehen habe ich auch nur, weil
Detailreichtum und allgemeine Schaerfe des Bildmaterials
wirklich hervorragend waren.

von Klugscheisser (Gast)


Bewertung
0 lesenswert
nicht lesenswert
P.S.:
Wenn ich jetzt Langeweile haette, koennte ich mal auf der
Platte mit den Fuelmen danach suchen. Das hab ich bestimmt
archiviert...

Aber schade. Langeweile habe ich im Moment nicht.

DVB-MPG2-SD-Material hat uebrigens irgendwo im Header ein Flag
das eine Bitrate von 15 MBit/s suggeriert.
Auch bei den Diashowsendern.

Im uebrigen habe ich mal in der (raeumlichen) Naehe einer Firma
gearbeitet, die die entsprechenden Encoder parametriert und
gewartet hat. Die hatten Unmengen von DVB-S/T-Receivern aller
moeglichen und unmoeglichen Hersteller um ihre Einstellungen
vorab zu testen. Der ORF hat da lange nicht so viel
Qualitaetssicherung betrieben.

von Dergute W. (derguteweka)


Bewertung
0 lesenswert
nicht lesenswert
Moin,

Klugscheisser schrieb:
> DVB-MPG2-SD-Material hat uebrigens irgendwo im Header ein Flag
> das eine Bitrate von 15 MBit/s suggeriert.
> Auch bei den Diashowsendern.

Das haben nicht alle, aber ja, das hatte z.B. Pro7 vor 20 Jahren auch 
mal - weiss garnicht mehr, ob's im Elementarstrom selbst oder in einem 
Descriptor in der PMT war. Bin ich auch druebergestolpert.
In der Spec. stand dazu auch nur, das das die Maximalbitrate ist.
Und wie's der Zufall will, sind 15MBit/sec auch die Maximalbitrate bei 
MP@ML. Drueber ist nicht mehr normkonform. Und da gibts/gabs sicher den 
ein oder anderen Decoderchip, der das nicht mitgemacht haette. Und mit 
was? Mit Recht.

Klugscheisser schrieb:
> Im uebrigen habe ich mal in der (raeumlichen) Naehe einer Firma
> gearbeitet, die die entsprechenden Encoder parametriert und
> gewartet hat. Die hatten Unmengen von DVB-S/T-Receivern aller
> moeglichen und unmoeglichen Hersteller um ihre Einstellungen
> vorab zu testen.

Da siehste mal; und ich hab' ueberhaupt keine Ahnung, von was ich so 
schwaetz' ;-)

Gruss
WK

von mahi (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schlaumaier schrieb:
> Rolf M. schrieb:
>> Schlaumaier schrieb:
>>> Bei den meisten "gängigen" Videoformaten verbraucht der TON wesentlich
>>> mehr Speicherplatz als das Bild.
>>
>> Das würde mich eher wundern.
>
> Mach das. Die Videos die ich meist schneide (TV-Aufnahmen) mit
> Virtualdub verbraucht das mp3-Format für das Audio bedeutend mehr
> Speicher als das Video.
> Kann durchaus sein das sich das bei hochauflösenden Aufnahmen ändert,
> aber ich sprach ja von "gängigen" Formaten.

Naja, als gängiges Format würde ich doch inzwischen eher HD oder FullHD 
ansehen.

Aber nun gut, schauen wir uns eine DVD an (war vor 10 Jahren gängig): 
Video MPEG2 üblicherweise um die 4-5MBit/s, Audio AC-3 oder DTS mit 
0,5-1,5MBit/s.

Dass ich TV-Aufnahmen gemacht habe liegt zwar schon eine Weile zurück, 
aber das waren eher über 1 GB/h als darunter. Wenn man MPEG1 Layer 2 
oder mp3 für Audio annimmt wären das max. 384kbit/s, Video ja angeblich 
weniger - dann wären das nur 300MB/h - kommt nicht hin.

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Moderne Audio- und Video-Codecs arbeiten quasi in 2 Stufen (grob 
vereinfacht):

1. Datenreduktion (verlustbehaftet). D.h. aus dem Datenmaterial wird 
ersatzlos entfernt, was der Mesch eh nicht sehen oder hören kann. Bei 
Bildern macht man sich z.B. die verringerte Farb-Ortsauflösung des Auges 
(deutlich weniger Zapfen als Stäbchen auf der Netzhaut) zu nutze, so 
dass z.B. 3x3 Pixel alle die gleiche Farbe, aber unterschiedliche 
Helligkeit haben - und keiner merkts. Bei Audio greift z.B. das 
"psychoakustische" Hörmodell, was z.B. Infos vor und nach besonders 
lauten Stellen entfernt.

Übertreibt man es mit der Datenreduktion, dann werden diese irgendwann 
sicht- und hörbar. Die Kunst besteht darin, das Optimum zwischen 
Qualität und Dateigröße zu finden. Ein Plakat, was man aus typisch 3m 
Abstand sieht, benötigt weniger Daten als eine Reproduktion in einem 
Kunstbildband, die man aus 20cm betrachtet.

2. Datenkompression (verlustfrei), informationstechnisch eigentlich nur 
eine Umcodierung. Was nach 1. "noch übrig" ist, wird dann mit den 
verschiedenst cleveren Redundanz-reduzierenden Aglorithmen beackert. Man 
speichert z.B. nur die Differenzen zwischen benachbarten Werten, weil 
dann z.B. 4 Bit reichen, statt 16. Oder man sucht im Datenstrom nach 
sich wiederholenden Mustern und speichert diese dann jeweils nur einmal 
nebst Multiplikator oder Verweis/Pointer usw.

Der Erfolg beider Stufen hängt in erheblichem Maße vom Inhalt ab und 
lässt sich deshalb kaum genau vorausberechnen.

von Peter M. (r2d3)


Bewertung
1 lesenswert
nicht lesenswert
Hallo Torben,

besorg' Dir mal bei Heise deren Sonderheft
"c't special Digital-Video 5/2005"

auf der DVD-Beilage ist ein 120-Minutenkurs Videokompression.
Die Prinzipien haben sich nicht verändert, nur die Algorithmen sind 
ausgefeilter.

Torben S. schrieb:
> Wie verhält es sich aber, wenn man z. B. mit dem Panasonic HC-X 1500
> Camcorder einen 10 Minütigen Film aufnimmt? Die Cam hat eine
> Videoauflösung von 3840x2160@60p.
>
> Ich rechne mal nach...
>
> 3840 x 2160 x 10 Minuten x 60 Sekunden x 60 Hz
>
> Das macht 35 GiB. Dann wird darauf ja noch eine Videokompression
> angewand (H.265?). Die könnte das Videomatrial um 50% verringern. Dann
> wäre das video 17,5 GiB groß. Ist das unter einer sehr vereinfachten
> Perspektive richtig?

Nein.

Vollbild:
3840 x 2160 Pixel x 3 Byte/Pixel  =~25 MB.

Die 3 Byte/Pixel nenne ich nur der Anschauung halber, praktisch werden 
es weniger sein, siehe:
Beitrag "Re: Speicherplatzbedarf Ton, Bild und Video"

Bei 25 MB pro Bild kostet Dich bei 60 fps die Sekunde 1,5GB, die Minute 
90GB und 10 Minuten 900GB.

Ein Codec, der eine Folge von Einzelbildern wegschreibt (motion jpeg, 
oder motion jpeg2000, wird Dir die Rohdatenrate auf <5% drücken.
JPEG2000 schätze ich auf unter 2% ein.
Du kannst einfach mal unkomprimierte TIFF-Bilder in JPEGs oder JPEG2000 
komprimieren, dann siehst Du, was Du für eine Qualität bei welcher 
Komprimierungsrate Du erwarten kannst.

Moderne Videocodecs komprimieren aber stärker.
Denke an den Tagesschausprecher beim Lesen der Nachrichten und 
unverändertem Hintergrundbild.

Es ist zwar sehr schnittfreundlich, alles als Einzelbild zu kodieren 
aber effizienter, Differenzbilder zwischen Einzelbilder zu betrachten. 
Die Einzelbilder nennt man I-Frames, die Differenzbilder P-Frames. 
P-Frames können sehr klein ausfallen, so dass zwei Bilder, kodiert als 
I- und als P-Frame viel weniger Platz wegnehmen als zwei I-Frames.

Beim Tagesschausprecher brauchen dann nur die Mundbewegungen kodiert zu 
werden, wenn er stillsteht.

Die Krone der Schöpfung sind dann B-Frames, die bestimmen sich 
bidirektional aus zwei benachbarten Frames.
Bei der P-Frame-Berechnung sucht man gerne nach verschobenen 
Bildelementen.
Bildelemente zweimal speichern ist teurer als ein Bildelement plus einer 
Bewegungsvektorinformation für das Folgebild.

Mit Hilfe von P und B-Frames und kann dann die Nettodatenrate weiter 
massiv gedrückt werden, also durch reine Einzelbildkodierung möglich.

Bei Verwendung von konstanten Kompressionsraten, was sich in konstanten 
Bitraten ausdrückt, schwankt natürlich die Qualität.

Wenn also bei einem Fußballspiel Nebelgranaten? gezündet werden und 
Millionen Partikel durch's Stadion wabern, erhöht sich  die Komplexität 
des Bilds so sehr, dass selbst bei Nutzung von die professioneller 
Videotechnik  der Qualitätsverlust sichtbar wird. So wurde mir das im 
Ü-Wagen von TVN aus  Hannover vor etwa 10 Jahren einmal erklärt.

Die Fernsehsender nehmen übrigens mit viel höheren Datenraten auf, als 
sie dann an den Endverbraucher ausspielen.

: Bearbeitet durch User
von Sebastian L. (sebastian_l72)


Bewertung
0 lesenswert
nicht lesenswert
auch von hier: Verstehe die Grundlagen.
Die uralte "c't special Digital-Video 5/2005" ist für Laien geschrieben. 
Falsch ist daran auch heute nix.
Die Reduktoren und Kompressoren sind besser geworden.
Dafür ist die Farbtiefe und die Auflösung des grösser geworden.
Letztendlich wünscht man sich immer die dicksten GPUs, die schnellsten 
Systembusse, massig Ram und SSD bis der Geldbeutel leer ist.

Torben S. schrieb:
> Wie verhält es sich aber, wenn man z. B. mit dem Panasonic HC-X 1500
> Camcorder einen 10 Minütigen Film aufnimmt? Die Cam hat eine
> Videoauflösung von 3840x2160@60p.
Das reicht nicht als Angabe um die Datenrate zu ermitteln.

Es macht einen gehörigen Unterschied welche Dateiformat und Codex du 
schreiben lässt:
Bei der Panasonic ist am oberen Ende
MOV (HEVC 200M) 4:2:0 10bit UHD 3840x2160 59.94p/50.00p
mit ca. 200Mbps (VBR)

am unterem Ende:
AVCHD PM 1280x720 59.94p/50.00p: ca 8Mbps (VBR)

Da ist ein Faktor 25! dazwischen.

Ausgeben kann die Kamera das als
H.264/MPEG-4 AVC 320×180 bis auf 0.5 Mbps runtergestaucht.
Also ein Faktor 400! geringer als das Maximale.

und wenn nun ganz allgemein gefragt wird:
Die Panasonic kann aber Licht und Farben nur in 4:2:0 abtasten.
Das sieht aus wie brasilianische Telenovela.
Will man Farben in Chrominanz und Luminanz beeinflussen, dann will man 
nicht mit farbreduzierten Daten anfangen.
Da greift man dann mindestens zu sowas wie der Blackmagic Pocket. Die 
schreibt dann 4k Videos mit ProRes 4:2:2 und macht 117.88 MB/s

Wem aber die 10bit Farbtiefe nicht genug ist, der muss auf 4:4:4 
umsteigen, hat 12 bit Farbtiefe - will man das in 8k dann ist man bei 
1769 Mbit/s
Solche Daten muss man bewältigen können und können eine Postproduction 
wirklich überlasten. Deshalb werden auch heute nur sehr wenige 
Blockbuster auch in 4:4:4 8k geschossen.


BTW:
Bei der kleinen Blackmagic hat man ein Arsenal an SD-Karten wie damals 
in den 80ern an Filmrollen.
100ft 16mm Film mit 24fps belichtet sind 3 min.
64 GB Karte in der Blackmagic sind 9 min.

von Sebastian L. (sebastian_l72)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Wovon ist es z. B. Abhängig, wie viel Speicherplatz eine Tonaufnahme
> einnimmt, die man mit einem Mikrofon aufgenommen hat.

Damals(TM) haben wir rechnen müssen wie schnell das Band auf der Nagra 
laufen darf damit wir die komplette Scene mit draufkriegten.
Je schneller das Band lief, je höher die Qualität.

Heute heisst das bitrate und samplerate.
Heute nimmt doch kaum einer noch unter 24bit/48 kHz auf.
Audio ist problemlos, es sei denn man hat 100+ Spuren.

von Sheeva P. (sheevaplug)


Bewertung
0 lesenswert
nicht lesenswert
Torben S. schrieb:
> Schlaumaier schrieb:
>> Einfach
>> gesagt ein Bild von einer weißen Fläche verbraucht weniger als ein Bild
>> von einer Landschaft.
>
> Das ist total interessant. Man denkt, für jedes Pixel stehen z. B. 24
> Bit zur Verfügung, egal, ob ich eine weiße Wand oder eine Landschaft
> fotografiere.

Für die ROHdaten ist das im Prinzip auch korrekt, aber dann schlägt die 
Kompression zu. Und die ist bei Videodaten durchaus ein Biest. Vor 
vielen Jahren habe ich einmal eine Beschreibung eines 
Kompressionsalgorithmus für Videos gelesen und möchte gerne versuchen, 
das hier nochmal halbwegs wiederzugeben.

Korrekt ist, daß Videos im Grunde genommen Abfolgen von Einzelbildern 
(Frames) sind. Häufig ist es aber so, daß sich zwischen dem Frame n und 
dem Frame n+1 nicht allzu viel ändert, deswegen wird Frame n komprimiert 
und gespeichert, für Frame n+1 werden aber nur die Unterschiede zu Frame 
n ermittelt, komprimiert und gespeichert. Für die Kompression, über die 
ich damals gelesen habe, war es IIRC so, daß nur alle 15 Frames der 
komplette Frame gespeichert wurde und für die dazwischenliegenden Frames 
jeweils nur die Unterschiede. Ich vermute, daß modernere 
Kompressionsalgorithmen nicht auf feste Abstände zwischen den Frames, 
sondern auf die Größe der Differenz abzielen, und immer dann, wenn sich 
das Bild stark verändert, den kompletten Frame speichern und ansonsten 
eben nur die Unterschiede.

Außerdem werden die einzelnen Vollframes nochmals komprimiert; anstatt 
für fünf nebeneinander liegende, gleichfarbige Pixel jeweils die 
vollständigen Farbwerte zu speichern, wird nur der Farbwert für das 
erste Pixel gespeichert und dann quasi gesagt, "wiederhole das noch 
viermal".

Obendrein nutzen manche Kompressionsalgorithmen wohl auch aus, daß das 
menschliche Auge nur etwa 65.000 unterschiedliche Farbwerte wahrnehmen 
kann, so daß nahe bei einander liegende Farbwerte gemittelt werden 
können. Das ist dann natürlich eine verlustbehaftete Kompression; die 
Rohdaten lassen sich aus so komprimierten Daten natürlich nicht ganz 
genau wiederherstellen. Moderne Kompressionen nutzen dabei vermutlich 
auch die Farbwahrnehmung des menschlichen Auges aus, so daß dieser 
Ansatz im mittleren Spektrum (grün und gelb), den das Auge besonders gut 
wahrnimmt, weniger stark genutzt wird als in anderen Bereichen des 
Farbspektrums.

Insofern sind die erreichbaren Kompressionsraten dieser mehrstufigen 
Kompression sehr stark vom Ausgangsmaterial, also den Rohdaten abhängig. 
Videos mit vielen schnellen Änderungen (sagen wir, von der 
On-Board-Kamera eines Rennautos) können daher nicht so gut komprimiert 
werden wie ein Video, bei dem sich große Teile des Bildes weitgehend 
gleich bleiben (sagen wir, ein Video des kompletten Feldes bei einem 
Fußballspiel).

von Frank E. (Firma: Q3) (qualidat)


Bewertung
0 lesenswert
nicht lesenswert
Der Korrektehit halber sollte man zwischen Daten-REDUKTION 
(verlustbehaftet) und Daten-KOMPRESSION (verlustfrei) unterscheiden. 
Natürlich wird beides kombiniert, doch ist jedes für sich aber ein 
deutlicher Unterschied.

von c-hater (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Sheeva P. schrieb:

> Für die ROHdaten ist das im Prinzip auch korrekt, aber dann schlägt die
> Kompression zu. Und die ist bei Videodaten durchaus ein Biest. Vor
> vielen Jahren habe ich einmal eine Beschreibung eines
> Kompressionsalgorithmus für Videos gelesen und möchte gerne versuchen,
> das hier nochmal halbwegs wiederzugeben.

[...]

Das trifft nicht mehr ganz auf "heutige" Videokompression zu. Eigentlich 
schon nichtmal mehr auf MPEG1, was ja wirklich schon arschalt ist...

Aber vieles davon ist nichtsdestotrotz auch heute noch durchaus 
zutreffend. Insbesondere viele der von dir genannten grundsätzlichen 
Eigenschaften von Video, die halt die Ansätze zur Datenreduktion 
darstellen, die von den Kompressionsalgorithmen benutzt werden.

Einen Teil davon hast du (für die heute relevanten) 
Kompressionsverfahren falsch beschreiben, das ist der Teil, der die 
I-Frames schlanker macht. Was du da beschreibst, ist RLE. Das ist für 
natürliches Video ein völlig ineffezientes Verfahren, schon MPEG1 hat 
das anders gehandhabt, die heutigen Encoder sowieso...

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.