HDV bug: Much worse than print to tape bug

johnmeyer wrote on 2/22/2012, 11:31 AM

I just posted this in the VP 11 - cannot print to hdv tape thread, but it is so important I wanted to make sure that everyone was aware of the problem.

Here is the problem in a nutshell: Vegas 11 does not create standard HDV files.

You can see this if you capture some HDV (which still works fine in Vegas 11 64-bit), put this on the timeline, add a title, and then render out the result (I'm using Vegas 11 build 521 64-bit running under Windows 7, 64-bit), using the HDV template that matches the footage (so you get the "=" sign next to the template).

If you put this rendered footage into Mediainfo and compare it to the original footage, you will see that the footage rendered from Vegas is missing all of the standard header information. If you do this same exact test in Vegas 10.0e (64-bit), the rendered file, when put in MediaInfo, looks normal.

Thus, Vegas 11.0 Build 521 (64-bit) is creating non-standard HDV files, and these files "break" print to tape, smart rendering, and goodness knows what else.

If you take any "good" m2t file (such as the one you captured, that hasn't been altered by Vegas) and ask Vegas to print it to tape, it prints to tape just fine, and it smart renders without any problem.

But, if you take any file that has been rendered to HDV by Vegas 11.0 and then attempt to "smart render" it, Vegas will not smart render it because it sees it as being non-standard. Thus, second generation files (files rendered by Vegas 11) cannot be smart rendered. However, smart rendering is not broken either.

So, in conclusion, both the HDV print to tape problem which has been reported several times, and the smart rendering problem are not caused by either of these features being broken: they are both working perfectly fine. Unfortunately, the problem is even bigger and even worse, namely that all HDV rendered by Vegas 11 is bogus (non-standard) and potentially is going to cause other problems down the road.

This is a priority one bug of the highest magnitude because it means that Vegas 11 is completely broken for use with any HDV workflow.

I have submitted a bug report.

Comments

JackW wrote on 2/22/2012, 12:57 PM

Thanks very much for this insight, John. It explains a lot.

Jack

Arthur.S wrote on 2/22/2012, 1:19 PM

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=792713

Thought I was alone with this one! Thanks for working out why V11 smart render doesn't work.

diverG wrote on 2/22/2012, 2:24 PM

Thanks for your efforts John.

It really makes one wonder if the team at SCS are fit for purpose.

Maybe users using HDV workflow should reqest a refund.

Geoff

Arthur.S wrote on 2/22/2012, 2:39 PM

I Did. ;-)

http://www.sonycreativesoftware.com/forums/ShowMessage.asp?ForumID=4&MessageID=794027

winrockpost wrote on 2/22/2012, 5:51 PM

there ya go!!,, John maybe you can go to work for Sony....at least would be nice if you beta tested and they listened to you..

none of my business but I'll ask anyway....you bought 11 ?

johnmeyer wrote on 2/22/2012, 6:06 PM

none of my business but I'll ask anyway....you bought 11 ? I do have a licensed copy of Vegas 11.

As for your other question, I think it is obvious that Sony is listening more the past few months than it has in awhile, and they are listening to many people, not just me. I think this bodes well for the future, but all of us need to submit our bugs and problem reports and, when possible, provide files and a description of how to re-create the problem so that they can pinpoint the cause of the problem and fix it.

Merely posting in this forum is not going to help, at all.

Steve Mann wrote on 2/22/2012, 9:49 PM

Thanks john - It's good to know. I wouldn't have ever seen this because all my HDV gets encoded for DVD, or BD and DVDA works just fine with the encoded files.

Grazie wrote on 2/22/2012, 10:17 PM

As I use the SONY HDV 1440x1080i Render Template a lot, this is a real interest to me to contrast and compare against MXF 1440x1080i before and after using the SONY 1440x1080i HDV Template.

John, I don't know if this will assist in any way, but I've taken my Canon MXF 1440x1080i footage and compared it before and after using the SONY HDV 1440x1080i Template. To ensure I am comparing like for like, I've confirmed my Project settings as a "match" to my Canon Footage, and Vegas comes back with the HDV Match:-

Using MediaInfo this is what I'm getting:-

BEFORE Render:

AFTER Render:

From this view in MediaInfo I'm only detecting those numbers I've arrowed. Should I be looking at a more complex MediaInfo Menu?

Cheers

G

Grazie wrote on 2/22/2012, 10:48 PM

Any thoughts as to why I should be getting "Writing Application Vegas 10", when I did all this in VP521? Does it make any difference?

Cheers

G

johnmeyer wrote on 2/23/2012, 12:01 AM

Mediainfo has a lot of different "Views," and I'm not familiar with that particular view. I used the "tree" view. The image below shows the information on the original captured video on the left, and then the information from the video rendered from Vegas 11.0 using the 1080-60i template on the right:

As you can see, the Vegas version (on the right) is missing all sorts of header information in the General section. I have no way to know if it is this simple missing information that causes Vegas to not smart render and not print these files to tape, or whether there is more to the story.

I also did the exact same test using Vegas 10.0e 64-bit, running under Windows 7 64-bit. When I put that file into MediaInfo, the General section matched the original footage, i.e., it looked like the MediaInfo General section on the left in the above image.

So, if I were you, I would most definitely not, under any circumstances, use Vegas 11 for any HDV workflow that involves rendering back to HDV. The resulting video obviously cannot be printed to tape and cannot be smart rendered, but I suspect that other problems may also pop up.

Grazie wrote on 2/23/2012, 12:27 AM

I see.

I can see the START and END times are "missing"! I'd have thought that was pretty important.

Going to use your Tree View. Nice s/w.

Cheers

G

Grazie wrote on 2/23/2012, 1:22 AM

Hmmm . . .

Just comparing in Tree View, and with even my bespectacled eyesight, I can see a difference in the length of the report - number of lines - and looking carefully for an anomaly.

I tried to export the info to present here, but I don;t appear to be able to achieve a simple "Sheet" output.

So, to recap, I can now see differences, apart from the Start and End, in your screengrab, which with my, CF Cards, isn't something I'd think would happen. Well, it can't be important to my workflow as MediaInfo isn't reporting it in the raw footage either.

I'm over my head on this stuff, but here are some anomalies. Least of which is a bit rate change??

Overall Bit Rate Mode: Variable - This is actually AWOL in the render!

Overall Bit Rate: 26.5 and 35

Format profile : Main@High 1440 and Main@High

Bit Rate: 25 and 35

Bits/(Pixel*Frame) - 0.9 and 0.643

Cheers

G

farss wrote on 2/23/2012, 1:57 AM

Nothing to do directly with the topic.
Doesn't your camera record FullHD i.e. 1920x1080?

Bob.

Grazie wrote on 2/23/2012, 2:57 AM

And?

G

farss wrote on 2/23/2012, 6:28 AM

How is a conjunction an answer to a question?

Two reasons I asked are:

1) Why use 1440x1080 when your camera can shoot 1920x1080?

2) What the camera is recording is not strictly HDV. It's considerably higher quality. In part because of the higher bitrate and in part because the encoder chips are better than what's in the HDV camera, Also HDV uses compressed audio and the MXF from your camera doesn't.

So rendering to HDV means you're taking a quality hit and yet according the report from Mediainfo that's not what you've rendered to, you've rendered to MXF @ 35Mbps.

Bob.

Jay Gladwell wrote on 2/23/2012, 7:21 AM

Probably because the video is being shown on 4:3 TV screens. Just a guess on my part.

Grazie wrote on 2/23/2012, 8:21 AM

1) My choice, as going to DVD, no BD. I'll do more 422 and 50mbs as and when it's required.

2) Attempting to get as near as possible to a render as for John.

Jay? What's a 4:3 screen?

G

Jay Gladwell wrote on 2/23/2012, 9:55 AM

The TV screens we grew up watching. In film, it was a 1.33:1 (Academy) ratio. That's why TV started out in this format.

Perhaps you remember this video.

PeterDuke wrote on 2/23/2012, 5:06 PM

The limitations of making cathode ray tubes would also have had something to do with the format chosen for TV. The first CRTs (made for instruments) were round (actually conical glass work) because that was easiest for physical reasons. TVs were an adaptation of that towards a rectangular format, but the more square-ish or roundish the easier it was to accommodate, so early TVs had curved sides to the rectangle with rounded corners. Not really 4:3 as we think of it today.

Jay Gladwell wrote on 2/23/2012, 5:14 PM

"4:3 (1.33:1) (generally named as "Four-Three", "Four-by-Three", and "Four-to-Three") for standard television has been in use since television's origins and many computer monitors employ the same aspect ratio. 4:3 is the aspect ratio used for 35 mm films in the silent era and used today for film production under the name Super 35. It is also very close to the 1.37:1 aspect ratio defined by the Academy of Motion Picture Arts and Sciences as a standard after the advent of optical sound-on-film. By having TV match this aspect ratio, films previously photographed on film could be satisfactorily viewed on TV in the early days of the medium (i.e. the 1940s and the 1950s)."

From Aspect ratio (image).

spotduster wrote on 2/24/2012, 12:59 PM

We ran smack into this problem and have reported it as well.

Possible (temporary) work-around (works for us so far):

1. Open the MainConcept MPEG-2 "Program Stream NTSC Widescreen" template.
2. Save it as "HDV 1080-60i (works)".
3. Copy EVERY single setting from the HDV template into this new template. (screenshots or another computer might be handy here)
4. Render out using this new template. You will notice that no-recompression rendering now works. It creates an "mpg", but simply rename this to "m2t" since all the settings match. You can now take this rendered "second generation" file and run it right back through v11 (using the new render template), and it will now no-recompression necessary render any number of times. The main trick is to rename the mpg to m2t after each render. Hope that helps. It got us working again here and no-recompression is working again. This trick may also work to get files to print to tape if you are having this issue.

It could be concluded from this discovery that only the HDV encode dll is broken and not the mpg encode dll. It may also be that the problem is not with Sony directly but with the MainConcept dlls.

ForumAdmin wrote on 2/24/2012, 1:45 PM

Thanks, John Meyer, and others who have contributed their insight. We have identified the cause of the issue and it will be resolved in the near future.

Paddy
SCS

Arthur.S wrote on 2/26/2012, 6:04 AM

Good workaround!

The main trick is to rename the mpg to m2t after each render. A thought (I do get one now and then :-) ) If you leave it at .mpg would DVDA then accept it without re-rendering?

diverG wrote on 2/26/2012, 7:46 AM

Spot/ Arthur. What have I missed?

Render template 'program stream NTSC Widescreen'
Rename to hdv 1080 60i and save.
Now the first field that needs changing is DVD -> HDV. I get a settings change warning which is accepted.

I now proceed to match the remaing field to a true HDV template. I have 2 screens and a second instance of Vegas open.
On completion the template is resaved.
When I use this new template the rendered/output file is .m2t not .mpg. I've repeated this several times so have clearly got something wrong. I thought the propblem might be due to having 2 instances of VP11 open so tried using an instance of VP10 (HDV template to copy from.

Geoff