possible to choose the warppoints of GMC?

[bond]

as currently 3 of the 4 available MPEG-4 hardware decoder chips handle 1 warppoint GMC only (as offered in divx5), i wondered whether it would be easily possible to add the possibility to xvid for being able to choose which number of warppoints you want to use if you enable GMC

so people who dont aim at (existing) hardware compatibility could choose 3wp GMC, but people with hardware players could use 1wp GMC

[Teegedeck]

From what I've read from technically insighted people, if you don't use 2+ warppoints you might as well not use GMC at all. 1-warppoint GMC wouldn't improve anyting.

For an interesting thread about GMC and warppoints look here (http://forum.doom9.org/showthread.php?s=&postid=435291&highlight=warppoints) .

[bond]

yep, i found this thread too :)

i just meant that if its easily doable, it would be nice to make it choosable, as it will ensure full compliancy with standalones, will avoid newbies to think that the xvid gmc, in contrary to the one from divx5, is not mpeg-4 compliant or so, makes clear what the differences are between the different GMC implementations and will also show that xvid on yet another feature kicks divx5's ass :D

[sysKin]

XviD, by default, will never ever use a 1-poing GMC. If GME says that actually 1-point is good, it's completely ignored and p-frame is created instead.

There is no way for 1-point GMC to improve anything.

Radek

[bond]

Originally posted by sysKin
XviD, by default, will never ever use a 1-poing GMC. If GME says that actually 1-point is good, it's completely ignored and p-frame is created instead.hm, thanks for the explanation, didnt know that :)

btw i love your sig ;)

[Teegedeck]

Hehe, yes. It must be an extraordinary feeling that calls for long, extended holidays. But seriously: Rush, rush, back to work and invent some new bugs! :cool:

[Andrey]

as currently 3 of the 4 available MPEG-4 hardware decoder chips handle 1 warppoint GMC only
Heh. This means that rest of them (one) handle:
1. No GMC
2. 2 or 3 warppoint GMC
? :)
Just curious, is there any microcontroller that can handle 3 WP GMC ?
I did not hear anything about it...

Thanks in advance !

[bond]

i dunno if i am up-to-date, but 1 chip doesnt handle gmc at all (dunno if this is ess or the old sigma chip) and the other 3 chips handle 1 warppoint gmc

[SeeMoreDigital]

Originally posted by bond
...i just meant that if its easily doable, it would be nice to make it choosable, as it will ensure full compliancy with standalones, will avoid newbies to think that the xvid gmc, in contrary to the one from divx5, is not mpeg-4 compliant or so, makes clear what the differences are between the different GMC implementations and will also show that xvid on yet another feature kicks divx5's ass :D I like the idea of being able to select the warp points. I guess, if it were possible, it could be implemented in much the same way B-VOP's are currently selected in XviD.

That said, in the spirit of DivX/XviD compliance, we all know that DivX uses only 1B-VOP (to go with it's shitty 1warp point). So why is it when I select 1B-VOP in XviD (with or without packed bit stream) my Xcard throws a wobbler?

How can the two Mpeg4 codecs be so different in this regard?

Cheers

[Teegedeck]

The bottomline of this all is (and excuse me for saying it in a rude way, but I want to make it clear): DivX GMC is a sham. There's no need to use it, there's no need (for a player) to decode it, there's no need for selectable warppoints in XviD. ;)

[SeeMoreDigital]

Originally posted by Teegedeck
The bottomline of this all is (and excuse me for saying it in a rude way, but I want to make it clear): DivX GMC is a sham. There's no need to use it, there's no need (for a player) to decode it, there's no need for selectable warppoints in XviD. ;) Got it :D

So now that we all understand that 1warp point is pointless. Is there any point in having more than 3warp points.... say 5.... well I had to ask?


Cheers

[virus]

Originally posted by SeeMoreDigital
So why is it when I select 1B-VOP in XviD (with or without packed bit stream) my Xcard throws a wobbler?maybe XviD simply doesn't like Sigma Designs... ;)
...especially what Skal called their "copy-paste department" :D

[Teegedeck]

Originally posted by SeeMoreDigital
Got it :D

So now that we all understand that 1warp point is pointless. Is there any point in having more than 3warp points.... say 5.... well I had to ask?
Some posts above I linked to an interesting thread about just that.

[virus]

Originally posted by bond
i dunno if i am up-to-date, but 1 chip doesnt handle gmc at all (dunno if this is ess or the old sigma chip) and the other 3 chips handle 1 warppoint gmc
BTW speaking of hardware support, LiteOn is selling a player (the LVD-2010 (http://www.liteonit.com/DC/english/lvd_2010/2010_mpeg4.htm)) that, according to them, "playback the latest video formats such as MPEG4 & XviD formats".
As if XviD was something different than MPEG-4! :eek:

They also invented a logo for XviD (see it here (http://www.liteonit.com/DC/english/productinfo.htm)) which has nothing to do with the original... but it's obviously based on the DivX one. I wonder if they can do this?

virus

[bond]

Originally posted by virus
[B]BTW speaking of hardware support, LiteOn is selling a player (the LVD-2010 (http://www.liteonit.com/DC/english/lvd_2010/2010_mpeg4.htm)) that, according to them, "playback the latest video formats such as MPEG4 & XviD formats".
As if XviD was something different than MPEG-4!well in fact, thanks to AVI, you cant play xvid streams in avi on a player which only supports divx5-in-avi without workarounds, like you cant play 3ivx streams by default on the existing players atm (altough 3ivx is mpeg-4 too)

by default the avi container harms interoperability (you first have to change the FourCC to something supported by the player, like DIVX, before you can use mpeg-4 streams not created by divx, in a "divx" player)

therefore atm it makes sense to list every codec, which is supported by default

[SeeMoreDigital]

Originally posted by virus
maybe XviD simply doesn't like Sigma Designs... ;)
...especially what Skal called their "copy-paste department" :D Well, I understand why that might be the case but I hope that it's not 'still' the case.

If 3ivX ever get round to building and ASP encoder it would be interesting to see if theirs would fair any better!

I think there's no denying it was a real shame that both sides fell out. We can only imagine how much better Mpeg4 as a whole would have got if Sigma had have paired up with XviD instead of DivX.

And with Sigma now palling up with Nero/Ahead I wonder if ('reading between the lines') this means that DivX 'is' pulling out of Mpeg4 altogether?


Cheers

[stephanV]

Originally posted by bond
well in fact, thanks to AVI

i would say: thanks to player-manufacturers who completely ignored (or misunderstood) how MPEG4 "works" in avi. DivX could also have a share in this (mis)development though... i dont know.

Originally posted by SeeMoreDigital
We can only imagine how much better Mpeg4 as a whole would have got if Sigma had have paired up with XviD instead of DivX.
well... i don't see a company doing a lot of business with a project that has an "educational" status.

And with Sigma now palling up with Nero/Ahead I wonder if ('reading between the lines') this means that DivX 'is' pulling out of Mpeg4 altogether?
DivX doesnt seem to make a lot of effort to support the MP4-container yet, that could be another reason.

[SeeMoreDigital]

Originally posted by stephanV
...DivX doesnt seem to make a lot of effort to support the MP4-container yet, that could be another reason. Actually I was not thinking about the MP4 container (for a change). Just Mpeg4 in general.

And even though XviD is for 'educational' purposes. You don't have to be all that educated to know that it's now way better than DivX, despite DivX's revenues and brand name!


Cheers

[bond]

Originally posted by stephanV
DivX doesnt seem to make a lot of effort to support the MP4-container yet, that could be another reason.i assume they will maybe rethink this after they realise that nero will bring MP4 (including multichannel, high quality aac audio, chapters and subtitles) to the firmwares of 2 existing mpeg-4 decoder chips (old and new sigma - and i hope mediatek soon too) :D

[RedDwarf69]

Isn't mediatek supporting 2 warppoints?
If we change
Originally posted by bond
so people who dont aim at (existing) hardware compatibility could choose 3wp GMC, but people with hardware players could use 1wp GMC

for "but people with hardware players could use 2wp GMC" would make sense to implement the option?

[Tommy B.]

I think it would make sense, at least when it would come to encoding credits or cartoons.

[lordadmira]

Originally posted by stephanV
DivX doesnt seem to make a lot of effort to support the MP4-container yet, that could be another reason. I don't think there'll be any wide penetration of the .mp4 container until Windows Media Player starts supporting it by default, which AFAIK is now does not. Until then it'll stay underground like Xvid used to. ;)

[Teegedeck]

Originally posted by Tommy B.
I think it would make sense, at least when it would come to encoding credits or cartoons.
Credits could be encoded using two warppoints but actually such motion is more efficiently encoded by b-frames.
Edited: utter stupidity

[stephanV]

Originally posted by lordadmira
I don't think there'll be any wide penetration of the .mp4 container until Windows Media Player starts supporting it by default, which AFAIK is now does not. Until then it'll stay underground like Xvid used to. ;)

i think it never will (and who uses WMP anyway, other then testing for files to be fool-proof :p)

people promised me standalone players with mp4-support so i guess that would increase penetration a lot :)

but back to GMC now

[Prettz]

Originally posted by Teegedeck
Credits could be encoded using two warppoints but actually such motion is more efficiently encoded by b-frames.
Edited: utter stupidity
Slightly off-topic:
I did a test a while back (using koepi's 6/24/03 build) on some credits that were very noisy and in color (but still against a black background). Xvid had an extremely hard time with quantization artifacts around the credits. The 1 warp-point GMC really really helped at totally eliminating the "shit" streaks that the scrolling credits left behind them, which just 2 b-frames couldn't do, and allowed me to lower the bitrate much further.

If you quant the p/s-frames the same as you would have done the b-frames, wouldn't this inherently be more efficient?

[Teegedeck]

Originally posted by Prettz
If you quant the p/s-frames the same as you would have done the b-frames, wouldn't this inherently be more efficient?
The good thing about b-frames is that they do look good at higher quants and don't hurt subsequent frames in spite of strong compression. Which you cannot say of p/s-frames. If you quantize one p-frame too strongly you also deteriorate the following p-frames.

[Tommy B.]

Originally posted by Prettz
Slightly off-topic:
Xvid had an extremely hard time with quantization artifacts around the credits. The 1 warp-point GMC really really helped at totally eliminating the "shit" streaks that the scrolling credits left behind them, which just 2 b-frames couldn't do, and allowed me to lower the bitrate much further.

Yeah, that's exactly my experience. I once used to encode my movies with DivX and since my KISS DP450 is able of playing movies encoded with 1point GMC, I used it through the whole movie.

Just to test the useability of it I encoded a movie with GMC and without. The credits were encoded separetely and that is where I noticed the difference. Credits without GMC had some pretty ugly lines for about 1 or 2 seconds until they completely disappeared. But afterwards they appeared somewhere else which made the credits overall ugly. Okay, I used 50kbit/s for encoding them but I was a little bit surprised when I noticed that there were no such ugly lines when GMC was enabled.

[Prettz]

Originally posted by Teegedeck
The good thing about b-frames is that they do look good at higher quants and don't hurt subsequent frames in spite of strong compression. Which you cannot say of p/s-frames. If you quantize one p-frame too strongly you also deteriorate the following p-frames.
You're right, I keep forgetting that in discussions about b-frames. Is it valid to have a video that looks like IBBSBBSBBS...? I would think that would be even better.

[Teegedeck]

AFAIK this is rather a typical frame-order when you use b-frames and GMC, isn't it?

[lordadmira]

And in situations where the credits are scrolling over a background, which is the norm in anime, GMC is useless. Because only the text is moving. And since the text is constantly moving over new background it has to be intra-coded for each frame (or nearly so). Flash on/off credits are much much more efficient.