Interlace Nest Checking in VP11 700/701 & VP12?

Comments

farss wrote on 10/3/2012, 10:39 PM
I just tried a crazy idea, shamelessly borrowed from Adobe's recommendation on how to handle interlaced footage in After Effects.

I changed the project's (child and parent) frame rate to double, in this case Double PAL (50fps).
Works a treat, nest it, scale it, render it to SD mpeg-2 50i and the result appears perfect, no munged frame / fields. The exact original temporal relationship is maintained.

Bob.
NickHope wrote on 10/4/2012, 1:08 AM
Bob, I tried the same test using your black ball at 60i and got the same confusing result as you. But the key point is that the output from rendering the nested project is not the same as if you render direct from the file, but it should be. Actually on my previous testing with real footage, I had noticed very tiny differences between the 2 fields of each output frame, but in terms of overall movement, objects are in the same place (i.e. progressive).

I agree that we really need this to be tested in the latest versions of V11 and V12, and reporting if the bug still exists. I will report the bug for V10 but I doubt it will get the same attention.

Here's a step by step test method for dummies:

1. Put some HD interlaced 60i video (with significant movement) on the timeline (could be AVCHD, HDV etc.)
2. Project properties > Match Media Settings (top right) > choose the same HD 60i file
3. Field order will probably show "Upper field first". It must not show "None (progressive)"
4. Set "Full-resolution rendering quality" to "Best"
5. Set "Deinterlace method" to "Interpolate fields"
6. OK > Save project as "child.veg"
7. Make a new project
8. Repeat steps 2 to 5
9. Drag child.veg to the timeline from Windows Explorer or whatever (so it becomes nested)
10. Render As > Save as type > MainConcept MPEG-2 > Template > DVD Architect NTSC widescreen video stream
11. File name > e.g. "SD-60i-from-nested-HD-60i.mpg" > Save
12. Make a new project
13. Project Properties > NTSC DV Widescreen > Change "Frame Rate" to 59.940 > Change "Lower field first" to "None (progressive scan)" > OK
14. Put "SD-60i-from-nested-HD-60i.mpg" onto the timeline
15. Move forward through the file with the right arrow key (zoom well in so that frames aren't skipped)
16. Movement should be evenly distributed between frames. If adjoining pairs of frames are identical or near-identical then you've got the bug.

Repeat the above steps but rendering directly from the file on the timeline rather than a nested project to see how the output should look.

V11 / V12 users test and post results please!
Jerry K wrote on 10/4/2012, 8:30 AM
Thanks Nick for posting this test. Maybe we will finally get an answer whether this nesting bug is fixed
in Vegas 12. I stopped at Vegas 10 so if the bug is fixed in Vegas 12 I will be forced to upgrade.

Jerry K
NickHope wrote on 10/4/2012, 11:28 PM
Hmm..., not much interest in this. Come on folks, the test only takes 5 minutes!
videoITguy wrote on 10/4/2012, 11:45 PM
This is a very interesting thread- and considering IMO that the nesting process is a real benefit of VegasPro edit - I am seeking answers as much as anyone else. It appears from Nick's investigation that this behavior has been around for a long-time as to version 8.0c - that is of real concern but I am personally dumbfounded that no-one looked and found this before.

Early in the thread I was coming to the conclusion that this came about due to some changes in how VegasPro was default interpreting incoming video properties - basically whether the editor was going to default to DV or HDV file handiling interpretations as the editing world progressively moved to a default and ordinary use of HDV as the source material. Maybe that assumption should be out the window.

Still, I use nesting all the time (yes, primarily HDV source) and have never been dissappointed. Now I want to take a look bit more closely. Thanks folks for looking at this.
Grazie wrote on 10/5/2012, 1:34 AM
Nick, I was out shooting yesterday . . . Back at base now.

OK, and this is with VP12, and using PAL 25 and then doubling to 50 PAL. Here's the "skinny" - Using the ARROWS I do get frame progression, of a kind . . . . It appears as if the next frame looks smudged-up, or softer - does that make sense?

Cheers

Grazie
farss wrote on 10/5/2012, 2:53 AM
"Here's the "skinny" - Using the ARROWS I do get frame progression, of a kind . . . . It appears as if the next frame looks smudged-up, or softer - does that make sense?"

If you use real world footage it maybe quite difficult to see what is going on as the motion blur from the camera will mask the problem. That's possibly why no one has noticed this in the past.

There's a 1 second clip you can use for these tests here.

There is no motion blur which makes it pretty easy to see if anything funky is going on when this clip is processed.

Bob.
NickHope wrote on 10/5/2012, 5:10 AM
It appears as if the next frame looks smudged-up, or softer - does that make sense?

Yes, that's what I'm seeing. But in overall terms, objects in the frame don't move.

It appears from Nick's investigation that this behavior has been around for a long-time as to version 8.0c

It's important to understand that there are 2 separate issues here.

The first issue does date back to V8 and probably earlier, and has nothing to do with nesting. That issue is a poor quality output when downscaling interlaced footage, if "none" is set as the deinterlace method. You have to set either "blend" or "interpolate" (which both give the same result).

The second issue is that 60i footage downscales incorrectly if it is nested. The output is progressive ("sort of"). This 2nd issue is not in V8. It is in V10. And from what Grazie has found, it's still in V12.

Grazie or other V12 users, it would be great if you could file a bug report for this.

There's a 1 second clip you can use for these tests

Bob, that's a 50i file, not 60i, so won't show up the problem.
farss wrote on 10/5/2012, 5:16 AM
"Bob, that's a 50i file, not 60i, so won't show up the problem"

It shows up the problem just fine. As far as I can tell there is no difference in the problem between 50i or 60i.

Bob.

Just to be sure, to be sure. There's a 60i version here
Grazie wrote on 10/5/2012, 5:27 AM
We really, really need to get some convergence on the methodology with the experimentation pretty soon otherwise we are all going to get drowned on soggy paths!

Cheers

Grazie
NickHope wrote on 10/5/2012, 5:27 AM
It shows up the problem just fine.

Not here in 10.0e 32-bit. Your 50i file renders correctly and identically to SD whether the source is nested or not. I just tested both to DV and to MPEG2.
NickHope wrote on 10/5/2012, 5:36 AM
We really, really need to get some convergence on the methodology with the experimentation

Agreed, which is why I posted the step by step test method above.

Just to be sure, to be sure. There's a 60i version

Thanks Bob. If I render that one directly, I get a correct result. If I render from that one from nested, it's (incorrectly) progressive. There are slight differences around the edge of the ball, but overall it's progressive.

So here, unless I'm doing something wrong, I'm seeing the problem with 60i footage but not 50i. I guess we should test some other frame rates too.
farss wrote on 10/5/2012, 6:58 AM
"Not here in 10.0e 32-bit"

I'm using the 64 bit version. Give me a while and I'll check it all again.
In part I had thought there wasn't a problem with 50i but then I realised I wasn't exactly duplicating Jerry K's workflow. The key seemed to be having de-interlace set to Interpolate in both the child and the parent.

Bob.
farss wrote on 10/5/2012, 10:55 AM
OK,
went back and redid everything, both in 50i and 60i.
Interesting......results and also shows the needs to be uber careful and check everything 10 times and then some :(

50i files all zipped up here.

60i files all zipped up here.


Bob.
NickHope wrote on 10/5/2012, 11:03 AM
Yeah, it's very easy to mess up and mislead yourself. I did so several times myself.

Looks like we're on the same page then? i.e. 60i has nest bug but 50i hasn't.
farss wrote on 10/5/2012, 4:51 PM
"Looks like we're on the same page then? i.e. 60i has nest bug but 50i hasn't."

Yes.

Now we have that settled we just need someone like Grazie to let us know what happens with V12.

Bob.
Grazie wrote on 10/5/2012, 11:47 PM
On the case.

It's very early on a rain-sodden London Saturday morning. I'll get me bones together and brew a cuppa first.

I'll keep me eye on the "not in PAL" observation. If there is divergence between NTSC and PAL then SCS surely needs to be all over these findings.

Great work gentlemen. I had a realisation that there were far too many variables for one testing-set. It needed to have your input to rigorously drill down/through these levels of intricacy.

Cheers

Grazie

Grazie wrote on 10/6/2012, 1:28 AM
OK, this is a back-to-back test in VP12 of Bob's Veggies for PAL and NTSC.

The Video!

Grazie

farss wrote on 10/6/2012, 2:40 AM
Interesting.

1) One of the frame counters displays "ruler" time which si probably set to 25fps, the other is project time which would be 50fps.

2) There's something wrong with the PAL version as well. You should only ever see one image of the ball.

Bob.
Grazie wrote on 10/6/2012, 2:57 AM
2) There's something wrong with the PAL version as well. You should only ever see one image of the ball.

You mean that "other" image of combing? Is that the softening I was saying I was getting in real video? Are you getting 2 distinctive images, one per successive frame?

Bizarre . . .

Grazie

farss wrote on 10/6/2012, 3:24 AM
"You mean that "other" image of combing?"

Yes.

"Is that the softening I was saying I was getting in real video?"

Most likely. That's why a prefer these synthetic tests, no doubt about what is happening.

"Are you getting 2 distinctive images, one per successive frame?"

Yes, looks almost exactly the same as the source video. Obviously the edges of the ball will be a bit jaggie but no ghosts, half raster bits and bobs etc.

"Bizarre . . . "

Time for an exorcism :)

Bob.
Grazie wrote on 10/6/2012, 5:47 AM
Now, is it at all possible that the MC rendering process is failing? Just a thought.

G

farss wrote on 10/6/2012, 6:20 AM
"Now, is it at all possible that the MC rendering process is failing? Just a thought."

This is Vegas, the place where any dream can come true :)

I'd say very unlikely. The MC encoder is a separate slab of code not tightly linked to the rest of Vegas. It would be ignorant of anything to do with nesting or scaling.
Easy enough to check though, just render to PAL / NTSC Widescreen DV as appropriate and check the results of that in the same way

Bob.
NickHope wrote on 10/6/2012, 1:32 PM
Strange. Just to reiterate what Bob said, I'm getting a distinct black ball with no combing for each and every frame in the 50p "View Result" project. But my 59.94p project behaviour is the same as yours Grazie.