Frage von Jens Ruedig:Hallo. Ich kriegs immer noch nicht hin: Die Berechnung der Datenrate
von 3,5 MByte/s bei MiniDV-Aufnahmen.
Also: Es werden 25 Bilder / s mit der Auflösung 720 x 576 Pixel
geschrieben. Die verwendete Farbtiefe ist 8 Bit / Kanal - und davon
gibt's drei.
Macht also die Rechnung:
25 Bilder x 720 x 576 Pixel x 3Kanäle x 8 Bit Farbtiefe = 248 832 000
Bit oder 31 104 000 Byte (;~31,1 MByte).
Hinzu kommt noch der Ton mit 2 Kanälen, 16 bit, 48 kHz oder 4 Kanäle,
12 bit, 32 kHz. Da direkt meine erste Frage: Wie bekomme ich daraus
eine Datenrate, die ich hinzuaddieren kann?
Außerdem: eine Spur für den Timecode (;Subcode) und einen ITI-Code für
Track-Informationen. Zweite Frage: Ich weiß zwar - das kann man
sicherlich vernachlässigen, aber kann man trotzdem für diese beiden
Spuren eine Datenrate angeben?
Dann wird das Bildmaterial mit DCT-Kompression um den Faktor 5:1
verlustfrei (;!?) komprimiert. Soweit OK, keine weiteren Fragen :o)
Zum Schluss aber die PAL-Signaldarstelltung:Eigentlich war ich ja in
der Rechnung oben von RGB-Werten mit jeweils 8Bit ausgegangen. Aber
die werden ja IMHO schon vom Camcorder zu YUV-Werten transformiert und
eben mit der Charakteristik 4:2:0 bzw (;4:2:2/4:0:0) gespeichert. Führt
das nicht die oben aufgeführte Rechnung ad absurdum? Wenn die 8Bit (;24
Bit) auch bei der Aufnahme eine Rolle spielen, so sollten sie doch
durch die Signaldarstellung bei der Speicherung auf die Hälfte
verringert werden - oder?
Jedenfalls: Wie ich es auch drehe und wende; welche Werte ich auch
ausrechne: 3,5 MByte/s bekomme ich nie 'raus. Was ist das für 'ne
merkwürdige Zahl?
Danke, Jens.
Antwort von Ottfried Schmidt:
On Fri, 30 Jan 2004 00:42:42 0100, Jens Ruedig
wrote:
>Also: Es werden 25 Bilder / s mit der Auflösung 720 x 576 Pixel
>geschrieben. Die verwendete Farbtiefe ist 8 Bit / Kanal - und davon
>gibt's drei.
>Macht also die Rechnung:
>
>25 Bilder x 720 x 576 Pixel x 3Kanäle x 8 Bit Farbtiefe = 248 832 000
>Bit oder 31 104 000 Byte (;~31,1 MByte).
Und die ist wegen der Verwendung von YUV 4:2:0 schon mal verkehrt.
In jeder geraden Zeile kommen auf vier Y-Werte je zwei für Cb und Cr.
In den ungeraden Zeilen werden nur die Y-Informationen gespeichert,
aber keine Cb- und Cr-Werte. Das sparte schon mal Unmengen Platz.
>Dann wird das Bildmaterial mit DCT-Kompression um den Faktor 5:1
>verlustfrei (;!?) komprimiert. Soweit OK, keine weiteren Fragen :o)
Natürlich nicht verlustfrei. Kein DCT-Format kann wirklich verlustfrei
arbeiten.
>Jedenfalls: Wie ich es auch drehe und wende; welche Werte ich auch
>ausrechne: 3,5 MByte/s bekomme ich nie 'raus. Was ist das für 'ne
>merkwürdige Zahl?
Rechne einfach nochmal nach. ;)
Antwort von Tobias Berger:
Ottfried Schmidt wrote:
>>Jedenfalls: Wie ich es auch drehe und wende; welche Werte ich auch
>>ausrechne: 3,5 MByte/s bekomme ich nie 'raus. Was ist das für 'ne
>>merkwürdige Zahl?
So wie ich weiß, besteht der DV-Datenstrom aus einem speziellen
MPEG-Dialekt, in dem nur (;JPEG-kodierte) Keyframes, keine Intraframes
sind. Also nicht viel anders als MJPEG.
Bei JPEG kannst Du ja stufenlos die Qualität und somit die Datenrate
einstellen.
Tobias Berger
Antwort von Ottfried Schmidt:
On Fri, 30 Jan 2004 12:11:40 0100, Tobias Berger
wrote:
>So wie ich weiß, besteht der DV-Datenstrom aus einem speziellen
>MPEG-Dialekt, in dem nur (;JPEG-kodierte) Keyframes, keine Intraframes
>sind. Also nicht viel anders als MJPEG.
>
>Bei JPEG kannst Du ja stufenlos die Qualität und somit die Datenrate
>einstellen.
Na ja, ein wenig anders als MPEG, JPEG oder MJPEG funktioniert DV
schon. Nur die grundlegenden Techniken sind dieselben.
So gibt es neben den Macroblocks bei DV auch die Videoblocks, die aus
6 Macroblocks bestehen. Am ehesten vergleichbar sind die mit den
Slices bei MPEG. Dasselbe gilt für die Superblocks, die aus 27
Macroblocks gebildet werden.
Darüber hinaus kennt DV zwei verschiedene DCT-Modi: 8-8 für ruhige und
2-4-8 für stark bewegte Szenen. Dazu kommen wie bei MPEG noch variable
Quantisierungsstufen, um die Bitrate konstant halten zu können.
Insgesamt also ein Bastard aus mehreren Technologien.
Wirklich tief eingearbeitet habe ich mich da aber auch noch nicht, die
IEC61834-2 hat immerhin 90 Seiten...
Antwort von Jens Ruedig:
>aber keine Cb- und Cr-Werte. Das sparte schon mal Unmengen Platz.
... kannst du da 'ne Hausnummer nennen? Bedeutet "Unmengen Platz"
vielleicht genau die Hälfte, wie ich es weiter unten angedeutet habe?
>>Dann wird das Bildmaterial mit DCT-Kompression um den Faktor 5:1
>>verlustfrei (;!?) komprimiert. Soweit OK, keine weiteren Fragen :o)
>
>Natürlich nicht verlustfrei. Kein DCT-Format kann wirklich verlustfrei
>arbeiten.
Hmm ... OK.
>>Jedenfalls: Wie ich es auch drehe und wende; welche Werte ich auch
>>ausrechne: 3,5 MByte/s bekomme ich nie 'raus. Was ist das für 'ne
>>merkwürdige Zahl?
>Rechne einfach nochmal nach. ;)
Hurra! Vielen Dank für die Hilfe! SCNR
Jens.
Antwort von Ottfried Schmidt:
On Fri, 30 Jan 2004 16:17:29 0100, Jens Ruedig
wrote:
>... kannst du da 'ne Hausnummer nennen? Bedeutet "Unmengen Platz"
>vielleicht genau die Hälfte, wie ich es weiter unten angedeutet habe?
720x576 2x360x288 gegenüber 720x576x3
Ist ziemlich exakt die Hälfte.
Antwort von bb:
Die DCT an sich ist verlustfrei, nicht aber die Quantisierung, die bei
den diversen MPEG-Derivaten verwendet wird (;und die natürlich der Grund
dafür ist, dass man überhaupt eine DCT macht).
Gruß
bb
Ottfried Schmidt wrote:
> Natürlich nicht verlustfrei. Kein DCT-Format kann wirklich verlustfrei
> arbeiten.
Antwort von Alexander Blinne:
bb wrote:
> Die DCT an sich ist verlustfrei[..]
Es passieren aber auch bei der DCT schon Rundungsfehler.
