Smugmug encodes 1080 video to about 7.2Mbps. 720 video to 3.2Mbps. It does this regardless of frame rate, so a 24p video like this effectively gets more bits per frame than a 30p video.

Curious. I just watched this test at 720 and it is not as good as the 1080. I noticed the 1080 is High profile and the 720, have recently at least have been Main profile.

John Dennis said:
[I]"The camera has a built-in ND filter which was on. It also has the ability to manually reduce (or increase) the exposure level. On any bright sunny day, I find I get better results with the exposure reduced by 2/3 to 1 stop. "[/I]

That's all great but you should think about how the camera is reducing exposure.

It has two choices:

The iris. If the iris is closed too far then then the diffraction limit is reached and the image becomes soft.

Shutter speed. As the shutter is opened for less time the difference between frames increases. This isn't a problem when most of the frame is static background or even if you're slowly tracking a moving object. The encoders are smart enough to make good use of the redundant data between frames. When there's a back ground such as moving water the encoder doesn't have much of a chance and I notice the worst blocking was in the spray around the swimmer. Keeping the shutter at 180 deg might help here and for that as I said an additional ND filter or a polarize could help. They're not an overly expensive item and generally a polarizer will just make water look better. I know some here rarely take the polarizer off their camera.

Bob.

@NormanPCN

"Curious. I just watched this test at 720 and it is not as good as the 1080."

I tend to agree though it seems counter-intuitive. If you could get the bits/pixel numbers it might be telling.

@Bob

I've got a lot to learn about cameras. Not sure the Canon G15 exposes that much information or control in its video mode. Still reading.

I found a lens adapter for the camera that would allow the addition of different filters.

@John Dennis
If you could get the bits/pixel numbers it might be telling.

Smugmug lets me download the file (their re-encode) but only at the full size I uploaded. So I used HB to render a 720 file and uploaded that to this temp gallery.

720 upload
Format/Info : Advanced Video Codec
Format profile : Main@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 20s 62ms
Bit rate : 3 104 Kbps
Maximum bit rate : 4 647 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.140
Stream size : 7.42 MiB (93%)
Writing library : Zencoder Video Encoding

1080 upload
Format/Info : Advanced Video Codec
Format profile : High@L4.0
Format settings, CABAC : Yes
Format settings, ReFrames : 4 frames
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 20s 62ms
Bit rate : 7 171 Kbps
Maximum bit rate : 10.1 Mbps
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 23.976 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.144
Stream size : 17.2 MiB (95%)
Writing library : Zencoder Video Encoding

The obvious difference here is the High vs Main profile. I have noticed in tests with HD at Fast preset, constant CRF and changing the profile from Main to High the output file size, and hence bitrate, goes down. Smug does a fixed bitrate output so if High profile compresses better, saves bits, then there should be more bits to handle the hard to compress motion detail.

Another interesting thing. The 720 upload looks a little better than 720 playback from the 1080 upload. Here is a link to the gallery folder with both files. The captions describe which is which.
http://normanpcn.smugmug.com/Other/Beta/n-jqSmF/i-jxRR3sv

NormanPCN,

I regret to report that I'm getting no joy from these after having seen the original camera source.

"Less bad" is the phrase that comes to mind.

1. Profile settings affect compression efficiency. It is not a quality metric.
2. Comparing CRF bitrate and file size at different profile settings is like driving with the brakes on. Or pi**ing into the wind. One counteracts the other, and not in the way folks are inclined to think.
3. Constant bitrate is less efficient than CRF or conventional VBR, and ultimately sacrifices some headroom by retaining unneeded footroom.

bits/pixel aren't as revealing with modern compression techniques. SSIM and to a lesser degree PSNR are more indelible markers of efficiency.

It just doesn't work the way most people imagine.
Speed, quality, compression. Pick two.
TANSTAAFL

Pixelation/blockiness tends to happen on subject matter that does not compress great. Even on my FIOS TV pixelation occurs on difficult subject matter. The ION channel is notorious.

Those water ripples are pretty unpredictable and random(ish).

I tried a little Sony Quick Blur at .75 and it helped the blockiness. Of course it is a little softer. On something like this one can help a video targeting low(er) bitrates with something like this. Only the first few seconds have the objectionable blockiness. The blur only used on those worst offending time sections. We gotta try to work with whats available to us.

Have you tried outputting directly to VP8/VP9 near the quality YT delivers? Maybe YT doesn't recompress that?

The problem with throwing more compression at web video is that it makes it harder to play.
So it's really a brick wall for the deliverer. There are lots and lots of single- and dual-core processors humming away in homes around the earth.

So, the offsetting factors when preparing video for the web server are:
Bandwidth, Playability, Quality; possibly in that order of importance for the broadcaster.
In other words, Rock, Paper, Scissors.
Unfortunately, we as uploaders have absolutely no control over what comes back down the pipe.

It's an interesting battle, with lots of turns no one would expect unless they dove in.

It's not just the artifacts, it's the artifacts on top of artifacts. Sometimes you will do an encode and there are artifacts there that aren't objectionable, but when Youtube encodes it again, the artifacts that they add to your artifacts can spider out from the action in a way that is particularly horrible.

My solution has always been to just get it as good as Youtube or Vimeo can get, and then leave it at that. Most of my videos are 15 or 30 second ads, so I can get away with some pretty large files for some pretty short times that won't work on a longer piece.

Anyway, there are some upload bitrate and file size limitations in Youtube. Handbrake is famous for getting good quality at low bitrates, but I find it to be even more spectacular at getting close to uncompressed quality at high bitrates. Do some test encodes on a really short video. Use constant quality and see how high (low number in CC) you can go before Youtube tells you the bitrate is too high. Then experiment with file size. You don't have to complete the upload. Just go up until Youtube rejects the file as being too big. Now you know what your maximum parameters are.

Make your highest bitrate, largest file size that you are allowed and upload that and don't worry about it. It's as good as it gets, and worrying about it beyond that is pointless.

Here was an eye opening situation for me.

My workflow was to render XDcam mp4 in Vegas, then run that XDcam mp4 through Handbrake to knock it down before uploading to Vimeo or Youtube.

One day I accidentally uploaded the XDcam mp4 file to Vimeo. It took forever, but when it finally finished uploading and converting... oh my, it looked incredible. So much better than my Handbrake encoded uploads.

I did some experimenting and found that if I just increased the constant quality in Handbrake to something like CC10, that the file was still much smaller than the XDcam mp4 source, but that after the Vimeo encode looked about as good as the XDcam mp4 encode.

What is important about this is that there wasn't a huge difference in the look of the Handbrake encodes at a constant quality of 10 vs 20. It was only after uploading to Vimeo that this difference was apparent.

What I realized is that with the higher bitrate, there were less artifacts on my Handbrake render, and that because of this, the Vimeo encodes had much less "artifacts of artifacts".

Since then I have always used much higher (lower number) settings on my Handbrake encodes. A constant quality of 15 looks pretty darned good. A CC of 10 or less and you might as well be uploading uncompressed.

Yes, there is still some damage by the Vimeo encoder, but at least I know that I am getting as good quality as I can get.

Another thing I've noticed is that noise doesn't always look particularly terrible on a master, but it looks horrendous after Vimeo or Youtube encoders compress it. A bit of Neat Video on an upload version can work wonders. Sometimes the difference is barely noticeable on the master. Sometimes the Neat video version just looks less sharp. But after Vimeo or Youtube get hold of it, the encode of the denoised version can look just so much better!

There is too much motion in the video for the bit rates of YouTube and Vimeo to keep up with. The 5 meg bit rate of Sony AVC just barely keeps up at 1280x720. An intermediate with HB will probably work fine.

Use Vimeo and tell those who want to view the video properly, to download the original video and then play it on their computer or TV. I always keep the original videos on Vimeo for downloading.

@Laurence

As a test of high bit rate uploads, I uploaded to original camera video to youtube and vimeo. I added links in my original post.

I don't have Neat.

@VidMus

"Use Vimeo and tell those who want to view the video properly, to download the original video and then play it on their computer or TV."

That's a good idea. The people who care about quality can download the higher quality video. The rest can just criticize my equipment, shooting and editing ability.

I downloaded the MXF file that you provided and tried using motion blur to wrangle the problem. The result from YT was less blocking however because there's so much motion visually the result was unacceptably soft.

As Laurence has said above there's a distinct difference between visually lossless and mathematically lossless. The MXF files does contain a lot of compression artefacts. Cameras unless recording RAW are also adding compression artefacts i.e. they're throwing away information.

Delivering content through YT is always going to be problematic, there's usually three layers of compression, in the camera, for the upload and then YT itself. The last step is constrained by how much energy YT is prepared to devote to finding the best fit for the data, how much bandwidth is available to deliver the stream and how much computational power the viewer's CPU has.

Anyways looking and thinking this through I still think your best shot at shooting these events and delivering a better outcome via YT will come from putting a polarizing filter in front of the lens. That'll hopefully remove many of the reflections from the water, the solid colour of the pool itself will dominate. That may make it easier on the encoders.

Bob.

Bob,
The polarizing filter may well solve part of the problem, but the water can get really dark. The rest of the problem will be solved only when we put our shekels together and buy Youtube from Google.
;?)

I didn't see any criticism, there is an issue and you asked us to help find the problem?

The footage looks like a fast shutter rate, more than a 24th/48th/96/th sec? So each frame is vastly different than the next. No way to optimize that with today's codecs, I would say.

Can you go back to experiment with the same venue, different shutter speeds for your 24p to see if lower frame rates can smooth out the footage inherently? Assuming the frame rates were high in your original?

"I didn't see any criticism..."

I was referring to friends and family who might only get to see the 3 mbps versions and think that was representative of the quality. I've found the contributors to this forum quite civil and helpful. I appreciate that help very much.

I'm still working on the shutter speed idea. I'm not sure how I can control shutter speed at the 24 fps frame rate with that camera.

Friends and family are unconditionally forgiving. They generally wouldn't notice a difference unless you pointed it out to them. Remember, they are watching the swimmer, not critiquing your work.

When I'm critiquing my work, there's hardly any room for anyone else.

@ Bob

On shutter speed. I've read and searched the 316 page Canon G15 User Guide and found no way to control the shutter speed in video mode.

I found a very good description of the concept though.

http://vimeo.com/videoschool/lesson/56/frame-rate-vs-shutter-speed-setting-the-record-straight