View Full Version : Hdv Codec Research


Michael Pappas
April 26th, 2005, 03:08 PM
I am doing research on HDV, and I have a few white papers on HDV and Mpeg. In this white paper by arthur Al Kovalick there is a mbs equivalent from IBP and what it is in I-frame image encoding. READ BELOW EXCERPT.............

-----------------BEGINNING----------------------
In the figure, the notations (IBP) and (I) are used. IBP refers to the most efficient form of MPEG also called Long-GOP MPEG. In this format, video frames are compressed in relation to the redundant image content of their nearest neighbor frames. This yields excellent compression metrics. So called I-frame compression is about 2.5 times less efficient than IBP but is easier to encode, decode and process. I-frame codecs don’t factor in the image activity of nearest neighbor frames so the coding is less efficient than its IBP cousin. So an HDV image encoded at 25 Mb/s (IBP) is roughly equivalent to an I-frame image encoding of about 60 Mb/s. So, when comparing two compression schemes, remember that the higher bit rate version may not necessarily provide the better image quality.
-------------------DONE-------------------------



What do you think about this?

If it's wrong or? Can you please state why it's wrong and then point to a white paper or study that backs up why it's wrong.

I am trying to write a HDV article and want to make sure the truth and facts are correct about how HDV is and compared to how other codecs perform. So far what I am starting to learn about HDV at 6 gop is it's quite efficient and a very advance codec without redundant compression schemes. I am in the very early stages of this research.



SOURCE for above info:

http://66.102.7.104/search?q=cache:R17K4mYwdN8J:www.pinnaclesys.com/BSD/liquidblue/English(US)/doc/WP_HDV_40804.pdf+++++++++++HDV+white+paper&hl=en&ie=UTF-8

PDF VERSION:
http://www.pinnaclesys.com/BSD/liquidblue/English(US)/doc/WP_HDV_40804.pdf



Michael Pappas

David Kennett
April 27th, 2005, 01:06 PM
Michael,

You're excerpt seemed a little misleading to me. It implies that there are two specific types of MPEG, and each yields very specific results. This is not the case for MPEG1, MPEG2, MPEG4, WMV, or even JPG stills. There is a wide latitude in each of these formats for compromises between quality, data rate, and even encoding speed (for software non real time encoders).

I have a Panasonic DVD video recorder with my TV. You can record 1 hour, 2 hour, 4 hour, or 6 hour mode on a single layer DVD. There is even a mode which allows you to fill the DVD with any length program, giving the best quality for the length of the recording.

If you want to get an idea of the mind-boggling options available for MPEG encoding, download the TMPGEnc trial. There is a steep learning curve, but master it, and you'll be making the best-looking MPEG, and make smaller files too! There are options like CQ (constant quality), CBR (constant bit rate), VBR (variable bit rate). You can define the GOP (Group-of-pictures) about any way you wish. A GOP is started with an I frame (Independant frame), and is usually followed by P frames (Predicted frames), and B frames (Bi-directional frames). A predicted frame is created by looking at several previous frames to predict what a future frame will look like. The data then sent for that frame would only have to correct for the inaccuracies of the prediction. B frames are usually placed between predicted frames, and are interpolated. The data sent for that frame need only correct for the interpolation errors. In MPEG2, I think the maximum GOP length is 15 frames. WMV encoding has no such restriction, and a GOP for fairly static shots (say a boring meeting) could be as long as 20 seconds. Longer GOPs can be more effecient, but you can imagine what this does to editing. That's why JVC chose a short 6 frame GOP for the HD1-HD10. GOPs need not be all alike. In fact a new GOP is started at scene changes, regardless of whether or not the previous GOP is complete. This usually results in shorter GOPs just before scene changes.

Data is further reduced using the discrete cosine transform (DCT), and some form of entropy encoding, but unless you're a math wiz you won't want to go there. I tread very carefully in those parts!

I think it was very clever of JVC to use the more efficient encoding of MPG, while making editing easier with the shorter GOP.

There is a ton of information around, but it can get very technical very quickly. Hopefully, my little dissertation will get you started.

David Kennett
April 27th, 2005, 01:30 PM
P.S.

I read the article you referenced, and my overall impression is that it's harder to read than it needs to be. He seems to be referring to "I frame only" MPEG as DV. DV is quite similar to motion JPEG, in that each frame is a separate entity (like JPEG still). I've never heard of DV being referred to as "I-frame MPEG" though. It's just "DV".