StaxRip

[stax76]

It's in the 'Misc' section, I'll move it to the field section.

[NikosD]

I don't know if I'm doing something wrong, but for me the main drawback left for StaxRip is the lack of flexibility regarding video source changes in the same session.

For example, I choose a video source from the "Automatic" menu of options or a specific source manually.

If for whatever reason I want to change to another one (due to an error in the specific source regarding the specific file or to test which source is faster to the specific file etc) I always (almost) have to CLOSE the app, DELETE the temp files and RE-OPEN StaxRip just to change source!

Because if I don't to do that sequence of operations, the most probable thing to happen is a crash of the app.

There are only a few times that I can change video source without closing the app and deleting temp files and StaxRip allows me to continue without crashing.

This is a time-consuming and mainly frustrating situation and I think that StaxRip should have a more robust workflow allowing video source change in the same session, especially when the app has a broad choice of video source by design and counts on them in order to read a video file.

Because if a source fails to open a file, there is a possibility another source to manage to open it and sometimes you have to check all of them in order to achieve maximum compatibility and performance.

[stax76]

I can't follow you here, if you want another source filter you can just use the context menu, a new feature is that this works even with DGDource, you can switch from FFVideoSource to DGDource dynamically and vice versa from DGSource to FFVideoSource, indexing happens automatically if necessary. If you want another source file, you can just open it on.

[NikosD]

OK.

I use FFVideo source and all things go well and finishes the transcoding.

Without closing the app, I want to try on the same clip, just after FFVideo another source like LWLib or LSMASH etc so I change source from the left menu.

The change of source for the same already transcoded clip is crashing the app.

How could I do that without crashing StaxRip ?

[stax76]

If it's reproducible for me I can take a look, if it's not reproducible for me like a few issues reported recently then it will be difficult.

[NikosD]

First of all I'm doing the tests with the default settings, after decompression of the app without any change in the preferences.

It happens "all the time" with me, maybe because I usually try difficult clips, that it is possible that some sources (or all of them) can't handle properly.

I'll try again with easier clips and report back.

On the other hand, a good test would be to transcode a clip with one source successfully, close the app and rerun the transcode successfully choosing another source.

If the app fails to successfully transcode the clip twice in one session using two different sources, then it's definitely an issue for the app.

[stax76]

If you use TS regularly which I think you do than it's the first explanation for why you see problems, TS is notorious for causing problems, best source filter for TS is clearly DGSource.

[cegy]

Originally Posted by stax76

@NikosD

Thanks for the feedback, here is a further improved build:

https://www.mediafire.com/folder/0jakce45o99kb/StaxRip

@Lupissimo

It should be there when you reset the profiles, there is a reset button in the profiles editor.

hi, stax76 i can confirm both the template dialog isn't being asked when giving it another new file (uses the template from before ) which is nice and i was shocked to notice the x264 stats which i was on about are also now showing in the log file
many once again for the understanding of what we've missed from the older staxrip (only a few things really )

p.s. for the codec comparison is there away for it to detect if vapoursyth is installed or not and if not tell the user its needed before using the codec comparison (one minor thing)

[stax76]

Originally Posted by cegy

hi, stax76 i can confirm both the template dialog isn't being asked when giving it another new file (uses the template from before ) which is nice and i was shocked to notice the x264 stats which i was on about are also now showing in the log file
many once again for the understanding of what we've missed from the older staxrip (only a few things really )

p.s. for the codec comparison is there away for it to detect if vapoursyth is installed or not and if not tell the user its needed before using the codec comparison (one minor thing)

There is now a option in the settings dialog for either showing the template selection dialog or loading the default template.

I'm glad the x264 log problem is gone and hope it don't happen again (I've not changed any relating code).

For the video comparison VapourSynth shouldn't be needed, I checked the code, it's always using AviSynth+ and FFVideoSource.

[cegy]

Originally Posted by stax76

There is now a option in the settings dialog for either showing the template selection dialog or loading the default template.

I'm glad the x264 log problem is gone and hope it don't happen again (I've not changed any relating code).

For the video comparison VapourSynth shouldn't be needed, I checked the code, it's always using AviSynth+ and FFVideoSource.

oh i wasn't aware of that lol

[Yups]

Originally Posted by stax76

Latest QSVEncC fixes it.

Possibly because he switched to bframes 2 as new default. Because of this change the GUI needs an update.

GUI default says bframes 3


Converted with bframes 2



Does anyone know what Ext. Features PerMBRC means?

[Yups]

http://rigaya34589.blog135.fc2.com/blog-entry-672.html


According to the feature table Ext_BRC and MBBRC is supported in HEVC VBR bitrate mode. For some reason it doesn't work, no effect.

PerMBRC seems to be MBBRC by the way, doesn't work though.

[stax76]

Possibly because he switched to bframes 2 as new default. Because of this change the GUI needs an update.

Next build has it fixed.

[NikosD]

I’ve just read an older post regarding the first benchmarks of the new HW decoding mode of QSVEncC.

My older benchmarks:

1) Core i7 4790 – Win 8.1 x64 Pro – iGPU HD 4600@1.5GHz – Drivers 4206
StaxRip x64 (1.3.1.2)/ QSVEncC x64 (v2.00β3)

I used CQP encoding mode using the default value of 24 with Balanced target usage and everything else set to Auto (default)
I didn’t use Audio encoding (Just Mux option or Auto Pass-through)

H.264 – Eclectic-1080p clip – 11Mbps

StaxRip x64 QSV 301 fps


The new results:

2) Core i7 4790 – Win 10 x64 Pro – iGPU HD 4600@1.5GHz – Drivers 4256
StaxRip x64 (1.3.1.2)/ QSVEncC x64 (v2.00β3)

H.264 – Eclectic-1080p clip – 11Mbps

StaxRip x64 QSV 230 fps



3) Core i7 4790 – Win 10 x64 Pro – iGPU HD 4600@1.5GHz – Drivers 4256
StaxRip x64 (1.3.1.6)/ QSVEncC x64 (v2.12)


H.264 – Eclectic-1080p clip – 11Mbps

StaxRip x64 QSV 201 fps (!)


My goodness (!)

The rise of performance using the older drivers and older QSVEncC version is 100 fps -> 50 %.

I gain 35% using older drivers and 15% using older QSVEncC.

Intel has done a disastrous job with drivers but QSVEncC looses some power too.

[JohnLai]

Driver and the program itself?
I was expecting the driver to be the issue....didn't expect the program itself also one of the cause (30fps gone from using new QSVenc? wow...)

*Now that might explains the anomaly of the QSV decode + resizing (vpp) slowdown*

Someone gonna report these issue to Rigaya and Intel........(~.~ I leave the task to you, @NikosD)

[NikosD]

Of course I have already done that even from version v2.06 which has the same speed like v2.12

He knows it, but haven't managed to resolve it yet.

A lot of stuff has been added to v.200 onwards and he is continuously adding more things.

[Yups]

ICQ bitrate mode works much better in HEVC mode, faster and much better quality at the same bitrate.

VBR
http://abload.de/img/vbrkikr1.png


ICQ
http://abload.de/img/icqc9ko3.png

[RazorBurn]

Thanks stax for adding KNLMeansCL in StaxRip. Would it be possible to add Chroma Processing in KNLMeansCL for both AVS+ and VS in StaxRip?

Vapoursynth:

y = core.std.ShufflePlanes(clip, planes=[0], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
u = core.std.ShufflePlanes(clip, planes=[1], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
v = core.std.ShufflePlanes(clip, planes=[2], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
clip = core.std.ShufflePlanes([y, u, v], planes=[0, 0, 0], colorfamily=vs.YUV)

AVS+

Y=KNLMeansCL(device_type="GPU")
U=UToY8().KNLMeansCL(device_type="GPU")
V=VToY8().KNLMeansCL(device_type="GPU")
YToUV (U, V, Y)

Im mostly encoded Surveillance Videos with a cheap USB Webcam, the night time videos has a lot of Chroma noise..

[stax76]

Originally Posted by RazorBurn

Thanks stax for adding KNLMeansCL in StaxRip. Would it be possible to add Chroma Processing in KNLMeansCL for both AVS+ and VS in StaxRip?

Vapoursynth:

y = core.std.ShufflePlanes(clip, planes=[0], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
u = core.std.ShufflePlanes(clip, planes=[1], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
v = core.std.ShufflePlanes(clip, planes=[2], colorfamily=vs.GRAY).knlm.KNLMeansCL(device_type="GPU")
clip = core.std.ShufflePlanes([y, u, v], planes=[0, 0, 0], colorfamily=vs.YUV)

AVS+

Y=KNLMeansCL(device_type="GPU")
U=UToY8().KNLMeansCL(device_type="GPU")
V=VToY8().KNLMeansCL(device_type="GPU")
YToUV (U, V, Y)

Im mostly encoded Surveillance Videos with a cheap USB Webcam, the night time videos has a lot of Chroma noise..

I'm not sure if the current system is good for adding too much code, currently all filters are loaded on startup and all settings are stored in one settings file. Deserializing the settings file takes half of the startup time and everything is always loaded in memory. There is also the problem whenever I reset the filter profiles, customizations are lost. Before adding much filter code I should probably first think about if I can find a better design being more efficient in regard of startup time and memory consumption and with better usability not resetting customizations all the time. In the next release various new plugins will be added so the filter profiles must be reset again.

[cegy]

stax76 is there a minor bug with preview as if the user clicks on crop the video is smaller (which is normal/good) than the whole screen for the input video of say 1920x1080 yet... for preview its full screen (as in the whole screen is covered) even if the video res is set at a smaller res say 1280x720 etc.. ?
where i'm sure when you click on preview it shows you what the output should be filters/video res wise

p.s the filename_preview.avs even shows the resizing aswell i.e LanczosResize(1280, 720) but it doesn't make any differences