From Vegas to DVD - Another Way.

VidMus wrote on 9/1/2014, 9:13 AM

Using a variation of Vegas to HandBrake, one can get much higher quality DVD results.

This assumes you setup Vegas to HandBrake.

(1) Create project in the normal way. I save the chapter markers to a file with Ultimate S Pro (4.1.8). If you have another way to save the chapter markers, use it instead.

(2) Click on the checkmark for Send2HandBrake.

(3) In HandBrake (I am using version 0.9.9.5530) set the size to 720 for width and 480 for height. It is important not to keep the aspect ratio. I will explain more later.

(4) A check next to 'Large File Size'. No check next to 'Web Optimized'.

(5) In audio I have the bit rate set for 384 for the best quality sound it will give me.

(6) I am using 'Constant Quality' with a setting of 5. This gives a reasonably large file but not way too large and helps prevent degradation of the video especially in the darker areas.

(7) I have the destination folder set in the options so I know where the file is going to be.

(8) I then start HandBrake and find something to do while waiting. LOL!

(9) When HandBrake is done, I start a new Vegas project using the *.mp4 file.

(10) I use Ultimate S Pro to load the chapter markers.

(11) I then render for DVDA with widescreen settings. Vegas will convert the square pixels to rectangular pixels to give the proper aspect ratio. Vegas does not resize the video at all! It simply converts the pixels. This way Vegas cannot make a mess of things with its terrible resizing. The video preview will still show the video as it is but the render is changing it correctly.

(12) Finish up in DVDA.

There are other ways to get the best results, but why settle for the garbage that MC renders?

Note: Before I could get the Vegas to HandBrake to work for me, I was rendering to an *.avi intermediate before using HandBrake. I no longer need to do that.

Comments

Former user wrote on 9/1/2014, 9:21 AM

I find that MC does not do well when trying to resize and render to an MPEG at the same time. I generally render to an uncompressed file to resize first and then render to mpeg.

Pretty much the same thing you are doing except you are using a highly compressed intermediate.

By the way, Vegas does not "convert" the pixels, there is a flag that is set so the DVD player knows what aspect to display.

VidMus wrote on 9/1/2014, 9:33 AM

"By the way, Vegas does not "convert" the pixels, there is a flag that is set so the DVD player knows what aspect to display."

Thanks for the correction. It has been a long while since I have looked at that info.

All the better because Vegas is not doing any resizing.

I am using a highly compressed video but it is still very high quality. The visual quality, details and sharpness are all still there. Note: Visual quality...

I no longer need to use a ton of drive space for an uncompressed file and the time it all takes is much less.

So I would say that this is a very good trade-off.

musicvid10 wrote on 9/1/2014, 9:38 AM

I have a refined workflow for doing the resizing and decomb in Handbrake, using lossless or near-lossless compression. Bypassing Vegas for HD->SD is a noble goal, but introducing another layer of lossy compression is not.

I will publish the workflow for HD to DVD using a Handbrake intermediate in this thread, but can't promise when, as fall is my busiest time.

Former user wrote on 9/1/2014, 9:46 AM

actually, you will find that rendering to an uncompressed file takes a lot less time. Do a test and you will see. OF course, you do end up with large files, but I consider these temporary and delete them when I am done. Vegas is very good at resizing. Just not resizing and compressing at the same time.

johnmeyer wrote on 9/1/2014, 9:50 AM

I had to read your workflow several times to understand what problem you are trying to solve. You are still encoding using the MainConcept MPEG-2 encoder in Vegas, so you aren't overcoming any limitations in that part of the workflow. Instead, it sounds like you are simply trying to use a different re-sizing algorithm than the one used in Vegas.

Am I correct?

If so, I would instead use an intermediate rather than final delivery codec. MP4, even at high bitrates, seems like a poor quality choice, and since the point of the exercise is to improve quality, this seems like an unnecessary compromise. Cineform is free if you download the free GoPro editing program from their web site.

If you want, you can skip all the intermediate stuff completely by frameserving out of Vegas (using the Debugmode Frameserver). Put that into a simple AVISynth re-size script (Nick Hope and I have posted many of these). Then, use the VFAPIConv tool to convert the AVS script into an AVI file that Vegas can read. Open a second instance of Vegas, put that AVI on the timeline, and render. Before you render, you can copy/paste your markers from the first instance of Vegas so that those get embedded into the MPEG-2 file.

By doing it this way, you avoid that terribly long wait creating the MP4 file; you avoid the quality degradation of going through a very lossy compression process; and you use exactly 0 bytes of disk space, since no intermediate is created at all. All in all, this should save you several hours when creating a 1-2 hour DVD.

I can create a short tutorial if you'd like.

Marco. wrote on 9/1/2014, 9:59 AM

This is similar to what I do with a quite modified version of Vegas2HandBrake. In same automated way I click onto another toolbar icon and thus let the project go its way through AviSynth to do a Lanczos 3 (or Lanczos 4) resize, file mount and then let another Vegas instance automatically open the resized file. Just one mouse-click. You could also make a version which feeds DVD Architect directly (and let DVD-A do the encoding).

Downside is there is another issue arising. When the new Vegas instance opens it takes forever to build the audio peak files.

johnmeyer wrote on 9/1/2014, 10:26 AM

Downside is there is another issue arising. When the new Vegas instance opens it takes forever to build the audio peak files. These are not needed for rendering. Just click on the "Cancel" button in the lower left corner of the Vegas display, or disable building peaks in the preferences.

Marco. wrote on 9/1/2014, 10:46 AM

Yes, these are the workaround I use for it (I disable building peaks for this certain process). I only wish I could find the reason why this extremely slowed down peak building happens and maybe how to avoid it from the base. Not sure if the FrameServer or the file mount causes it.

johnmeyer wrote on 9/1/2014, 1:23 PM

I just created a tutorial for how to completely eliminate the need for intermediate files when using AVISynth scripts with Vegas. Here is a link to the separate thread where I have posted that tutorial:

Tutorial: Vegas --> AVISynth --> Vegas

VidMus wrote on 9/1/2014, 2:13 PM

"Instead, it sounds like you are simply trying to use a different re-sizing algorithm than the one used in Vegas.

Am I correct?"

You are 100% correct!

Amazing thing is that the mp4 method I posted here gives surprisingly excellent results but I am 100% open to a better method.

The best way I can think of is that SCS would do it themselves and fix this nonsense once and for all!

The name is Vegas Pro and yet we have amateur ways to render a video to DVD. At least what is built into Vegas Pro! That is 100% nonsense!

johnmeyer wrote on 9/1/2014, 2:26 PM

The name is Vegas Pro and yet we have amateur ways to render a video to DVD. Yup. It's a pity.

musicvid10 wrote on 9/1/2014, 3:37 PM

I don't mean to rain on anyone's parade, but if it's ONLY downscaling I am after, I just use Vegas, which is very similar to Photoshop bicubic. Keep the min. bitrate at 2,000,000 in the mpeg-2 render, and it will be fine, and go faster.

It is downscaling + deinterlacing that Vegas isn't as good at. For this, both Handbrake and Avisynth are worthy solutions, but they are not the same. It has been proven to my satisfaction that the Nick / John methods are better than HB, but s-l-o-w on a dual core. OTOH, avchd processed (correctly) through Handbrake looks really good!

I'm glad we've got everyone talking here (I suspect Nick is lurking around the corner), because we represent three distinct workflows to create the same result, HD to DVD.

For production, the big questions all boil down to speed (don't they always). Given comparable results, whether one uses an intermediate, frameserves to Avisynth, or to Handbrake, comparing our net encoding times to Vegas->Mainconcept seems to be the most inert benchmark. For SD quality comparisons, PSNR is good enough.

This is totally the wrong time of year for me to get bogged down in another set of tests, which I'll probably never completely finish, but I think with the collective brainpower already participating (add Nick, Laurence, and Jerry too), we can come up with a streamlined workflow.

-- I wouldn't use Lanczos 4 for video resizing because of piping and possibly more blown pixels than Lanczos 3..

musicvid10 wrote on 9/1/2014, 3:56 PM

"

All that proves is that the best video solutions still begin life as open source.

VidMus wrote on 9/1/2014, 3:58 PM

"I don't mean to rain on anyone's parade, but if it's ONLY downscaling one is after, just use Vegas, which is very similar to Photoshop bicubic. Keep the min. bitrate at 2,000,000 in the mpeg-2 render, and it will be fine, and go faster."

On a recent BIG project using 100% progressive videos I did just that and it was garbage! A room divider in the scene had a lot of wiggly lines in it with even the slightest motion. I used my other way and it was as clean as it can possibly be.

When all of the performers were on stage, it was an ugly mess of those wiggly lines. All from 100% progressive videos!

So no, it was not fine and it was not acceptable at all.

musicvid10 wrote on 9/1/2014, 4:06 PM

"A room divider in the scene had a lot of wiggly lines in it with even the slightest motion."

That's not a result of using Vegas' bicubic resizing algorithm.

-- If the footage is interlaced, a project deinterlace method must be chosen. It's fine to leave it at interpolate all the time.

-- The render quality must be set at Best any time resizing is going on in Vegas. Both are necessary to ensure no squiggles, and that's how my default project properties are set.

"Good uses bilinear scaling without integration, while Best uses bicubic scaling with integration. If you're using high-resolution stills (or video) that will be scaled down to the final output size, choosing Best can prevent artifacts."

-- The one situation I would us Lanczos 3 is if there is moire in the output that isn't in the original. In that case, it's worth the extra effort.

Former user wrote on 9/1/2014, 4:06 PM

I would really be curious what the differences are. I downscale in Vegas (interlace to interlace) all of the time and it looks fine. I have not found a better way (I haven't used handbrake) except maybe Vdub, but even still I find Vegas quality is fine.

musicvid10 wrote on 9/1/2014, 4:33 PM

Handbrake doesn't render interlaced, without forcing a minor hack. The combination of deinterlacers used in Handbrake is what makes it unique.

farss wrote on 9/1/2014, 5:04 PM

[I]"On a recent BIG project using 100% progressive videos I did just that and it was garbage! A room divider in the scene had a lot of wiggly lines in it with even the slightest motion. I used my other way and it was as clean as it can possibly be."[/I]

Downscaling progressive to interlaced is always problematic, heaps of posts about this over the years. This is not a problem unique to Vegas either, I see a lot of the same problems in OTA video.

Bob.

VidMus wrote on 9/1/2014, 6:28 PM

As I said, the videos are 100% progressive!!! I am NOT using interlaced, I am NOT rendering from progressive to interlaced!

IF this problem were not the fault of Vegas then how do you explain the fact that my workflow while it is not ideal, it does 100% eliminates this problem?

All I know is that I got the best DVD video EVER using this workflow and that is all I care about!

Thanks much for your replies and all...

musicvid10 wrote on 9/1/2014, 7:07 PM

VidMus,
Sorry, we ferreted this one out over a decade ago. It doesn't matter whether the video is interlaced or progressive.
Good = bilinear = squiggles.
BEST = bicubic = no squiggles.
It works fine most of the time with PROGRESSIVE footage such as yours, and takes less time.

Now, I have already experimented with lossless and near-lossless intermediates in Handbrake, when both interlace and downscaling must be addressed. I can confirm that your workflow is valid, and I believe I have something to offer. But for the life of me, I truly don't understand all the drama . . .

VidMus wrote on 9/1/2014, 7:30 PM

"BEST = bicubic = no squiggles."

I used 'best' and I did get the squiggles. That is why I looked for a different workflow.

Maybe there is something that does not like my 60p videos?

musicvid10 wrote on 9/1/2014, 7:37 PM

Post some camera samples and we'll find out.
Unable to reproduce squiggles using my 60p.

OldSmoke wrote on 9/1/2014, 8:32 PM

I mentioned a similar workflow but without frame-serving in this thread http://www.sonycreativesoftware.com/forums/ShowMessage.asp?Forum=4&MessageID=902624 and got shot down too. In fact, I think I mentioned it even a month earlier in another thread but I cant find it right now. Anyway, I have been using the intermediate to HB and now the frame-serving solution and the results speak for themselves. Like VidMus, I had issues with 1080 60p footage from my GH30 and eventually came up with the idea to use HB to downsize the HD footage to DVD format and the results are just simply better.

musicvid10 wrote on 9/1/2014, 10:07 PM

Well, reading that thread again, at least my feelings have remained consistent on the subject.

There is nothing intrinsically wrong about doing downscaling-only of progressive footage in Handbrake, as long as lossy recompression is kept under control, and one has the extra time to spend. I still can't see enough difference to get excited about it, especially not in a production workflow.

Decomb is Handbrake's strong suit; I would use it for that or to suppress moire, and as I mentioned, the "Nick and John" methods in Avisynth do it even better.