[Andrew Stuckey]

Hi Seth.

Presume you’ve seen these pages, but if not they’ll get you 90% of the way there.

https://support.google.com/youtube/bin/static.py?hl=en&guide=1728585&page=guide.cs
https://support.google.com/youtube/bin/static.py?hl=en&topic=1728573&guide=1728585&page=guide.cs

https://vimeo.com/help/compression

[Andrew Stuckey]

Bit late to the party Michael…

I am in the same boat with the same model iMac. Ahh, the joys of expandability on an imac with no Thunderbolt 😉

You’ve no doubt solved your storage issue by now. What did you end up going with?

For first time readers to this thread, I thought it was worth mentioning that it is possible to add an eSATA port to the 2010 iMac giving you potential speeds up to 3Gbps.

OWC offers eSATA Upgrade service which could be very useful. Probably only practical if you’re in the US.

[Andrew Stuckey]

Hey Scott,

What is the intended use for the output?
Intrigued to know what your Streamclip settings were. Assume you used H264 codec or a variant. What other settings are you using?

Some programs (like older versions of Handbrake, unsure about Streamclip) have a “target size” feature you could try. But like Jeff said, good to use the calculator to get an idea of the ballpark bit rate you’ll need to aim for then do some test conversions.

Depending on your source footage, eg: if you have lots of talking head or static footage, variable bit rate may help reduce size. If it’s mainly fast motion though, constant bitrate will be a safer bet to achieve the desired file size.

[Andrew Stuckey]

[Yiannis Valkan] “Any known issues?”
If you’re thinking of getting a second hand or refurb 2010 model, you should realise that the i5 and i7 models lack jumbo frame ethernet support and no Thunderbolt.

But if you’re not going to be using a NAS or gigabit ethernet then the 2010 models are still fine. Note also that Firewire 800 is the fastest i/o port which might struggle with multiple streams of uncompressed HD video. I would highly recommend getting one with the optional internal SSD so you can use this as your media drive for good throughput rates.

Otherwise just spend a little more and get the 2011 i7 with jumbo frame support and Thunderbolt! 🙂

[Andrew Stuckey]

Thanks for your thoughts Brett.

So you’re saying that most 7200rpm drives (and certainly a RAID) are already faster than FW800 at 70-80Mbps? It would be great to know how much faster.

eSATA is not easy to install on the 2010 iMac. OWC offers an installation service but living in Australia kind of kills that idea. I’m trying to hold off on the whole eSATA route and upgrade to Thunderbolt sometime in the next 6 months.

But again… what’s the point of having all of TB’s delicious through put if you’re restricted by the physical output of HDD or RAID (which may not even be 500Mbps let alone anywhere near 10GBs!)

Am I missing something here?

One obvious solution is to go SSD, but I can’t justify the current SSD prices on 250, 500 and 1TB units, let alone 8TB of solid state RAID?? (Don’t think they even make em yet.)

So it seems that the choke point on almost all workflows (using >FW800) will be the sustained data output of the drive or RAID array. Right? Which makes the choice between eSata, USB 3.0, GB Ethernet or TB quite arbitrary as all should be much faster than what HDD’s can currently push out.

[Andrew Stuckey]

Hi Paul,

I’m not entirely sure my advice will prepare video for both RTMP and HTML5, but at least test it out. At the very least you will no doubt get some improvements in picture quality.

I can highly recommend using the x264 codec for H264/mp4 format video rather than Apple’s default H264 codec found in QT and Compressor. I’ve recently switched and seen far superior results.

https://www003.upp.so-net.ne.jp/mycometg3/

While it can be plugged into QT and Compressor, I’ve seen much better results when using x264 in third part software such as Handbrake and MPEG Streamclip. Mind you they seem to be a heck of a lot faster than Compressor too. So faster and better = good. 😀

Handbrake (which uses x264 by default) has the option “Web Optimized”. When this is ticked
the header of the MP4 file is rearranged to optimize it for streaming across the web.

I’m not sure of the same option in MPEG Streamclip, but I’m sure it would have one.

I’d suggest running a small test file through handbrake and see how it goes.

[Andrew Stuckey]

From Craig’s experience it sounds like MPEG Streamclip won’t give you the absolute best quality encodes on the market but considering it’s FREE it pushes out very decent results.

I guess it depends on your needs/budget.

Telestream Episode will set you back $500 and Sorenson Squeeze, $800.

[Andrew Stuckey]

Good experiences with MPEG Streamclip.

Biggest strengths I’ve seen…
– Quick (so much faster than Compressor even when run through several virtual clusters)
– Great quality (depending on the codec and format used)
– Accepts many input formats
– Supports many output formats
– Can install additional codecs such as x264 (highly recommended for great quality H264/mp4 encoding).

The only caution I would note is that development can be slow. So it might lag behind more progressive programs. (Although they did release a new beta version in August 2011.)

I haven’t tried everything with it by all means. I’m sure there’s plenty it can’t do, but a big thumbs up from me so far. 😀

[Andrew Stuckey]

Some good info here on mobile/ browser compatibility. Thanks.

My number one piece of advice for achieving best quality H264 format videos would be to use the x264 codec (https://www.videolan.org/developers/x264.html) and NOT Apple’s H264 codec found in Quicktime and Compressor.

The x264 codec can be installed in QT and Compressor, but I have found much better results using popular compression programs such as Handbrake and MPEG Streamclip. Handbrake uses x264 by default and it can be installed into MPEG Streamclip. You’ll find both programs MUCH faster than Compressor too (even when running Compressor using several virtual clusters).

All the best with the project.

[Andrew Stuckey]

Hey.

Just to clarify…
Are you saying the original media lags when played back in FCP or that it’s somehow lagging in the exported clip?