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.

Koepi · 23rd September 2002, 17:57

You got the idea right

But I really dislike the "abuse" of pframes for this matter as bframes are on their way and already looking very nice according to... uhm... I think it was sysKin

He has a better idea for MVhints: making them real hints as offset for improved motion search, resulting in an even better quality for 2pass+MVhints instead like now decreasing quality!

His motion estimation will become default soon and thus some other benefits, too.

Regards,
Koepi

-h · 23rd September 2002, 18:28

This is a good idea, but would probably be integrated with motion masking.

In that case, we would adaptively set the TOOSMALL_LIMIT value, which determines how sparsely detailed a block has to be before being skipped. We would increase the limit (skip more blocks) if the block happens to have a large motion vector, or additionally if we know that the next frame will replace that block with an intra block.

However that doesn't really happen all that often in the context of a full movie, but you may gain 1% or so in compression.

-h

Aktan · 24th September 2002, 04:19

"Every little bit helps"

Koepi · 24th September 2002, 11:12

Integrating this with adaptive quantization is a great idea because you're willing to sacrifice some "original" blocks for bitrate there - this makes perfectly sense, I didn't think about that before, sorry.

But without lumi masking the resulting frames/macroblocks should be as close to the original as possible IMO.

Regards,
Koepi

pandv · 24th September 2002, 13:30

Happy to read good news about B-Frames and MVHints.

And, about skipping blocks, I proposed this only for 1 CD encodes, because the Koepi's statment (should be as close to the original as possible) it's true if you have enough bitrate available. If you are bitrate limited I am more for "should look as good as possible". So, if implemented, I think it need to be optional.

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.

23rd September 2002, 17:57	#2 \| Link
Koepi Moderator Join Date: Oct 2001 Location: Germany Posts: 4,454	You got the idea right But I really dislike the "abuse" of pframes for this matter as bframes are on their way and already looking very nice according to... uhm... I think it was sysKin He has a better idea for MVhints: making them real hints as offset for improved motion search, resulting in an even better quality for 2pass+MVhints instead like now decreasing quality! His motion estimation will become default soon and thus some other benefits, too. Regards, Koepi __________________ Koepi's new media development site

24th September 2002, 11:12	#5 \| Link
Koepi Moderator Join Date: Oct 2001 Location: Germany Posts: 4,454	Integrating this with adaptive quantization is a great idea because you're willing to sacrifice some "original" blocks for bitrate there - this makes perfectly sense, I didn't think about that before, sorry. But without lumi masking the resulting frames/macroblocks should be as close to the original as possible IMO. Regards, Koepi __________________ Koepi's new media development site

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

23rd September 2002, 18:28	#3 \| Link
-h Kilted Yaksman Join Date: Oct 2001 Location: South Carolina Posts: 1,303	This is a good idea, but would probably be integrated with motion masking. In that case, we would adaptively set the TOOSMALL_LIMIT value, which determines how sparsely detailed a block has to be before being skipped. We would increase the limit (skip more blocks) if the block happens to have a large motion vector, or additionally if we know that the next frame will replace that block with an intra block. However that doesn't really happen all that often in the context of a full movie, but you may gain 1% or so in compression. -h

24th September 2002, 04:19	#4 \| Link
Aktan Registered User Join Date: Feb 2002 Posts: 303	"Every little bit helps"

24th September 2002, 13:30	#6 \| Link
pandv Registered User Join Date: Oct 2001 Posts: 62	Happy to read good news about B-Frames and MVHints. And, about skipping blocks, I proposed this only for 1 CD encodes, because the Koepi's statment (should be as close to the original as possible) it's true if you have enough bitrate available. If you are bitrate limited I am more for "should look as good as possible". So, if implemented, I think it need to be optional. pandv