Insane prcessing increase setting framerate!

[asarian]

Okay, I tried this:

vid = core.lsmas.LibavSMASHSource(r"f:\veai\surr.mov", fpsnum=24000, fpsden=1001)

As oppposed to

vid = core.lsmas.LibavSMASHSource(r"f:\veai\surr.mov")

The former (in my vspipe line) says it will take an estimated 100 hours!! Even on that 1 single line alone (Sic!)

Without the fpsnum=24000, fpsden=1001, the latter movie processing takes like only 6 hours.

Something is drastically, drastically wrong! Is there any way I can speed this CFR conversion up?!

[poisondeathray]

You can use ChangeFPS in havsfunc ; it's like ChangeFPS in avisynth

A more accurate way is to make use of the timecodes such as VFRtoCFR. You'd need to extract the timecodes from the mov first
https://github.com/Irrational-Encoding-Wizardry/Vapoursynth-VFRToCFR

[asarian]

You can use ChangeFPS in havsfunc ; it's like ChangeFPS in avisynth

A more accurate way is to make use of the timecodes such as VFRtoCFR. You'd need to extract the timecodes from the mov first
https://github.com/Irrational-Encoding-Wizardry/Vapoursynth-VFRToCFR

Thanks! Problem is, that TVAI suddenly decided to render my movie at VFR, and I need to recode it back to CFR. So, a recode is required... but preferably not one that take a 100 hours. :)

[poisondeathray]

But it's probably not really VFR was it ? The source was CFR ? Something like jitter in timestamps ?
You can use AssumeFPS in that case

[asarian]

But it's probably not really VFR was it ? The source was CFR ? Something like jitter in timestamps ?
You can use AssumeFPS in that case

No, it was a clean CFR source; then TVAI, on its own accord, decided to f it over, and output it to VFR.

[poisondeathray]

You probably don't even need to re-encode it (unless you were going to re-encode for other reasons). There might be some utilites that can patch it, like AMCDXVideoPatcher if it was prores/mov

or I think dev versions of mp4box can mux prores into mp4 now, if it can , you might be able to fix it with mp4fpsmod without re-encoding

[asarian]

But it's probably not really VFR was it ? The source was CFR ? Something like jitter in timestamps ?
You can use AssumeFPS in that case

Oh man, this will end in just 5 hours, instead of a 100:

vid = core.lsmas.LibavSMASHSource(r"e:\veai\surr.mov")
vid = haf.ChangeFPS(vid, 24000,1001)

Versus old one:

vid = core.lsmas.LibavSMASHSource(r"f:\veai\surr.mov", fpsnum=24000, fpsden=1001)

Both will do exactly the same, right?

[poisondeathray]

Yes they should be the same. AssumeFPS should be the same as well in your case, maybe even slightly faster because there is less logic and it's an internal function

But check the framecount of the original source and the TVAI mov , they should match. If they don't.... something else is up

[asarian]

Yes they should be the same. AssumeFPS should be the same as well in your case, maybe even slightly faster because there is less logic and it's an internal function

But check the framecount of the original source and the TVAI mov , they should match. If they don't.... something else is up

Good advice, once again. I know TVAI's ffmpeg reported a few dropped frames (like 7); hope that this will not be noticeable too much.

:thanks:

[poisondeathray]

Good advice, once again. I know TVAI's ffmpeg reported a few droped frames (like 7); hope that this will not be noticeable too much.

:thanks:

But dropped frames is a real problem ... and it probably is VFR in that case. Don't use AssumeFPS for that

VFRtoCFR is more ideal in that case , because it will place duplicates in the exact location of the drops (assuming the TVAI timecodes/timestamps were accurate for the drops) ; whereas ChangeFPS might not

I typically use image sequences for exporting for that , it's more reliable

[asarian]

But dropped frames is a real problem ... and it probably is VFR in that case. Don't use AssumeFPS for that

VFRtoCFR is more ideal in that case , because it will place duplicates in the exact location of the drops (assuming the TVAI timecodes/timestamps were accurate for the drops) ; whereas ChangeFPS might not

I typically use image sequences for exporting for that , it's more reliable

Well, their output definitely is VFR, yes (as they're doing a lot of frame interpolation, though were not supposed to in the model I'm using).

[poisondeathray]

If it was something semi-important, personally I would render the 7 drops separately and splice them back in

If it's something I didn't care about much, I'd use ChangeFPS . If it was something I cared about a a tiny bit more than little, VFRtoCFR

[asarian]

If it was something semi-important, personally I would render the 7 drops separately and splice them back in

If it's something I didn't care about much, I'd use ChangeFPS . If it was something I cared about a a tiny bit more than little, VFRtoCFR

Just copied the source (with ffmpeg) to another location. Source dropped no frames, so it's definitely TVAI that messed up their output.

[poisondeathray]

Just copied the source (with ffmpeg) to another location. Source dropped no frames, so it's definitely TVAI that messed up their output.

Report it - it's the only way things get fixed

Some aspects still feel like beta software after all this time, and the price has gone up

[asarian]

Report it - it's the only way things get fixed

Some aspects still feel like beta software after all this time, and the price has gone up

It's been reported alright (not just by me).

And, indeed, their prices have gone up.... significantly

https://community-cdn.topazlabs.com/original/3X/0/3/0345c69f5aeba01c6aff355e80d7df6b17819215.jpeg

Yep, you read that right! At $300 per 1,000 credits, the guy is looking at having to pay over $150,000 for a 14 minute cloud render. :D