While there appears to be a wide range of opinions on Flow Motion image quality, I haven't yet seen any video samples posted for comparison. In order to gauge how much I'll need to improve Flow Motion to impress the skeptics, I shot a 3-way comparison of Flow Motion, CBrandin's 66Mbps AQ2 patch, and Driftwood's Quantum 100 patch.

To make sure I'd see just how grungy it looks, I biased my test conditions heavily against Flow Motion by shooting a low-contrast flower arrangement 2-stops underexposed at 1SO 800 with a 50mm lens at f1.4 and a 1/60 shutter speed. This depressed Flow Motion's bitrate down to about 38Mbps, while both CBrandin's 66Mbps patch and Driftwood's 100Mbps Quantum patch were able to maintain their rated bitrates.

I loaded the three clips into Premiere CS5.5 and boosted the gamma curve to bring up the shadow details for close inspection. Then I did a 100% crop down to a 1280x720 frame and exported the sequence to an H.264 MP4 at 50Mbps. I uploaded it to Vimeo, where the uncompressed version is now available for download:

Unfortunately, I trashed the Premiere project and lost the slip of paper I wrote the patch testing order on. Vimeo's compression makes it kind of hard to compare things so I'm hoping someone can help me out here?

@LPowell through Vimeo it's difficult to discriminate between them

@LPowell Unfortunately the download option is not available everywhere. In some countries you simply can't download videos (Vimeo policy).

@LPowell I’m a little confused. You say you shot each clip in the sequence at 24p, but your Vimeo upload is encoded at 60 fps progressive. There are duplicate frames in your source file (frame1-duplicate-frame2-duplicate-duplicate-frame3-duplicate-frame4-duplicate-duplicate, and so on).

Can you help me figure this out?

The “Download this video” link is supposed to give you the original file (before Vimeo conversion, that is), unless Vimeo is doing something behind our backs.

with a free account Ability to download converted files,
check your video's on vimeo when they are for example a year old... much and much more compression on it then in the first weeks.......

With Plus, all your videos are converted using 2-pass encoding. That means your videos looks cleaner while taking up the same amount of bandwidth.
Source File Downloads 1 week Always*
Uploads are converted to Vimeo format. Basic account users have their original files removed after 1 week, leaving only the Vimeo version. Plus users can opt in to having their original uploaded file stored. Preserve your source files with Plus!

@Mr_Moore Thanks for alerting me! In my haste, I uploaded the wrong render to Vimeo. You should be able to download the correct file now.

I downloaded and pixel peeped the clip several times, and, honestly, it's hard for me to distinguish between them in terms of quality--they all seem to be the same! But I suppose the compression may be playing a role even though it's the downloaded file? I will do my own tests soon enough. Thanks for the great work @LPowell!

BTW, I didn't see a link to the video. I just did a vimeo search to find it.

@mozes You misunderstand, I downloaded the clip from vimeo. I meant the compression from the output of the original file from the NLE.

Good job LPowell. I tried the settings and they produced some good stream parser results. However, the 720p settings were not stable in ETC mode. It crashed after a few seconds with ETC and the 14-140mm. I used a class 10 30 gb/sec Sandisk card. Hopefully, there is something that can be done to improve the stability.

@qwerty123 I cropped the original 24H videos to 1280x720 and encoded at 50Mbps to minimize any compression loss from re-encoding the files. On my HDTV and calibrated monitor, I see no perceptible differences stand out.

Here is the patch with just one small change - the MJPEG framerate changed to 2fps for use in timelapser. Not necessarily very efficient; only about 41mins on a 32Gb card due to the MJPEG compression table values, and a bit of a waste of the patch MJPEG settings, but might be useful to have that option as part of an allround excellent patch. Enjoying results so far and about to try the ETC settings recommended, thanks again @LPowell

@towi Thank you for the test results. The uneven cadence sample is an example of the encoder being forced into Fallback Mode at the extreme edge of its bitrate limit. I'd be interested to see the rest of StreamParser's report in that case. I wasn't able to get Fallback Mode to work properly in FSH and SH modes, which is why they may produce card speed errors in extreme cases, particularly in ETC mode or if using a shutter speed higher than 1/60 sec. The current patch settings maintain the best overall stability I could achieve with the built-in Quantizer Tables. With the next version of PTool I'll be able to improve the stability margins with custom tables.