Does Xvid implement some kind of shape detection?

[Magno]

I've been thinking lately in some ways to improve the yet-to-be-beaten quality in Xvid encodings; MPEG-4 standard talks about shape detection in Video Layer so it could be encoded through time with different motion vectors.

My question is: Has Xvid this technique implemented? Wouldn't be interesting to do some kind of shape detection in each frame to encode the object with one motion vector for all macroblocks that compound the object?

Thanks to all in advance!

[DeathTheSheep]

some ways to improve the yet-to-be-beaten quality in Xvid encodings
Nice. ;) However, if improving XviD is your aim, wouldn't you think it more pertinent at the moment that XviD's other issues be resolved prior to the implementation of new technology? For instance, the B-frame flickering in still scenes (particularly with low framerate or lower bitrate encodes) or the N-VOP insertion problem, both of which I've outlined in previous threads but have yet to be addressed.

The main benefit in using XviD over another emerging standard today is its breathtaking speed; I'm unsure as to whether or not such a technological endeavor, if not already implemented in XviD, would negatively impact its speed. If so, the possibility of its implementation would be rather restricted, to say the least.

Additionally, I've been hearing rumors of XviD's primary coders easing out of the XviD project--whether due to XviD's prevailing feeling of completion, the transfer of the developers to x264 (AVC), or otherwise tapering off. Regardless, the workforce required to add this (if not already implemented) is rather small.

I hope I've addressed the issue, if not answered your question directly ;) After all, I'm no developer!

Cheers, DTS

[Teegedeck]

Layer separation is not part of XviD's aim, that is fullfilling Advanced Simple Profile. There also are doubts whether the benefits of layers are in any sane proportion to the computational effort it would take to encode/decode such streams.

Such questions have been asked before, have a little search.
However, if improving XviD is your aim, wouldn't you think it more pertinent at the moment that XviD's other issues be resolved prior to the implementation of new technology? For instance, the B-frame flickering in still scenes (particularly with low framerate or lower bitrate encodes) or the N-VOP insertion problem, both of which I've outlined in previous threads but have yet to be addressed.I really don't dig it how quickly people call something 'the blablabla problem of XviD...' or an 'XviD issue' when 'my problem with XviD' would be more apt a term... Me and the other folks on this forum have been encoding with XviD and B-frames for years and haven't experienced the problem you describe in that thread and thus it seems to me that this is rather an individual case than an 'issue'. Nevertheless, your problem is a problem and I would have liked to help you tackling it.

To make it clear: I have no idea whatsoever whether there is an underlying cause for the problem with your source, that's why I didn't reply in that thread -- except perhaps there may be one simple explanation: You encoded at quant=7. Don't do that. It's a rotten idea. Your encoding shows clear artefacts from overquantization. XviD doesn't look so hot from quant=5 upwards (H.263 quantization). There's just limits to what MPEG4 ASP can do. If you want that strong compression then you're indeed better off with AVC.

Ah; and don't use N-VOPs, it ain't a good idea because they are inserted arbitrarily. Also, you don't gain much from dropped frames as you might realize when you regard the framesizes on still-scenes, especially those of B-frames.

Sorry I couldn't help you better.

[DeathTheSheep]

Sorry I couldn't help you better.

What?! You did help-- thanks a lot; yes, I hadn't considered whether or not the source itself has issues... I guess it just "looked" fine (I think I might have uploaded a sample somewhere...hmm). Now that you mention it though, zoomed to 400%, I can see some areas that flash just the tiniest bit in the source! Maybe that flickering is causing huge B-frame insertion/flashing problems too.

Wow, I just believe you've just helped solve the problem plaguing me since the dawn of mankind. Who would have thought it? Now...eh... anything to reduce that odd flicker? AVS script or something? ;)

As for the detection of shapes, layers, objects etc... Yeah, I too didn't really think it would bring all too much benefit but would reduce speed. Well, cheers

Regards,
DTS

[Magno]

As for the detection of shapes, layers, objects etc... Yeah, I too didn't really think it would bring all too much benefit but would reduce speed. Well, cheers

I DO think it would improve a lot, but yes, it is too cpu-intensive. Maybe it could be implemented as an option, just like an "insane" mode :D

[DeathTheSheep]

YES! I love insane mode.... But the "9999" performance mode in DivX Helium blows the doors of the now puny "Insane mode..."

But regardless, lots o' those XviD dev.s have "abdicated the throne" ;) :D ... so, something on such a grand scale might not necessarily be possible unless some cool new hotshot programmers take a step up.

Besides, I still think the existing features could use a bit of tweaking or optimization. Perhaps a few more of the "essentials" (according to this sheep, at least) include:
1. Sexy new FWV/GUI!! Heck yes. Look at x264 right now... *gurgle*
2. Different modes for B-frame bias (cartoon mode might want to use fewer B-frames on scenes with hardly any motion. P-frames in cartoons tend to be smaller and better looking than overquantized Bs in stiller scenes, not to mention the gap in P prediction caused by B-frame insertion. B-frames are still awesome in high-motion/high-bitrate scenes IMO).
3. Revamped, dynamic N-VOP insertion (3ivX 4.9b quality or better). Suggestion: If a frame has only a very small bit of motion (unnoticable), just stick in a P-frame. If it has no motion (or just about no motion, or no noticeable motion), insert an N-VOP.
4. Insane mode with (possibly?) limited layer detection, AQ for B-frames, P vs B experimentation (the codec takes time to calculate which would actually be preferable in the video), Quantizer noise shaping, loop filter (like ffdshow's), more advanced motion prediction, etc.

The fact is, the devices I use don't handle AVC very well, and AVC is only just emerging anyway. So an "Insane Mode" with the above features and "Layer detection" would be an awesome competitor to AVC but still maintain significantly wider compatibility and faster decoding time than AVC.

I think Magno really does have a point in this; if AVC is so darn slow, and XviD can almost rival its quality, wouldn't it make sense to slow it down enough to make it actually a major competitor but with greater compatibility and decode speed?

Just my [XviD] final thoughts. ;)

[Magno]

I think Magno really does have a point in this; if AVC is so darn slow, and XviD can almost rival its quality, wouldn't it make sense to slow it down enough to make it actually a major competitor but with greater compatibility and decode speed?



That's JUST the point of my question! :D

Two more questions:
What are those N-VOPS? I always thought that meant multiple consequitive B-frames.... Am I right?
What does "Insane mode" consist of? I never dared to make the question since DivX is not OpenSource and developers wouldn't be willing to answer. Maybe is an exhaustive search?

[Sharktooth]

N-VOPS are "null" frames.
Insane mode in divx is something like exhaustive search. Setting insane mode maximizes all possible codec internal settings to achieve the best possible quality regardless of the encoding speed.

[chilledoutuk]

maybe vhq4 on bframes or have a vhq5 for people who have a lot of time on there hands.

@ DeathTheSheep how did you set divx helium to 9999 as it tells me that 9999 is not in the aceptable range

[Teegedeck]

If you encode at a quality that you perceive as 'indistinguishable from the original' ('transparent'), regardless what codec you use, then you need never worry about quality. All that improvements in encoding technology bring you then is smaller filesizes. That's all there really is to it.

As for 'even insaner VHQ modes' or layers; is a saving of 2% in filesize really worth a, let us guess, doubled encoding-time, meaning an encode that takes days to finish?

[DeathTheSheep]

@ chilledoutuk
True, it doesn't let you set it at first.
The steps:
0. Open any random video file with virtualdub, click video->compression->DivX Helium->settings.
1. Set the codec to unconstrained profile (it only works here) and fiddle around with all of the other settings to your liking. Move the Performance slider to its max.
2. Click OK to get out of the codec settings, then OK to get out of VirtualDub's vfw list.
3. Reopen virtualdub's vfw list, hit DivX Helium's settings, and VOILA-- it now allows the user to set any value.

Truth to be told, though, I actually can't tell much quality difference between 9999 and 8610. In fact, 9999 almost seemed faster...
The problem with Helium is that the vfw has to be unloaded from memory before it can remove the limit.

If you encode at a quality that you perceive as 'indistinguishable from the original' ('transparent'), regardless what codec you use, then you need never worry about quality. All that improvements in encoding technology bring you then is smaller filesizes. That's all there really is to it.

Exactly--A great way to give words to the current ASP encoder's situation. With an "Insane"-type mode for XviD (doesn't have to be "MEGA-insane layered mode"--an extended option implemented like "Turbo Mode" would suffice I suppose), the quality will remain the same but the filesize will decrease-- it would literally fit the definition of "an improvement in encoding technology":)!
Essentially, people with faster computers (2 Dual-Core Hyperthreading Pentium4 Extreme Editions) would be able to actually make Uber-high quality video while maintaining total decoder-side compatibility with all of their ASP-certified devices. This seems to be the crux of the matter.

Ever try playing back VGA AVC on a PPC? :D You need ASP here, and at transparent quality, any little twitch of extra storage space would help tremendously.
I'd happily wait the long hours common with encoding AVC if all of my players/pdas/handhelds/older computers/etc supported it. Since that is not an option, I'd happily wait an equal (or even increased) amount of time encoding in the ASP we know and love (and that works), if any amount of much-needed quality/filesize benefits were attained in doing so.

So, if its possible to milk out even a little bit of extra quality for the power user (at least enough to rival DivX's Insane mode speed ;)), I think its well, well worth the longer encoding time, especially given the complexity and current incompatibility of AVC with many of the devices/players which, quite frankly, need it most but do not have it.

In my philosophy, XviD will not have reached its prime until a "insanier quality" mode appears; only then can ASP's maximum potential finally be fully realized and taken advantage of... before AVC deems it too late, and ASP is never improved much again.