Why Handbrake?

OldSmoke wrote on 6/12/2013, 5:55 PM
I hope I am not touching something that is old but I have been trying to figure out why so many users are going the Handbrake route to get their footage onto the Internet. I have made myself a small test project with 10sec. of the "Bell Nuite HD Testchart" which I rendered out to three different formats: MC-AVC for Internet, Sony AVC for Internet and DNxHD for Handbrake. When I process the mov file with Handbrake, following the well know tutorial, and bring all clips back on top of each into an empty Vegas project, I find that the DNxHD-Handbrake result is actually the worst.
https://dl.dropboxusercontent.com/u/39278380/handbrake.jpg
https://dl.dropboxusercontent.com/u/39278380/mc-cuda.jpg
https://dl.dropboxusercontent.com/u/39278380/testchart.tif

The MC image is very close to the actual chart but the other seems to blend the lines in area "1".

Maybe I am missing something but I played with this or quite a while and I am certain I followed the tutorial precisely. I also notice that the handbrake mp4 file seems a bit shorter on the timeline then all other files. The DNxHD mov file however has the same length.

Am I missing something or is my test wrong? I also rendered a short 2:30min clip from the last figure skating event out via DNxHD and Handbrake to see if there is any noticeable difference but I just can't see it. Also the files size of MC AVC and Sony AVC are actually smaller then Handbrake one.
My source footage is HDV from a Z5U if that makes any difference.

Here is a link to the whole project if someone is interested: https://www.dropbox.com/sh/17x60zx07c5ti13/mrA0XnHzWj

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

Comments

John_Cline wrote on 6/12/2013, 6:40 PM
Handbrake is about MUCH more than rendering a static image. Handbrake is capable of producing the best looking low-bitrate video. As far as judging an encoder based on the resulting file size, that is a false equivalency, file size is determined entirely by bit rate and that is one of the parameters that you can control. What an encoder can do quality-wise at a given bit rate is another matter entirely. Handbrake makes better looking video at Internet-friendly bit rates than anything else. Encoding is an art and the potential downside to Handbrake is knowing which parameters to adjust to produce the desired results.
craftech wrote on 6/12/2013, 6:52 PM
What you have shown is exactly why I don't like tests using that chart.

What's wrong with it?
Simple: It's not moving.

John Cline just pointed that out so I won't elaborate.

John
OldSmoke wrote on 6/12/2013, 6:56 PM
While I hear what you are saying but in the end the visible difference is important too. As mentioned earlier, aside from the static test chart I also rendered a short clip of a figure skater skating, a full 2:30 program. That clip contains fast motion and it has to "look" good. The MC AVC file at 10Mbps plays as well as the Handbrake file and the Sony AVC is actually "in my opinion" a bit better as it results in softer, less noisy background.
Maybe you are right when it comes to putting more content into a smaller package, higher compression I mean but why should I if I can make use of the full bit rate sites like Vimeo and YouTube offer? Content on both is not limited by size but by time. What do you consider Internet friendly bitrates? I always upload my files at full HD resolution 1920x1080 30p at 10Mbps and it plays back fine on my PC, iPad and iPhone. Are yo saying that the tutorial doesn't produce what you would consider a good result?

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

musicvid10 wrote on 6/12/2013, 7:00 PM
"John Cline just pointed that out so I won't elaborate."
I will, but . . .

Wow, where do I start? Oh, here:
http://www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx

I'll be happy to share some carefully controlled Belle-Nuit charts comparing 21 encoders I tested early on, and I can assure you they look somewhat different than the lossy jpeg images you posted.

But that doesn't begin to tell the story.
-- A still chart has no motion. That's 90% of the story behind interframe compression.
-- No motion = no bitrate vs. quality comparison. That's the other 10%.
-- Handbrake has infinite possible combinations for deinterlace, decomb, and even bob. Vegas has two (bilinear and bicubic) that have been around since the 1980's.

Below 8-Mbps, Sony AVC and Mainconcept fall apart significantly. At AVCHD bitrates, you would be hard pressed to tell a difference.
http://www.jazzythedog.com/testing/DNxHD/HD-Guide.aspx#LBR

If it is quantifiable data you're after, this is a good place to start.
http://compression.ru/video/codec_comparison/h264_2012/
http://compression.ru/video/codec_comparison/h264_2011/
http://compression.ru/video/codec_comparison/h264_2010/
and so on . . .
Andy_L wrote on 6/12/2013, 7:15 PM
That Handbrake is so much better than Vegas for these kinds of tasks seems long since well established to me.

The question is why?
OldSmoke wrote on 6/12/2013, 7:23 PM
As I said, I followed that tutorial and end result was a mp4 file that wasn't any smaller then what I got from MC AVC or Sony AVC and the bit rate was similar too, around 10Mbps.

I am actually looking more for visible difference then facts coming from tests, my customers like to look at actual videos rather then test clips.

Dont get me wrong, I happily follow the Handbrake workflow but as you said, at 10 Mbps, which is what I upload, there isn't any visible difference; did I get that right? I am willing to learn if I get better results.

Maybe it is my footage, a fast moving skater which I closely follow with the camera from start to end, panning and zooming constantly, puts a lot of stress on the encoder and I will always end up with a big file and high bit rate??

I guess I have to provide links to uploaded videos rather then the lousy images I provided?

Proud owner of Sony Vegas Pro 7, 8, 9, 10, 11, 12 & 13 and now Magix VP15&16.

System Spec.:
Motherboard: ASUS X299 Prime-A

Ram: G.Skill 4x8GB DDR4 2666 XMP

CPU: i7-9800x @ 4.6GHz (custom water cooling system)
GPU: 1x AMD Vega Pro Frontier Edition (water cooled)
Hard drives: System Samsung 970Pro NVME, AV-Projects 1TB (4x Intel P7600 512GB VROC), 4x 2.5" Hotswap bays, 1x 3.5" Hotswap Bay, 1x LG BluRay Burner

PSU: Corsair 1200W
Monitor: 2x Dell Ultrasharp U2713HM (2560x1440)

musicvid10 wrote on 6/12/2013, 7:31 PM
At 10Mbps, which is about at the threshold for visible artifacting differences between MC and x264, you should be just fine with either, ...

~ As long as ~

1. If starting with interlaced footage, you are using the Yadif plugin in Vegas;
2. You are OK with Bicubic as compared with Lanczos resizing; and
3. You are happy with the way motion detail looks to you in Vegas renders by comparison with x264.

Note that rendering a still image chart does not reveal the effects of any of those three considerations.

Almost every possible encoding parameter is adjustable in x264, but only a handful are in Vegas.
http://mewiki.project357.com/wiki/X264_Settings


musicvid10 wrote on 6/12/2013, 7:43 PM
"

Yes. The compression differences when comparing any two interframe encoders will equalize at either end of the motion spectrum. From 250 Kbps or less at zero motion to Tens of Mbps or more with fast motion. Next step is to do a frame-by-frame comparison of the results, and if you are happy with them, stick with what you're doing.
http://en.wikipedia.org/wiki/Inter_frame
" ... higher compression I mean but why should I if I can make use of the full bit rate sites like Vimeo and YouTube offer?"

You've missed the point entirely. Youtube and Vimeo both reprocess your video to around 2000-2500 Kbps. That means uploading anything over ~8000 Kbps meets the definition of overkill, assuming it comes from a good encoder. So the question then becomes, "Why spend all the extra time encoding, uploading, and processing high-bitrate, high profile stuff, when it is all for naught?" Part of what we did in researching the video tutorial was seek the OPTIMAL encoding and upload zone, not the most time-consuming and wasteful.
johnmeyer wrote on 6/12/2013, 7:46 PM
I agree with all the replies, but to drive home the answer to the subject line ("Why Handbrake?) I want emphasize two of the key things already mentioned.

1. The workflow created in that wonderful tutorial avoids the inferior deinterlacing done inside of Vegas when re-sizing down to lower resolutions.

2. Handbrake (and MeGUI) both do a significantly better job at lower bitrates than either the MC or Sony encoder, both of which are actually quite awful at low bitrates. The differences are not subtle when tested with real-life video. The tests done by several tireless individuals here in the forum about two years ago were quite definitive.
musicvid10 wrote on 6/12/2013, 7:51 PM
John, I'm going to frame that response and hang it on the wall in my home studio. You just made it all worth it (that and 20,000 combined hits on the online video).

Oh, and thanks again for all your help with my audio yesterday!
m
VidMus wrote on 6/12/2013, 8:17 PM
OldSmoke says, "Content on both is not limited by size but by time."

Actually on Vimeo size can matter in that one has a 5 gig a week upload limit.

I upload church services each week. There is the morning service and then the evening one which is a combination of service and class.

The morning service averages an hour. The evening service averages 2 hours.

Because of this I use an average bit rate of 3000kbps. I also size the video to be 1280x720 because the above bit rate is too low for full HD.

I know that I cannot possibly get a descent looking video with MC or Sony's AVC at that bit rate. In fact it will look terrible!

So HandBrake is a jewel when it comes to having to use a low bit rate and still have good quality!

As for me and as I have pointed out in other threads I use Video for Windows *.avi Sony YUV instead DNxHD. It does make huge files but it also works best for my needs.

A short full HD video with a high bit rate can be done with what Vegas has. Will it actually be better? Maybe, but look closely at the final results. In the darker areas of the videos there is an annoying and constantly shifting pattern that I absolutely cannot stand!

Interesting Note: The new 2013 Sony cameras has the ability to record directly to MP4 and has that same hideous shifting pattern in it. I did a test shot outdoors with sunshine and wind and the shadow areas from the trees had that same shifting pattern. So apparently the same Sony encoder is being used in the new cameras. The cameras bit rate is 6000kbps.

Anyway, if one looks at all of the aspects of the videos produced by HandBrake vs. what is in Vegas, HandBrake wins hands down especially when a low bit rate is a must.

Just for kicks, do a test with a very low bit rate of say 500kbps with a frame size of 1280x720. This is very low but you will see a HUGE difference between what HandBrake puts out vs. what MC and Sony's AVC puts out!

Finally, I have spent many hours trying to find a way to use what is built into Vegas. Mainly just for the sake of staying in Vegas and looking for a faster way to get the videos out. Compared to using HandBrake, MC and Sony's AVC fails every time!

I hope this helps.
johnmeyer wrote on 6/12/2013, 8:39 PM
Oh, and thanks again for all your help with my audio yesterday!You're welcome!

Your tutorial (and the somewhat parallel one that Nick did) are the two best video tutorials I've ever seen. What's more, the effort that everyone put into that work was truly amazing. That quest to achieve the "ultimate" quality result showed this forum at its best.

My only disappointment is that not only did Sony fail to participate in any of it, but it also appears that they never took the problems seriously, and as a result we still have to jump through hoops in order to do something that absolutely EVERY video editor now does almost every day.
VidMus wrote on 6/12/2013, 8:45 PM
"1. The workflow created in that wonderful tutorial avoids the inferior deinterlacing done inside of Vegas when re-sizing down to lower resolutions."

Even without de-interlacing Vegas re-sizing down to lower resolutions is poor even with best-full!

On a wide shot in my morning church videos there is an exit sign in the video. If I were to let Vegas resize to 1280x720 with *.avi or DNxHD instead of HandBrake that sign will not be readable. The loss of quality from Vegas resizing is quite noticeable! And this is without Vegas de-interlacing it. If Vegas de-interlaces it, it will be even worse!

I wish HandBrake was built into Vegas!
musicvid10 wrote on 6/12/2013, 8:51 PM
It would be good to not leave the impression that the tutorial (now two years old and due for an update) was somehow a solo venture.

Jerry, Nick, Alistair, stringer, kimberly, Laurence, johnmeyer, bob, and even the Handbrake developers gave substantive support. My role was as instigator and compiler.

Hulk wrote on 6/12/2013, 9:10 PM
Handbrake produces excellent quality video but in my opinion Ripbot is just ever so slightly better. Both are much better than what you can do with Vegas Pro.
johnmeyer wrote on 6/12/2013, 9:50 PM
Is ANYONE in the Vegas product team reading this??? If not, why not?

This is not a minor issue, especially for a "pro" video editor. Uploading to the Internet is de rigueur for every contemporary video editor, and de-interlacing and re-sizing are fundamental elements to that workflow. While you can simply upload full-res, high-bitrate video and let the hosting site do these steps, YouTube makes it clear (not sure about Vimeo) that you will be better results if you do it yourself. All this was confirmed by the team that helped Mark and Nick create those tutorials.
musicvid10 wrote on 6/12/2013, 10:08 PM
Unfortunately, the key ingredients to improved web-friendly output (Lanczos, x264, ffmpeg, various advanced deinterlacers) are all open source.

Although the GNU general license allows for incorporation into paid solutions with proper attribution, Sony has apparently chosen, through its internal licensing policies, to exclude these, and other open-source solutions from their products.

Nor have they proactively bought up other projects whose products and expertise would enhance their own services, as have Pinnacle, Red Giant, and GoPro, to name a few recent examples.

If these policy restrictions are etched in stone, then Sony should undertake a rapid deployment strategy to develop their own proprietary algorithms, in the same sense that they have already done with a few of the Quicktime encoding libraries.

One need only take a look at Kodak, Gates Rubber, Sun Microsystems, PanAm, Commodore, Montgomery Ward, and other entities who chose not to retool in order to keep up with the times, in order to see the implications.


VidMus wrote on 6/12/2013, 10:28 PM
Their current licensing agreements may be what is preventing them from using open source or even talking about it. Such as their license agreement with MC.

My guess...

A suprise in Vegas 13? Please wake me up if that happens. Grin!

musicvid10 wrote on 6/12/2013, 10:34 PM
We pay plenty for the MainConcept and Dolby Digital license royalties that are passed on to us as Vegas Pro purchasers.
farss wrote on 6/12/2013, 10:58 PM
I generally shoot 1080p and render 720p at 6Mbps using the Sony AVC encoder for upload to YouTube.
Results are great, no need to futz around. That said the source video is usually from my EX1 which gives me a lot of control over detail. I can generally avoid any noise by using -3dB gain. Quite simply much worse things than what Vegas might do to the image are going to be done to it by YouTube.
In the event that I have to deal with interlaced footage then I use the YADIF de-interlacer which is very good and free.

Where I would use Handbrake is for one client who plays out content from their own servers and they go down to a bitrate of 500Kbs at a resolution of 1024x576.

That said this client uses CS6 and comparing their work scaled in Ppro/ AME and what I can get out of Vegas I don't see anything in it. Even more of a test, they and I go through several generations of H.264 encoding at low bitrates and it all holds up well enough. What does seem to suffer most at such low bitrates and over generations is the audio, even just speech gets noticeable artefacts.

Bob.
riredale wrote on 6/13/2013, 12:23 AM
I have a related question. I know a process involving Handbrake is recommended for top-notch low-bitrate web delivery, but all my work for the past few years has been for DVD.

If I'm shooting in 1080/60i and want to deliver on 720/480 DVD (Mpeg2), is there a Handbrake process significantly better than the standard Vegas MainConcept encoding I've been using? My projects generally run about 5-7Mb/sec average.
johnmeyer wrote on 6/13/2013, 1:00 AM
is there a Handbrake process significantly better than the standard Vegas MainConcept encoding I've been using? My projects generally run about 5-7Mb/sec average. The answer to your question can be found somewhere in this epic thread:

Interlaced HD to DVD AGAIN - some test renders

I'm sure that one of the players can give you a short summary ...
Grazie wrote on 6/13/2013, 1:33 AM
John Meyer: Is ANYONE in the Vegas product team reading this??? If not, why not?

John, if, after SCS were to read the valuable results carried out, what would you have SCS do?

Cheers

Grazie

VidMus wrote on 6/13/2013, 9:19 AM
To better see what that repeating pattern looks like please look at the test video I uploaded to Vimeo.

http://vimeo.com/68303040