GMC: observations... and now discussions!

[Manao]

Moitah : yes, 2WP is equivalent to 3WP whose last WP is (0,0). And the same goes for 1WP, btw.

[Moitah]

@SMD: Interesting, I wonder how XviD does with those clips.

@Manao: Thanks for the info.

[bond]

SMD, as i wrote already, divx5 always seem to signal 2warppoints :)

[SeeMoreDigital]

Originally posted by bond
SMD, as i wrote already, divx5 always seem to signal 2warppoints :) I wonder what this could mean?

Could there be something not quite right with MPEG4 Modifier. Or has DivX been misleading us all these years?


Cheers

[bond]

Originally posted by SeeMoreDigital
Could there be something not quite right with MPEG4 Modifierno, there is no problem with mpeg4modifier, divx5 streams indeed signal 2warppoints in the vol as i wrote here (http://forum.doom9.org/showthread.php?s=&threadid=90473), didnt get any answer from divx guys tough

[SeeMoreDigital]

Originally posted by bond
no, there is no problem with mpeg4modifier, divx5 streams indeed signal 2warppoints in the vol as i wrote here (http://forum.doom9.org/showthread.php?s=&threadid=90473), didnt get any answer from divx guys tough I wonder how much more confusing GMC can get ;)


Cheers

[SeeMoreDigital]

A couple of days ago Moitah was kind enough to send me a preview version of MPEG4 Modifier 1.3.2 to help test his new GMC "warp-point" reading implementation.

I generated some encodes using DivX, XviD and NeroDigital. With and without black mattes and obtained the following results: -


DivX encode with mattes
http://img238.exs.cx/img238/2261/divxgmcwithmattes0im.gif


DivX encode without mattes
http://img238.exs.cx/img238/1656/divxgmcwithoutmattes0cr.gif


NeroDigital encode with mattes
http://img238.exs.cx/img238/1849/nerogmcwithmattes3ca.gif


NeroDigital encode without mattes
http://img192.exs.cx/img192/503/nerogmcwithoutmattes6ai.gif


XviD encode with mattes
http://img11.exs.cx/img11/5259/xvidgmcwithmattes1im.gif


XviD encode without mattes
http://img238.exs.cx/img238/6971/xvidgmcwithoutmattes2yu.gif

When you compare the "with" and "without" mattes results for each codec. DivX results appeared to be very consistent at 1 warp-point. Nero's results were as bobololo has stated. But XviD's results require explaination... me thinks!


Cheers

[Manao]

If black mattes favorizes a lot 1 WP GMC, it doesn't mean that a 3WP GMC can't be found sometimes. There's only 3 frames in which it occures, so i don't think there's something wrong. A visual inspection of the clip may prove that these frames are ( perhaps ) very dark.

I hope that the application is buggy when it says 0 WP GMC detected on some frames with Nero's MPEG4 ( else, Nero has a very unwanted behavior in this regard ).

[SeeMoreDigital]

Originally posted by Manao
...A visual inspection of the clip may prove that these frames are ( perhaps ) very dark. I've just made the files available via my "slow home server". So please download and analyse them...

DivX_GMC_with_mattes (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/DivX_GMC_with_mattes.7z) @ 1077KB

DivX_GMC_without_mattes (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/DivX_GMC_without_mattes.7z) @ 1163KB

Nero_GMC_with_mattes (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/Nero_GMC_with_mattes.7z) @ 618KB

Nero_GMC_without_mattes (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/Nero_GMC_without_mattes.7z) @ 922KB

XviD_GMC_with_mattes (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/XviD_GMC_with_mattes.7z) @ 1068KB

XviD_GMC_without_mattes (http://82.2.167.237/Uploaded_Files/Doom9_Forum_files/XviD_GMC_without_mattes.7z) @ 1128KB

Each one of the files has been encoded to the same file size and has been compressed using 7-zip. As you can see the NeroDigital files have compressed much more than the DivX and the XviD files!


Cheers

[Moitah]

Thanks SeeMoreDigital!


@Manao: I don't think its wrong... here's the code:
if ( (vol.sprite_enable != (uint)Sprite.None) &&
(vop.coding_type == (uint)VOPType.S_VOP) )
{
vop.warping_points_used = 0;

for (int i = 1; i <= vol.sprite_warping_points; i++) {
bool x_used = CopyWarpingCode(bits);
bool y_used = CopyWarpingCode(bits);

if (x_used || y_used) {
vop.warping_points_used = (uint)i;
}
}
}
private bool CopyWarpingCode(BitStream bits) {
for (int i = 0; i < _sprite_traj_len_code.Length; i++) {
if (bits.Peek(_sprite_traj_len_bits[i]) == _sprite_traj_len_code[i]) {
bits.Copy(_sprite_traj_len_bits[i]);
bits.Copy(i);
bits.Copy(1);

return (i != 0);
}
}

throw new Exception("Invalid VOP (unable to find sprite trajectory length VLC)");
}
The lookup tables are right, I double checked them. I know that code is executing on the Nero file (I put a messagebox in there to test).

EDIT: And putting bits.Peek(18) before any of the other code shows "001001001001001001", which is "00" and "1" (marker) repeated twice for each 3 warp points....

[Manao]

Moitah : so it's Nero's GMC decision which is very unefficient ( what a surprise... )

SMD : so the frames where XviD uses GMC aren't dark. But still, it's possible that the GME algorithm came up with plausible values in these case. I'll have later a closer look to see if there are macroblocks that are indeed using GMC in these frames

[SeeMoreDigital]

Originally posted by Manao
... so the frames where XviD uses GMC aren't dark. But still, it's possible that the GME algorithm came up with plausible values in these case. I'll have later a closer look to see if there are macroblocks that are indeed using GMC in these frames Thanks Manao,

Hopefully I did not encode the samples at too low a bit-rate for you do this!


Cheers