1 Topic by CrendKing

(1 replies, posted in Using SVP)

When diagnosing AVSF issue 47, I noticed that when playing a 24FPS video, and use FRC 25/8, the script clip video info's num_frames is always 26333. This number is so small that since it maps to source frame 8395, the video would freeze at about 6 minutes. In fact, other ratios such as 22/7 generates smaller number (e.g. 456455) than the one I put for source clip (10810800), but big enough to not cause issue.

My question is, why does SVP shrinks the num_frames when the FPS is increased by it? Is this some kind of overflow problem?

Also, in the same issue, I noticed that when I set my monitor to exactly 75Hz and SVP to "To screen", SVP chooses to use 22/7 instead of 25/8, for 24FPS video, where former results in 75.4286 FPS, but latter is the better 75Hz. Only if I lower my monitor to somewhere like 74.8Hz will it use 25/8. Is this a bug?

Go to forum: Using SVP

2 Topic by CrendKing

(1 replies, posted in Using SVP)

I updated to today's SVP Manager version 4.5.0.210-1 and noticed that the generate.js is changed for VapourSynth variant. Specifically, when playing 10-bit video, it generates

input_um = clip.resize.Point(format=vs.YUV420P10,dither_type="random")

Unfortunately, due to how DirectShow and AviSynthPlus handle P010 differently, AVSF only takes P010 input but never outputs P010. Instead it always outputs P016. And it seems VapourSynth, for compatibility reason, handles P010 exactly the same way.

So, if the script converts the output clip to P010, AVSF won't find a suitable output format, and the result video will be completely green.

AviSynth variant doesn't have this problem because when using NVOF (as you instructed), it never converts the source clip. Only the nvof_src is converted.

The fix would be simply replace the two

format=vs.YUV420'+(media.p10?'P10':'P8')

to

format=vs.YUV420'+(media.p10?'P16':'P8')

Go to forum: Using SVP

3 Reply by CrendKing

(6 replies, posted in Using SVP)

OK. Looks like after SVP injection, the frame request pattern is changed to be slightly faster due to FRC. My getFrameAsync() callback doesn't wait long enough for these properties to become available before returning the source frames. The fix will be in the next version.

Go to forum: Using SVP

4 Reply by CrendKing

(6 replies, posted in Using SVP)

Just tried to completely turn off FRC in SVP manager, no cropping, no black bar detection, no alter size, no lighting, no OSD msg, still has the bad frame duration. Only happens after the injection.

Anything the frame got passed through has chance to alter the _DurationXXX RFP, not necessarily the svp ones. Maybe you could binary search the components to find the root cause?

Go to forum: Using SVP

5 Reply by CrendKing

(6 replies, posted in Using SVP)

Anyways, I'll switch to the "greater than 0" check. If you managed to fix this in the future, it should need no more fix to work.

Go to forum: Using SVP

6 Topic by CrendKing

(6 replies, posted in Using SVP)

Hi. I'm the guy from AVSF. Thanks for adding the support of the VapourSynth filter. I was trying this new feature.

I found that once the SVP injection happens, the video plays in extremely fast pace. Even pausing the player doesn't stop the frames.

Debugging into my code, I found that after the injection, the _DurationNum and _DurationDen properties of the output frames are 0 and 1 respectively, which explains the strange behavior. If I change the code to test frameDurationNum > 0 && frameDurationDen > 0, the average script frame duration is used and I can confirm it works.

What's strange is, if I copy the relevant generated script code to my initial script and disable SVP manager, the properties are adjusted correctly.

I know the 0/1 thing is how VapourSynth represents variable fps video clip, but it's not necessarily the same for the reserved frame properties, right? Otherwise these properties are not very useful.

So can you guys reproduce the issue?

Go to forum: Using SVP