Video Playback Observations

[qwksilver]

To test the estim, i originally downloaded latest ,288
really choppy video, unusable to an extreeme

I reverted to .287, and problem vanished, system and funstim seem fine, getting ready to test it.

ps. can we get a point release on the about screen, it just constantly says 1.1.0

[qwksilver]

update, this is actually still somewhat noticeable in 287 also. 1080 playback has gone to the bucket, 720 takes 3-4 times longer to change video, and scrubbing in anything above 480 is huge breaks. this is likely a hardware issue on older equipment, i haven't run this on my gaming machine for comparison, but I will try that today.

i'm not sure if you are processing video directly...my main vlc handles most video (4k/60fps) on this machine fairly well, and zoom player is more memory intensive and get's choppy on just the really high stuff with no noticable load/transition time.

i think vlc just uses windows/direct x 11
while zoomplayer uses MadVR, EVR, Haali, or several VMR options that use DX9. I choose EVR on this machine, madvr seems to make load times really laggy. I also thing that ZP uses fdshow or LAV in someway to preload? I actually am only guessing at this.

Anyway, my point is if you are using any of these for plug ins. I curious which, if not, is that a possible solution, to off load video processing and render back to the available windows space.

[FredTungsten]

I just use a standard .NET MediaPlayer in the background (probably DirectShow based).
Can't reproduce any of these problems even with all 3 e-stim implementations active at once.
No problems with scrubbing through 1080p either.

[qwksilver]

might just be performance of this machine, i'll check my other machine later today.
this is a laptop, 12gb ram i3-7100 2.4gh and intel hd-620 video onboard. win10-latest

[qwksilver]

I did a whole bunch of codec updates, and performance improved. i can say however that changing video has a 5-10second load time, i can't run 1080p at all. I'm fairly sure that I'm now below the min hardware required. My other machines do not have these issues.

ps what are the official min hardware for full function?

[FredTungsten]

No official requirements, but if it runs smoothly in Windows Media Player it should run reasonably well in ScriptPlayer too. Unless your bottleneck is your CPU - the script handling needs some too.

Probably the number one thing that costs a lot of processing power is the soft-seek between gaps / videos - so that should be the first thing you disable.

[qwksilver]

no soft seek or gap skipping
manually seeking causes a huge stutter
anything higher than 720p is also a huge stutter with ongoing playback stutter
i think it is cpu borderline, i'm running about 90%cpu and 75% gpu
playback only with vlc is no issues reasonable load times
playback only in zoom player is no issues till really high bitrate 4k
not sure how vlc processes but madvr is too much, i use EVR, and dx9 or dx11 directshow is cluncky without the EVR front end.

[FredTungsten]

Not really something I can do a lot about tbh.

[qwksilver]

This is a hardware issue, I would say min specs are above my old laptop machine and below the prodesk mini g4
old = core i3-7100U, 12gb ram, Intel UHD Graphics 620 (Mobile Kaby Lake)
new = core i5-8500T, 16gb ram, Intel UHD Graphics 630 1gb (Desktop Coffee Lake)

also, one of those files was corrupted :< and a redownload fixed it, but didn't try on old machine found on new.
machine is otherwise not changed, direct os move.

new specs are way better at processing scripts, video, and estim all side by side.
and it's tiny, super portable, https://i.ebayimg.com/images/g/ylkAAOSwtNBfKs6O/s-l1600.jpg

[qwksilver]

This issue is back, for me on more than a few videos that run flawlessly with another video player. (with scriptplayer open and serving the script out to a launch. (so the extra performance doesn't seem to be it now). i'm wondering if the video engine can utilize ffdshow, EVR, and lav hardware acceleration). playback feels like the video engine is only using cpu, without precaching/buffering or gpu acceleration.....

To be clear, load times seem fine, just playback is super jerky, and in a lot of cases on video that was working fine several releases back.

list of options from my media center player, might make more sense than my words...I hope.

[FredTungsten]

I just use the out-of-the-box DirectShow based MediaPlayer that comes with Windows - no options or anything.

[qwksilver]

is this relevant at all: https://docs.microsoft.com/en-us/windows/win32/medfound/video-quality-management
or more likely this https://docs.microsoft.com/en-us/windows/win32/directshow/step-4--add-the-video-renderer

I hate that I suck at code, I tried to stare at it and hunt down the call to the video player to play....per se, to see if I could even suggest access to other filters, but alas.

[FredTungsten]

This one is the basis for the integrated player:

https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.mediaplayer?view=netcore-3.1

[qwksilver]

I think i have found the source of this problem for me. It seems that videodownloadhelper's companion encoder, which I use to retrieve video from a certain site, is generating corrupted files, opening those files in avidemux throws an error, something about timeline corruption. It seems that a more modern api just brute forces the data and smooths out the playback somehow. more processor power (aka my big machine) can even play these in scriptplayer with no problem. but this dedicated video player will have issues with 1 file at 720p, and 30fps and play another larger file at 1080 or even 4k and 60fps and those are all smooth.

I've run a batch re encode on a bunch of broken video and changed to x265 for smaller files in the process, and I get amazing results.

since, as you say. this isn't something that script player can address without a complete video engine change, and a reencode will fix the video at the source, i'm closing this out as otherwise unfixable, if others want to know the re-encode process feel free to post a follow up note here and i will get that out when i have more time.