Comments

Steve Grisetti wrote on 7/17/2009, 8:55 AM
Can you tell us more about your workflow?

What are your source files and where did they come from? (What type of camcorder? Were they output from Vegas?)

How much free, defragmented space is left on your hard drive? Are you working off your C drive or a second hard drive?

Finally, have you ensured that you have all of the latest updates to your operating system and that you have installed the latest version of Quicktime (which is essential to all media work on both Macs and PCs).
jcloninger wrote on 7/17/2009, 9:06 AM
Hey Steve... everything up to date and I have seperate hard drive for each step System>Capture>Render>Author etc...

I authored 2 discs yesterday and 3 more day before that... never had a problem before... nothing has changed.

Capture and edit HDV from Canon XH-A1 cams in Vegas 9. Render to the Sony AVC 15mbps template without any changes to template... also render ac3 audio from vegas...

DVDA 5.0b Bluray AVC 1440x1080 60i project....

Stuff I find on the net and even SCS help (suggestions before sending inquiry) says probably over the bitrate... NO files are over bitrate...
musicvid10 wrote on 7/17/2009, 9:32 AM
Turn down your burning speed.
Close all unnecessary background operations and stay off the internet while burning.
Use the best media possible.
Make sure your burner firmware is up to date.
If that doesn't work, test with files created at a lower bitrate.

A buffer underflow occurs when your computer can't keep up with providing the data that is being requested by the burner. Not a mystery at all.
jcloninger wrote on 7/17/2009, 9:39 AM
It is during the authoring stage... NOT burning.

FYI, I just changed project to MPG2 and rendered the assets from Vegas' MPG2 blu-ray template which gives a m2v, it works... I wonder if the whole project (5 minutes in length) is too short for AVC? Only thing I can think of.
Lou van Wijhe wrote on 7/17/2009, 1:39 PM
Lots of people have this problem. There's nothing wrong with your procedure, it's a bug, supposedly in DVDA. Sony says the solution is to recompress the footage once more in DVDA which of course is ridiculous.

Lou
Lou van Wijhe wrote on 7/22/2009, 7:02 AM
I just downloaded the new Vegas version 9.0a in the hope that it might have a solution for the bug described in this thread too. I did a test render in 9.0a, loaded it in DVDA 5.0b but got the same error. In the Optimize Disk function DVDA says everything is OK and when starting to prepare to a specified folder, DVDA crashes again with the said error message.

In the release notes of DVDA 5.0b SCS said:

QUOTE
When using media that was rendered outside of DVD Architect, video buffer underflow errors can occur during project preparation if portions of a video stream exceed the project's bit rate. You can use the Optimize Disc dialog to force recompression (re-encoding) of the media file, and the project will prepare without error.
UNQUOTE

If "rendered outside of DVD Architect" also means "rendered in Vegas" then Vegas and DVDA shouldn't be sold as a compatible bundle.

And the error not only happens "when portions of a video stream exceed the project's bit rate", it also happens when the bit rate is well within the project's bit rate.

I'm not impressed with the long list of fixes in 9.0a if SCS doesn't also succeed in putting this very essential function right.

Lou
Lou van Wijhe wrote on 7/23/2009, 12:35 PM
To check if the error was indeed caused by too high a bitrate, I re-rendered my troublesome AVC project using the Sony 8,000 kbps instead of the 15,000 kbps template. This file was also rejected by DVDA. Looking at the resulting AVC files with a bitrate viewer I saw to my surprise that the bitrates between the two were almost identical:

8k version: AVG 7,523 kbps PEAK 11,909 kbps
15k version: AVG 7,521 kbps PEAK 11,975 kbps

This really is odd. Whatever the cause may be, these bitrates are within the Blu-ray limits and DVDA should process these files normally.

There is no problem when I use files rendered as MPEG-2 but I liked AVC for the smaller file sizes and the same or better image quality.

Lou
David Laine wrote on 7/24/2009, 12:42 PM
Hi

I had this same problem today with DVDA

1st i'm told by Sony that pro9 cannot make an AVCHD DVD that will play on my Pana bd35 told not supported

I then buy a Bluray writer then I found vegas pro 9 cannot smart render my Canon HG 10 files told I must wait an unknown time for a fix but told it is yet another bug

I find I can get my files to smart render in vegas if I put them through cyberlink espresso first

I spend 4 evenings editing the footage of my kittens first month of life then I try to make a Bluray disc with menu (5items) then I get the same error as the first poster in this thread

So I use another programme (freeware) to make a disc

I have never come across software that needed the help of so many other programes to work

Vegas and DVDA really do suck as does sony cust support

Dave
Erik Olson wrote on 7/24/2009, 8:32 PM
I am having the same problems. Spent a week rendering 6mbps AVCHD files in Vegas 9 -- they work great turned into individual AVCHD disks using tsmuxer + imgburn (displays wonderful on my pany bd35k! -- I recommend this as a free solution for avchd disks from vegas-rendered AVCHD files).

But then I went to import them into DVDA for the big blu-ray compilation, and got the same underflows mentioned here. Konran's Bitrate viewer shows a few peaks at ~11mbps.

Some speculation:

1. I wonder if DVDA has a bug that won't accept peaks above 10-12 mbps in this release? This would seem ridiculous, but on the other hand, maybe if it got stuck in "DVD bitrate" limits.

2. One reason for this may be that the footage I rendered consists of slides intercut with video of the presenter, so the bitrate tends to have peaks when flipping to the motion portions. When rendering at higher bitrates, it almost seemed less peaked.

3. I wonder if this was a bug introduced in DVDA 5.0B, and maybe it isn't in 5.0a or 5.0 proper. Will have to try uninstalling and putting in a previous version.

UPDATE: Just as bad in original DVDA 5.0 release. I'm firing up my old Vegas 8.0 system and re-rendering video on the same template to see if that changes things....
Lou van Wijhe wrote on 7/25/2009, 2:23 AM
Erik,

Your speculation #1 is something I thought of too. I have a number of AVC files that are under the 9,800 kbps DVD limit and DVDA processes them happily. One going over it causes this bloody error. It looks as if DVDA defaults to the DVD parameters instead of Blu-ray.

I'm curious how your last experiment will turn out. But it is odd again that we are doing these experiments whereas SCS is in a much better position to do them.

The automatic error reporting in Vegas is a clever thing. They should extend it to DVDA. It might open their eyes.

Lou
Erik Olson wrote on 7/25/2009, 8:39 AM
A-HA! Overnight, I re-rendered the EXACT SAME FOOTAGE using Vegas pro 8.0c, and it passes DVDA just fine. Comparing the Vegas 9 render with the Vegas 8 render on the bitrate viewer, the VP8 render has much less pronounced peaks and valleys -- it reports 8850 kbps as the peak. The VP9 render is much more "all over the place" (as VBR should be, right?) and reports 12382 kbps as its peak.

So while this still seems like a bug in DVDA, it looks to me as though it's been "masked" by earlier versions of Vegas.

But gawd, I don't want to have to go back and re-render 12 hours under SV8 (not to mention all the projects are saved in SV9 format).

I will do one more test and re-render the exact same footage under 9.0a and compare the graphs on the bitrate viewer just to see if they've changed anything. Grr.
Erik Olson wrote on 7/25/2009, 9:12 AM
PS: Any suggestions for a good bitrate viewer? I have been playing with the free one from http://www.winhoros.de/docs/bitrate-viewer/ but I'm not actually sure I trust his absolute numbers. For instance, the 16mbps raw footage from my SR11 shows up as 8mbps, and the footage rendered from Vegas shows up as about 40% of the bitrate it's supposed to. So I wonder if those 12mbps peaks are actually more like 25+ ?
Lou van Wijhe wrote on 7/25/2009, 12:30 PM
AFAIK this is the only bitrate viewer processing AVC files. I know for sure that its MPEG-2 analysis is correct. I'm not sure about AVC.

Nevertheless, when I offer my problematic AVC file to DVDA, the Optimize disk utility puts green OK signs on both the video and audio file, reports the video bitrate as 15,022 and the audio bitrate as 1,534 and reports that no file will be recompressed. What more could you want?

And then DVDA gives this "buffer underflows" error.

Lou
Erik Olson wrote on 7/25/2009, 4:21 PM
I don't think that the bitrate viewer analysis is correct for AVC files. For one thing, the average and length of clip are wrong (which is probably the basic problem). I dug some more and found a 30-day trial of elecard streameye, which seems to be reporting accurately.

So for my SV9-rendered 6mbps file, I get an average of 6.0 mbps and a bit allocation max of 18.0 mbps (and minimum 1.04 mbps). This same file in the bitrate viewer showed 2.5 mbps average, 12.3 mbps as its peak. The render from SV8 showed a max of 14.0 mbps and min of 2.2 mbps.

Interestingly, Elecard also reports High profile, even though the preset said main, but I digress...

It's still clearly less than the 40 mbps allowed by the Blu-Ray spec. So this is definitely a DVDA bug, not a Vegas bug!
Lou van Wijhe wrote on 7/26/2009, 12:38 PM
I offered my troublesome project directly from Vegas to DVDA using Debugmode's frame server and let DVDA do the AVC rendering. Everything turned out fine but this approach doesn't work of course if you have a project with multiple video files. You can't overload your system with multiple instances of Vegas just to circumvent a bug.

By the way, the Debugmode frame server made Vegas unstable. Vegas crashed the first time I used the frame server and after the second, succesful time Vegas crashed whenever I chose another option but the frame server. So I took this plugin off again.

Lou
Lou van Wijhe wrote on 7/27/2009, 6:02 AM
I filed the following bug report with SCS:

QUOTE
Bug: Video Buffer Underflow error during prepare of Blu-ray Disc project #2

This error has been reported before (Answer ID 4293). However, I think the answer you gave doesn't apply in this case.

My source files are in PAL HDV. When in Vegas 9.0a (build 704) I render a project using the Sony AVC Blu-ray 1440x1080-50i, 15 Mbps video stream template and import the resulting AVC file into DVDA, the Optimize disk utility puts green OK signs on both the video and audio file, reports the video bitrate as 15,022 and the audio bitrate as 1,534 (PCM stereo) and reports that no file will be recompressed. However, when I start the Make Blu-ray Disk function, the program crashes and displays this video buffer underflow error.

This doesn't happen with every Vegas generated AVC file I import into DVDA. However, in view of the long rendering time it is annoying enough even if it happens once in a while.

The answer you gave the original poster of this bug isn't satisfactory in this case. After all, Vegas's output should be compatible with DVDA's input and DVDA should process compliant Vegas generated AVC files without problems. The re-rendering in DVDA you suggested is not acceptable.

It might be a good idea to implement the automatic error reporting system as in Vegas in DVDA too instead of waiting for customer bug reports. The reported error is experienced by many users, see a.o. http://www.sonycreativesoftware.com/forums/ShowMessage.asp?MessageID=664984&Replies=15
UNQUOTE

Let's hope something comes out of this.

Lou
Lou van Wijhe wrote on 7/31/2009, 5:23 AM
I'm having some difficulty convincing SCS that the error is NOT caused by too high a bitrate. As soon as I have futher info I'll report it here.

In the meantime I found an easy and cost-effective way to check the bitrate, i.e. with Cyberlink's PowerDVD. Start a media file, right click in the display window and check "Show Information". The program displays the bitrate while playing the file.

I checked my problematic file this way and the bitrate shown hovered around 15000 kbps, which is correct. I have PowerDVD v8.

Lou
Erik Olson wrote on 8/3/2009, 10:57 PM
I've also opened a bug with SCS on this last week. No real progress yet...
plekkie wrote on 8/4/2009, 2:59 PM
Based on discussion on GV Edius forum ref. rendering AVC (.h264) files for Encore and DVDA, I did some trials this evening:

Used Edius BD creator to render BD images with following video encoding settings (all CBR):
Max (=22,8 Mbps), 17 Mbps, 12 Mbps, 10 Mbps, 8 Mbps.

When trying to import the resulting .m2ts file in DVDA to create a BD image with a simple menu and one Title, DVDA freezes already by simply clicking the file. I have therefore demuxed into elementary streams with TSMuxer, and renamed the .264 file to .mp4 (DVDA does not recognise the .264 extension for the video elementary stream created by TSMuxer).

Result:
Only files with Max, 17 and 12 Mbps could be imported in DVDA project. The preview is OK, and according to DVDA the video files are BD compliant. When preparing the BD compilation however, the buffer underflow error message appears. Except for the file rendered with 12 Mbps, with this one the preparation completed in an OK BD disc image.

The files rendered with 10 and 8 Mbps could not be imported in DVDA at all.
Lou van Wijhe wrote on 8/4/2009, 3:20 PM
There definitely is something wrong in DVDA. Even AVC files rendered in Sony's own Vegas Pro cause this underflow error. Sometimes they don't, sometimes they do, so you can't count on it.

I'll ask SCS once more if they can confirm that this as a bug.

Lou
Lou van Wijhe wrote on 8/6/2009, 1:09 AM
At SCS's request I have uploaded a sample file. As soon as I get an answer from them, I'll post it here.

Lou
Erik Olson wrote on 8/6/2009, 9:59 AM
Lucky! I can't get the problem to occur on small sample files. I have to render a significant portion of the entire hour-long projects in order to have it produce the little bitrate spikes that freak out DVDA.
Lou van Wijhe wrote on 8/6/2009, 1:15 PM
Erik,

I sent SCS a 1 minute sample file that already freaked out DVDA. Nevertheless, it was produced by Vegas and should therefore be OK (I do have larger files that were accepted by DVDA, so it is all rather puzzling).

Today I received the following response from SCS:

QUOTE
Thank you for uploading your sample files. We were able to test them and, unfortunately, we did not encounter the 'video buffer underflow' error you had described. Here are the steps we performed, please let me know if you have done something differently.

1: Open the video project in DVD Architect Pro 5.0
2: Go to File > Properties and change the disc format from DVD to Blu-Ray. Then change the Audio format to PCM Stereo. Click Apply and OK.
3: Next, to go File > Optimize Disc. Click on the video title so that it's highlighted, then click on the Video 1 tab (located on the right-hand side of the Optimize Disc screen).
4: Change Recompress from No to Yes. Then change the Use Default Bitrate option from Yes to No. Click OK.
5: Click on the Make Blu-ray Disc button and select Burn > Current Project.
UNQUOTE

I answered as follows:

QUOTE
It’s not surprising that you did not encounter the 'video buffer underflow' error I had described because you inserted an irregular step 4. This step 4 is in fact a workaround that was proposed some time ago by the development team to circumvent problems caused by too high a bitrate, which in my case doesn’t apply. Introducing this step masks the problem.

AVC files rendered by Vegas using the appropriate template should be compliant with DVDA and there should be no need for recompression. When you import my sample files into DVDA you’ll see that DVDA reports them as compliant and sets Recompress to No. So changing it to Yes is illogical. Besides, AVC rendering (compression) is a time consuming process, especially if it needs to be done once more in DVDA, which also lowers the picture quality unnecessarily.

Leave out step 4 and you will recreate the error.
UNQUOTE

Lou
Erik Olson wrote on 8/6/2009, 11:11 PM
The guy on my SCS support thread finally gave me a go-ahead to send them a disk. But perhaps I will wait to hear what they reply to you before I bother burning the BD-ROM with the hour-long source material, resultant avc file, vegas and DVDA projects and detailed instructions.

I get the feeling that once this escalates to an actual dev, this could get fixed quite quickly. But as long as it gets mired in tech support with the thought that a double-recompress is acceptable, this will keep going around in circles.