You are not logged in. Please login or register.
SmoothVideo Project → Posts by Chainik
> IC is properly processing that scene.
with a threshold value <=15
making a lot of false SC detections in other scenes
dawkinscm
> The only "garbage" Rife frames are with SVOP and NVOF which explains why I didn't like what I saw.
but you said the opposite thing - "With both NVOF and SVP this is a very sharp and jarring cut" 
flowreen91
> When trying to transcode ... to see the difference between scene changes
Hint: press '.' key in mpv to step frame by frame. Or "Ctrl+right" in MPC-HC.
dawkinscm
> He says he sees Rife.jpg with IC
This isn't what I'm saying.
I'm saying you'll see either
1. repeated frame 1 - when SC detected + "Repeat frame", regardless of the method used (IC or MVs)
2. blended frame 1 and frame 2 - when SC detected + "Blend adjacent frames", regardless of the method used (IC or MVs)
3. some garbage mixed by RIFE - when SC missed, regardless of the method used (IC or MVs)
And I'm also saying that MVs are more accurate than IC, regardless of the "threshold" value.
Blackfyre
> For some reason SVP smoothness does not work properly with them now.
this is the cost of non-blinking
it has to repeat frame when DV data changes, which may happen at random places
dunno, YT now gives error 403 on some video and/or audio streams
lets hope it's something that will be fixed soon in yt_dlp
it's clearly a scene change and SVP do everything right - see f1.jpg before SC and f2.jpg after SC
> what you call "garbage" might simply the AI doing it's job1
see attached rife.jpg
for the 3rd time - if you OK with this - then OK, "SC = disabled" is right for you
and I'll continue thinking that proper SC detection is a must for every frame interpolation algorithm
> But an example of why IC is slightly better is in Dr Strange 2 where he throws his cloak to catch the girl. At the point she is caught the scene changes to show her being carried back.
what is the timecode?
there's no way to "over-react"
if it see the SC it repeats the frame before SC or blends two frames
if it miss the SC then you'll see something mixed by RIFE -> which is your case with IC
that's it
> At the point she is caught the scene changes to show her being carried back. With both NVOF and SVP this is a very sharp and jarring cut. With IC there's still an issue but it's less jarring and looks more natural.
So MVs see the scene change while IC doesn't, and still it's "better". OK then
Blackfyre wrote:Drakko01 wrote:I pointed out one example of this in Doctor Strange Multiverse of madness, after defender Strange is killed by the Ribboned Creature and America chavez run underneath.
Can you provide the timestamp? I have that in high quality and I can test tomorrow.
3.06 and 3.16 the ribbons of the creature , maybe I misinterpreted and its something else.Thanks for taking the time.
---
smooth.scene.limits.scene = 8000;will do the trick for those scenes
---
updated defaults in svpflow libs, ver. 273-1
DolbyVision blinking must be fixed at last
plus DV colors (i.e. brightness) were incorrect because of wrong colorspace conversion before/after RIFE processing
24 * 5 , and then take every other frame
did you updated to mpv 0.38?
> SVP motion has at least a couple of clear and repeatable stutters for certain scenes that IC does not.
meaning
1. it's a false positive SC, right? in which case you'd better share a sample with the problem... there're a lot of variables to adjust there.
2. you really prefer "RIFE-generated "garbage" frames" over frame repeating at a false-positive SC
> but Image Comparison just performs better overall for every problem scene I have.
probably you just prefer RIFE-generated "garbage" frames over repeated or blended ones
Drakko01
>I still think that image comparison work the best
to be "the best" it must give less false positive scene changes, and less missed scene changes
which is not true
apparently, DV blinking _was_ fixed, but it seems that now, with a processing logic changed for "motion vectors scene change", the blinking is back, but for a different reason and it's a different kind of blinking now...
still the latest "0.38" changes were necessary, but not enough
"the same problem" is only regarding AMD cards and AMD drivers
it has nothing common with NV cards and mpv versions
> if I need to update my ICD loader
not for SVP
cool
but "2x conversion" looks much more user-friendly
> Can you share the command line
it's right in the transcoding log
> Where???
App. settings -> All settings
> Watch on my Youtube video
It's absolutely unclear what video output settings you have in each case...
When you run VLC from SVP's menu, video output will be set to the one set in SVP's main.setup.vlc.vout value, regardless of what you'll see in VLC's Preferences!!!
> Maybe it won't have the seek crash.
_very_ unlikely
> Overall, it looks like it's not the driver problem anymore, the vs_rife.dll was the problem
.dll is not the problem, it just preventing user from setting dangerous values, leading to undefined behavior
overall setting threads higher than driver-reported value is not practically usable
q.e.d.
SmoothVideo Project → Posts by Chainik
Powered by PunBB, supported by Informer Technologies, Inc.