Cartoon Mode Recommendation: Split up functions?

[zettai]

As detailed in various places, Cartoon Mode is actually two functions: detect_static_motion and vop_cartoon.

Now, due to the nature of vop_cartoon (which in it's quantization loses certain details in order to reduce noise) Cartoon Mode isn't much use for detailed animated sources like a lot of anime.

However, the detect_static_motion option could have a lot of benefit even for anime sources, as many are animated at 8 or 12 fps and between static frames exists a lot of noise. Admittedly a good temporal smoother can fix this too but I was wondering why both of these options should be bundled together when vop_cartoon only offers a benefit in certain types of sources.

I'm not particularly experienced with either of these functions, admittedly, but it seems that detect_static_motion could have all sorts of benefit for different sources and it might be nice to be able to select these individually.

[RadicalEd]

Like this (http://misatokatsuragi.home.comcast.net/xvidcore-1.0.0-RC4-mod.zip)?

However, detect_static_motion by itself doesn't seem to actually do anything... though my test source was overfiltered. Mess around and see what you can get.

No dice. Unless I'm terminal and there's some kind of indirect internal connection between vop_cartoon's limit changes and parts of the detect_static_motion algorithm, it appears to be useless http://www.animemusicvideos.org/phpBB/images/smiles/icon_neutral.gif
At least, I can't figure it out.
Just commenting out
if (codec->config.cartoon_mode) {
//this line: frame.vop_flags |= XVID_VOP_CARTOON;
frame.motion |= XVID_ME_DETECT_STATIC_MOTION;
}

in the untouched RC4 source has the exact same effect. So I dunno :\


Please take note, I am a moron. VOP_CARTOON and D_S_M are reliant on each other. I just suck at tracing C code :| boo.

[mf]

Cartoon mode needs post-1.0-final plugins :). I wait patiently.

[lordadmira]

What would be REALLY useful in a "Cartoon mode" would be detect_periodic_motion. Because all animation makes extensive use of repetitive motion loops to animate things like running, flying, debris, path motion, etc. They just animate a few frames and then just play these over and over until the scene is finished. Right now B frames can't really exploit this type of redundant information. Because they're limited to referencing proximal P frames, IIRC. This type of function would only need allow them to reference any two arbitrary P frames in the GOP. Get all the blocks that make up the motion loop into P frames and then they can be used over and over again for the entire scene. Now that I think would lead to a big quality jump in anime encoding.

[RadicalEd]

Alas, that's in the realm of H.264. No way to do so in any of the other profiles.

[lordadmira]

Heh, could u expound a little on ur cryptic answer. Like "why".

[mf]

That wouldn't work. MPEG4 won't allow it. You can try to optimize the B-frames but that's all you can do. That said, cartoon mode needs to be available from zones >_>.

[RadicalEd]

Originally posted by lordadmira
Heh, could u expound a little on ur cryptic answer. Like "why".

B frames can only reference previous/next frames in normal mpeg 4. H.264 added the ability to reference any frame in the video.

Cartoon mode needs to steal ff-mpeg4's quantizer noise shaping and spatial/temporal complexity masking :|

omg, attack of the anime encoders.

[DeathTheSheep]

RadicalEd, great idea... Quantizer noise shaping and complexity masking really helps hide "trash noise" and improve visual quality.

Anyone know the status on the function splitup? Does XviD have yet to make any improvements to its detect_static_motion function?

[Teegedeck]

You're trying to reanimate a thread that's been dead for over a year... >_< ;)

[DeathTheSheep]

Oops, good point, didn't see the date there... :D

Sorry 'bout that. ;)