The MXF container's audio is not compatible with Handbrake. Instead of a single stereo stream, you get two separate mono streams. Handbrake can't merge them, or blend in a separate audio file.

"See, this is actually what I'd like to know - exactly what x264 settings these online delivery services are using for 720p encodes. At least then I'd be in the same "compatibility" boat as them, but I've done a LOT of web searches and that information seems a closely guarded secret."

Most of the relevant information can be gleaned by taking a look at the streamed files. For instance, Vimeo is currently delivering:

>The MXF container's audio is not compatible with Handbrake. Instead of a single stereo stream, you get two separate mono streams. Handbrake can't merge them, or blend in a separate audio file.

That's not my experience. I use .mxf with Handbrake regularly and it always works fine. Both the video and audio are as they should be in the Handbrake render. I wonder why your results are different.

I've never had any problem with MXF audio in Handbrake either, although I prefer DNxHD as my intermediate, since I am not smart-rendering HDV, but starting with AVC (AVCHD to MPEG-2 MXF pretty much sucks).

Using Vegas Pro 8.0c and Handbrake 0.9.4, 0.9.5

I use DNxHD often as well, especially if I'm mixing cameras or was off in my exposure or white balance on the HDV camera. Having options is a good thing. I wish Handbrake could take in Cineform avi.

I, too, have never been able to get stereo when going the .MXF > Handbrake route. In any case, I prefer mono, so I always render a mono .WAV in Vegas before the .MXF render. Then I set the Handbrake audio to mono - all then works great for mono .MP4s.

But the day might come when I'd like stereo; if someone can tell me how?

Sony seems to encapsulate each channel as a separate audio stream, so you end up with two mono streams. You can pick one, and Handbracke will re-encde it as 2.0 mono, but you can't pick both and get proper stereo.

If all you want is mono in the first place, then it's fine.

Weird. I get both left and right audio tracks. Tell me, did you ever install the .mxf viewer utility called "PDZ-VX10"? It is an outstanding viewer for .mxf clips. It deinterlaces on the fly and also corrects the sRGB to cRGB. It uses the graphics card so it only looks good on computers with graphics cards that go beyond integrated graphics, and even then you have to go into the preferences and enable the GPU acceleration in order to see the magic. Mxf video played back with this utility looks spectacular. Anyway, maybe when I installed that, it installed some sort of codec that explains the difference in our experiences. The PDZ-VX10 software is free and can be found here:

https://www.servicesplus.sel.sony.com/sony-software-model-PDZVX10.aspx

The MXF container is designed to handle up to 8 channel audio, so I think it's storing it in a linear format regardless of how many channels you use. I think it's being stored like 7.1 or 5.1 normally is, instead of old-fashioned stereo.

I installed the viewer. Playing back the files with stereo audio is no problem, the issue is how Handbrake sees the audio for re-encoding.

Top is MXF, bottom is XDCAM EX MP4.


Essentially I can pick whether I want the left or right channel, but not both.

You have essentially three options:

1) Encode to DNxHD, which is visually lossless and does not exhibit this strange behavior;

2) Demux and Remux the audio, using any of a number of third-party utilities; or,

2) Contact Handbrake support, while including the stable / nightly build number of the version you are using.

Again, best of luck to you.

Ah, now I see what you're talking about. Yeah, I've been encoding just one of the audio tracks and didn't notice it. Darn. I guess I have to use DNxHD after all.

Seems to be some issues using DNxHD with HDV original video. I select 1440x1080 1.33:1 interlaced in Vegas, and then the 1080i 8-bit 145 DNxHD profile.

What I end up with is 1920x1080 video that programs want to play back as 1440x1080. Does DNxHD not support true 1440x1080 resolution?

Edit... scratch that... looks like the -TR option should do proper 1440x1080. They really now know to create plain-english labels...

Edit 2... scratch that scratch. I can get proper 1440x1080 only by using the -TR open in DNxHD, but Handbrake can't open those files! Neither can VLC (which can open the non-TR encodes).

So my choices seem to be:

1. Smart render to M2T and suffer lower quality on re-rendered bits (an actual visible drop)

2. Render to DNxHD and have Vegas resize my frames to 1920x1080 (not great because Handbrake has very good resizing - unless someone has done some tests on this)

3. Smart render to MXF and live with mono sound (not going to happen)

4. Smart render to XDCAM EX @ 25mbit and get visual corruption (not going to happen)

5. Re-render to XDCAM EX @ 35Mbit and suffer generational loss (although I would imagine this is minimal versus the bits that have to be re-rendered anyways)

6. Render to some uncompressed codec (projects aren't important enough to waste hundreds of gigabytes of disk space)

7. Deal with complicated re-muxing (not going to happen - I'm trying to make my life easier, not harder)

This is like a comedy of errors. Every time I figure I've got the perfect solution, something happens that completely wrecks it.

For now, I'm thinking #5 is the best option.

Option 8 ;)

"Edit 2... scratch that scratch. I can get proper 1440x1080 only by using the -TR open in DNxHD, but Handbrake can't open those files! Neither can VLC (which can open the non-TR encodes)."
You are covering already-charted territory. Search the forums if in doubt.

"2. Render to DNxHD and have Vegas resize my frames to 1920x1080 (not great because Handbrake has very good resizing - unless someone has done some tests on this)"
What better option would you suggest for a format that insists on 1:1 PAR?

'6. Render to some uncompressed codec (projects aren't important enough to waste hundreds of gigabytes of disk space)"
Agreed. In addition to that include the REC 601/709 colorspace error that has been well-documented in both the Vegas and Handbrake forums in your absence . . .

"7. Deal with complicated re-muxing (not going to happen - I'm trying to make my life easier, not harder)"
It is you, not us who seem to be determined to make your life harder; by comparison, muxing (demuxing + remuxing) is a relatively easy process, although you are among the uninitiated.

"This is like a comedy of errors. Every time I figure I've got the perfect solution, something happens that completely wrecks it."
That again, is entirely the result of inexperience, and not aptitude. If you will but follow the results of those who have gone before you, most of your questions will be answered. Although I rarely recommend this thread to newcomers, I think it will be of particular interest to you . . .
http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=748190

A comedy of errors? Not if you are willing to consider the substantial research of those who have gone before you (unless you are a teenager, of course!).

;?)

What better option would you suggest for a format that insists on 1:1 PAR?

Do you mean DNxHD or Quicktime? Because I don't agree that either actually requires 1:1 PAR. It seems to me that normal DNxHD is simply hard set to 1920x1080 as the encoding resolution, regardless of the incoming frame size.

What it DOES do is correctly set the PAR so that when played back, the 1920x1080 encode correctly reflects whatever the original resolution was. So a 1440 file (regardless of PAR) encoded to 1920, plays back as 1440. It may ignore the incoming PAR, but the fact that it sets any sort of PAR after the fact leads me to believe that there's an encoding resolution limitation, not a 1:1 PAR limitation. I guess there's some huge technical reason why 1440x1080 1:1 encodes are completely impossible, but 1920x1080 1:1 encodes are fine!

What's sad is that my issues seem to be related to bugs and manufactured limitations.

Why should XDCAM corrupt in smart render mode?
Why should DNxHD not accept 1440x1080?
Why should Handbrake accept DNxHD but not DNxHD-TR?
Why should MXF format only render to 2 separate mono streams and not normal stereo?
Why should M2T produce lower quality MPEG2 than MXF or XDCAM with the same settings?
Why should my workflow have to involve frameservers, processors, encoders and muxers for a tiny quality improvement when there *could* have be much easier solutions had any of the more automated possibilities that should have worked, actually did?

If I wasn't laughing, I'd be crying.

I'm not actually looking for answers to the above; I'll assume for now that someone before me already noticed these things and figured everything out, and if I just look hard enough I'll find that answer... however so far I have struck out with the search engine on most, and will just continue to blunder along blindly.

The only saving grace is that I have figured out enough that my videos look better than they did last week.

"Do you mean DNxHD or Quicktime?"
BOTH!!

As far as I can tell, all of your "Why's" can all be addressed by doing a search of these forums.

But best of luck to you.

I'm sad that you're "done", however - and please excuse my ignorance - a Pixel Aspect Ratio of 1:1 implies that the pixel is perfectly square. Quicktime's requirement of 1:1 pixel aspect ratio would then imply that it is incapable of displaying videos with pixels that are not perfectly square (ie. any video that actually had them would look squished or stretched).

Then why does a 1920x1080 16x9 file encoded in DNxHD display as squished 4x3 in Quicktime? Does that not imply a PAR other than 1:1?

"a Pixel Aspect Ratio of 1:1 implies that the pixel is perfectly square. Quicktime's requirement of 1:1 pixel aspect ratio would then imply that it is incapable of displaying videos with pixels that are not perfectly square (ie. any video that actually had them would look squished or stretched)."

That is correct. Again, with deference to your inexperience, best of luck.

Why should my workflow have to involve frameservers, processors, encoders and muxers for a tiny quality improvement when there *could* have be much easier solutions had any of the more automated possibilities that should have worked, actually did?

The ideal automated solution is improved deinterlacing, resizing and encoding from Vegas itself. If you're not happy with its output then please tell SCS in a feature request. In the meantime, frameserving is the epitome of an automated workaround.

In view of your frustrations with XDCAM, MXF and DNxHD, I suggest you take a deep breath and a large chill pill then work steadily through my guide that I linked in option 8 above. It probably looks more daunting than it actually is, and it gives you an "automated" route that avoids most of the problems you have encountered.

You could still use MXF for archving, if you wish, so that you get better quality "dumb-rendering", and in the future, if you need true stereo and not 2 mono streams, or need to write back to HDV tape, then you should be able to smart-render the whole thing back to m2t and still enjoy the higher quality dumb-rendering that the MXF render gave you.

That workflow is not really any good for batch-rendering though.

I apologize, because I think my inexperience has finally got the better of me. I'm completely lost and don't even know what DNxHD is producing at this point from 1440x1080 input, because half the programs I use report the resolution as 1920x1080, and the other half report it as 1440x1080.

Top left is Quicktime Movie Inspector. Top right is Vegas. Bottom left Handbrake. Bottom right is ACDSee Pro.



I know you think I must be cheating and using multiple files, but I'm not. Either it's making a 1920x1080 file with a 0.75 PAR - which has been bashed into my head tonight is impossible - or it's making a 1440x1080 file that is for some reason reporting as 1920x1080 in some programs, implying a 1.33 PAR that never ends up being honored.

In the mean time I am currently analyzing the quality difference between 1440x1080 XDCAM @ 35mbit, and DNxHD forced 1920x1080.

Edit: Results: DNxHD by a mile. Definitely worth the time for the image improvement, even if I have to live with some horizontal resampling.

Nick: interesting suggestion. Smart-render to MXF, and then take the MXF and smart-render to M2T. Seems like a good solution for archival (since these DNxHD files are really too big).