Hi

You are very kind thanks it works great

So now I wonder what settings I need to smart remder the files from new blue upshift?

Though now I can use vegas to re endode to mpeg 2 over night just use batch render

I never could smart-render NewBlueFX UpShift mpeg2 files. I don't think you can.

I've been unable to smart render MainConcept Mpeg2 [at least not at any bitrate that makes an acceptably high-quality intermediate file] I pulled an all nighter last night [couldn't sleep] and performed a bunch of side-by-side conversions of H264 encoded mp4s into various smart-renderable formats. I blogged about it.

I've been unable to smart render MainConcept Mpeg2 [at least not at any bitrate that makes an acceptably high-quality intermediate file]

???

Just smartrendered some Max/Avg/Min 80/60/20 Mbps Main Concept Mpeg2 (made by the recipe above) and it worked flawlessly - or do you need higher bit rates?

At even 35 Mbps many dlna players and dlna TV-sets that I know of have problems playing it, so I mostly use Max 31 Mbps and AVG 28 Mbps - which actually seems to deliver video originally recorded as AVCHD 1920x1080 50i at 24-25 Mbps in a quite satisfying quality on a 58" Plasma.

One thing I forgot to mention; If you choose a variable bitrate for the first render, change it to constant for the second render. No idea why this makes a difference, but it does here in 'Arthur Land'. :-)

Kindof strange: In 'Ritsmer land' I use variable bitrate only - all the time.

Must be something to do with jet lag ritsmer :-)

Those are precisely the VBR parameters that I used with MainConcept, only I didn't create a Blu-ray derivative, or render separate elementary streams. I'll have to try that out. Thanks.

It was uncheck Save as separate elementary streams.

Pls let us hear your results.

So I've unchecked the save as separate elementary streams option, added the highest bitrate audio possible, and used the VBR settings as suggested. I'm not sure what's wrong, but the final render is terrible. Totally unusable. Macroblocking of skin tones.

So I went to 422 profile. Same thing. Then I made sure that MainConcept was rendering to square pixels. Same thing. Then I changed it from a transport stream [m2t] to a program [mpg]. Same thing.

I'm not sure how many more times I'm willing to let MainConcept disappoint me here...

EDIT: In the meantime, my recommendation to use Sony's HDMXF 422 still stands.

"I'm not sure what's wrong, but the final render is terrible. Totally unusable. Macroblocking of skin tones."

This is unheard of in my Pro 8. Tried it with GPU off?
20 Mbps minimum should be plenty to prevent that kind of blocking in fades, shadows, and movement, but trying it higher won't hurt anything.

Although everyone knows what you mean by "macroblocking," its technical usage is somewhat different, as in dct encoding boundaries.
I know, I've done it too . . .
;?)

Thank you for the correction. Pixelation and other jaggies are present as compression artifacts, but particularly noticeable in the skin tones :) Regardless, a flaw by any name is unacceptable.

I haven't wanted to render with GPU assist turned off: I'm baking in color correction, a little sharpening, and stereoscopic alignment so that the final render is faster. [I'm just chalking up the initial render to "Ingest" time as a day's-worth of shooting can be processed overnight]. As it is HD MXF does render with GPU acceleration, to great results.

I'd be willing to try MainConcept again without GPU acceleration if it was a reasonable turnaround for the quality, but after just a quick 1 minute test, the render time for my test media is more than 10 times the GPU-accelerated Sony HD MXF 422 setting- without promising much better quality.

I simply can't justify a week-long render to get access to usable intermediates. Then again, I haven't been able to render to HDCAM SR either, and a 37 minutes timeline took 80 hours to render for DNxHD, so this could all be an issue of my system only playing nicely with a small subset of available codecs/wrappers.

I see you're using a quad, albeit an older one.
Still, without actually seeing your projects, the times you are reporting may border on the atypical.

If you are rendering to external drives, overheating can be an issue, as all drives throttle back periodically to cool themselves down. This alone can put your render times into days, instead of hours.

Yeah, I do a stable overclock when needed [3.25 GHz]- and this particular quad has been shown to perform exactly like the equivalent Phenom II for video encoding at the same clock speed, so it was an awesome value when I bought it, and just gets better with each year that GPGPU solutions like CUDA and OpenCL become more prevalent.

I/O bottleneck? Not a chance. Renders of this length and computational intensity aren't remotely I/O bound. And if the internal HDDs are running that hot during such a slow data transfer, a timely render is the least worrisome outcome; more like an untimely system failure.

After a little more tinkering around, I finally found a setting for MC that got the sharpness right, but slaughtered the chroma:

MC 422 60 Mbps VBR:

Aaaand here's the Sony HD MXF 422 difference composite, [and the file weighs in at only 2/3rds the size of the MC render above]:


Night, meet Day.

A subsequent attempt at smart render confirmed the previous result: for whatever reason, MainConcept will not smart render on my system [but Matrox will somehow]. Still scratching my head.

I do think you're overthinking the situation [EDIT].

But do let us know what you come up with. The MainConcept MPEG-2 encoder has proven to be stable, reliable, and predictable over its long history in Vegas. And smart rendering in this codec is rather straightforward. The things you're reporting are unusual, if not unique to your system, workflow hierarchy, and individual perspective.

As for Matrox, an alternative you have mentioned several times, I gave up on that set of codecs long ago because of inferior reproduction and performance on my system, using both actual footage, and a stable reference (BelleNuit).
Go figure.

One affordable alternative that compares favorably to MC is TMPGENC. Maybe that's going to be a better solution for you.

Um... thanks?

You're welcome, but do keep us posted, OK?

"One thing I forgot to mention; If you choose a variable bitrate for the first render, change it to constant for the second render. No idea why this makes a difference, but it does here in 'Arthur Land'. :-)"

"Arthur land" should be called "La La land". Quoted the above from memory - dangerous at my age. What I meant was; If you use a 2 pass variable setting, UNTICK the 2 pass box for the smart render. Doooohhhhh!!!

A sign of great and ever unfading intelligence that you remember such things after so many days ... :-))