PDA

View Full Version : H264 and Pixlet problems


osxrules
04-21-2007, 04:46 PM
I use these formats most of the time and I can't recall when it started but they are both showing problems now that I don't remember being there.

When I render out a Pixlet movie to a disk based flipbook, the preview comes out blue as though there are no red or green channels. If I save as a quicktime movie and open it in Quicktime, it plays fine. This only seems to happen with the Pixlet format.

When I use the H264 codec, it desaturates the output clip compared to uncompressed. I'm now using Sorenson 3 again because the color shift with H264 is really bad. I'd like to use H264 but given the encoding time, color shift and even quality per file size (which surprised me), Sorenson 3 is looking like the better option. I don't recall this color shift before so could this be a Quicktime issue?

beaker
04-25-2007, 03:38 PM
I would do your final compression in a separate app. Shake is built using a much older version of the quicktime libraries. So as more and more updates come out, more things with Shake and quicktime can break and become uncompatible.

osxrules
04-27-2007, 12:21 AM
I need Pixlet though because it is uncompressed and makes files 10 times smaller than animation. H264 desaturates if I use Quicktime standalone too.

I'm now getting an even worse problem with Pixlet. I have rendered out a Pixlet file and it shows as blue in the viewer. I play it in Quicktime and it's fine. But I then bring it back into Shake for use in another node and when I render out to Pixlet, it produces noise over the whole image like a TV screen but colored pixels. Now, if I render to some other formats it's fine but even ones like Uncompressed 8-bit, it's just noise so it's obviously not reading Pixlet files correctly either.

I love Pixlet but I've had so many compatibility problems with it, I don't think I can use it reliably any more. It won't even play back 1024x576 files in real-time on 2GHz+ Core 2 Duo machines whereas other formats do at those resolutions and bitrates. It's odd because Pixlet seemed to play better on G4s/G5s. I'm guessing it has some Altivec stuff in there.

Is there another uncompressed format that gives file sizes as low as Pixlet? Photo-JPEG wasn't bad but still around double the size.

luckbat
04-27-2007, 12:44 AM
I'm not sure I'm understanding you correctly. Pixlet is nowhere near lossless. Neither is Photo-JPEG, for that matter. Perhaps you mean "lossless-looking?" That's a whole other ball game.

I suspect the bottleneck is your HD speed, not your processor, so I'd recommend using uncompressed video and working off a fast external drive or something similar.

osxrules
04-27-2007, 01:12 PM
I'm not sure I'm understanding you correctly. Pixlet is nowhere near lossless. Neither is Photo-JPEG, for that matter. Perhaps you mean "lossless-looking?" That's a whole other ball game.

Yeah, I guess 'lossless-looking' is what I'm after. I know animation is lossless and I have never been able to distinguish 100% Pixlet and 100% animation. A lot of articles suggest that at 100% quality, the codecs are lossless including the Photo-JPEG and Motion-JPEG codecs but they can't be at the file sizes they get. I remember why I stopped using the JPEG ones before and it was because of banding artifacts and lack of alpha channel support but the banding seems to just affect playback - if I export to tiff, the image looks the same as the lossless codecs. They are good codecs for file size and playback speed. MJPEG with alpha channel support would probably do.

The option to encode PNG images into a Quicktime .mov looks quite good. That supports alpha and should be lossless. File sizes seem ok in some cases, coming close to Pixlet and MJPEG but in others not so much. Sometimes it's just as bad as animation. It also takes a while to encode.

The playback is also a little choppy but I can always export to MJPEG for a playback test.

I suspect the bottleneck is your HD speed, not your processor, so I'd recommend using uncompressed video and working off a fast external drive or something similar.

Yes, I think it is the HD speed. An external drive with uncompressed video may be the best solution. They are cheap enough and it would be easier for transferring stuff between computers.

beaker
04-27-2007, 03:40 PM
Are you dealing with RGB or YUV data? For YUV I would just use the Apple Uncompressed 8 or 10 bit. For RGB, PNG works but is slow as piss to compress and playback. My favorite codec is BitJazz, but it does cost money. The file sizes and playback ability make it so worth it though.
www.bitjazz.com

osxrules
04-27-2007, 08:32 PM
Are you dealing with RGB or YUV data? For YUV I would just use the Apple Uncompressed 8 or 10 bit. For RGB, PNG works but is slow as piss to compress and playback. My favorite codec is BitJazz, but it does cost money. The file sizes and playback ability make it so worth it though.
www.bitjazz.com

I'm just using RGB data. I came across the BitJazz Sheervideo codec quite a lot in my search for the best codec to use and it gets pretty good reviews. The price isn't all that bad but I just don't want to rely on a 3rd party codec when I'm sharing between a lot of machines and software packages.

I had a look at JPEG2000. I didn't think any JPEG codecs were lossless but on highest quality it seems to be and the file sizes kind of reflect that. It also supports an alpha channel. Again though, the playback performance isn't good enough like the other image sequence formats.

After trying out a few, MJPEG seems closest to what I need. Pixlet's advantage is the alpha channel support but I like the performance of MJPEG and the file sizes are ok. What I could do is render the alpha channel out to a separate file if I need it for further editing but usually I just output once for use in Final Cut. Final Cut doesn't always like Pixlet's alpha channels either so hopefully this will give me one less problem.

beaker
04-28-2007, 01:21 AM
Mjpeg files are universal on most machines, but they are just so huge. Also it degrades a lot on multiple compressions. Which is why I like Bitjazz because there isn't any loss when it is recompressed and if you do jump from yuv to rgb and back there isn't any gamma shifts from app to app (and it doesn't clip superwhites in yuv).

osxrules
04-28-2007, 01:38 AM
Ok, guess not. It seems that MJPEG output is broken too. I get a noticable color shift when I export direct to MJPEG from Shake. Pixlet and Animation render out exactly the image that I see in the viewer. MJPEG oversaturates everything (the opposite of H264). Now what's really annoying is that if I render to Pixlet, open in Quicktime and export to MJPEG, I don't get a color shift. I guess I'll just have to suffer with Pixlet for the time being and then just convert to MJPEG after I render in quicktime, for viewing. I'm not using animation because the file sizes are way too big.

Why is it that codecs create a color shift at all? Surely there is no way that you can allow for such a thing in your pipeline. You can't change the entire clip to suit each codec.

I don't suppose there's any chance these bugs will get fixed now that Shake development has stopped. It looks to me like Apple is breaking Shake down piece by piece and incorporating it into the Final Cut suite to make an AE rival.

beaker
04-28-2007, 04:12 PM
As I suggested earlier, just render to a file sequence and compile a quicktime movie with another application. You could do this with automator, sequence publisher, motion, etc...

As for it being fixed, nope, will never happen. They have made statements about this many times on the shake listserve. They wrote it based on very old quicktime libraries. They would have to rewrite the entire quicktme interface which would take too much time.

CGTalk Moderation
04-28-2007, 04:12 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.