Why does Handbrake look so much better?

Laurence wrote on 12/10/2010, 11:44 AM

No you aren't seeing things. That worked perfectly! Colors are right on after the Handbrake render! I just started wtih my regular old HDV project though and just set the DNxHD settings as you described for a 720p render. I think you solved it! Now to understand why...

musicvid10 wrote on 12/10/2010, 12:21 PM

Well, this may give us a clue (I'm going to dig deeper and report on the HB forums as well).

With the 709 flag set in DNxHD, here is what MediaInfo reports from the rendered HandBrake file, which I think is exactly what it should be:

Color primaries : BT.709-5, BT.1361, IEC 61966-2-4, SMPTE RP177

More to come, but it looks like revisiting the problem (after many months of frustration) "may" have given us a solution. DNxHD comes through again!

Laurence wrote on 12/10/2010, 1:10 PM

MusicVid. I still have two questions:

1/ What is the difference between DNxHD 75 and DNxHD 110?
2/ So far I can't make 1080 HD DNxHD resolutions work with Handbrake. Can you?

PerroneFord wrote on 12/10/2010, 1:19 PM

DNx75 is a 75Mbps codec... DNx110 is a 110 Mbps codec. Same everything, one just has more bandwidth than the other (and should look every so slightly better).

farss wrote on 12/10/2010, 2:10 PM

The amount of metadata in the DNxHD file is interesting. I thought simply specifying Rec 709-5 would be all it requires, why include the matrix coeffiicients?

Googling SMPTE RP177 turned up this.

Mostly way over my head however it I think confirms something I've long had in the back of my head, what effect does shifting levels really have on color and the answer seems to be rather complex.

There's another problem too, we're all using the term "sRGB" however sRGB is a real colorspace spec that defines more than just luma values e.g. primaries.

Aside from all the technical stuff that article does explain why a media file should define fully what it contains. In the past this was not done leading to all sorts of issues.

Bob.

musicvid10 wrote on 12/10/2010, 3:11 PM

Perrone, I have a question for you.
I had assumed that for porting over to FCP, I should set RGB levels in DNxHD. However, given the revelations here, I wonder if I need to revisit that. I never actually saw the output after I passed it over to the FCP editor.

Since you have access to both platforms, could you tell me if DNxHD should be flagged 709 or RGB for Vegas to FCP? Thanks.

PerroneFord wrote on 12/10/2010, 3:13 PM

I *ALWAYS* do 709 to go into Avid or to FCP. And I never get color shift issues. In fact, if you DON'T do 709 when making a DNxHD file, Avid won't fast import. It has to do a conversion on the file to bring it in and it takes a WHILE...

musicvid10 wrote on 12/10/2010, 3:34 PM

Thanks Perrone,
I was afraid I was doing it wrong. Now I know I was.

musicvid10 wrote on 12/10/2010, 3:53 PM

"2/ So far I can't make 1080 HD DNxHD resolutions work with Handbrake. Can you? "

@Laurence,

Yes, I did. For this test I set my Project and Render properties at 1920x1080 24p. Setting the Project to match output pre-sets the default render template (remember that the Custom Video render window can override the DNxHD templates).

Also, if you are starting with non-square pixel source media (for instance 1440x1080 HDV), it has been recommended to use one of the "TR" templates in DNxHD; they offer an advantage when converting to square pixels for output. [EDIT: See comment below.}

musicvid10 wrote on 12/11/2010, 9:14 AM

I'm doing some tests with actual HDV (1440x1080) material instead of generated media. I found that the "TR" renders won't seem to open the Handbrake (gives an error).

The DNxHD renders and the Handbrake output (decombed and downsized) are outstanding.

The idea with 1440x1080 is to set the custom render properties to 1920x1080, 1:1 PAR.

Laurence wrote on 12/11/2010, 11:13 AM

I find the Handbrake decomb and the Mike Crash smart deinterlace to be pretty equal. Handbrake decomb is easier to set up. I rarely shoot interlaced anymore though.

I am still just amazed at the quality of the Handbrake h.264 renders. I've been redoing all my old Vimeo Pro videos.

musicvid10 wrote on 12/11/2010, 11:29 AM

There will be a new decomber (Decomb3) which is said to put the old one to shame (although it is very good).

When it will be launched in a HB Nightly is anybody's guess . . .

amendegw wrote on 12/11/2010, 11:40 AM

"I am still just amazed at the quality of the Handbrake h.264 renders"Me too! I posted the following in another thread, but will repeat here. I rendered the following video to be played on relatively low bandwidth connections. The opening title - sparkler & spinning newspaper article looked like crap in other rendering techniques I attempted. However, I got what I think is very good quality using Handbrake at only 400kbps. Click here

...Jerry

PS: The link to this video will only be valid for a couple days.

PerroneFord wrote on 12/11/2010, 11:57 AM

People really don't know how much different the encoder makes until they see it back to back. It really makes a difference. I've also found that the Mainconcept encoder in Vegas and the one is Squeeze produce VASTLY different results...

musicvid10 wrote on 12/11/2010, 12:04 PM

"I've been redoing all my old Vimeo Pro videos. "

When you're done, could you leave at least one of your old renders up for comparison? Link to your user page please?

musicvid10 wrote on 12/11/2010, 12:17 PM

"People really don't know how much different the encoder makes until they see it back to back."

Here's a link to the latest h264 shootout, including x264, MainConcept, and several others. There's also an appendix for VP8 which seems to place it pretty much between x264 and Xvid. (Squeeze isn't included because it's a different encoder, but one might find it elsewhere on the site).

http://compression.ru/video/codec_comparison/h264_2010/

PerroneFord wrote on 12/11/2010, 12:31 PM

The problem I have with this test (same with their previous tests) is that I don't use presets. I custom tailor all my encodes. And doing that, I tend to get excellent results.

I have tried x264 years ago and found it gave good results, but didn't care for any of the GUI front ends. Maybe they are better now.

musicvid10 wrote on 12/11/2010, 1:07 PM

"I have tried x264 years ago and found it gave good results, but didn't care for any of the GUI front ends."

Compared to the others, Handbrake is relatively painless, and still offers a full set of CLI options through a separate window.

farss wrote on 12/11/2010, 1:19 PM

The sparkler is obviously difficult to encode. Looking at the Very Low encode enlarged to full screen there's obvious blocking happening looking at it frame by frame. Played back at speed no one is going to notice. The Hi encode is very clean.

What you are doing is an actual test of an encoder, at last something meaningful in this discussion.

There's a comparison table between all the H.264 encoders at the end of the Wiki here.

There's a reasonably readable explaination of Rate Distortion Optimisation here.

Both X264 and the MC H.264 encoder use this, the latter I assume only in 2 pass VBR. I have had issues with using this. Whilst it is a better way to encode it can create problems with playback on low power computers that simply don't have the grunt. The video plays back fine until it hits the "complex" sections and then starts to stutter.

Bob.

amendegw wrote on 12/11/2010, 1:44 PM

I guess I should have posted this earlier. All four renders were encoded using Handbrake with the Default Decomb video filter, 2 Pass VBR, deblocking -2, -1. Everything else was default.

Here's the custom statistics for each "quality render"

High Quality:
...Bit rate : 2 000 Kbps
...Width : 1 280 pixels
...Height : 720 pixels

Std Quality:
...Bit rate : 768 Kbps
...Width : 720 pixels
...Height : 400 pixels

Low Quality:
...Bit rate : 400 Kbps
...Width : 640 pixels
...Height : 352 pixels

Very Low Quality:
...Bit rate : 128 Kbps
...Width : 320 pixels
...Height : 176 pixels

Why the odd dimensions? Handbrake likes to use multiples of 16 - seems to play fine, though.

...Jerry

Edit: Oh, one more thing. I rendered to a Sony mxf from Vegas and used that as the input to Handbrake.

musicvid10 wrote on 12/11/2010, 1:52 PM

Even as a longtime advocate, I'm still surprised that your highest bitrate was only 2Mbs @720p.

As far as the block size, you can set it lower than 16, but some players (QT maybe) may have a problem with it. And you can get random macroblock errors around the edges if you turn it off completely.

amendegw wrote on 12/11/2010, 2:08 PM

musicvid,

Everything I know about Handbrake, I've gleaned from your posts (and lots of trial-and-error). Much thanks!

As a matter of fact, it's probably the main reason I've started to migrate away from Silverlight. The reason I've always liked Silverlight is because I could always get better quality wmv encodes than mp4's from Vegas.

I really like JW Player, but it's limited to Flash. Once you "turned me on" to Handbrake, I found that I could encode quality mp4's at low bitrates and play them on JW Player.

That said, Silverlight will also play mp4's but I have not found a MediaPlayer that I like. I've started a half-dozen times to code my own, but the Expression Blend learning curve is steep (for me, at least).

...Jerry

Edit: Yes, I'm aware that JW Player makes a Silverlight MediaPlayer, but I didn't like it (can't remember the reason right now).

musicvid10 wrote on 12/11/2010, 2:16 PM

I tested Silverlight somewhat recently, but by that time I was already comfortable with the HB workflow and quality, so I put Silverlight aside and never looked back. JW Player is a great free project! However YT embeds are so easy I often just do that.

Same thing happened when Google released the VP8 codec. After a couple of frustrating results, I never could figure how they could put it up as a worthy competitor to h264. Glad you've benefited some from my trail of crumbs. I've stumbled many times.

Randy Brown wrote on 1/12/2011, 12:02 PM

At the risk of getting too OT here I have an old demo reel on DVD that is 4:3.
I would like to get it on my website (quality over size) displaying in a 16:9 aspect (not stretched but cropped).
Would someone be so kind to tell me the best workflow to do this pretty please?
Thanks very much,
Randy