just wondering how you guys are encoding your videos to h264? are you doing it manually or using a frontend? a few FYIs: h264 does not belong in avi, some examples of proper containers for h264 would be mkv and mp4. also one-pass encoding with x264 is generally done nowadays with CRF, not CQ. from the documentation:
The final ratecontrol method: Constant Ratefactor. While qp targets a certain quantizer, and bitrate targets a certain filesize, crf targets a certain 'quality'. The idea is for crf n to give the same perceptual quality as qp n, just in a smaller space. The arbitrary unit of measure for crf values is the "ratefactor".
also the progressive blurring someone commented on isnt actually youtube doing that, thats kalles fraktaler doing that intentionally. youtube itself doesnt render subregions of your video at progressively more terrible quality, it is happy to just go ahead and turn every single pixel of every frame into a smeary poopy featureless mess. karl's idea was that you will only be uploading videos to youtube so in the end you wont notice anyway or maybe hopefully gives some sort of softening effect at the center of the image
... he is a bit misguided in his thought process on that one.
The whole point is that H264 codec was designed for "normal" video data, including things like all manners of cinematography, real life video and animation, both CGI and cell drawn.
Fractal data by design is notoriously difficult to encode using existing codecs. the level of detail in a fractal is infinite, limited only by pixel resolution. The self-replicating shapes create extremely unnatrual patterns. Videos from normal sources typically consist of forground and background areas that often move at different rates of speed. H264 was specifically designed to track block areas of movement as they pan across a video frame as with any cinematography sequence as well as hand or computer generated animations, rather than relying on outdated codecs which only looked at the differences between static pixels on adjacent frames, often leading to tearing and pixelation of anything that moved considerably between frames. That Cinepak codec used to compress 320x240 (and smaller) videos across dial up for view on PCs with Pentium I processors. Your CPU was considered state of the art if it included MMX instructions.
But I digress. Fractal data has tons of repeating detailed areas of infinitely repeating patterns. Depending on the type of fractal or region within, the density of this fractal data can range from extremely sparse (Mandelbrot "utter west" needle for instance) to so dense it becomes space filling (the crust of the main cartoid like I zoomed in this video). Color palettes vary wildly based on artist preference, but generally tend to be smooth gradients to wild changes of brightly colorful bands in which the brightness, hue, and saturation values vary as wildly as their respective RGB values.
In real life cinematography as well as all types of animation, objects are typically made out of material which is solid in hue and saturation but light hits the textured object creating subtle variations in brightness. Our eyes likewise have more rods than cones so our eyes/brains perceive finer details in brightness fluctuations than in color. As a result, both real world / human perception often contain / percieve less data in hue/saturation compared to brightness, so using BHS instead of RBG just makes sense as a way to encode data. Jpeg format uses this and most photos have little loss of detail using decent compression ~90%. Video formats use this too and are further compressed into 4:2:0 color space to further reduce the data prior to compression.
Obviously, fractal data has very unnatural / unrealistic color space. The combination of smooth gradients with fine grainy detail makes compression tricky for static images. Often PNG creates a smaller file than Jpeg 100%, and the lossy artifacts due to Jpeg compression are noticable even at max settings due to the reduction of color space. Well, try to render a video out of this fractal soup and you've just opened pandora's box. H.264 has a number of things going for it, primarily an excellent motion prediction algorithm. Zoom movies consist almost entirely of endless zooming in, with features getting larger as they accelerate toward the edge of the screen. So the motion prediction effect of H.264 is by far the biggest space saver compared to obsolete codecs. Still, the higher the complexity of the image, the greater the data rate must be to prevent noticeable loss in quality.
Youtube is a streaming service, so any video, HD or not, has a bandwidth cap on it. VBR is the ideal format for fractal vids, contributing more bits to finer details and less bits to sparse details. But the disparity of image complexity in fractal zoom videos compared to "normal" videos can range in the orders of magnitude beyond anything that one would normally encounter in traditional media like film and animation. As a result, sometimes it takes a gig or more for a 1280x720p video a couple minutes in length (sandstone), other times a sparser video tens of minutes in length only needs a fraction of that bandwidth. Ad to that the complexity increases exponentially as you approach the minibrot at the end of the video, and you've got a nice video file with decent file size for it's length, with the bulk of the file size located towards the end or in a few other exceptionally complex areas. In other words, bitrate can change by orders of magnitude. Still, it's a nicely playable local file assuming your CPU can keep up to play it at 100% speed. Not good for streaming services where bandwidth is limited and compression efficiency is sacrificed to ensure the video is watchable on less powerful devices such as mobile, etc...
As for the rediculously dense and complex sandstone zoom, the allocated bandwidth is nowhere near being good enough hence the best option is to link the original download file for local playback.
Not sure where I'm going with this wall of text, but I don't think H.264 or any other current video codec is really ideal, but H264 CRF by far produces the best results. Fractal data is so bizarre by nature and I noticed H264 has custom tunings for common content types. Maybe efficiency could be improved by hand tweaking a set of custom parameters for fractal zoom videos? I generally select "none" but maybe the gurus can come up with some hting better, especially if deep zoom rendering becomes more mainstreamed.
And quit harping on the AVI format. AVI sucks. The 2Gb limit pisses me off, especially when dealing with HD resolutions. But 2Gb was bigger than most desktop harddrives when the AVI standard was established. Yes, Mp4 or (insert other container format here) would be infinitely better, but I am at the mercy of the software developers to code something that outputs a better file format. Sure people will advise to render lossless or near lossless compression (Huffy YUV 4.2.0 or other wierd crap) in smaller segments, then splice the videos back together with a program like VirtualDub or AVI Demux and separately encode, but dat's a b!tch to do and I'm lazy. As long as I have prerendered frames, I can reencode the video as many times as I want until I get an acceptable file under 2Gb.
Sorry for the wall of text. I overstate myself sometimes. Derp.