Doom9's Forum - View Single Post - Idea about saving space for 1 cd encodes (B-Frames and lumimasking like)

pandv · 23rd September 2002, 17:52

Sorry, I try to explain a complex thing in english, and I need to be very schematic to avoid confusion (if you want a spanish post, let me know).

The savings using B-Frames are in the quantizer increment, because the next frame is not affected (it's based in the previous P or I Frame).

In a normal encode we have K-blocks and M-blocks, the M-blocks are based in the previous one (from the previous frame), the K-blocks are independent.

So, if a block (M or K) in one position is followed by a K block in the next frame (same position), maybe we can increment the quantizer for this bloc, without visual notice (the bad quality is replaced in the next frame with a new block).

With MVHints, I think we have the needed information to compute this situation.

It's possible? It's realistic?

pandv.

23rd September 2002, 17:52	#1 \| Link
pandv Registered User Join Date: Oct 2001 Posts: 62	Idea about saving space for 1 cd encodes (B-Frames and lumimasking like) Sorry, I try to explain a complex thing in english, and I need to be very schematic to avoid confusion (if you want a spanish post, let me know). The savings using B-Frames are in the quantizer increment, because the next frame is not affected (it's based in the previous P or I Frame). In a normal encode we have K-blocks and M-blocks, the M-blocks are based in the previous one (from the previous frame), the K-blocks are independent. So, if a block (M or K) in one position is followed by a K block in the next frame (same position), maybe we can increment the quantizer for this bloc, without visual notice (the bad quality is replaced in the next frame with a new block). With MVHints, I think we have the needed information to compute this situation. It's possible? It's realistic? pandv.