Can somebody show me the calculation that DV is ~13GB/hour

[Hulk]

I realize that the video stream is 25Mbps, which comes out to 11.25 GB/hour.

I thought DV audio was basically PCM 48/16, which is around 660Mb/hour.

I can't get this to get to even 12GB/hour.

?

I assume there is something simple I'm missing?

- Mark

[Brian Ellis]

Simple, there are headers and control data.

For a 480i system, one track consists of an ITI sector comprising 625 bits of an Edit Gap, 500 bits of an audio preamble, 14 sync blocks of audio sector, 550 bits of audio postamble, an edit gap of 700 bits, a video preamble of 800 bits, a video sector of 149 sync blocks, a video postamble of 975 bits, an edit gap of 1550 bits, a subcode preamble of 1200 bits, a subcode sector of 12 sync blocks, a subcode postamble of 1325 bits and an overwrite margin of 1250 bits, making a total of 136,225 bits. There are 10 such tracks/frame, making 170281.25 bytes/frame. Multiplied by 29.97 gives about 5.1 Mb/second, which theoretically gives over 17 Gb/h on the tape. The data useful for that tape is eliminated and the whole is transformed into 10 data in frame sequences for IEEE-1394. Each DIF sequence contains 150 DIF blocks of 80 bytes each, comprising 135 blocks for video, 9 blocks for audio and 6 blocks for header, subcode and video auxiliary info (e.g., fps, lpf etc.), which gives mathematically 12,947,040,000 bytes/h, according to my calculations. This is what you put on your hard disk, plus a little slack, because of the difference between a sequence length multiple and the cluster size.

SImple? Not really!

[cDynamics]

Hi,

I'm sure Brian's explanation gives you detailed info regarding the "extra" stuff that increases the bitrate, but I guess it boils down to the following from AdamWilt.com:

<<<
DV video information is carried in a nominal 25 megabit per second (Mbits/sec) data stream. Once you add in audio, subcode (including timecode), Insert and Track Information (ITI), and error correction, the total data stream comes to about 29 Mbits/sec or 3.6 MBytes/sec
>>>

So when you use the "total data stream" of 29 Mbits/sec, you can see where the 13gb per hour comes from...

Regards,
George

p.s. I think the size will increase if you use DV Type-2 files due to a redundant audio stream

[Hulk]

Thanks guys. Pretty messy!

- Mark

[landrover]

Why would a redundant audio stream increase file-size? That would mean that DV-2 type files contain two audio-streams, one separate and one embedded. Anyone?

[cDynamics]

That's how I understand it... The DV Type-2 file contains an "extra" audio stream.

From Microsoft.com

http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/dx81_c/directx_cpp/htm/type1vstype2dvfiles.asp

Regards,
George

[Brian Ellis]

The difference is small. I'm not sure exactly how it works. In the Type 1, each of the 9 audio DIF blocks precedes 45 video blocks, with the 6 header blocks at the start of the DIF sequence. This is the format as it comes into your IEEE-1394 card and as it is recorded on the hard drive for Type 1. I think, but am not sure, that if you are saving this data in type 2, what happens is that the 9 audio blocks are stripped and placed at the end of the video blocks. However, this is nothing to do with DV, it is a Microsoft definition of AVI. This probably simply requires an extra header sequence, representing the small difference in file length.

[landrover]

Brian,

if it is like you think it is, (which sounds plausible to me), it wouldn´t explain the increased filesize. An extra header will not increase filesize dramatically. A "mirrored" audio track will. So are we overlooking something?

[cDynamics]

Try it...

I like to use empirical data. I just used MSP to output a one-minute DV video clip. One as Type-1 and one as Type-2.

The Type-2 auto-filled audio as pcm. So I tried it again with NTSC DV audio. The resulting Type-2 files (one with PCM, and the other with DV audio) were close in size -- and both Type-2 files were larger than the DV Type-1 file (by about 14mb).

Regards,
George

[Brian Ellis]

Originally posted by landrover
Brian,

if it is like you think it is, (which sounds plausible to me), it wouldn´t explain the increased filesize. An extra header will not increase filesize dramatically. A "mirrored" audio track will. So are we overlooking something?

I'm not at all sure, but I don't believe the audio track is mirrored. If it were, there would have to be duplication of 15 blocks per sequence, which would mean an 11.1% extra overhead. I don't recollect, on the one time I tried rendering to Type 2, out of curiosity, more than one-tenth of this, give or take an ounce or two.

Remember the extra header section would be on every DIF sequence, thus 10 per frame (NTSC) or 12 per frame (PAL), so, yes, this would make a sizeable, but still small difference. It is possible, of course, that the extra header may also be stripped of data relating to video control.

[cDynamics]

This line from the link I left earlier suggests the audio is redundant (and stored twice in the DV Type-2 .avi):

<<<
This is because type-2 files carry redundant data: the video stream still contains audio data, which is hidden by labeling the stream as video.
>>>


Regards,
George