Build 770 bug: XDCAM EX still won't smart render

Tech Diver wrote on 12/13/2013, 2:08 PM
I really wish XDCAM EX smart render would be fixed, as I often shorten my recorded XDCAM EX clips to save on storage space. In older versions this most definitely worked.

For those who might ask: Yes, I did enable no-recompress long-GOP in the VP preferences, and yes my source files and project are both identical to the rendering template 1920x1080-30p, 35 Mbps VBR. Like I said, this definitely used to work and it is further stated in the documentation that smart rendering is supported.

Peter

Edit: Darn, I wish I could fix the typo on the subject line!!!

Comments

Adam QA SCS wrote on 12/13/2013, 3:42 PM
Peter,

I could not repro this. Please give me more details on what you are doing so that I can possibly be able to repro it.

Thanks,

Adam
Laurence wrote on 12/13/2013, 4:45 PM
Vegas has never smart rendered progressive footage. Not HDV, not SD DV, not Cineform, not XDcam. If it isn't flagged interlaced, it won't smart render. My Z7 has a "30p" option in the interlaced which is 30p flagged as 60i and that will smart render, bot only to a 60i end format, and interlace will be added to any transition that isn't a straight cut. I gave up on smart rendering shortly after I began shooting progressive.
Tech Diver wrote on 12/13/2013, 9:31 PM
Hi Adam,

My footage is from both a JVC GY-HM750 as well as a GY-HM150. That is, they both identical in settings and do not smart render. File format is XDCAM EX .MP4, at 1920x1080-30p recorded at 35 Mbps VBR.

I drag a clip onto the timeline from the explorer tab, and just to be sure, I bring up the project settings and click on the "Match Media Video Settings" icon. I then click on the "Render As" icon and select the "HQ 1920x1080-30p, 35 Mbps VBR" template under the "XDCAM EX (*.MP4)" section. Note that this template does have an "=" sign in front of it confirming it does match the project settings correctly.

The last time that I know that smart render worked was on my system that ran Vista 64 with VP-10e. Now I am running Win 7 64 with VP-12. I tested smart rendering with the exact same clip that had worked a year ago but no longer does. Furthermore, I have two installations of Vegas on Win 7 64 machines and they both exhibit the same behavior.

Your statement that you could not reproduce this implies that it works for you. Have you tried this with footage from one of the JVC cameras? Perhaps there is some minute difference between the clips generated by JVC that is different from your clips. If you wish, I can post a short clip in my DropBox.

Thank you for looking into this matter,
Peter
Marco. wrote on 12/14/2013, 7:07 AM
This is not a bug but actually a bugfix. Smart rendering XDCAM EX was disabled in the latest build to fix a render hang.

"Vegas has never smart rendered progressive footage."

Don't know why this doesn't work for you (except of XDCAM EX as mentioned above). Smartrendering e. g. of HDV progressive worked and still works fine here.
Arthur.S wrote on 12/14/2013, 12:28 PM
+1 has always worked for me too!
Tech Diver wrote on 12/16/2013, 2:00 PM
Before everyone goes off on a tangent, smart rendering works for me too *EXCEPT* for files in the XDCAM EX format.

Peter
Marco. wrote on 12/16/2013, 2:35 PM
As mentioned above: Smart rendering XDCAM EX is disabled now (VP12 build 770) right on purpose.
Tech Diver wrote on 12/16/2013, 3:02 PM
Though that certainly would explain the issue for this particular build, it does not explain why I have not seen it work in any of the VP12 releases that I have tried. In fact, last week I installed 770 (thinking it might work) because 670 also exhibited the problem I described (as did 5xx, 486 and 3xx...)

Peter
ChrisDolan (SCS) wrote on 12/17/2013, 1:28 PM
Marco is right, disabling the EX smart render to fix the hang was my work.

It was a really tough call because it worked right ~90% of the time and hung the other ~10% of the time. What tipped my decision toward disabling was that the way it was built originally was just wrong -- we were using an AVC parser to find the MPEG-2 frames to copy over -- so that 90% success rate was mostly just due to the similarities of MPEG-2 and MPEG-4 bytestreams and a lot of luck. My fear was that the 90% success included a bunch of cases of silently corrupting the bytestream, which is even worse than a hang in my opinion.

I hope to fix it right in the future, but it's going to require tearing out all of the old code and starting over, so getting the new fix on the schedule has been tricky.

Please accept my apologies for removing a feature you relied on, but I felt it was necessary.
Tech Diver wrote on 12/17/2013, 1:43 PM
Hi Chris,

Thank you so much for the explanation, as it is really great to hear the details behind the issue. Now that I understand, I will wait patiently for when it is eventually fixed.

Thanks again,
Peter
videoITguy wrote on 12/17/2013, 2:02 PM
Kudo's to Chris Dolan, he is explaining it like it is. In particular he notes that outcomes of certain choices ( this is like the pharmaceutical industry) in the field can be upto sheer luck of the draw. Sounds awful, but this is very real.
And he well points out, maybe the code has to entirely be ripped out of place, and new way to get there be attempted. I think a lot of forum users from the layman's vantage point, have said so as well in observing the kinds of behavior of the present code base.