It ain’t gonna look good at 3 mbps.

john_dennis wrote on 7/24/2014, 8:41 PM

In my role as “grandpa in the stands with a camcorder” I find myself shooting a lot of undulating water at swim meets in the summer. After a number of uploads to youtube where I was ashamed of the results that I shared with family members, I decided to look at my methods for rendering and uploading to streaming services. I reached the conclusion that in some cases: 1) It ain’t me. 2) It ain’t Vegas Pro. 3) It ain’t Handbrake.

Sooner or later, we have to face the fact that some types of video are never going to look good at the bit rate that youtube returns, ~3 mbps.

Here is one type of scene that I shoot a lot that falls into that group, undulating water.

Just for yuks, here is the Vimeo version.

https://vimeo.com/101687395

The source video looks fine to me. My Blu-ray renders at 25 mbps look just fine to me. I rendered to the Mainconcept AVC codec for Internet upload at various bit rates in increasing 1 mbps increments but lost interest when I found that the bit rates that yield acceptable results were far above the bit rate that youtube will ever return to me.

So, here’s the deal.

If some of you are up for the challenge of proving me wrong and want to try your hand with your secret method of encoding for streaming, knock yourself out with this source file. (Link long since abandoned. See 2016 Update).

2016 Update: I found a Canon utility for the camera that allowed me to cut the video on I-frames without re-compressing. Here is link to a 20 second video identical to the original but not such a burden to store and download.

If you’ve been there, done that and have examples of other types of scenes that you would never consider uploading to a streaming service, please post them in this thread and save others a lot of frustration.

Hope your summer is just as happy as mine has been so far.

John Dennis

I'll add links to on-going efforts below:

youtube from the camera video

Comments

vtxrocketeer wrote on 7/24/2014, 9:03 PM

John, I don't have a solution off the cuff. Because YT always suggests video to watch, I wound up viewing at random your Fishing at Sly Park video. That one included a lot of fast moving water (well, fast motorboat over water), churning water from ducks, and gently undulating water. On YouTube it all looked a LOT better than the horrid example of the pool. What, if anything, did you do differently for the Sly video?

musicvid10 wrote on 7/24/2014, 9:39 PM

Motion + Detail + Youtube = Disaster.
Been disappointed a couple of times just recently.
Triple their usual delivery bitrate and it will start to come alive.

OldSmoke wrote on 7/24/2014, 10:17 PM

john

have you tried shooting in 1080 60p or 720 60p? I think it easier for HB to convert from a higher frame rate with less temporal spacing... nothing scientific, just a thought. I am not sure if HB will actually look at the alternate frame and Interpolate or just neglect it in which case shooting at 30p is sufficient. Hmm.. I could actually test that on my swimming pool.

musicvid10 wrote on 7/24/2014, 10:37 PM

Youtube now accepts 60p.
But that's not the problem John Dennis describes.
it's bitrate.

john_dennis wrote on 7/24/2014, 10:59 PM

@vtxrocketeer

"What, if anything, did you do differently for the Sly video?"

That edit: Sly Park video was shot on a Sony AVCHD camcorder at 1440x1080-60i. There were a number of youtube postings to show 1) native Vegas de-interlacing, 2) Yadif de-interlacing and 3) Vegas 8.0c through DNxHD to Handbrake.

john_dennis wrote on 7/24/2014, 11:03 PM

@Musicvid10

"Triple their usual delivery bitrate and it will start to come alive."

That's about what I found in my incremental renders. Unfortunately, youtube won't return much more than 3 mbps. Once, I even sent them a 22 mbps source to no avail.

OldSmoke wrote on 7/24/2014, 11:04 PM

John.

If it's shot in 1440x1080 60i (HDV) then why is the sample an MXF at 24p?

john_dennis wrote on 7/24/2014, 11:12 PM

@ Old Smoke

"have you tried shooting in 1080 60p or 720 60p?"

Last year, I shot a similar scene at 30p. It was nauseating coming back from youtube. The aspect that annoys me most is the blocking. The are no squares in water in real life. I've concluded that 3 mbps is not enough to portray undulating water no matter how good the original video was.

Someone prove me wrong.

john_dennis wrote on 7/24/2014, 11:15 PM

@ Old Smoke

"If it's shot in 1440x1080 60i (HDV) then why is the sample an MXF at 24p?"

I was responding to vtxrocketeer about the Sly Park video. I'll edit the post for clarity.

The undulating water video was originally shot at 1920x1080-23.97p on a Canon G15 at 35 mbps in a MOV wrapper. I rendered it to length in MXF to maintain near original quality for others if they want to try their favorite encode method.

PeterDuke wrote on 7/25/2014, 12:47 AM

Yes, rippling water is difficult. An SD MPEG2 TV channel in Aus. (SBS) that shows many documentaries and uses a lower bit rate than its competitors (often 4.4 Mbps) is most likely to show compression artifacts when there is rippling water.

John_Cline wrote on 7/25/2014, 1:32 AM

I can only think of one thing worse to make an inter-frame encoder go nuts; a frame full of multi-colored confetti shot out of a cannon.

farss wrote on 7/25/2014, 2:46 AM

The only thing I can suggest you could try is addling some motion blur.

Bob.

musicvid10 wrote on 7/25/2014, 9:15 AM

"

Or, multi-colored confetti shot out of a canon over undulating water.

And here's the proof; my clipping indicator tests. The first one has relatively lower frame complexity, and "kinda sorta" works on Youtube. It shows luminance clipping only.

Now, here's the one with full luminance and chroma indicators. The outcome was so horrid that it caused me to abandon any further uploading of these tests. The 12Mb/s 720p encode out of Handbrake was flawless for any practical viewing purposes.

As one can plainly see, the 1080p version uploaded Youtube is even worse! Watch what happens at the 10s mark and again at 24s. Yet another reason to stick with 720p.

Now, the conundrum is, Youtube can easily deliver the bandwidth for clear viewing, but how many people would be able to play it?

BTW, if anyone wants my modified clipping indicators (as a Photoshop Action), I'll throw them up on Dropbox. They work much better than what you see on Youtube.

musicvid10 wrote on 7/25/2014, 9:40 AM

"

A weak denoise filter in Handbrake is often effective in maintaining program clarity without encoded file sizes going through the stratosphere.

john_dennis wrote on 7/25/2014, 10:42 AM

@ John Cline

"...to make an inter-frame encoder go nuts; a frame full of multi-colored confetti shot out of a canon."

And yet at least one show does it every May for the big finale.

I read your post three times before the coffee was made and I thought you said "a frame full of multi-colored confetti shot with a Canon." After my first cup of coffee, I finally read it correctly.

musicvid10 wrote on 7/25/2014, 10:48 AM

Cannon.

john_dennis wrote on 7/25/2014, 10:51 AM

On motion blur and denoise filters:

Although I've actually given up on 3 mbps, I'll ponder the thought.

I am interested in your clipping indicators. I think some of those white sparkles on top of the waves were clipped in the camera even though I reduced the exposure drastically per an old recommendation from Bob to always underexpose in bright situations.

Steve Mann wrote on 7/25/2014, 11:18 AM

The problem is the recompression in YouTube. Macroblocks are the compression artifacts from small areas of similar color and luma levels.

It's not you, it's YouTube.

How does it look on Vimeo? I've been generally happy with their recompressions.

NormanPCN wrote on 7/25/2014, 11:48 AM

I downloaded the MXF file and used Handbrake to encode using crf 25 and uploaded to Smugmug. It looks pretty decent.

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.

http://normanpcn.smugmug.com/Other/Beta/n-jqSmF/i-jxRR3sv/A

If you watch this, don't leave the resolution in "Auto". The hardest to encode parts are at the very beginning of the video and it takes some seconds for auto to figure out what resolution to stream. Just set to 720 or 1080 and then play.

edit: I notice that in this example Smug's 1080 is much better than the 720.

I downloaded the Youtube versions with YTD Downloader. MediaInfo says 2.1Mbps for 720 and 4.1Mbps for 1080.

john_dennis wrote on 7/25/2014, 12:41 PM

"How does it look on Vimeo?"

I included the link in the start of the thread, but the Vimeo video never starts on the workstation I'm using at the moment.

musicvid10 wrote on 7/25/2014, 2:22 PM

Here's the luminance clipping Action:
http://dl.dropboxusercontent.com/u/20519276/Chromasia%20Actions%20%28Version%202%29.atn

You would render an image sequence to its own folder in Vegas, then run the Action Set on that folder.

I designed the chroma clipping Action on top of that one. Interesting, but not terribly useful unless you're producing for PBS. Let me know if you want it.

There are indeed plenty of clipped sparkles in your pool footage, and that's how it needs to be to maintain correct exposure.

john_dennis wrote on 7/25/2014, 2:33 PM

Got it. Now I have to learn how to run it. Will Photoshop Elements support it?

musicvid10 wrote on 7/25/2014, 3:54 PM

I think so, put it in your /Presets/Actions folder and see if the Actions palette will load it.

farss wrote on 7/25/2014, 4:13 PM

[I]" I think some of those white sparkles on top of the waves were clipped in the camera even tough I reduced the exposure drastically per an old recommendation from Bob to always underexpose in bright situations."[/I]

If you reduced exposure enough to avoid clipping the sun reflected off the ripples you're going to have one very dark video!

A relevant question is 'how did you reduce the exposure?'

Even shooting these kinds of scenes with cameras that have internal ND filters I find myself running into issues that will affect the outcome from YouTube. I'm either forced to use extreme aperture values or increasing shutter speed. To avoid this I've found it necessary to either add more ND filters in front of the lens and / or use a polarizing filter.

Bob.