HC 016 - blocks in still parts

[zsb]

I encoded a piece of Japanese animation with HC 016 and was rather pleased with the way it handled vertical scroll parts. The animation consists mostly of still or slow moving scenes. However, some closer inspection reveals some oddities. See these screen caps (zip file includes all 13 pictures). They are from the beginning of a scene. The log file is also available there:

ttp://www.cc.jyu.fi/~tristan/hc/m3/

You will notice the wall behind the girls is heavily macroblocked. It will turn smooth a bit later when the girl turns her head more. This is only one example - there are several within the encode. None of this is present in the source.

Also worth noticing is the picture 02: you will notice odd blocks in the middle of the girls hair and in the right side ribbon. Needless to say, in the source pictures 01 and 02 are identical.

Next, picture 03: the subtitle disappears and leaves some garbage behind.

Then compare pictures 07 and 08: the same odd blocks appear as in pictures 01 and 02. Another point of interest is the garbage around her mouth and the block on her chin.

Why all this detailed description? Well, as you see in the log file, the encode consists of over 30000 frames and I have sampled only 13 - I admit most are probably fine, I won't go over every frame - but even then problems of this kind should not exist in a great encoder like this one. I tried to keep all the settings as default as possible to avoid problems. Therefore I'm asking if I missed some obvious setting that would produde these results. So far I haven't found a solution.

So, in conclusion, HC shines in video that is rich in motion (live action at least) but when it comes to still scenes and consecutive (nearly) identical frames, it still has room for improvement. :)

[Mug Funky]

hmm. a few questions (sorry, haven't looked at the pics yet).

what bitrate did you set?

can you see the blocking when you play it back? some obvious macroblocking completely disappears even with eagle eyes and the knowledge of where and what to look for... video coding has a psychovisual aspect to it after all, and assumes the video will be played back at the input frame rate.

does your source have blocks in it? re-encoding has a habit of amplifying blocks, even in non-moving areas. deblocking the source helps a lot here, but extreme blocking will get through by necessity (it'd take a clever deblocker to guess the difference between a big disgusting block or a very sharp edge on a graphic, and know which to blur and which to pass through).

finally, a sample of the encoded file would be good - we can learn a lot more from that than from some stills. some of the unprocessed source would also be cool so we can replicate the problem (and look for blocks in the source...).

[zsb]

Thanks for the answer. I will try to answer your questions.
hmm. a few questions (sorry, haven't looked at the pics yet).

what bitrate did you set?
bitrate Kb/s: 2060
max. bitrate Kb/s: 2496
can you see the blocking when you play it back? some obvious macroblocking completely disappears even with eagle eyes and the knowledge of where and what to look for... video coding has a psychovisual aspect to it after all, and assumes the video will be played back at the input frame rate.
Yes, I can see the blocks just fine. Of course, there are other things to look at during playback, so one might not be able to see it if not concentrating on finding it. The other glitches are more visible, however.
does your source have blocks in it? re-encoding has a habit of amplifying blocks, even in non-moving areas. deblocking the source helps a lot here, but extreme blocking will get through by necessity (it'd take a clever deblocker to guess the difference between a big disgusting block or a very sharp edge on a graphic, and know which to blur and which to pass through).
I do mention in my report that the source has none of these problems. I didn't want to bring this up in an early stage of analysis as this, but I guess I have to. I have encoded the same piece of animation with CCE and there are also no signs of the problems I describe in my first post. As I mention in another thread that announced 016 release, I had to look for alternatives since CCE fails in several panning scenes. HC shines in this respect.
finally, a sample of the encoded file would be good - we can learn a lot more from that than from some stills. some of the unprocessed source would also be cool so we can replicate the problem (and look for blocks in the source...).
I'll see what I can do. My account has a size limit but a sample should be fine. Unprocessed source is another matter... :)

[kumi]

You can try uploading large files to http://www.yousendit.com/ or http://www.megaupload.com