Need Help Understanding Codec Differences

Jay Gladwell wrote on 11/11/2009, 6:04 AM

I took a 10-second clip of a camera original file (MXF progressive) and dropped it on the timeline. The file size is 172.59 MB.

I rendered that clip out as a Sony MXF (progressive) 35 Mbps VBR file. The file size is 44.79 MB.

Using the same CO clip, I rendered the clip out as an Uncompressed avi file. The file size is 2.43 GB.

When I compare the clips using the vectorscope and waveform monitor, I see no fluctuation whatsoever among the three clips. Yet there is a considerable difference in the files size.

So here are my questions:

1. When I rendered the CO as a MXF file, I got the message “No recompression necessary.” If there was no recompression, why is the new MXF file less than 50% smaller? Why isn’t it the same size?

2. When I rendered the CO as an Uncompressed avi file, Vegas was obviously doing something (it took a few seconds longer). Again, if there was no “recompression” as it is an “uncompressed” file, then why is it several times larger than the CO?

3. Considering the variable sizes of the files, where is there no apparent difference in the images according the vectorscope and waveform monitor?

Comments

MPM wrote on 11/11/2009, 11:19 AM

If it helps in a general sense, waiting for someone that knows about the MXF format your camera uses itself, rendering uncompressed usually means decoding/reconstructing the encoded images, some sort of color conversion [different formats save the color data different ways], & of course sending the stream to hdd -- so that's what your software is doing that takes a bit longer.

As far as differences go, the only real test I'm aware of is using AviSynth -- you'll find info on their site & in their user & developer forums. You can also visually see differences importing frames on separate P/Shop layers & using the difference method of compositing. The monitors in Vegas are an approximation of what you'd see on hardware & like a histogram only show you how colors are distributed.

But that little bit is about all I can say -- can't tell you more about Sony MXF than you can read on the Wikipedia page &/or by Googling.

DaveM2 wrote on 11/11/2009, 12:30 PM

Guessing too - I would compare the properties of the original MXF progressive and the Sony MXF (progressive) 35 Mbps VBR that you created. That may give you some clues. From your numbers, your rendered mfx file is about 25% the size of the CO. That's a lot, so I would think a close look of the properties of each should give you an answer. If the properties from Vegas don't give you enough info - I know there is a good video property reading program (I think free use) out there - just can't recall the name. You may want to search the forum - I know someone has mentioned it on the board before.

farss wrote on 11/11/2009, 12:58 PM

The camera original seems to carry a heavy payload, the actual mpeg-2 stream is much smaller. Don't forget there's multiple audio tracks in the CO, XML files etc.

When it comes to comparing the results of encoding vectorscopes and waveform monitors are pretty much useless. It's like using a VU meter to tell the impact of mp3 encdoing. A much better tool if you don't trust your eyes is to subract the original from the next generation.

Bob.

Jay Gladwell wrote on 11/11/2009, 1:30 PM

Thanks, guys, for your input--much appreciated!

"A much better tool if you don't trust your eyes is to subract the original from the next generation."

Bob, not wanting to pressume anything, how is that done?

farss wrote on 11/11/2009, 1:45 PM

Put the original on one track, the encoded file on another. Set top track to 50% opacity and apply the Invert FX.
You should see a frame of perfect grey, make certain you're in Best and look pixel to pixel. Check frames where there's heavy motion.

I had a great example of what modern codecs do yesterday. Guy brings around a QT file to check I can load it into Vegas. Looking at the content it looked fine except in the fast pans or bits shot out the window of a car on a dirt road. Looking at it frame by frame the low bitrate H.264 had turned the fine detail in the grass and leaves to mush. Visually quite hard to see at full frame rate playback.

To answer more of your original question. Uncompressed stores frame as bitmaps from memory. MXF uses mpeg-2 which has spatial and temporal compression. When you render from MXF to Uncompressed Vegas is going from one codec to another, it cannot simply copy the frames. Even though you've gone to uncompressed it's not the same as copying one frame in the source to exactly the same frame's worth of data in the output hence it doesn't say No Recompression. Hope that makes sense.

Bob.

Jay Gladwell wrote on 11/11/2009, 2:18 PM

Thanks, Bob, that worked well.

I tried it with a clip of no motion and the result was a totally grey frame.

Then I tried it with a clip where I was panning on a woman walking passed several potted palms with the thin, fine fronds (which were slightly out of focus). I expected something to show up there, but it was totally grey too.

"When you render from MXF to Uncompressed Vegas is going from one codec to another, it cannot simply copy the frames. Even though you've gone to uncompressed it's not the same as copying one frame in the source to exactly the same frame's worth of data in the output hence it doesn't say No Recompression."

Yes, that made sense. Perhaps I don't though.

If the data is merely 0s and 1s, why can't it simply copy the data straight across, even after FX have been added?

What am I not understanding?

John_Cline wrote on 11/11/2009, 3:47 PM

If you have added FX, then the data has changed from its original form.

Jay Gladwell wrote on 11/12/2009, 3:16 AM

Good point, John. I wandered off track.

Jay Gladwell wrote on 11/12/2009, 3:37 AM

Evidently, I missed something. So how do we account for the difference between the CO file and the Vegas rendered MXF file that was considerably smaller?

I guess I am asking why doesn't Sony's Vegas use the same codec as Sony's camera to create MXF files of equal size and data? Why doesn't Vegas render out a file comparable to the CO?

megabit wrote on 11/12/2009, 3:46 AM

Perhaps it's the number of 48/16 uncompressed audio channels? You have 4 of them in the original clip; rendering to mxf in Vegas takes only 2 of them.

Try changing the number of audio channels to 4 in the Audio tab of the output template, and compare the sizes again.

Just a wild guess, though :)

Piotr

PS BTW, I never understood the 4 channels in my EX1. If it really reserves the bandwidth for the unused 2, it's a severe waste of the codec potential!

megabit wrote on 11/12/2009, 4:09 AM

I'm taking back my last remark. The 4 audio channels are NOT present in the raw EX clips; it's something introduced by the new Clip Browser 2.6 (for optical XDCAM compatibility).

farss wrote on 11/12/2009, 12:51 PM

The CO file is mp4 and carries more than just the mpeg-2 vision and audio stream I think. There could well be provision for a bucketload of metadata. The MXF file that you render out can be a bit for bit copy of the vision and audio stream and still be much smaller if it doesn't include all of the payload contained in the CO.

That said it would be nice if Vegas did support everything in the XDCAM spec. So far the implementation is very limited, just enough to score a bullet point on the box.

Bob.

Jay Gladwell wrote on 11/12/2009, 2:58 PM

"The MXF file that you render out can be a bit for bit copy of the vision and audio stream and still be much smaller if it doesn't include all of the payload contained in the CO."

Interesting! I didn't know that. Thanks, Bob.

"That said it would be nice if Vegas did support everything in the XDCAM spec."

One would think such would be the case. Can't help but wonder why it isn't!