How can Vegas stuff this up?

farss wrote on 1/12/2009, 3:00 AM
I'm trying hard to stay calm and avoid expletives but this really is not only beyond a joke it leaves me now very seriously questioning my own sanity sticking with Vegas.

Today I took on an urgent job. Take a 6min program cut by someone else and mastered to Digital Betacam and make it into a very basic DVD to submit for an audition. Sounds trivial. I have now wasted many hours on this.

No problem capturing with V8.0b. Did a quick encode to mpeg-2 at 8Mb/sec CBR and copied the files to a thumb drive to author when I got back home. Finished it in a few minutes and sat down to watch it. It is a total friggin disaster! The field order swaps and jumps all over the place. The hero shots from a HUGE crane with a dutch roll looks like a bad acid trip. The whole encode is a joke.

I go back to the office to check the master on an expensive SDI monitor. It is PERFECT. I take the SDI monitor over to my Vegas system and playout from the T/L. Perfect, beautiful, gotta love the stuff shot with the big cameras and heavy iron. I open the same AVI in PPro CS2, still perfect on the monitor.

Now how the heck did this all go ever so badly wrong. I haven't a clue, somehow between Vegas and the MC encoder something is getting the field order wrong and it happens depending on how much motion there is in the frame or some such oddity. I have seen this happen once before years ago. I thought this problem had gone away but now I suspect the reason is the last DB job I did that was fine I'd captured in CS2.

I do have one clue. It would seem that the problem only happens when there's a cut in the master tape / captured file between archive footage and the new material. No, the field order is correct otherwise it would not playback correctly from the T/L. It could be that although all clips have the same field order due to the original material being different then field dominance changes and this is confusing something.

Any suggestions apart from giving up entirely on Vegas most welcome.

PS. I'd submit this to support but if, after 10 lots of emails they tell me "Oh yeah, THAT problem, we know about that", then I'd really loose the plot.

PPS. This is all PAL, vanilla 720x576 50i

Bob.

Comments

randy-stewart wrote on 1/12/2009, 3:31 AM
Bob,
A shot in the dark on this. How about rendering to an .avi format first and then use Vegas to go MPEG2? Sounds like the original file has frames that aren't being understood by Vegas. Maybe rendering to .avi would lessen or resolve that. Again, just shooting in the dark here using my amateur intuition.
Randy
farss wrote on 1/12/2009, 3:49 AM
Actually a good suggestion, trying it now, just takes time shuffling so much data around. Good thing I didn't capture as 10bit.

Bob.
farss wrote on 1/12/2009, 5:20 AM
The vision encoded to DV looks just fine.
Encoding to mpeg-2 from that and playing out a DVD from that it looks almost as bad as from the DB, wierd. It's maybe significant that it's slightly better.
Looking and thinking some more I'm not convinced this is a field order problem which I've seen plenty of. Motion becomes stuttery but doesn't have that backwards / forwards cadence that reversed field order has. Instead it's more stobing. Coul it be that the encoder has been overloaded, the worst shot is a long dolly from the back of the crowd through waving arms towards the stage. The waving arms are a suttery mess. No macroblocking though.
Perhaps significantly, no motion blur either, the cameras must have been running at fast shutter speed but if this was just some Saving Private Ryan look why does it look perfect from the DB master.

Tomorrow I'll try two things.
1) Encoding out of Ppro.
2) Capturing as DV from the J30 and encoding from that.

Just to prove I've not lost my marbles even my wife thinks it looks like rubbish and she watches 10th generation NTSC VHS and thinks it's OK so this must be really BAD.

Bob.
TheHappyFriar wrote on 1/12/2009, 5:55 AM
for some reason this seems really familiar to me, I just can't put my finger on it. I think the last time I had something like this was with vegas 4.

could you post a small clip for others to check out & see what happens on their systems?
farss wrote on 1/12/2009, 6:06 AM
I think I may have nailed it.
It looks like ALL the field order is wrong. What confounded me not seeing that straight upfront is a lot of it is progressive, even some motion graphics are mixed P and I. What a trap.

Bob.
TheHappyFriar wrote on 1/12/2009, 6:37 AM
you mean the field order on the master? It's different clips put together & then put on a master?

If that's it then I DID see that in vegas 4. :) I mixed Huffy analog footage I captured on my rig with footage captured via a Matrox RT 2500 back then & when I burned to DVD I saw the exact same thing because of the two different field orders of the clips.
rs170a wrote on 1/12/2009, 6:37 AM
[i]It looks like ALL the field order is wrong.[]/i]

Bob, I had a similar issue with Canopus AVI files a few years ago.
MarcoB was able to help me by suggesting some changes to the Vegas ini file that cured it.
His last post (repeated below) had some comments that may be applicable to your situation.
HTH.

*********************************************************
The modified ini-file seems to be perfect for any dv stuff because dv must be lower field first and even if Vegas is confused by certain dv files like the Canopus ones it'll be perfect - lower field first.

But if you have a video input which fits 720x576 size and 25 fps but which is NOT dv then it does also change the field order to lower field first which might be not correct then.
So if you import or capture video which is Sony YUV it actually should have upper field first but with this modified ini-field it will be read as lower field first in Vegas.

This means you probably will not have any trouble with that kind of modified ini-file when using dv video. But you must reset the ini-file if you're going to use video which actually is upper field first.
If you have a project running with mixed stuff - both upper and lower field first - the modified ini-file is no help at all.

*********************************************************

Mike
johnmeyer wrote on 1/12/2009, 8:19 AM
Bob,

I have seen lots of video with reversed fields, and often the usual "judder" or "ghosting" one associates with this problem is not evident. As a result, you (as you just did) spend hours looking for other problems.

The purpose in posting here is not, however, to just sympathize with your problem, but to offer some advice for how to avoid killing hours of time in the future. I posted here:

Jerky SD

how to use settings in TMPGEnc (you can use the trial) to easily and quickly determine if fields are reversed. It works perfectly, 100% of the time, and you'll know within ten seconds if you have reversed fields.

I've also posted how to use AVISynth to do the same thing:

HDV to SD deinterlace: surprise!

TMPGEnc is really easy to use, so I would recommend using that. Less than one minute from when you open the program, you'll know if you have a field problem.
farss wrote on 1/12/2009, 12:48 PM
Thank you Mike and John, there's some valuable input there that I'll certainly persue although the clock is ticking on this. I do have a TMPEG licence from years ago which I should make more use of.

I have had one other thought. The VCR I captured with and the one I used to check the master tape is not the same. I'm hard pressed to imagine how a fault in a VCR could cause this kind of wierdness. Then again on the weekend I spent a few hours with an engineer in a room full of to die for hardware ( He has TWO Cinealta HDCAM SR decks!!!) while he told me of all the wierd 'ghost in the machine' stuff he's had to deal with over the years so I guess anything is possible as DB VCRs do a bit of image processing, moreso than DV decks.

Thanks again.
Bob.
[r]Evolution wrote on 1/12/2009, 12:56 PM
Not having experienced this and following this thread trying to understand... do you guys still feel that this is a Vegas problem?
johnmeyer wrote on 1/12/2009, 1:40 PM
I do have a TMPEG licence from years ago which I should make more use of.I am pretty sure that all you need is the trial. You won't be encoding anything. You just simply walk through 3-4 frames and you'll know if you have a problem.

As to whether this is a Vegas problem, I don't think so, although having said that, many video file formats (like MPEG-2) put information about the file not only in the header, but also at various points within the file (like at I frames). It is possible that there is some non-standard way some capture apps encode the field information and that Vegas doesn't gracefully handle this non-standard header. This is total speculation on my part.

There certainly have been quite a number of posts the past six months from people who have video that has a different field order than what is in the media information that Vegas provides when you right-click, although some of these reports turn out to be from people who, for whatever reason, manually changed the field order of their media. Except for situations such as what Bob is reporting here, that is almost always a big no-no.

farss wrote on 1/12/2009, 2:51 PM
"As to whether this is a Vegas problem, I don't think so"

You want the bad news?

It IS totally and utterly a Vegas problem I'm sad to report.

I took the same 8bit YUV file that I'd captured in Vegas and created a project in Ppro CS3. From that I encoded to m2v and wav at 8Mbits/sec. Ppro does both at once for you WOW. I thought it was supposed to be hard to use!
I took those files into DVDA and made a PAL 16:9 DVD.
It is absolutely perfect, not any sign of ANY motion judder, field order flipping backwards and forwards etc, etc.
I have seen this happen before with Vegas and YUV, right in the middle of a shot, field order flipped for a few seconds. This was footage from Blue Planet. Say what you like about The Beeb they don't mess up these kinds of things.

Just in case anyone else doesn't quite get this.
Same source file, same encoder as both Adobe and SCS use much the same MC encoder. Same authoring application (DVDA) same media, same everything apart from NLE. The only really notable difference is Ppro uses the M$ Directshow interface and Vegas is still stuck with VFW. When I first struck this kind of problem years back someone said it's a known issue with VFW and obviously M$ aren't going to fix it as it's legacy support only.

No doubt if I raised a trouble ticket with SCS and banged and kicked on their door eventually they'd say the same thing, complain to M$ :)


Just to be really even clearer. This is not a field order problem as you'd normally expect. Vegas is somehow encoding to mpeg-2 and flipping field order at random as it does so. I could get a better outcome by reversing the entire clips field order but it was still not perfect. At some points in the one shot it'd flip back and forwards.

I'm so p'ed off over this I'm laughing.

Bob.
kairosmatt wrote on 1/12/2009, 7:40 PM
Bob-I'm feel for your pain!

But it also, in some ways, make me feel a wee bit better knowing that there are such experienced people out there having interlacing issues.

I completely wussed out after my last major debacle with partially backwards fields and now de-interlace everything. Even if someone hands me older footage, I de-interlace. Keeps me sane...though I have realized there are some quality issues especially when de-interlacing standard definition.

OT: when you say Blue Planet, is that the BBC Blue Planet? How did you come to play with that?

kairosmatt
johnmeyer wrote on 1/12/2009, 8:46 PM
It IS totally and utterly a Vegas problem I'm sad to report.Bob, did you use any velocity envelopes? Back in version 5 (or maybe it was 6), if you reversed the motion with a velocity envelop (so the video started playing backwards), the field order would reverse as soon as the speed went negative. I ended up corresponding directly with one of the engineers, and I gave them lots of ways to recreate the problem. It was eventually fixed.

I mention this because, even if you don't use a velocity envelope, maybe that piece of information may help determine if there is a workaround.

I'd sure take the three minutes to send a trouble report, however. Like I said in the earlier post, it sure seems like a LOT of people have been reporting field reversal problems.
farss wrote on 1/13/2009, 12:22 AM
"when you say Blue Planet, is that the BBC Blue Planet? How did you come to play with that?"

Yes.
You can buy copies of most programs made by public broadcasters on tape, you just have to ask. They do charge a bit for making dubs. Very handy for testing because you know it's generally going to be pristine video.
The other reason to have such copies around is when you've got to test gear it's nice to have something worth the watching and listening to.

Bob.

farss wrote on 1/13/2009, 1:28 AM
"Bob, did you use any velocity envelopes?"

No, this is a straight 'dub' from the client's Digital Betacam master tape to DVD. All I've done is trim the T&B off the start and the black off the end and then encode that to mpeg-2.

The work around was dead simple. Open same file in Ppro CS3, use Adobe's encoder to encode to mpeg-2 and wav and author in DVDA. In Ppro I did a little work on it to blank the top line which is oftenly a problem with 16:9 DB. I really had a hard time of doing that in Ppro, it's a doodle to do in Vegas though.

I need to do more testing. I seem to have no problem if I capture the tapes using Ppro and encode with Vegas. I seem to have no problem if I capture with Vegas and encode with Ppro. It's the Vegas > Vegas combo that has the problem. I've never had a problem with Vegas if I capture as DV from the J30 either so I think I can say it's something in the YUV file that causes the problem.

It's hard work too. As I've seen it's hard to see field order problems on a small CRT so to check what I'm seeing I have to tie up an expensive monitor with an SDI card in it. I'm happy to do this to help SCS (on anyone else) get to the bottom of a problem and improve their product.
However I'm asking big favours of my mates borrowing VCRs and monitors and when all you get back from SCS when you give them a detailed blow by blow description of the problem is "Please re-install Vegas" it's very, very hard to get enthusiastic about donating your time to the cause.

Bob.

johnmeyer wrote on 1/13/2009, 7:34 AM
Bob,

Now wait a second. You captured to YUV using the Vegas capture, and it is that capture that has problems when encoded to MPEG-2 in Vegas. Is that correct?

If so, then you must have been using some sort of capture hardware other than DV via camcorder pass-through. And if so, that capture is passed to Vegas via VFW drivers. These drivers stink, and there are all sorts of configurations that must be done, some down at the pin level (I am speaking of the pins that you "connect" in the low-level VFW dialogs), if you want to get good results.

What you did -- capture in another application -- is exactly the correct way to do this. I have tried for years to capture into Vegas (and similar applications) from my ATI Radeon 8500 DV (soon to be retired for my new i7 computer which arrives next week). Every time I think I'm getting a good capture, I find something else that is screwed up. This includes field problems, horrendous gamma and level shift, color problems, etc. So, even though the Vegas capture application is absolutely horrible (both the original, and the HDV versions), I am not entirely convinced that your problem is entirely the fault of Vegas, but rather I think it is the older way in which Vegas interacts with Windows.

Just do the capture elsewhere and then edit in Vegas, which is what it sounds like you have already done.
farss wrote on 1/13/2009, 12:53 PM
"Now wait a second. You captured to YUV using the Vegas capture, and it is that capture that has problems when encoded to MPEG-2 in Vegas. Is that correct?"

That's right. This footage was captured using Vegas's internal capture to capture digital betacam over SDI using my BMD Decklink card.

Encoding from that AVI file to mpeg-2 I have a horrendous mess using Vegas.

Encoding from the same AVI file to mpeg-2 everything is perfect.

I've also in the past not seen any problems if I use Ppro to capture and Vegas to encode.


I have to agree with you. It would seem that VFW = WTF = What's This Field?

Bob.
[r]Evolution wrote on 1/13/2009, 11:25 PM
What if your workflow consisted of Capturing using the BMD Decklink Capture Utility... would that solve your issue?

Whenever I have to capture using my BMD Decklink I always use the Decklink Capture App then import my files into Vegas, Premiere, or FCP. It's become second nature to do so now.
farss wrote on 1/13/2009, 11:45 PM
"What if your workflow consisted of Capturing using the BMD Decklink Capture Utility... would that solve your issue?"

I haven't tried using that in quite a while. I've previously just used Ppro as Vegas just didn't capture at all but sometime ago BMD released new drivers that seemed to work with Vegas and I thought we were out of the woods. Oh well.

Bob.