this discussion recommends H.264, but without much reasoning or discussion. Also, it does not address the issue of MOV vs. MP4 container.
My old Final Cut Express still renders a much cleaner MOV/h.264 with the same data rate as Premiere's MOV/h.264. In fact, Premiere's MOV output is horribly pixelated. What's up with THAT?
I'm using Premiere CC on a 64bit iMac quad core...
Please check the export settings as this issue may arise if there is a setting mismatch. Means the source settings and export settings.
If you're planning to embed that video in an HTML5 video tag, export as MP4. Some browsers (Firefox, IE) won't play it if it's in a QuickTime wrapper.
the "MOV vs MP4" quandry was for an intermediate stage of file delivery, as I mentioned in my 1st post. I'm mastering in ProRes 4:2:2, (6 gig), compressing to "intermediate" (MP4 vs MOV), then sending this "intermediate" by file transfer to an associate who compresses via Sorenson Squeeze to a 150 Meg Flash FLV file.
He uses this "intermediate" file I send as his source material for Sorenson Squeeze.
In the past, I used Final Cut Express' MOV output to a 350 Meg file with good resolution. Premiere CC's "good" resolution for this intermediate file weighs in at 700 Meg; it's 350 Meg output is badly pixelated.
I'm switching to MP4 as "container-type" for the intermediate file, which produces a nice output around the 350 Meg mark. Either "container" (MOV or MP4) holds the H.264 codec, so it's odd that MOV output is so distorted.
Anyway, we'll stick with MP4 for now. My "Squeeze" guy was kind of stuck on Quicktime for some reason ...
I'd recommend skipping the intermediate and just making the web version directly from the original ProRes.
yes. best and easiest. most logical. we have some beaurocratic baggage in the way that dictates otherwise. "evolution" takes time for this crippled species called "humans"....
While I appreciate that transferring multi-GB files across prosumer network connections isn't the simplest option, H.264 was designed as an output codec, not a DI. This is a classic case where either the machine doing the transcode needs to be local to the machine doing the NLE work (i.e buy your own copy of Squeeze, it's not expensive), or you should look at physical media exchange. Even in these days of fibre to the premises, many small production houses still find it simpler to courier a bunch of flash drives overnight than risk a massive upload failing on the hash check.
Is there a specific reason why you cannot use the FLV export function in Adobe Media Encoder? I know Squeeze has much more functionality in areas like WEBM or multi-stream work, but if the end result is just an FLV file for delivery over HTTP, the fine details aren't as important as they once were. Users don't care about a couple of percent extra on the file size.