MVtools scene detection for a clean cut? (1080-50i to 720-30p)

[nhope]

I have a bunch of HDV 1080-50i clips on my Sony Vegas Pro timeline and I'm converting them to 720-30p UT video codec format to mix with footage originating from HDV 1080-60i by frameserving to the following script, then VirtualDub. It will later be rendered to H.264 for the web.

AviSource("d:\fs.avi")
AssumeTFF()
ConvertToYUY2(interlaced=true, matrix="Rec601")
QTGMC(SubPel=2, EdiThreads=2)
super = MSuper(levels=1, pel=2)
MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=30000, den=1001)
Spline36Resize(1280,720)
AssumeFPS(29.97)

The quality is great. However at some of the scene changes in the 30p output I get a clean cut, but at others I get a blended frame. This is not a big deal as the eye generally glosses over these rapid transitions between scenes, but I was wondering if there is a smarter way to do it whereby I always get a clean cut?

I guess one solution might be to duplicate a frame instead of blending at those transitions, but I fear that might look less smooth during playback.

I guess another solution might be to drop a frame, although that would make the video shorter and I would prefer to retain the overall length of the video so I can still sync 50i and 30p to audio on my timeline.

So it seems the ideal solution might be to somehow detect which transitions are going to render a blended frame, and then at those transitions to generate a new frame by either looking just backwards at the preceding clip, or just forwards at the following clip, depending which of those 2 clips' ends is closer to the cut. I hope that makes sense!

Possible? Or should I just live with the blended transitions?

[Didée]

MFlowFps(super, QTGMC_bVec1, QTGMC_fVec1, num=30000, den=1001, blend=false )

[nhope]

Damn it, I was hoping the solution would be really complicated.

Thanks Didée!

[TheSkiller]

Some tips:

1) Avoid AssumeFPS(29.97)
It's not exactly the right frame rate. It might seem over-the-top but it's a difference whether a video is marked as 29.970000000000 fps or 29.970029970029970(...) fps which is the real NTSC frame rate, 30000/1001.
Use AssumeFPS(30000,1001). In fact you can omit this line because the frame rate was converted to 30000/1001 by MFlowFps already.

2) If "d:\fs.avi" is your raw HDV source (YV12) then the matrix parameter in ConvertToYUY2() won't do anything at all! It is only used for conversions between any YUV color space and RGB.
If you need to do a conversion from Rec709 to Rec601 coefficients then you need to use ColorMatrix (http://forum.doom9.org/showthread.php?t=82217).


ColorMatrix(mode="Rec.709->Rec.601", clamp=0)


Edit: However, your destination seems to be HD which means you should not convert to Rec601.

[nhope]

Thanks for you reply TheSkiller.

1) Avoid AssumeFPS(29.97)
It's not exactly the right frame rate. It might seem over-the-top but it's a difference whether a video is marked as 29.970000000000 fps or 29.970029970029970(...) fps which is the real NTSC frame rate, 30000/1001.
Use AssumeFPS(30000,1001). In fact you can omit this line because the frame rate was converted to 30000/1001 by MFlowFps already.
That's a good point. I had to leave AssumeFPS in for one of my earlier conversion scripts, so that found its way into this one. The frame rates used in Sony Vegas Pro only go to 3 decimal places. As this footage is going back into Sony Vegas Pro, I guess 29.97 might be OK, but as you say, I can leave it out anyway.

2) If "d:\fs.avi" is your raw HDV source (YV12) then the matrix parameter in ConvertToYUY2() won't do anything at all! It is only used for conversions between any YUV color space and RGB.
If you need to do a conversion from Rec709 to Rec601 coefficients then you need to use ColorMatrix (http://forum.doom9.org/showthread.php?t=82217).


ColorMatrix(mode="Rec.709->Rec.601", clamp=0)


Edit: However, your destination seems to be HD which means you should not convert to Rec601.

My source is actually a frameserved RGB AVI stream. I have found that matrix="Rec601" gives the correct result when rendering to UT video codec in VirtualDub, even though everything is HD (1808i to 720p).

[poisondeathray]

My source is actually a frameserved RGB AVI stream. I have found that matrix="Rec601" gives the correct result when rendering to UT video codec in VirtualDub, even though everything is HD (1808i to 720p).

But how are you determining the "correct result" ? The preview in vdub? It's using Rec601 converting to RGB for display (usually incorrect for HD material)

ie. You are frameserving RGB from vegas but converting to YUY2 (rec601) in the script; vdub is using Rec601 to convert to RGB for display, not Rec709. But when you view this on some other device or HD workflow , it will most likely use Rec709 for display

[nhope]

But how are you determining the "correct result" ?

By comparing the rendered UT Video Codec file against the original HDV files in Sony Vegas Pro. Rec601 is the same. Rec709 is different.

[poisondeathray]

By comparing the rendered UT Video Codec file against the original HDV files in Sony Vegas Pro. Rec601 is the same. Rec709 is different.


So you render UT 422 out of vdub with the script , then re-import into vegas?

The problem is vegas is converting UT 422 to RGB using Rec601, not treating it as Y'CbCr

Why not do whatever you have to do in vegas, before you frameserve out? This way you don't face several uncessary colorspace conversions ?

EDIT: sorry nevermind, I see what you are doing, you're mixing it back in a vegas project with 60i footage

[nhope]

Actually I'm rendering to Ut Video Codec RGB (URLG). Since Vegas works internally in RGB, there is no conversion happening on import to Vegas.

[nhope]

Back to the original point, the mvtools documentation implied that blend=false might actually simply repeat frames at scene changes. So it concerned me that there might be a bit of a "jolt" at scene changes. But I'm finding that there is no such repeated frame, at least in the case of my 50i to 30p script. Motion is totally smooth amd cuts are clean. So that's great!

[Gavino]

the mvtools documentation implied that blend=false might actually simply repeat frames at scene changes. So it concerned me that there might be a bit of a "jolt" at scene changes. But I'm finding that there is no such repeated frame, at least in the case of my 50i to 30p script.
Repeated frames are necessary only when increasing the frame rate. When decreasing, the issue does not arise.

[nhope]

Ah OK. Thanks Gavino. That makes sense. I'll look out for that in another project where I'm planning to convert PAL to NTSC (both interlaced) in a similar manner.