Handbrake question

rraud wrote on 6/6/2013, 1:07 PM

Handbrake works with MXF files.. or you could just use the MainConcept AVC (mp4) and save a step.

Weldon wrote on 6/6/2013, 1:12 PM

I have been using Handbrake and Avid DNxHD together for a few years based on a great YouTube tutorial I got from this forum. I only used that combo for work that was going on Vimeo or YouTube and it worked great. I don't use that process for DVD or BluRay projects and since I can't seem to correct my QT issue, I need another intermediary codec to continue using the Handbrake process. Is there a MXF lossless preset?

Marton wrote on 6/6/2013, 1:13 PM

I think he like to use handbrake because he is not satisfied with the quality of Mainconcept renderer. Right?
Try AVI with lagarith or UT lossless codec.

NormanPCN wrote on 6/6/2013, 2:07 PM

Handbrake works with MXF files but not all codecs in MXF. For example, HB does not support HDCAM SR (mpeg-4 sstp).

Too bad, as it would make a nice intermediate.

Laurence wrote on 6/6/2013, 3:12 PM

The trouble with MXF files in Handbrake is that you lose one stereo channel. You have to choose either the right or left channel and the Handbrake render becomes a mono render with just that one audio channel.

If you are using Sony XDCam mxf, the video is in the mpeg2 codec, I render out to XDCam mp4 because the video is the same mpeg2 codec, but I get both audio channels. You can even smart-render between XDCam mxf and XDCam mp4 (mp4 container with mp2 codec video).

VidMus wrote on 6/6/2013, 3:13 PM

I am using Video for Windows *.avi with the Sony YUV Codec. This will create a huge file but gives excellent quality and it renders a little bit faster than DNxHD. Handbrake will also render an AVI file faster than a DNxHD file.

What I like the most is I do not have to deal with Quicktime and all of its problems and I do not need to install another codec hoping it will work and/or keep working.

I did use mpeg with a high bit rate *.m2t file but it will not work with 1920x1080 progressive with a 59.940 frame rate.

A clean 1.0TB hard drive will easily handle most renders and I typically have videos from 1 to a little more than 2 hours.

Clean work drives will help speed up rendering.

Hope this helps.

wwaag wrote on 6/6/2013, 8:01 PM

I thought that Handbrake quit supporting avi a few releases ago. Are you using the latest version?

wwaag

musicvid10 wrote on 6/6/2013, 8:15 PM

Handbrake stopped encoding AVI some time back.
As far as decoding, anything that libav will recognize will open in Handbrake, including many flavors of AVI.

VidMus wrote on 6/7/2013, 12:26 AM

I am using version 0.9.5 (2011010300).

I recently downloaded the latest version, filename "HandBrake-0.9.9-1_x86_64-Win_GUI.exe" but have yet to try it with avi.

I will do a system clone to protect what does work and see if the latest version works or not and reply again with the results.

VidMus wrote on 6/7/2013, 2:01 AM

Ok,

I installed the latest version of HandBrake and it works fine with the Sony YUV codec *.avi file.

I tried it with the program itself and the batch file that I like to use.

Settings are set to the frame size of the project such as 1920x1080, None (progressive scan), Pixel aspect ratio:1.0000, Video format: Sony YUV Codec, Interleave 0.250 and Create an OpenDML (AVI version 2.0) compatible file is checked.

Audio is PCM Uncompressed, 48,000 Hz, 16 Bit, Stereo, Sample rate 48,000, Bit depth 16 and stereo

Project is Best

Note: Tutorials on Vimeo show audio as 44,100 but Vimeo now suggests 48,000. The tutorials are out of date with that.

In HandBrake I just started setting the average bit rate for the video to 3000 kb/s because the videos including the morning and evening Church services are usually more than 3 hours long and if I use 5000 kb/s or more I will exceed the 5 gig weekly limit on Vimeo.

Videos are 1280x720p

The quality is not the absolute best but it is not bad either. I was using 2000 kb/s but that was not quite up to par. I will need to replace the current videos with the updated files.

I hope all of this helps.

https://vimeo.com/channels/cocccm

rraud wrote on 6/7/2013, 10:00 AM

I was just stating that a MXF file will work in HB. I normally use DNxHD as a intermediary file.

musicvid10 wrote on 6/8/2013, 8:56 AM

Quite a while back, I tested a number of potential intermediate codecs in Handbrake, to see what would be accepted.

The ones that were not accepted by Handbrake at that time were:
-- Mainconcept MPEG-1 (just curious)
-- JPEG 2000
-- Cineform
-- Matrox "Uncompressed"
-- Lagarith RGB

The following codecs would have placed in the top four, had it not been for the issues noted:
-- Helix I420 had an interlace bug in Handbrake, requiring a custom setting
-- Sony MXF had the mono audio bug already mentioned

Everything else came out pretty much as expected, with Sony YUV at the top of the compressed codecs for chart reproduction, and DNxHD second. Although render times were nearly the same, the Sony YUV files were ~7x larger than DNxHD 8-bit.

It is important to note that Handbrake handles RGB and YUV source differently, so it is important to give it the appropriate levels going in; 0-255 for RGB, and 16-235 YUV. Also check the output levels, as there are bound to be a few "surprises."

Disclaimer: These tests were run quite a while back, and as libav in Handbrake and codecs themselves have continued to evolve, the results might be different today. As an example, libav now decodes 10-bit DNxHD, which probably makes it nearly indistinguishable from 10-bit Sony YUV as an intermediate source (Handbrake output is still of course 8-bit 4:2:0).

If one doesn't mind gargantuan file sizes, I later ran another set of tests, comparing only lossless RGB codecs for render times and file size.
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=769574

I would love to see someone run their own set of updated tests; we might just come up with another "gem" of an intermediate.

VidMus wrote on 6/8/2013, 9:41 AM

I am using the 8 bit Sony YUV simply because it renders faster than the 10 bit version does.

I do make sure that I am sending it 16-235. My Sony cams (all of them) are originally 16-255 so I use Sony levels to correct that. Makes the sky a prettier blue on outdoor scenes.

I wish 0-255 were the norm just for the sake of a little bit more dynamic range.

Note I can use MC *.m2t but the final video is not what it should be. It is a bit darker. The *.m2t will render faster though. HandBrake will also render it faster to mp4.

I will stick with Sony 8 bit YUV for now.

All that work to get the best video only to have to reduce the quality with a lower bit rate to overcome Vimeo's 5 gig a week limit. Sunday morning and evening videos can be quite long so I have to compromise somewhere. I am using --vb 3000 kb/s in my batch file. I prefer to use a batch file with HandBrakeCLI instead of HandBrake itself.

https://vimeo.com/channels/cocccm

musicvid10 wrote on 6/8/2013, 9:48 AM

VidMus,
That will work. Your choice is at the top of 8 bit compressed codecs for quality, and nearly as good as uncompressed, save for chroma subsampling.

An interesting question that has been on the back burner for some time is whether banding is best controlled by rendering an 8 bit intermediate in Vegas, such as you are doing, or rendering a 10 bit intermediate, and letting Handbrake do the downsampling.

A fairly easy test to set up, I would imagine, using a gradient created in Photoshop, and the Sony YUV encoders. Maybe I'll try it later this weekend.

As is stated often on the internet, Rule #1 of video encoding remains:

"Quality, Size, Speed. Pick two."

[EDIT] Starting with a 32 bit project in Vegas, a 10-bit intermediate gives less banding in Handbrake than an 8 bit intermediate. The banding would be noticeable on a gradient background or sensitive grading. I'll start a new thread so as not to hijack this one more than I already have.