StaxRip 2.0 Support Thread

[Forteen88]

aq-mode in what Encoder. aq-mode doesn't give much details, since most encoders have aq-mode.Oh, never mind, they changed default AQ-mode in x265 from 1 to 2 (it might differ which preset you use). Thanks anyway.
https://bitbucket.org/multicoreware/x265/commits/b14834a9d1c1864ea7e94d9cfed4e33f37e767c6

But there should be a way to still set x265 aq-mode to 1 in StaxRip.

EDIT: Thanks ukmark for the tip using custom commandline instead.

[Revan654]

Oh, never mind, they changed default AQ-mode in x265 from 1 to 2 (it might differ which preset you use). Thanks anyway.
https://bitbucket.org/multicoreware/x265/commits/b14834a9d1c1864ea7e94d9cfed4e33f37e767c6

But there should be a way to still set x265 aq-mode to 1 in StaxRip.

If it's a default value it doesn't show up in the command line.

I tweaked the default value just in case, Uploaded the changes to the Resp.

x265 docs don't post all the changes. It hard to figure the update value change.

[katzenjoghurt]

Hey Revan. :)

I usually forget that app even exist at times. It has not been updated since 1.7.


Whaaat? That thing is so awesome to check the output quality.


- You are loading a massive file into the code, it takes time to index & cache that file. It uses FFVideoSource as the source filter using AVS.


Sure...
But try to import a big video in 1.7.0.6 and afterwards try to import it in 2.0.0.0.
In the latter the application will freeze for some time after the indexing is done.


- Many of offset is usually based off the codec, filter, or if the fps is off by .1 even if it doesn't show it in info data.


Hm. So why could 1.7.0.6 behave different than 2.0.0.0 then?
I'm back to using the old version now again because... as I said the import often takes ages now due to the freeze and every second time I can't really work with it due to that 1 frame offset which won't occur in 1.7.0.6.

It's a pity I could only reproduce it with full movies and not with some free downloaded YouTube samples to give you a test case.


It's why it's usually a good idea to respec the video before encoding just incase something is off.


respec?


- There allot of elements to take into account like range, Depth, and the display. Most PC Monitors are only 8Bit. You will not get the full effect of 10Bit color.

You're addressing the color difference between 8bit and 10bit I mentioned?
It's really some issue in that comparison tool - as I don't see those color differences when comparing VLC snapshots.
It gets pretty obvious in dark scenes.
Some other user mentioned it already here and Stax replied to it:
https://forum.doom9.org/showthread.php?p=1831455#post1831455

I checked that part of the code Stax mentions and it indeed changed.
And it feels like the colors are at least less off now. Though I still see
some slight differences sometimes - not sure if that's due to encoding though.
Didn't compare these frames in VLC yet.

[Revan654]

Hey Revan. :)



Whaaat? That thing is so awesome to check the output quality.



I just forget it exist, There are allot of files needed to create Staxrip.



Sure...
But try to import a big video in 1.7.0.6 and afterwards try to import it in 2.0.0.0.
In the latter the application will freeze for some time after the indexing is done.

Hm. So why could 1.7.0.6 behave different than 2.0.0.0 then?
I'm back to using the old version now again because... as I said the import often takes ages now due to the freeze and every second time I can't really work with it due to that 1 frame offset which won't occur in 1.7.0.6.




ffms source filter & indexer is different but that's it. The app is unchanged. It could also be dotnet(I don't have control over this).

I could try to do what I did with the thumbnailer, Which skips the index completely and loads instantly. Some files do not get along with ffms.


youtube and such are reencoded using latest standards, It very unlikely those files would create any kind of issues.



respec?


It removes all the data and sets colormatrix and such to unspec. You would unspec like so(This function is already build in to the context menu):

clip = core.resize.Point(clip, matrix_in_s="unspec",range_s="limited")
clip = core.std.AssumeFPS(clip, fpsnum = int(%media_info_video:FrameRate% * 1000), fpsden = 1000)
clip = core.std.SetFrameProp(clip=clip, prop="_ColorRange", intval=1)


Just double check the framerate section, mediainfo and such can throw it slightly off.

When you respec it you might use something like so:

clip = core.fmtc.resample (clip, css="444")
clip = core.fmtc.matrix (clip, mats="709", matd="709")
clip = core.fmtc.resample (clip, css="420")
clip = core.fmtc.bitdepth(clip, bits=8, fulls = False, fulld = False)


Some files can have strange framerates, This was file from the web. unspec would properly scale to the correct rate.

https://i.imgur.com/LN2GsRW.jpg


You're addressing the color difference between 8bit and 10bit I mentioned?
It's really some issue in that comparison tool - as I don't see those color differences when comparing VLC snapshots.
It gets pretty obvious in dark scenes.
Some other user mentioned it already here and Stax replied to it:
https://forum.doom9.org/showthread.php?p=1831455#post1831455

I checked that part of the code Stax mentions and it indeed changed.
And it feels like the colors are at least less off now. Though I still see
some slight differences sometimes - not sure if that's due to encoding though.
Didn't compare these frames in VLC yet.

When dealing with color there allot to take into account, Plus VLC uses a very engine and it has multiple ways to render including GPU.

Like I said to get the fully 10 Bit you need a 10Bit monitor plus your GPU set completely.

Not sure if the viewer processes any of the alpha channels. That could be throwing things off too. I think it just uses the standard RGB.

[ukmark]

Oh, never mind, they changed default AQ-mode in x265 from 1 to 2 (it might differ which preset you use). Thanks anyway.
https://bitbucket.org/multicoreware/x265/commits/b14834a9d1c1864ea7e94d9cfed4e33f37e767c6

But there should be a way to still set x265 aq-mode to 1 in StaxRip.

You can set it under x265 'options' then use 'custom' section to enter '--aq-mode 1' and it will show up at the bottom next to the other x265 settings.

[katzenjoghurt]

Thanks for your reply Revan.
I will play around with it.

[Malonn]

I can't update Staxrip from within the program. If I do it through the interface (tools -> advanced -> update) nothing happens, no messages; nothing. If I do it via command line, it throws a "system.exception" error. Any ideas? Is this feature a known broken that I'm not aware of?

[Revan654]

I can't update Staxrip from within the program. If I do it through the interface (tools -> advanced -> update) nothing happens, no messages; nothing. If I do it via command line, it throws a "system.exception" error. Any ideas? Is this feature a known broken that I'm not aware of?

The html code changed on github, so the source code has to be updated.

[Malonn]

Oh, okay. You have to update StaxRip. Np, np. Now I know, and knowing is half the battle.

[Revan654]

You Can Grab New Builds at Here (https://ci.appveyor.com/project/Revan654/staxrip)

https://ci.appveyor.com/api/projects/status/j0alakgd5ahkyjmw?svg=true

These will range From Beta to Final, But will not contain any External Files.

[paauw]

qsvencc is working with this 2.0.0.1 build

thanx revan

[Revan654]

qsvencc is working with this 2.0.0.1 build

thanx revan

NP.

FYI, Appveyor Names the base number. Use the Info tab to get the real build number. The First one will be accurate after that not so much.

The Filesize is about .5 megs smaller compared to MSBuilder(VS 2017).

Any xml files or pdb files can be deleted.

[Revan654]

Slight Update(From The Pipeline):

2.0.0.1 (Pipeline Version: 2.0.0.3)

- Updated Video Comparison Form, Will No longer need to index the File before View the Video.
- x265: Reset Some of the Defaults to there New defaults.
- Core: ImageUtils(Moved MKV to ffms instead of Using L-Smash)
- Core: Updated Caption for Thumbnails(If No Audio Exists it will Will leave the Field Blank).
- Core: Slight Renaming of two of Menu Items(Nothing Major)
- Core: Slight Tweak to to Temp Folder Creator, Nothing Noticeable.
- x265: AQmode Tweaked
- XAA Temp Remove from AVS, Code Needs to be Re-Worked with New Syntax.
- VS: Updated DGIndexNV Load Function It now loads using it's native method instead of AVS load function.
- VS: G41Fun replaces hnwvsfunc
- VS: hnwvsfunc Script removed
- VS: fvsfunc functions updated
- VS: Auto-Deblock Added to Context Menu
- VS: nnedi3_rpow2 added to Script folder for Support.
- VS: Added FixTelecinedFades to Context Menu for RCR.
- Encoders: Rebuilt QVSEnc Encoder Code.
- x265: Has been updated to 3.0+RC*
- x265: Updated the Defaults to there New defaults.
- x264/x265 Control CRF: Updated the Range. It Starts at 12 CRF and Ends at default value of 28.

^Just Pushed a New Update Mainly for the new VS Script and altered source filter for ImageUtil.

Mpvnet Slightly Updated:
Link: https://github.com/Revan654/mpvnet/releases/download/2.0/Mpvnet.2.0.rar

[frenchfries]

Hey

I'm loading a test MKV into stax that I have just manually updated to 2.0.0.1/2.0.0.4 and also the mpvnet update and it's asking for handbrake. That seems weird to me.

Any comment on that?

[AVspace]

I also just installed the newest update and it's requiring me to install Handbrake same as the person above when i add a source file. Is this really necessary to the program now? I'd prefer not to use that in my encoding they were working fine without it.

If it uses Handbrake in any way to encode i'd sooner go back to the older version. I haven't good experiences with encoding using that in the past.

[AVspace]

In two-pass mode using a quick first pass can anyone inform me how to change a few of the first pass settings to achieve a slightly better quality? From what i read if you change a few things like raising the -me a few notches it gives you an improvement? In my command line it just shows the same settings as my main settings and i don't seem to be able to change anything.

[Revan654]

I also just installed the newest update and it's requiring me to install Handbrake same as the person above when i add a source file. Is this really necessary to the program now? I'd prefer not to use that in my encoding they were working fine without it.

If it uses Handbrake in any way to encode i'd sooner go back to the older version. I haven't good experiences with encoding using that in the past.

I kind bundle everything in single folder. VS2017/StaxRip scanned the Folder and picked it up. It will be fixed in the next Push.

Version: 2.0.0.5 will have it Removed.

It Should be up on the Site Shortly.

[Revan654]

In two-pass mode using a quick first pass can anyone inform me how to change a few of the first pass settings to achieve a slightly better quality? From what i read if you change a few things like raising the -me a few notches it gives you an improvement? In my command line it just shows the same settings as my main settings and i don't seem to be able to change anything.

Any Defaults will not Show up, Some require additional Options to become enabled.

Just be aware When No-Slow-pass is Enabled it also enables/changes these values:

--fast-intra --no-rect --no-amp --early-skip --ref 1 --max-merge 1 - -me DIA --subme 2 --rd 2

You also try use one of the lossless flags.

These are some of the Settings I use:

--output-depth 10 --aq-mode 1 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --no-info --no-deblock --no-sao --no-strong-intra-smoothing

The Last three options tends to detroy the detail in the picture. I have no idea why these are enabled by default.

This is one option that a major Studio uses with x265

--output-depth 10 --cu-lossless --limit-modes --aq-mode 1 --no-open-gop --pmode --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --repeat-headers --no-info --hrd --aud --no-deblock --no-sao --psy-rd 1 --no-strong-intra-smoothing

[AVspace]

I kind bundle everything in single folder. VS2017/StaxRip scanned the Folder and picked it up. It will be fixed in the next Push.

Version: 2.0.0.5 will have it Removed.

It Should be up on the Site Shortly.

Thanks for the update. I was easily able to go back to the previous version so it wasn't too much of an issue. I'll go for 2.0.0.5

[AVspace]

Any Defaults will not Show up, Some require additional Options to become enabled.

Just be aware When No-Slow-pass is Enabled it also enables/changes these values:

--fast-intra --no-rect --no-amp --early-skip --ref 1 --max-merge 1 - -me DIA --subme 2 --rd 2

You also try use one of the lossless flags.

These are some of the Settings I use:

--output-depth 10 --aq-mode 1 --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --no-info --no-deblock --no-sao --no-strong-intra-smoothing

The Last three options tends to detroy the detail in the picture. I have no idea why these are enabled by default.

This is one option that a major Studio uses with x265

--output-depth 10 --cu-lossless --limit-modes --aq-mode 1 --no-open-gop --pmode --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --repeat-headers --no-info --hrd --aud --no-deblock --no-sao --psy-rd 1 --no-strong-intra-smoothing

Oh, this is my fault. I forgot to mention i use 264. That's my bad.

That's still helpful though especially if i do some x265 encodes. So if it's a default value it doesn't show up in the bottom where it shows --pass 1 and i'd have to custom change it to show up. I find out what the default values for a quick first pass are and then manually adjust it. I found the "custom first pass" section in the settings so i just need to find out what the default values for a quick first pass are and enter any adjustment. I didn't realize stuff like this --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --no-info had much of an effect i have them all set to undefined i'll look more into this.

[Revan654]

Thanks for the update. I was easily able to go back to the previous version so it wasn't too much of an issue. I'll go for 2.0.0.5

There should be zero conflict switching between version from 2.0+ and using your Settings file.

[Revan654]

Oh, this is my fault. I forgot to mention i use 264. That's my bad.

That's still helpful though especially if i do some x265 encodes. So if it's a default value it doesn't show up in the bottom where it shows --pass 1 and i'd have to custom change it to show up. I find out what the default values for a quick first pass are and then manually adjust it. I found the "custom first pass" section in the settings so i just need to find out what the default values for a quick first pass are and enter any adjustment. I didn't realize stuff like this --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --no-info had much of an effect i have them all set to undefined i'll look more into this.

I no longer use x264, I just don't see the point.

The x264 doc hasn't been updated for years. Just Right click on the Text in x264 option(StaxRip) and it will show you the cli with it's default value(If argopt is proper typed out.)

colorprim is mainly triggers for videoplayers so it knows what settings to use when playing things back.

--no-info not sure if x264 has this option or not, It's just debug code. and it junks of the metadata.


THis is what I been using with x265, x264 should be similar.

--pass 1 --bitrate 140496 --output-depth 10 --limit-refs 1 --cu-lossless --aq-mode 1 --pmode --pme --colorprim bt709 --colormatrix bt709 --transfer bt709 --range limited --no-info --no-deblock --no-sao --psy-rd 1 --no-strong-intra-smoothing

Along with Medium Preset, 10Bit & Two Pass Mode(CBR Mode should never be used).

CRF is nice but you can not target a certain bitrate or size.

[AVspace]

It's mainly the speed benefit i get when using x264 and i was able to find very solid setting with x264 that give me good results and a look i like from being able to use higher settings with the faster encoding time.

"The x264 doc hasn't been updated for years. Just Right click on the Text in x264 option(StaxRip) and it will show you the cli with it's default value"

Thanks again. That worked.

[dev84]

Hello Revan654 thank You for keeping StaxRip alive, please tell me is Your 2.0.0. completely different software from original StaxRip 1.7.0 or is it compatible and old cfg files will work with new version or is it better to start it from zero and cfg it fresh?

Thx
Pawel

[Revan654]

Hello Revan654 thank You for keeping StaxRip alive, please tell me is Your 2.0.0. completely different software from original StaxRip 1.7.0 or is it compatible and old cfg files will work with new version or is it better to start it from zero and cfg it fresh?

Thx
Pawel

cfg file hasn't been used for ages. Everything uses .dat / srip format.

You will need to start Fresh.

[dev84]

ok, thx

[Revan654]

Python has breaking very easily as of late. This is the second time it broke without me even touching it. It finally started to work once I installed numpy & Pillow.

[brucethemoose]

Python has breaking very easily as of late. This is the second time it broke without me even touching it. It finally started to work once I installed numpy & Pillow.

You're using a portable python, right? Forgive me, its been a few months since I installed Staxrip, so I can't remember if it's an external dependency or included in the download.

Anyway, I've been fed up with Python too, which is why I love the portable install the VS Fatpack uses. It seems to be immune to borked system installs, and worst case, you can just delete the whole Python directory and restore it from an archive without hunting down other settings a regular install spreads through your system.

[Revan654]

You're using a portable python, right? Forgive me, its been a few months since I installed Staxrip, so I can't remember if it's an external dependency or included in the download.

Anyway, I've been fed up with Python too, which is why I love the portable install the VS Fatpack uses. It seems to be immune to borked system installs, and worst case, you can just delete the whole Python directory and restore it from an archive without hunting down other settings a regular install spreads through your system.

I had Anaconda installed since I needed Python Dev IDE, Since MS has no plans to update Python to 3.7 until VS 2019 gets released.

Flatpack is also almost triple the size of the base python.

StaxRip uses VFW for the preview window which requires access to the registry, It needs the python & VS registry keys. Yes you could add manually keys but it's not worth effort when install does all this work for you already. Nor the risk of screwing up your registry.

I wish there was a way to package VS into a single exe file and use it in that form. Don't think that is possible due to how VS works and how many external resources are needed.

[Schattenspieler]

You Can Grab New Builds at Here (https://ci.appveyor.com/project/Revan654/staxrip)Is what we want to download behind the "Artifacts" button? There is one StaxRip.zip with an executable and some libs and stuff in there.
Sorry if this seems like a stupid question, but there are no hints and the FAQ doesn't cover that.

[Revan654]

Is what we want to download behind the "Artifacts" button? There is one StaxRip.zip with an executable and some libs and stuff in there.
Sorry if this seems like a stupid question, but there are no hints and the FAQ doesn't cover that.

Artifact = Package Files. So, Yes.

[Schattenspieler]

Sry, didn't know and the faq there doesn't give clues. I'm used to "artifacts" being usually unwanted visual or acustic leftovers from processing videos.
Learned smth. new today! (:

[sellers]

You Can Grab New Builds at Here (https://ci.appveyor.com/project/Revan654/staxrip)

https://ci.appveyor.com/api/projects/status/j0alakgd5ahkyjmw?svg=true

These will range From Beta to Final, But will not ladbrokes bonus code (https://top10casinobonuscodes.com/ladbrokes-promo-codes) contain any External Files.

Thanks!

[Z'Hadum]

Hello Revan654,
in the latest (test) Version (2.0.0.6):
It seems that importing the encoder options does not work correct:
For example if I import the following Commandline:
--crf 20 --preset slower --tune grain --level-idc 5.1 --rd 5 --ctu 32 --psy-rdoq 4 --aq-strength 0.9 --qcomp 0.65 --cbqpoffs -3 --crqpoffs -3 --vbv-bufsize 160000 --vbv-maxrate 160000
--pbratio 1.2 --rc-lookahead 80 --min-keyint 1 --keyint 240 --no-strong-intra-smoothing --psy-rd 2.5
The Option "no-strong-intra-smoothing" is not set.

Another very small issue:
it seems the psy-rd Parameter is not in your menu or I can't find it (I found only psy-rdoq).
Afaik in past versions this options had a dedicated switch


Last but not least: :thanks: for your work. :)

regards
Z'Hadum

[Revan654]

Hello Revan654,
in the latest (test) Version (2.0.0.6):
It seems that importing the encoder options does not work correct:
For example if I import the following Commandline:
--crf 20 --preset slower --tune grain --level-idc 5.1 --rd 5 --ctu 32 --psy-rdoq 4 --aq-strength 0.9 --qcomp 0.65 --cbqpoffs -3 --crqpoffs -3 --vbv-bufsize 160000 --vbv-maxrate 160000
--pbratio 1.2 --rc-lookahead 80 --min-keyint 1 --keyint 240 --no-strong-intra-smoothing --psy-rd 2.5
The Option "no-strong-intra-smoothing" is not set.

Another very small issue:
it seems the psy-rd Parameter is not in your menu or I can't find it (I found only psy-rdoq).
Afaik in past versions this options had a dedicated switch


Last but not least: :thanks: for your work. :)

regards
Z'Hadum

psy-rd is in Other Menu at the bottom, It will only show up if it differs from the defaults(Defaults have changed recently).

Import function will only enable switches not disable them.

[Vesdaris]

Hey guys, I wanted to ask you, how is the quality of nvenc hevc 10 bit encodes on the latest nvidia gpus (Turing)?

If you set every setting to get the best quality out of it how would nvenc hevc 10 bit fare against a software hevc 10 bit? I don't care about the size being larger than hevc software endode coz it would be still smaller than x264 encode.=)

I know hardware encoders were notoriously bad once but afaik they have been getting better.

Thank you

[videoh]

The nVidia Video SDK 9 required for Turing is not yet available (Coming Soon! :sly:). So nobody can answer that yet.

[IbrahimKh]

Hi, where can I get the latest build (2.0.0.6)?
I have no idea where is the download button here https://ci.appveyor.com/project/Revan654/staxrip
and https://github.com doesn't have v 2.0.0.6

[Vesdaris]

The nVidia Video SDK 9 required for Turing is not yet available (Coming Soon! :sly:). So nobody can answer that yet.


Ah I see.. I didn't know that.

What about Pascal's hevc 10bit encodes quality? Still unacceptable?

[gonca]

Ah I see.. I didn't know that.

What about Pascal's hevc 10bit encodes quality? Still unacceptable?

They are decent enough

[Vesdaris]

When I try to install FFTW I get this error

https://imgur.com/a/fnfGd6e

Any ideas on how to fix this?

Cheers

[Episodio1]

When I try to install FFTW I get this error

https://imgur.com/a/fnfGd6e

Any ideas on how to fix this?

Cheers

I got the same error. The DLL's needed are in \StaxRip\Apps\Support\FFTW
1.) Copy 3 of them to \windows\system32
2.) Staxrip will detect them but it expects FFTW version 3.3.6. Press on "VERSION" in staxrip and type in: 3.3.8

[Revan654]

When I try to install FFTW I get this error

https://imgur.com/a/fnfGd6e

Any ideas on how to fix this?

Cheers

Your still using the beta build, This had been fixed with Final Release or Pipeline.

[Revan654]

New Pipeline Build: https://ci.appveyor.com/project/Revan654/staxrip/build/artifacts

Added Merge: Chapter Cutting Feature to MkvMuxer (Credit: wybb)

Not Sure how it works yet, Since I have not tested it.

[jkilez]

Sure...
But try to import a big video in 1.7.0.6 and afterwards try to import it in 2.0.0.0.
In the latter the application will freeze for some time after the indexing is done.

Hm. So why could 1.7.0.6 behave different than 2.0.0.0 then?
I'm back to using the old version now again because... as I said the import often takes ages now due to the freeze and every second time I can't really work with it due to that 1 frame offset which won't occur in 1.7.0.6.
ffms source filter & indexer is different but that's it. The app is unchanged. It could also be dotnet(I don't have control over this).
There definitely is a problem with the "ffmsindex.exe" included in the 2.0 package. The problem apparently does not occur when the indexing time is short, but when indexing takes more than 3-4 minutes, the indexer will actually index the file *twice*, causing StaxRip to hang while it does the second pass. The problem disappears if you replace the FFMS2 files in the 2.0 package with those from the 1.9 package.

[mcjordan]

NVEnc v4.3.1 by rigaya

Changelog:

Finally NVENC SDK 9.0 was released, so I updated it with a scatch.

[Common]
Updated to NVENC SDK 9.0. NVIDIA graphics driver 418.81 or later required.
Added B ref mode setting for HEVC encoder. (--bref-mode middle / each)

[NVEnc.auo]
- Added "quality (--preset)" and "B frame reference mode (--bref-mode)" on the setting screen.

[NVEncC]
Added --preset to readme.

According to NVENC SDK, the update point of Turing's NVENC function is as follows.

Improvement of compression efficiency by supporting B frame in HEVC.
* Other improvements in both H.264 / HEVC. Support by referring to RDO (distortion rate optimization) and multiple frames.

** important point **
Of Turing, only TU 117 (GTX 1650x) Does not support HEVC B frame, that is, TU 116 (GTX 1660x) Supports HEVC B frame in reverse.
Does it mean that TU117 does not change so much with GP 107, even if it is not bad? Even so, I do not want such a confusing thing.

https://github.com/rigaya/NVEnc/blob/master/NVEncC_Options.en.md

[Revan654]

There definitely is a problem with the "ffmsindex.exe" included in the 2.0 package. The problem apparently does not occur when the indexing time is short, but when indexing takes more than 3-4 minutes, the indexer will actually index the file *twice*, causing StaxRip to hang while it does the second pass. The problem disappears if you replace the FFMS2 files in the 2.0 package with those from the 1.9 package.

The source code from 1.9 and 2.0 comes from the same place and the indexing code is unchanged. It's very possible the source is the issue.

[Revan654]

FYI, Here New Released Program of mine, Contact Sheet Maker Using WPF Framework. Also There a Winform version if you prefer. It uses AVS+ Portable along with ffms2 / L-Smash source filters to create the Contact Sheet.

Link: https://github.com/Revan654/Thumbnailer/releases

https://raw.githubusercontent.com/Revan654/Thumbnailer/master/Docs/Screenshots/WPFPreview.png

[jkilez]

The source code from 1.9 and 2.0 comes from the same place and the indexing code is unchanged. It's very possible the source is the issue.
You had just stated in previous post that the indexer *was* changed, and it is obvious that it has. Even the index files it creates are different from the indexer included in the 1.9 package.

From the 1.9 distro (\Apps\Plugins\Both\FFMS2\):
09/15/2018 08:28 PM 35,147 COPYING.GPLv3
02/12/2019 01:54 PM <DIR> doc
09/15/2018 08:28 PM 6,779 FFMS2.avsi
09/15/2018 08:28 PM 31,737,068 ffms2.dll
01/01/2018 03:25 PM 15,656,960 ffms2k.dll
09/15/2018 08:28 PM 3,462,877 ffmsindex.exe
5 File(s) 50,898,831 bytes

From the 2.0 distro (\Apps\Plugins\Both\FFMS2\):
02/10/2019 12:42 PM 35,147 COPYING.GPLv3
02/12/2019 01:52 PM <DIR> doc
02/10/2019 12:42 PM 6,779 FFMS2.avsi
02/10/2019 12:42 PM 31,737,068 ffms2.dll
02/10/2019 12:42 PM 13,276 ffms2.lib
02/10/2019 12:42 PM 16,110,080 ffms2k.dll
02/10/2019 12:42 PM 15,958,528 ffmsindex.exe
6 File(s) 63,860,878 bytes

Edit: Note that moving "ffmsindex.exe" from the 2.0 package to 1.9 causes 1.9 to have the same problem. There is either a problem with that version of "ffmsindex.exe" or a problem with how that version interacts with StaxRip.

[jkilez]

I have a relatively easy enhancement (or fix) request.

The Problem: When encoding with xvid_encraw using the "-progress" option, the little status bar in the "job processing" window does not get used, and the actual log file gets filled up with many lines of progess updates. This is not a problem if the "-progress" option is not used, but that default output is not as useful as the "-progess" output, which looks like this:
1441 frames( 19%) encoded, 40.45 fps, Average Bitrate = 4856kbps
1451 frames( 19%) encoded, 40.34 fps, Average Bitrate = 4884kbps
1461 frames( 20%) encoded, 40.28 fps, Average Bitrate = 4899kbps
1471 frames( 20%) encoded, 40.23 fps, Average Bitrate = 4911kbps
The Fix: Add another SkipString definition for "xvid_encraw" so that the "-progress" output is properly processed.

In file "Encoding\VideoEncoder.vb" lines 517-527 (changes in red):
Function GetSkipStrings(commands As String) As String()
If commands.Contains("xvid_encraw") Then
Return {"key=", "frames("}
ElseIf commands.Contains("x264") Then
Return {"%]"}
ElseIf commands.Contains("NVEnc") Then
Return {"frames: "}
Else
Return {" [ETA ", ", eta ", "frames: ", "frame= "}
End If
End Function
As this output includes a percentage value, it would also allow the little graphical progress bar in the "job processing" window to function when encoding with Xvid.