Rendering/h.264 encoding for objects with "round corners"? And a possible render bug.

  1. rendering/h.264 encoding of objects with “round corner”

I’m trying to encode my new animation/music video to h.264 for webdistribution and while I’ve successfully used the codec on many non-3D projects in the past I always was a bit unhappy with (sharp) corners and blender rendered 3D animation (e.g. 3D text).

Now this time I seem to have a real problem since my leading characters are 3D visuals with round corners and no matter how high I set the kbps rate it keeps looking ugly when encoded to h.264. Maybe the problem is also with the rendering, not sure… I tried setting the OSA to 11 and 16, but this does not seem to help. The main problem I think is with the encoding (done via QuickTime Amateur, a for free QuickTime Pro clone).

How can blender rendered animation with “round corner” objects be compressed with h.264 and bring good results…? (I searched the forum and could not find an answer for that one.)

And also what brings the best results for rendering objects with sharp edges or “round corners”…?

Please see the attached .pdf screenshot (converted to png since I can’t post the pdf…) (“h264 encoding problem”) with my notes to see what I mean.

  1. possible render bug

Before I post this one as a bug report I want to make sure that it is a bug…

When the camera is placed inside and in the centre of a spot with halo I get black and coloured dots where there should not be any. They seem to be arranged in a symmetrical kind of way. A known problem…?

Please see the other attached .pdf screenshot (converted to png) (“possible renderbug”) for details.

Thanks!

Hmm… I just saw that my uploaded images have been converted to low-res jpegs… So you will not see much of what I point out, hope it makes things clearer anyway…

(looks like the attachments got lost, so I try again with this reply…)

Attachments



Are the screenshots of the render original size?
Because in the size you posted them I see hardly any differences at the edges you pointed out.

But you also should remember, no matter how high you set your bitrate, h.264 is still a compression after all and uses its certain algorithms to compress the material, so you can not expect a perfect result, even if you set the bitrate incredibly high.

In this case I would recommend (just to test if it would look any better) to render it at a Quicktime with some high quality compression (like “Animation” or even “None”) and then compress the resulting Quicktime-File to h.264.

It might make a difference, I am not quite sure, how Blender handles keyframes and such when creating a h.264 file.

Best, MasterDomino

Thanks for your answer!

The screenshots: yes, you can’t see much, I uploaded a high-res png (about 1 mb) but the forum converts them to low-res jpegs…

I now tried again a small sample, it is a jpeg conversion but this is more or less what you would see in the 640x480 video that was compressed at a kbps rate of 1024. Higher compression look better, but the problem remains and is not satisfying, even at very high kbps rates.

My actual workflow is a bit more complicated than that of course: I render the video with 640x480 as a series of Targa stills, import those in the blender nle, export them as a .mov using the same TGA settings, import them into Final Cut Express (since there seems to be no way to export video and sound in the OS X built as a .mov/TGA sequence, only mpeg-2 seems to work, all other combination crash blender or don’t do anything at all). After the Final Cut Express export I convert the video with QuickTime Amateur to h.264 and it looks more or less like the jpeg I now just attached…

I wonder how others do this and thought this must be a common problem…?

Attachments


Ok, now I can see, what you mean.

And now that I see it I think the problem is rather that you used such an extremely saturated green. Pure saturated colors (first of all red, but also green) are often very problematic in Videos, they tend to “bleed out” (not sure if that is the correct english term).

Being a DVD author I just can speak for the DVD compression rules, that if you have a pure green (meaning R 0 G 255 B 0), you have to lower your green value to 185 (no, not 235). This applies to other pure colors as well.

I am not sure now how this translates to h.264 (since DVD is MPEG-2, not h.264), but I guess if you lower the intensity of the green you should get better results.

Best, MasterDomino

Ahh, that is a very interesting piece of information… You are right about the intensity of the colours, hmm… I have to investigate this further in context with h.264 since the whole video is basically based on two colours, green and orange, and in both cases I probably use a lot of very saturated ones. I don’t want to redesign (and render) the whole video (over 3 min.) if I can avoid it of course… But maybe a piece of the puzzle. Thanks!

Well, if you still have your Targa stills and they look fine, you don’t need to rerender it, you just need to lower the intensity of the green in some application, before you compress it to h.264 again.
Final Cut Express should be fine for that or probably also the node system of Blender (not familiar enough with it yet to really tell).

OK, I see what you mean… I’ll try this with the nodes system and will post my complete workflow for h.264 encoding to the forum once I’ve figured it all out - there are not enough threads about the details of h.264 encoding in this forum and I think this is information that could be of interest to many.

Also: in a couple of weeks Adobe will release their iTunes like app for Flash video aggregation and Flash will have h.264! (And YouTube etc. too…) Sounds like a good combination for getting our blender made video works out on the net, even if I personally don’t like Flash that much, but h.264 Flash video could be interesting…

Actually it is probably way easier to do it in Final Cut, but of course it would be nice for the community to know how to do it right in Blender.
But be aware, it is not only a problem with h.264, also other codecs show the same characteristics, like MPEG-2 and even DV-PAL for example.

That sounds very good, I didn’t know of that yet.

Most codec, especially H264 AVC has this problem where extreme saturated colors tend to become blocks. (check out some high quality trailers on Apple.com/trailer to see the same problem)

A few things to keep in mind:

  1. Like others have already said, always render/composite the movie as a RAW stream (TGA/PNG/AVI RAW), so that you’ll always have a high quality stream to go back to in case anything goes wrong with the encoding.

  2. try play around with the encoding settings, The h264 encoder in Blender (FFMPEG, to be exact) isn’t as ‘good’ as x264, which I THiNK is available on Mac, too?

  3. Most H264 decoders apply post-processing to the video, so the blocky colors should become less noticeable.

  4. Adobe will offer H264 capability with the next update of Flash 9. But it will take the rest of the world about 12 month to update to the new player (current version 9 will not play)

Yes, x.264 is available for Macs, in fact til now I thought that blender was using this codec, since it is the open source codec.

I am just wondering how the compression works if you directly compress it while you render, because afaik h.264 also respects information of upcoming keyframes… So to properly compress Blender would have to always wait for the next keyframe to be rendered before it can compress all the frames before, which means it must store all the other frames before in some uncompressed form in some temp directory. Or am I somehow wrong there? Does anybody have some more details about that?

@indiworks: Since you are working on a Mac I would in fact recommend that you use ffmpegX for your compression. It always gives me very good results and you can choose between three different h.264 codecs. So you can try and compare. It is shareware, but you can do what you want legally with the unregistered version also.

MasterDomino

OK, thanks, so the general wisdom seems to be that saturated colours really can cause these problems… I am just a bit surprised, since I’ve used H.264 on many non-3D videos and usually you can get any quality you want by adjusting the bitrate. But I guess 3D animation is a special case… (I will have a closer look at some of the Pixar trailers then.)

Yes, I render all my animations as a series of Targa (Raw) images and usually keep those in my archive.

On the Mac you e.g. have ffmepX for open-source x264 encoding, ffmpegX is a great tool, a bit difficult to get all the settings right at first (seems not to work…), but once you’ve figured it all out (look at their forums for help), it is a good tool. I’m not using x264 at the moment, the last time I checked all x264 encoding was significantly darker than the commercial H.264 that you get via QuickTime Pro or the for free QuickTime Amateur: old version or new version.

Then there is of course Ogg Theora for open-source video encoding (more details here), last time I checked you had to use the OS X Terminal for using it and I only could get either picture or sound encoded, but not both at the same time. But it does look interesting, if it really can compete with H.264 in terms of quality I don’t know yet.

And just to have it all in one place, this is the BBC’s effort to replace the much hated RealVideo codec with their open-source Dirac Video Codec, but I don’t think it is ready yet.

About the H.264 encoder in blender: I can’t use it anyway since this does not seem to work under OS X (10.3.9). The only working combination for combining video and sound is FFMpeg/MPEG-2. All other presets either crash blender or don’t do anything at all. I thought this was a know problem, but maybe this is another OS X (10.3.9) related bug I should report…? (Since 2.44 there are quite a few of those unfortunately…)

If anyone is interested in finding out more about distributing their own media online using alternative platforms, open-source software etc. have a look at the quite extensive P2P Audiovisual Guide that I maintain!

I’ll give it another try then - in combination with working on those saturated colours I have. (Last time I checked x264 via ffmpegX produced somehow quite dark results when compared to H.264, but maybe they fixed that by now…?)

If I remember correctly the dark colors came from the fact that the Quicktime Player was interpreting the gamma curve of the so encoded material in a wrong way. That was at least the case with the (great) software VisualHub http://www.techspansion.org/
This bug has been fixed in VisualHub, so I guess it must be a software problem, not a codec problem.

But since this costs money I’d like to point out that on the same site also iSquint is available which is a version of VisualHub that is limited to converting for iPods. But it is for free and since it can be used to make h.264 videos and it is really easy to use you should give it a try.

Also if you are interested in these things you should check out MPEG-Streamclip which is another free and very advanced alternative for the Quicktime Player and it even can do batch conversion!

Thanks also for the link to your P2P-Audiovisual Guide, it looks very interesting!

MasterDomino