The Salvation of H.264

Posted on May 6, 2010 by proctor

h264

Some time ago, I wrote a post called “Which Format Is Best?”, which walked you through my process of converting video files for more “VJ-friendly” playback. I should say right off the bat that this conversation only applies for Mac users. The short version is, when you download content (mini-movies, motions, etc), you are receiving a QuickTime movie that has been encoded with the H.264 codec (the industry’s standard right now). However, when pulling more advanced playback stunts like on-the-fly speed control & quick sporatic dissolves, this codec seems to struggle, resulting in choppy playback at the time of adjustment. And since I like my playback to be as smooth & seamless as possible, I’ll do whatever it takes to make that happen. So in that post, I highlight another codec that I’ve been using called “PhotoJPEG”; when exported at 50-75% quality (don’t ask), it results in a balanced combination of smooth playback, file size, & quality. #VICTORY

Last week, all of that changed.

When we were in the final stages of producing the Playback Drive, I asked the team the question, “Are we going to give people H.264 like everybody else, or are we going to go the extra mile and convert them all to PhotoJPEG?” The beauty of working together on a team is that there are other people more knowledgeable than you could ever imagine being yourself. Some liked the idea, and some didn’t. Why? Because they were never satisfied with PhotoJPEG to begin with. You see, PhotoJPEG compromises a fraction of quality when compared to H.264. The difference is marginal (even I cannot tell sometimes.) But to the professionally trained eye, you can tell.

So which is more important when VJ-ing? Pristine quality? Or seamless playback?

We thought about offering both codecs with a “read me” file explaining which format was for which situation. We didn’t want to compromise the quality of our loops, not even a fraction. But one of the guys on the team (Jason Norris, who’s been working w/ Nick Rivero on all sorts of crazy cool ideas) did a little research and experimentation.

What he discovered is this: if you export a video to QuickTime using H.264 but choose the option to KEY ALL FRAMES, it will result in seamless playback, just like PhotoJPEG…except that you’ve not compromised any quality! Here’s a snapshot of the advanced settings when exporting via QuickTime 7 (this should apply to other programs as well):

h264 high

So…I have officially abandoned PhotoJPEG as my VJ codec of choice. From now on, it’s H.264 all the way (keying every frame along the way, of course.)

So what? What does this mean for you?

- if you’ve gone through all the work of converting all your loops to PhotoJPEG, then welcome to my camp. But I’m not that worried or frustrated honestly, b/c remember, the difference in marginal. Just select this compression type & setting for new loops that you’ve created or downloaded. Don’t re-export your PhotoJPEG videos back to H.264…it won’t help you regain that little bit quality. If it bugs you that you have lost that extra margin of quality…sorry…again, welcome to my camp. If you downloaded content from WorshipHouse Media, you can always re-download it in it’s original format via their new “My Media” feature.

- if you are new to all this, just know that this is for more advanced VJ playback & getting rid of the little things that most people won’t really notice. But if you still want to follow my lead, then whenever you download a loop/motion from a website, simply convert it to H.264 with the settings I described above.  (FYI: it’s already in H.264, but not with the “key all frames” option.) Also, this practice does not apply to “mini-movies” or any kind of video that you aren’t scratching/jogging/speeding up/slowing down/etc. To learn more about batch conversion, read my previous post and watch the video. Compressor works great, but for those without Final Cut Studio, I recommend Stomp.

A note of warning: when keying all frames using “Best” on compression quality, it will result in a much larger file size, about 4-5 times the size of a file using the default settings of H.264. For example, a 90MB video will now be around 400MB. The day after I posted this, Joel Smith of Thr_ve tested this compression method himself and found that if you use “High” instead of “Best”, you will find a much more conservative file size without compromising the quality. But in any case, you are going to be dealing with a larger file size, which is totally worth it to me. So if you’re thinking of getting a Playback Drive, you might want to consider the 2TB model! ;)   — And yes, the Playback Drive already has everything converted with these new settings. (the amount of content equals 33GB.)

It’s all about excellence. Even in the details. Thanks, Jason, Nick & Joel for working hard to find a better way for all of us!

15 people have shared their voice

  1. confirmed, my friend. After our convo's about this yesterday, earlier this afternoon I played around with a couple of motion backs and the results were BEAutiful.

    I've started the process of reformatting my main vids.

    kudos Jason & Nick, kudos.

    p|b on May 6, 2010

  2. Interesting.
    Up front, “This applies only to VJ, not playing loops fwd only, speed=1x, no fades, etc as may be done on Sunday mornings across the world.”

    Intro:
    The concept of using just the base keyframe compression of H264 and applying it to each frame independently (as if it was a photo) is interesting. This leaves out all of the motion based encoding (interframe compression) that H264 is designed for.

    H264 Single Frame:
    Although I have yet to track down the encoding used on the key frames (what your video will be comprised of), I can only imagine it is either not quite up to par with a single frame/photo style image compression like JPEG (PhotoJPEG or jp2000) OR it is something like very much like JPEG (which is possible) and you’re taking about the same compression in reality..
    Is it like DNG (Adobe’s Raw), JPEG 2000, PhotoHD (Microsoft’s cross between DNG & JPEG), or some other wavelet based compression? If H264 was good for a still image (a frame), wouldn’t someone take that piece and make it a photograph compression format?

    Are you giving PhotoJpeg a fair shake? You only use 50-75% quality. Would an extra 20% (to 90-95%) serve the same purpose?

    In essence, you’re after a format that maintains the source quality as much as possible, while still being playable. Certainly, the raw HDMI output from the camera or Pro Res would maintain the quality, but wouldn’t be as moldable in your hands.

    Considerations:
    There are a couple things to keep in mind.
    1. Larger files take more space on disk; not really a problem for most people.
    2. Larger files take longer to pull from the HD. Maybe that is more of problem if you use a 5400rpm laptop hard drive.
    3. Larger files may take more memory. I don’t know if theory matches reality on this one.
    4. H264 usually takes 2x as much processing power to decode. This statement may not hold if all you’re doing is key frames.

    To be clear, I don’t do any live work, let alone leave the state/continent to do so; just start-to-stop countdowns and videos. Therefore, I’m more interested in having a good storage format that doesn’t overtake my hard drive space.

    On your playback drive. I wonder how many people will use it for VJing (scrubbing, mixing, & palindrome) vs. the number that use the clips alone on the screen, 1x forward. Or with hardware overlay or with just words. I guess depends on the target audience.

    I guess, bottom line, I’m not 100% convinced yet. But, I like some of the concepts.
    (I was going to respond to the previous post too, but like Allan, I got zapped by the javascript)

    David Johnson on May 7, 2010

  3. Besides the formatting being so ugly, I was going to add some links that talk about processing requirements, etc.

    http://www.discoverdvc.org/publications/EPFL/A%20comparative%20study%20of%20JPEG%202000,%20AVCH.264,%20and%20HD%20Photo.pdf
    http://www.larryjordan.biz/articles/lj_video_codec.html

    ["Photojpeg"s] are easy to uncompress without taxing the playback system. This is critical because you want your computer to spend its time running ProTools [& vjing], not in decoding compressed video.

    H.264 uses GOP compression and requires serious computer horse-power to decode.

    http://mulder.dummwiedeutsch.de/pub/x264/

    vj
    http://www.fraktus.com/VJ/VJCodecs.php

    http://createdigitalmotion.com/2010/04/updated-mpeg-la-pool-planning-to-torpedo-ogg-theora/
    http://www.readwriteweb.com/archives/will_idealism_be_firefoxs_downfall.php

    David Johnson on May 7, 2010

  4. I'm with David right now, Not totally convinced. The beauty of h264, and what has made it SO popular, is it's ability to interpret between keyframes and generate a great reproduction at a fraction of the file size. By keying all frames, it has become a processor intensive and massive file that no longer serves it's beneficial purpose. I'm not all for jumping on a media codec JUST because it is the big name right now. I may have missed something in the article but it seems you are saying that with 3X the file size and higher CPU demand we get virtually the same look as we do with PhotoJPEG compression and all we gain is that we are using h264.

    Also, it might be worth doing a little educating on converting things to h264. If someone moves a video on a Mac into h264 and doesn't make some gamma adjustments they MAY quickly ruin their blacks and some transparencies against blacks. I started using x264 instead of h264 to get around the gamma issue, x264 strips gamma info and leaves it native. Before that I had to use the gamma adjustment in Compressor to take videos from FCP and AE onto my Pro & PVP machines.

    What are the other benefits of h264 that I might be missing? What did I overlook in your explanation that makes this comment look stupid and uninformed?

    Travis Paulding on May 8, 2010

  5. David –

    Glad to hear some challenging thoughts about compression!

    I'd like to try and respond to some of your thoughts and concerns.

    I would have to agree with you in saying that most people will probably just play their clips at 1x speed-straight. That being said, we want to make sure that we cover as many people out there as possible and if we were to use an inter frame compression, then we'd be leaving a group of people out. By encoding it the way we do, we are allowing those on both sides of the argument a way to use their content.

    As for H.264 vs P-JPEG, we looked and chatted hard about which way to go. My good friend, Jason, spent a good bit of time setting up varying types of compressions in an effort to squash out some of these concerns. He compressed clips in both PJPEG as well as 264. The compression settings varied across all ends of the spectrum, as to make sure to cover all bases. A couple of variables that we considered in our tests were: file size, overall look of the processed file, machine processing power to playback the file, platforms/software in which these files played back from, and user hardware.

    One of the biggest concerns for us with PJPEG was the shear file size. Everything from 25% up to 100% was tested. 100 provided us with files that were in the GBs and anything around 75 provided not-so-useable quality. It made it pretty obvious to us that to maintain a desirable quality, our files would be considered unmanagable by most people, especially laptop toting users, whose drive space is a precious commodity. So While 264 does use more processing power for playback, it gave us far better image integrity for the same file size.

    While our compression might not be "up to photo quality", you have to consider that the vast majority of users will be playing back their content on projection surfaces. Projection factors in the variables of distance and diffusion, which in summary, will make the differences negligible from the audiences standpoint; this is something that I have personally studied over the past few years. If we attempted to use uncompressed or even ProRes (in any variant), no user out there would be capable of such need bandwidth to playback our files (prores proxy or lt, possibly).

    Shear machine power is definitely a large concern for us. All of us who created the PBHD are all laptop toting users (yes, both Mac and Windows) who do not have the luxury of toting high-end boxes to our shows, we definitely agree that power is a concern. As I write this though, I remember back just less than a decade to when DV and HDV were serious concerns to end users, leaving many to believe that they were un-editable.

    I am not here to argue you, nor am I looking to "win" this debate. I much appreciate your thoughts and concerns, as this is a topic of great concern to us. Do know that we all have discussed, argued, deliberated, and questioned our choices with the PBHD.

    I would love to chat more in depth. Feel more than free to contact me personally via email at nicholasrivero at gmail dot com, where I'd love to chat more in depth about your thoughts and concerns.

    Thanks for your feedback.
    //nick

    Nick R on May 8, 2010

  6. Joel! Joel Joel Joel! thanks so much for that. That sold me.

    Nathaniel on May 8, 2010

  7. Joel, good info there. I guess its sad that I didn't get bored and drool. What you are saying makes sense. And the one thing I was curious about was if the, in essence, keyframeless h264 footage did reduce CPU strain. Sounds like it does. I don't really care about CPU strain, the presentation computers we use for loops normally can handle it fine. I was concerned indirectly with it because CPU load = choppy transitions for me. We rarely change speed of clips but transitions can range from .5 to 5 seconds for us and that is where h264 historically stunk it up in my experience.

    Joel I do have one question, were you converting your files from originals or were you converting your existing P-JPEG videos into h264? Currently our library of a few hundred loops is almost exclusively Sorenson 3, based on recommendation by Brad Weston a few years ago, and I am wondering if I should look at moving them to something else, be it P-JPEG or x264. I still have originals for most of them but not all.

    I think you guys are on the right track here and maybe some more settings tweaks in Compressor might even yield better overall results. Has anyone tried keyframing every other in 264? That may really reduce file size and still not really strain playback. I will give some of my own content a try in x264 with no keys and every other and see what happens. I have not noticed any negatives to using x264 over h264 though. Proctor, you asked for a link to x264, here is one: http://www.videolan.org/developers/x264.html

    Thanks for the effort you guys put into this.

    Nick, your post answered a lot of my thoughts as well, I think we were typing at the same time.

    Travis Paulding on May 8, 2010

  8. Let me start by saying that my background is primarily in live production where media servers and projectors are the norm. Most high end media servers suggest that content be encoded with every keyframe every frame to allow for smoother time remapping and such to be done.  That is where the idea for tweeking the H.264 setting to conform to that sort of standard came from.  The P-JPEG files by default have this sort of file structure.  I just have never been satisfied with the visual compression/ artifacting that takes place when using the codec.  Several of us have been using H.264 for years now because of that.  The color space and quality retention is quite good.  That being said, I would agree with Travis that the X.264 codec offers some great improvements.  But when we decided to encode our content for a mass audience, we decided to use a codec that we knew would be playable on as many machines as possible.  No, we do not have the resources that Apple, Google/ Youtube, Vimeo, etc. have, but we did do some testing.  Multiple tests/ trials were done on 8Core MacPros, on Dual/ Single Core Mac Minis, on several different config MacBookPros and also on an old 1.5ghz G4 Powerbook to find a codec that could be handled by all of them.

    I strongly agree that the beauty of the H.264 codec is that it is a temporal compression codec.  Meaning it saves disk space in the file by only retaining info about the pixels that change from frame to frame until a full keyframe is reached.  Because of this temporal compression, the computer has to recalculate the "in between" data more aggressively when the file is "speed adjusted" or slowed down.  The codec is designed to play the file at real speed, and by default the keyframe spacing around every 60 frames (AKA approx. 2 sec.).  Which if all is going well, shouldn't skip at all.  But as the file is slowed down, the file is missing too much info between key frames, thus causing skipping.  The solution… add more keyframes.  This could seem like we are totally defeating the purpose and efficiency of the H.264 codec.  And you might be correct, but the tests that we ran concluded that the trade off of what David seems to suggest as a less processor intensive codec (P-JPEG) had to be balanced against the need for more RAM to buffer the larger file sizes.  There is always compromise, like Joel pointed out.  I will make a nice blanket statement that most presentation/ vj software use RAM buffering to increase performance playback.  So the trade off of how much RAM your machine has verses the speed of your processor is always at the forefront of most live visualists' choice of playback machine.  We tried to take those restrictions into account when deciding how to encode our content for a wide audience.

    To comment on Travis' dislike of gamma restrictions in the H.264 codec… The content on the PBHD was created by people who use video projectors almost exclusively.  The contrast ratio and gamma curves of most projectors in the sub $75,000 range can't even come close to that of even the cheapest consumer grade LCD or plasma screen monitors.  With televisions pushing contrast to over 100,000:1 the average projector is lucky to get 6000:1 (most lower end models only have a 2000:1), there is no way to realistically compare the two different mediums.  The lose of blacks that you notice when watching a movie on your computer is only a fraction of what you are losing after the image is sent to a projector.  The guys at Barco/ High End Systems have posted a great tutorial on how to optimize content for projection. http://bit.ly/9KA7s3
    With some of their suggestions, the content (videos and stills) on the PBHD have been optimized for projection and not necessarily for television broadcast.

    I hope these comments help to explain where our choices for content encoding come from.  For now H.264 is where we find the most acceptable level of compromise between file size, quality, and performance.

    Jason N on May 8, 2010

  9. Travis,

    I have seen a vast improvement during long transitions with the keyframe every frame variant of H.264. I haven't really tried the every other frame approach, but would be interested in your results.

    A far as trans-coding from one compression type to another… I'd say start with the original source files if possible. The recompression of data will only make the file look worse. That being said, we did play around with recompressing a standard H.264 with a 60 frame spacing of keyframes to the all keyframe variant, with acceptable lose of quality. It is not a lossless workflow, but it seems to work.

    -Jason

    Jason N on May 8, 2010

  10. Jason, I'll let you know when I figure something out on the keyframes. I am aware of the quality loss when moving from P-JPEG to 264 but was just curious if that was what you had done in your tests or if you used original source files.

    Travis Paulding on May 8, 2010

  11. I’m about to put you to sleep with my nerd-talk, so be warned.

    I have been doing some tests since Proctor wrote this blog. I thought it was too good to be true. To be honest, I’ve never been a fan of H.264, and I’m barely a fan of Photo JPEG, only when it’s quality is over 80%. As a producer I want to offer the best quality content both in creativity and technical quality. I’m a perfectionist, and the H.264 codec causes me to lose sleep.

    I’ve tried many different codecs. I even tried the x264 route, but found that the x264 encoded files actually took more processor resources than the regular H.264. It might have been just my setup, but I was looking for something that caused less CPU strain with equal or better quality. x264 didn’t last long. Plus, it’s not recommended by the Renewed Vision folks anyway. While individuals might have great success with x264, as a provider I can’t justify using it. The pictures from x264 were very good, though.

    I am constantly looking for the perfect balance between visual and technical quality with minimal file sizes and maximum compatibility. Obviously, the perfect codec is not out there yet. So, I’ve had to compromise in at least one area for now. Which is okay, because every other content provider is doing the same, including iTunes. Just watch an episode of Mad Men from the iTunes store and pay attention to how bad the dark shots look. I mention Mad Men because it’s where I really notice it. Don’t hate.

    Now, with that said, I’m back on the H.264 wagon. Yes, the gamma issue is ridiculous and Apple should have fixed it 3 years ago. It’s just an issue I’ve learned to live with or find a workaround.

    As far as the tests, here’s what I’ve discovered:

    The files currently offered on the thr-ve site are in the Photo JPEG codec at 50% quality. I chose that codec because it offered somewhat equal quality as H.264 with less CPU strain, better dissolves and transitions, etc. I’ve learned that a lot of people convert their H.264 files to Photo JPEG at 50% anyways, thanks to Proctor’s earlier blog post about it. So, I figured, why not just give them what they’re going to use. The files ended up being about 2-4 times larger than the H.264 files, but still an okay size to download. If you look at stock sites like iStockPhoto (the video side) and RevoStock, they offer 95% quality and 75% quality (respectively) Photo JPEG Quicktimes. So, the practice is very common, tried and true.

    Then came the new H.264 compression with ALL frames keyed. It has never occurred to me to even try that little checkbox in the export settings. Kudos to Jason Norris and Stephen Proctor for bringing this to light. So, I tried it, skeptically.

    Note: I’m using Apple Compressor for all encodes. It’s finnicky and has tantrums frequently, but it’s actually the best and fastest for what we offer. The “Which Encoder is the Best” discussion is for another day. You learn to work with what you have.

    I found that setting the quality slider to BEST or 100% made H.264 files 3x larger than my current Photo JPEG files. No bueno. It would take most people days to download a 6 motion volume. So, I tried setting the slider to HIGH or 75% with all frames keyed. The results were interesting. Most (about 85%) of the files were significantly smaller than the Photo JPEG files, often less than 40% the Photo JPEG file size. Some (about 5%) stay the same size. Then, the other 10% of the files were actually larger than the Photo JPEG files, significantly. The average bitrate for the H.264 files was 20 megabits per second. In the high-detail or high-textured files the bitrate sometimes shot up to 40-45 megabits per second. That’s kilobits times 1024! As Keanu Reeves would say, “Whoa.”

    Here’s an example of 6 files (Photo JPEG at 50% quality, H.264 at 75% quality with all frames keyed):

    1 – Photo JPEG was 92.4 MB, H.264 was 92.4 MB
    2 – Photo JPEG was 153.6 MB, H.264 is 90.6 MB
    3 – Photo JPEG was 213.6 MB, H.264 is 90.1 MB
    4 – Photo JPEG was 47.8 MB, H.264 is 36.2 MB
    5 – Photo JPEG was 56.2 MB, H.264 is 39.2 MB
    6 – Photo JPEG was 119.6 MB, H.264 153.4 MB (Lots of texture and detail)

    Overall, the quality is WAY better than the Photo JPEG files we currently offer. The macro blocking in the H.264 files is nearly non-existent. It’s only noticeable in the drastic gradients and black/gray areas. With the Photo JPEG files, the macro blocking was very noticeable in nearly all files, but not annoying.

    Here’s the kicker to it all:

    When playing back a higher bitrate movie, one with a lot of texture and color, I found that the Photo JPEG file took about 35% MORE CPU processing to playback than the newly compressed H.264 file. My guess is that the strain is lifted from the processors because it’s not having to take multiple frames of the H.264 to keyframe. It’s basically taking higher, yet better, compressed images like the Photo JPEG codec and playing them in the set framerate. That’s the part that sold me. It’s what I call a WIN/TIE/WIN situation. :-)

    So, I’ll stop now since you have probably started drooling on your keyboard from boredom. I will be doing a blog post this next week about this, but I thought I would join the conversation on here to let you know my findings.

    Thanks to James Norris and Stephen Proctor for sharing this info, this is greatness!

    Joel Smith on May 8, 2010

  12. Travis,

    To answer your question about originals. Yes, we converted everything from the original Lossless Animation Quicktime Movies. We export all content to the Animation codec and keep those files archived so we can always go back (like we are now) and re-encode to a better codec.

    As far as my tests went, I did not test the files in ProPresenter or any presentation software. I simply ran the videos in Quicktime Player and watched the Activity Monitor for stats. Someone else might be able to give us a real-world test to find out the true stats.

    Joel Smith on May 8, 2010

  13. At the risk of repeating stuff you guys have already pointed out….

    Joel's test that show a softer impact on the CPU tells me that the CPU impact that is mentioned around the web may have to do with the temporal workload. So. That is definitely a plus in the H264/All column.

    Also. Since h264 has been around for a couple years, the CPUs have caught up and may be less of an issue. Like most software, we write for the future – not for the current hardware.

     

    The fact that they seem to be smaller and the decrease in blockiness implies a wavelet style of photo compression that seems to be the future (like Redcode, JPEG 2000, & JPEG XR). JPEG is a DCT (1992 technology). I'm not suggesting JPEG2k for general consumption – it doesn't have the traction; much like AAC still plays second fiddle to MP3.

     

    The fact that there is an upfront option to encode the whole thing as key frames is also an indication that someone thinks it is a viable workflow. It is pretty hard to get something into an Apple product without good justification. I'm searching the net to see if I can find out why it is there.

     

    Jason: that link to the optimized projection settings is pretty radical too. I always assumed any dullness during projection were a fact of life or bad projector calibration.

    David Johnson on May 10, 2010

  14. Short version: Sounding pretty good for "H264 I-Frame only"

    (just watch which tool does the conversion)

    .

    I asked around an finally was given a tidbit of information.

    What we're describing here is a I-Frame-only (IDR-Frame to be exact) video format.

    That gave me an ah-ha moment.

    This isn't entirely new; late last year Apple released the "iFrame" format for use with video editing.

    This is similar to a Panasonic format "AVC-Intra" by Panasonic.

    Both are basically the same thing. Apple's is limited to the low end (max 960×540), while Panasonic wants it as a high-end replacement of some broadcast formats.

    On paper, it sounded good for "H264 I-Frame only"

    Testing CPU'ness:

    Test 1: start video & scrub around; look at CPU. If the CPU can keep up, great.

    Test 2: Play in QT Player ping-pong loop. Look at FPS.

    However, now that I'm home running test:

    Took a HV20 video clip. 1920 x 1080 to MPEG Streamclip (to qt) then to JPEG-Deinterlace (to get 24fps), then export using QT or Premier.

    1. JPG 2000 100% was way to slow: 2fps instead of 24. Size is also out of bounds. 50% still too big too.

    2. MPEG4 = 24fps.

    3. H264 export from QT Pro couldn't keep the 24 fps (jumps between 18 & 24).

    4. H264 as .MP4 it plays right.

    5. H264 from Premiere seems okay though.

    6. But MOV from Premiere again is a bit behind on the FPS.

    7. The original format (Apple Intermediate) seems to run okay (24fps) size is same as h264. A bit surprising.

    8. I think DV Kitchen worked. As did the X264 version of DV Kitchen.

    Footnotes:

    iMovie 09 – iFrame video format

    . http://support.apple.com/kb/HT3905
    . http://en.wikipedia.org/wiki/IFrame_%28video_form...
    . http://blog.lib.umn.edu/mcfa0086/discretecosine/1...

    ** AVC-Intra
    http://en.wikipedia.org/wiki/AVC-Intra

    ** mJPEG vs. 264 comparison

    . http://forum.doom9.org/showthread.php?t=146979
    - confirms (in my mind) that h264 has been able to jump ahead because jpeg has to remain compatible with base jpeg standards.

    ** Adobe's perspective on 264

    . http://www.adobe.com/devnet/flashmediaserver/arti...

    David Johnson on May 10, 2010

  15. Great post, better feedback. My take running Resolume is that all keyframes are mandatory if you’re scratching, slowing down, piling up filters, multiple clips. CPU load is a significant issue, even though GPU renders it out. ArtBeats online distribution is Pjpeg for the big $$. Can’t see H264 under duress? Resolume has there own codec which is fat but solid. A pain to transcode everything, but you lose less fps… file size is big, slightly compressed, but playback flies; like (3) 1080 clips simultaneous no drop fps + some filters. I know that most churches don’t mix VJ apps, but that where the vj world is at. I believe PJeg is still standard. My church uses H264 in PresenterPro but looks soft and artifacts too, on a fast Mac tower… My vids look markedly worse, but they don’t want to deal with big file size. my $.02
    Possibly dated: http://www.fraktus.com/VJ/VJCodecs.php

    Dan on May 27, 2010