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
Logischerweise von der Qualität. Auflösung, Abtastrate, Codec. Audio ist da noch recht einfach, bei Video ist die Datenrate schon schwankender.
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.
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.
Theor schrieb: > Torben S. schrieb: >> Audiomaterial besteht doch aus einer Menge von Einzelbildern. > Da habe ich gewisse Zweifel daran. :-) Warum? Ist das nicht so?
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. :-)
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.
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
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
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
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?
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
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
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.
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 :)
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)
> 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.
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.
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.
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.
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.
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.
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 !!!
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.
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.
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
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
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.
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.
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.
> 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.
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
> 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.
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.
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
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.
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.
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
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.
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.
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).
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.
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...
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.