Search options (Page 168 of 234)

khps30263
Thank you. I found my mistake.
I have made new fix: SVPMgr_CommonAppData2.zip
Please try it again.

You can try to run SVPMgr as administrator. Maybe it will helps.

khps30263
Thank you.
Additional info is good.

It is addinfo from English-named user?

What version is pointed in ReadMe_eng.txt?

khps30263

Something wrong with ExBlockSize parameter value.
Please show your additional info: SVP tray menu - Information - Additional information.

P.S. I translated error text from Chinese with google translation. I got:

Then it is wrong SVPMgr.wsf. There are no file operations at SVPMgr.wsf(94, 3).
I think it is from another version of SVP. Please reinstall SVP 3.1.2 from download page (Lite or Full, it does not matter), replace files from SVPMgr_CommonAppData.zip. And try again.

Skaven252
how did you generate that report? Just Excellence?
Just MS Excel and couple of hours

if I use "mode=0", it halves the resolution of the video to 960x540
It shows to me the same.

I can't find any success way to open MOV via DirectShowSource too.

Only with "mode=3" I get full resolution.
Then I recommend to convert to any other container and open not through QTInput. QTInput(mode=3) adds fake dropped frames.

For example.
You can use yamb to produce MP4 (without re-encoding). Or you can use gdsmux to produce MKV (without re-encoding too).

About CFR calculation. This is graphical result (I computed it in MS Excel): deviations of frames timeCodes. Data of clip2 used.

Graphic shows how early (lead) or later (lag) each frame will be dispayed if play frames at constant frame rate 29.95 fps.
As you can see maximum deviation is about 2 ms. MKV and MP4 data is close to each other. And we have one drop at the middle of the video. We must to insert one duplicate of frame to fix frames lead after drop.
QTInput(vfrFPS=29.95) and DirectShowSource(fps=29.95, convertfps=true) will do it automatically. All frames will opened. Without losses. All frames are at its own places.

Skaven252
rebuilds the header data
Are you sure this operation is correct. Results still have synchro?

Can you share source to me?
Second file with one drop will be enough.

Skaven252
I checked how works QTInput. It works good with different value of mode parameter.
QTInput with mode=0 works good. Frame # 2108 is copy of 2107 in second clip and FramesCount is 5111.

QTInput("wide ipd test cam2 t02.mov", vfrFPS=29.95)

This script gives perfect sync with true length.

But with used by You mode=3 I can't see duplicate frame in the region of #2107 frame. This mode is not frame accurate. It potentially can lead to lose synchro.

dudul

It looks like you have old version of SVP with video memory leaks troubles (about 0x3FFFB error).
You need to install latest version of SVP 3.1.2. Download page.

I changed the supported thread from "Auto" to 4, and video lagged, so i changed to 2 and still lagged, then changed again to "Auto". Guess what? It doesn't lagged and crashed anymore
Of course. Any change lead to script reinitialization. You can do 10-20 reinitializations before crash. Free video memory not released. It is error 0x3FFFB.

Congratulations! Your system is unstable
Now you must to test your CPU, your memory and your video with stress tests to find bad working device in your system.

Skaven252
Um, "pointing the framerate", I presume, doesn't do the same as AssumeFPS?
No. It is different things. If you open video with wrong FPS you will lose original frames or will get unwanted duplicates. For example opening 30 fps video with framerate 1 frame/sec will lead to losing 29 frames each second. And AssumeFPS in this case can't help absolutely.

Skaven252
Ough! Yes! I was wrong about floating VFR.
It is constant framerate with a little deviation and one hard drop in second clip.

Base framerate is 29.95 fps (or 29.95048 to be precise).
You can open it and work with it as CFR:

DirectShowSource("[filename]", fps=29.95, convertfps=true)

After that you can get synchro by 0.003 sec (3 msec)

Later I will tell about how I checked it.