StaxRip

[Atlantis]

I just spend time to reconfigure from zero, please say you only added Neo FFT3D. I already added it myself. :)

Update: ok I see more has been changed in the package. I'm going to re-download and overwrite it without re-configuring again, that would be ok I guess?

[JKyle]

A couple more.
Re-download the file, just overwrite the existing Apps folder with the new one.

[JKyle]

I see that in the new version we get muxing timestamps in mkv. I have done a little research but don't get it. Why do we need it? We didn't use it before. Is it only for syncing audio and video? if yes why it worked before without it.

It's to prevent audio sync issues when the mediainfo is incorrectly recorded as CFR by some apps like OBS.
See this post on the Issue Tracker (https://github.com/staxrip/staxrip/issues/730#issuecomment-861119949).
It didn't work right before when we could extract timestamps from only VFR MKV files.

[JKyle]

FYI, there's a lot of change in the filter profiles/menus in v2.7.0.

For those of you who just overwrite the files (although not recommended officially): do not forget to

1) backup your own custom filter profiles

2) restore the default profiles

https://i.imgur.com/Ff1nBzHl.png

3) and then add your custom filter profiles again

to see the new changes. Same for VapourSynth.


And don't forget to update your old settings by taking similar steps as above for each and every menu, profile, template, setting, etc.

And in case you're using installed frameservers (AVS or VS), try switching b/w portable and installed (installed -> portable -> installed, restarting StaxRip each step) to purge any remaining garbage in the settings file.

[user77777]

What could be the problem?
https://www.upload.ee/image/13343313/16.41.45.png

[JKyle]

@everyone,

You need to replace SMDegrain.avsi with the following updated file in order to avoid SMDegrain errors in v2.7.0.

SMDegrain.avsi (https://cdn.discordapp.com/attachments/850730860654624829/869312727779270707/SMDegrain.avsi) (version: 3.1.2.115s)

Location:

<StaxRip-Folder>\Apps\Plugins\AVS\SMDegrain\SMDegrain.avsi

There was some internal function name changes along the way and this will definitely cause script errors if you keep using the shipped script file SMDegrain.avsi. So please make sure to update the file.

[Atlantis]

Anyone experiencing that the new version is slower? Not the encoding, talking about staxrip itself, it seems it does the usual stuff slower than the past version.

[user77777]

Replaced the file with a new SMDegrain.avsi (version: 3.1.2.115s) - one nothing has changed (
https://www.upload.ee/image/13344627/06.12.37.png
https://www.upload.ee/image/13343313/16.41.45.png

[JKyle]

@user77777

SMDegrain update was not intended specifically for your case.

Your error cannot be reproduced.

Google 'Platform returned code 1114'.

[lordalibaski]

I had this problem because I use an old Xeon CPU so had to install an older version of JPSDR


Apps - Manage - Search - JPSDR - Auto Update - let it download and choose the correct version for your system I had to choose Release_XP_SSE2 and it fixed this issue.

[SupermanTV]

Hi everyone,
I am currently digitizing my old DVs and DVDs: deinterlacing, etc. and I'm wondering if Staxrip handles color subsampling differently now.

Images: (from DV yuv411 / DVD yuv420)
- Original DV 4-1-1 capture.
- Staxrip encode from 2019: bit darker/contrast.
- Staxrip 2.7.0 (and other recent versions): Notice the change in red tone.. Seems like there's a yellowish tint overall in the newer Staxrip encode...

I'm hoping maybe someone can test this with older DVs out there to confirm, so I can get a better idea about this.

Thanks a lot for any input!!


**My script: (MOV ProRes SD or HQ)
- Automatic Source:
tcFile = "%temp_file%_timestamps.txt" # timestamps file path
Exist(tcFile) ? FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex", timecodes=tcFile) : FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex")
ConvertToYUV420()

- Crop(8, 6, -16, -10)
- QTGMC(preset="Very Slow", InputType=0, sourceMatch=3, lossless=2, sharpness=0.5, tr2=3, ediThreads=8)
Prefetch(7)
- KNLMeansCL(D=1, A=1, h=2, device_type="auto")
- nnedi3_rpow2(rfactor=2, cshift="LanczosResize", fwidth=960, fheight=720)

[Atlantis]

Did some tests. So I'm not liking this timestamps thing. I encoded a video. When I jump to a frame number for example, then when I go to the same number on the source, it is not the same frames. It's 2 different frames assigned to the same frame number. This is troubling for me so I'm not going to use them.

[fredlkrue]

Did some tests. So I'm not liking this timestamps thing. I encoded a video. When I jump to a frame number for example, then when I go to the same number on the source, it is not the same frames. It's 2 different frames assigned to the same frame number. This is troubling for me so I'm not going to use them.

Same here, it shows different output frame rate.

Source: 23.976 fps
Output: 23.8095 fps

[JKyle]

Timestamps extraction for MKV files is not hard-wired in the new version. It's an option for the templates/projects.

https://i.imgur.com/t9B6BYhl.png

If it doesn't help, you can turn it off.
Do you have any issue with turning it off in your startup or favorite templates?

[Atlantis]

No, I'm just saying I am not going to use it.

It's strange that it does that. Why the frame numbers should change and not point to the same image? Is it normal?

[JKyle]

No, I'm just saying I am not going to use it.

I don't think I need to persuade you to use it.

If you think it's not working as expected but you can't help but use it, report a bug with concrete evidence.

Like I pointed out, the new timestamps extraction feature is obviously helpful for some users with some videos. As always, there is no universal cure-all in video encoding. If the new feature doesn't work right, then maybe it's not fit for the specific video, or a bug. If you are sure it's a bug, submit a bug report with a valid log or any supporting material.

But in this case, it's obviously different: you can always opt out of this new feature in Options. I truly don't understand why you keep complaining about things that you can choose not to use in the first place.

[JKyle]

In case you enabled timestamps extraction, chose MKV as the output format, and there is a change in frame numbers/frame rate/duration, the Assistant is supposed to issue a warning/suggestion as follows in v2.7.0:

https://i.imgur.com/ilOm9Yzl.png

If you are sure the Assistant does not warn about those changes, then plz report a bug with a valid example.

[Atlantis]

I truly don't understand why you keep complaining about things that you can choose not to use in the first place.

I truly don't understand what you are saying and why you are saying these things. Please give examples of things you think I keep complaining. Your post is a false statement. I do not keep complaining about stuff.

In case you don't know, this is a forum, not your personal home. A forum is a place for people to discuss. So when I notice new stuff I write here to discuss with people. I'm not sending letters to your home. In case you are not interested in a subject matter, it is very easy, you just ignore it. So please stop complaining about posts you don't like. You ignore them. It is very easy. I do it all the time.

[JKyle]

Please give examples of things you think I keep complaining. Your post is a false statement. I do not keep complaining about stuff.

So,

God knows how many times, how many years ago I asked please like for Audio and Subtitles, add buttons ALL and NONE for attachments. If we had those, at least we could deselect all with buttons.

Something wanted to say for a long time about the main window. The size is fixed, can't it be resizable?

If it is hard to program it that way and fixed is easier, at least it should be a little larger. It's too small for today needs. For example I have 8-9 filters and would like to see them all at once and not to scroll.

these were not complaints?

And putting several posts about the same topic (timestamps) over and over without providing any supporting material is not a complaint?

They sound just like complaints to me.

Many developers and contributors including @stax76, @44vince44, and me have repeatedly asked that users please be a little bit more cooperative by posting issue reports and feature requests on the GitHub repo with logs, error messages, and samples. And you squarely declined it and insisted on posting here claiming that you are just giving advice and suggestions.

Well, OK. Even though I feel uncomfortable with the way you present your arguments,

...you just ignore it.

I will.

[chipxtreme]

Is it just me but I just went to auto update NVEnc and MKVToolnix to latest versions on 2.7.0 and it failed. In previous versions always worked. Working again in 2.8.0

[SupermanTV]

Anyone?? I'd appreciate any help.


Hi everyone,
I am currently digitizing my old DVs and DVDs: deinterlacing, etc. and I'm wondering if Staxrip handles color subsampling differently now.

Images: (from DV yuv411 / DVD yuv420)
- Original DV 4-1-1 capture.
- Staxrip encode from 2019: bit darker/contrast.
- Staxrip 2.7.0 (and other recent versions): Notice the change in red tone.. Seems like there's a yellowish tint overall in the newer Staxrip encode...

I'm hoping maybe someone can test this with older DVs out there to confirm, so I can get a better idea about this.

Thanks a lot for any input!!


**My script: (MOV ProRes SD or HQ)
- Automatic Source:
tcFile = "%temp_file%_timestamps.txt" # timestamps file path
Exist(tcFile) ? FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex", timecodes=tcFile) : FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex")
ConvertToYUV420()

- Crop(8, 6, -16, -10)
- QTGMC(preset="Very Slow", InputType=0, sourceMatch=3, lossless=2, sharpness=0.5, tr2=3, ediThreads=8)
Prefetch(7)
- KNLMeansCL(D=1, A=1, h=2, device_type="auto")
- nnedi3_rpow2(rfactor=2, cshift="LanczosResize", fwidth=960, fheight=720)

[guest]

Hi everyone,
I am currently digitizing my old DVs and DVDs: deinterlacing, etc. and I'm wondering if Staxrip handles color subsampling differently now.

Images: (from DV yuv411 / DVD yuv420)
- Original DV 4-1-1 capture.
- Staxrip encode from 2019: bit darker/contrast.
- Staxrip 2.7.0 (and other recent versions): Notice the change in red tone.. Seems like there's a yellowish tint overall in the newer Staxrip encode...

I'm hoping maybe someone can test this with older DVs out there to confirm, so I can get a better idea about this.

Thanks a lot for any input!!


**My script: (MOV ProRes SD or HQ)
- Automatic Source:
tcFile = "%temp_file%_timestamps.txt" # timestamps file path
Exist(tcFile) ? FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex", timecodes=tcFile) : FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex")
ConvertToYUV420()

- Crop(8, 6, -16, -10)
- QTGMC(preset="Very Slow", InputType=0, sourceMatch=3, lossless=2, sharpness=0.5, tr2=3, ediThreads=8)
Prefetch(7)
- KNLMeansCL(D=1, A=1, h=2, device_type="auto")
- nnedi3_rpow2(rfactor=2, cshift="LanczosResize", fwidth=960, fheight=720)

Well, first of all, if you want someone to "see" the examples, you need to attach them a different way, as sometimes they can take a long time to be "approved", so no one can view them. Imgur for example.

So clearly something has been changed or modified from build to build, hence the different results.

[TomSmith]

Hi,

for some time I do have a problem with the VCEencC. I just installed StaxRip 2.7 to solve it but it is still not going to work...

Right now the error is:
GPU #0 (AMD Radeon RX 5700) [H.265/HEVC] does not support input format P010.
Finished with error in VCEEncC

I don't know where I did anything to set the input format to P010.

Using StaxRip 2.6 it was the same error but showing - if I remember correctly - 'nv12'.

If there is someone knowing anything about this error and how to fix it, let me know, please.

Kind regards,


Found the answer... VCEEncC 6.13 has to be used to avoid this error.

[SupermanTV]

Well, first of all, if you want someone to "see" the examples, you need to attach them a different way, as sometimes they can take a long time to be "approved", so no one can view them. Imgur for example.

So clearly something has been changed or modified from build to build, hence the different results.

Thank you for replying, and the advise!!
I'll try with Imgur.

[SupermanTV]

Trying again with url to my images:
https://imgur.com/a/PPvX0JC


Hi everyone,
I am currently digitizing my old DVs and DVDs: deinterlacing, etc. and I'm wondering if Staxrip handles color subsampling differently now.

Images: (from DV yuv411 / DVD yuv420)
- Original DV 4-1-1 capture.
- Staxrip encode from 2019: bit darker/contrast.
- Staxrip 2.7.0 (and other recent versions): Notice the change in red tone.. Seems like there's a yellowish tint overall in the newer Staxrip encode...

I'm hoping maybe someone can test this with older DVs out there to confirm, so I can get a better idea about this.

Thanks a lot for any input!!


**My script: (MOV ProRes SD or HQ)
- Automatic Source:
tcFile = "%temp_file%_timestamps.txt" # timestamps file path
Exist(tcFile) ? FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex", timecodes=tcFile) : FFVideoSource("%source_file%", cachefile="%source_temp_file%.ffindex")
ConvertToYUV420()

- Crop(8, 6, -16, -10)
- QTGMC(preset="Very Slow", InputType=0, sourceMatch=3, lossless=2, sharpness=0.5, tr2=3, ediThreads=8)
Prefetch(7)
- KNLMeansCL(D=1, A=1, h=2, device_type="auto")
- nnedi3_rpow2(rfactor=2, cshift="LanczosResize", fwidth=960, fheight=720)

[Fishman0919]

I'm try to use --hme-search star,sea,full but the encoder fails to start.

Any ideas?


... after testing with ffmpeg and x265.exe (x265-3.5+11-c8905a7 and x265-3.5+12+14-106329cbd-[Mod-by-Patman])... seems to be an encoder issue... using sea and fulll at the same time fails.

[Atlantis]

The release between v2.7.0 and v2.8.0 was so close! Only 6 days.

[BobDig]

"Timestamps extraction for MKV files" is not working for me too, guys please remove it.
It will make an encoding useless because it is crashing in the end. How can this be the default?

If the warning appears, you have to go the container settings, then you have to select the full path of the Timestamps extraction-file with the cursor and press delete. Why? If you ignore this message the endfile will be unplayable and or staxrip crashes after the encoding.

The alternative is to close staxrip, delete the temp folder and then start fresh and deselecting this feature under options before you do anything else.

Third thing to do is to create a template. But no new user or noobie will do that.

In my eyes you are destroying this project with over complicating things..., who asked about this feature in the first place.

[Atlantis]

Just don't use it. No need to remove it. As it was explained before, disable it in the options.

[Morku]

Hi, I am new to StaxRip and have a question.
Everytime I select a Source, the whole video will get Demux e.g. hevc. Depending on videofile, this can be huge. The documentation says, I can "2. Only audio and subtitle streams of preferred languages are automatically demuxed." what I would prefer. In Options -> Video -> "Demux Video" is already unchecked. It Demux the hevc anyway. Is it really necessary? Thought the lwi file will be enough. Thank you very much!

[Atlantis]

It does not demux the video for me.

[Morku]

I have deleted the Settings folder. Now it's doing fine. Maybe I messed around and have overseen something.

[Atlantis]

I always do a clean install. I don't even copy my settings. I make them on a new installation.

[LaddieMawery]

I've been running into an error today with a x265 encode. Doing anything but muxing the audio straight crashes the process. I've tried it with AC3, AAC, and OPUS, but it crashes every time.

Crashes happened using both 2.8.0 and 2.7.0 versions of the program as well. Most of the crashes don't output a log file either, it just hangs until the process is forced closed.

Pastebin link to the error message. (https://pastebin.com/kQ93RLr2)


It says to update FFMPEG, but I've had no issues with other encodes until today.

Edit: I ended up remuxing the disc instead of using the raw files and everything seems to work fine.

[Magik Mark]

Hi!

Can someone guide me on doing this:

1. Reencode DTS and Atmos audio track such that the "dialogue" part is boosted 3x, outputting the same audio format

Thanks

[kalehrl]

How can I manually switch to light theme?
By default it is black.

[Atlantis]

Tools -> Settings -> User Interface

[craigpro]

Since video-compare is a CLI tool, I made a very simple GUI for it: video-compare_GUI (https://github.com/JJKylee/video-compare_GUI/releases).

For more info, see this issue thread (https://github.com/staxrip/staxrip/issues/702).

Thanks for this tool - I found it quite useful as finally I could do some pre and post encode comparions. Previously I'd used FFmetrics and while that analysed the encoded video being very (0.98 SSIM) close to the original I wasn't aware of what the actual differences were.

Bug report? I noticed that with 1080p source the video replay was only showing what appeared to be maybe the 'top left' quarter of the video from both files - is there a way to make it show at full size / video source resolution please? I tried the 'high DPI' setting but that doesn't affect it.

EDIT: also I tried running the command line version of the video-compare-20210827-win64.zip tool and it displayed with no issues at 1080p for both files.

Anyways thank you!

Using your video compare gui I could see that some extremely fine details with texture in shirts and around hair was being lost. Mind you this is re-encoding an original 1080p 1.22GB x264 encoded file with a 2 pass NVenc 265 encoding and the resultant file being output as a 210MB file (same resolution).

Increasing the minimum bitrate to retain those fine details might be interesting to experiment with but I'm fairly happy with the file reduction size already as this is for non archival purposes and from memory I think you helped me with my settings a while ago (thank you!).

--vbr 0 --codec h265 --preset P7 --output-depth 10 --multipass 2pass-full --vbr-quality 33 --aq --aq-temporal --bref-mode middle --bframes 4 --ref 5 --lookahead 32 --multiref-l0 5 --multiref-l1 4 --vpp-deband range=24,thre=6,thre_y=6,thre_cb=6,thre_cr=6,dither=24,dither_y=24,dither_c=24

EDIT 2: Hmm something else I noticed - the colours values from the x264 'source' file are lighter than the x65 NVenc encoded file - it's like the 265 encoder is boosting / making the colours lighter? will investigate more in the moring.. is midnight my time.

https://imgur.com/a/jOTdbIr

[craigpro]

ok making a new post - I've noticed that encoding from 8 bit x264 to 10 bit NVenc 265 the colours are slightly 'lightened/changed' on the 265 encoded file.

my settings:

--vbr 0 --codec h265 --preset P7 --output-depth 10 --multipass 2pass-full --vbr-quality 33 --aq --aq-temporal --bref-mode middle --bframes 4 --ref 5 --lookahead 32 --multiref-l0 5 --multiref-l1 4 --vpp-deband range=24,thre=6,thre_y=6,thre_cb=6,thre_cr=6,dither=24,dither_y=24,dither_c=24

example stills from video - the zoomed in section shows an area of hair - the left hand size is the original video and the right hand side is the encoded video - looking at the pixel RGB values for the same pixel, they are different.

https://imgur.com/a/jOTdbIr

left hand side RGB = 120 - 98 - 96
right hand side RGB = 131 - 102 - 96

note I don't have any colourspace options ticked at all in my encoder options - I'm trying a test encode right at this moment.

update: ok so I did colourspace enabled, translate from bt709, matrix translate to bt709 and there is still a colour shift.

for my test video, the RGB colour codes for each encoding with the hex value

265 = 80 33 0 502100
264 = 72 25 0 481900

so there is definitely some colourshifting going on which should NOT be occurring - has anyone else noticed this? I'm using Staxrip 2.1.9.0 with NVenc 5.29

thank you.

update 2: I just updated to Staxrip 2.8.0 and tested and the colour shifting is still there with the same settings as listed above, no colourspace options enabled.

264 79 32 0 4F2000
265 87 35 0 572300

[craigpro]

hmm third observation with Staxrip 2.8.0 - NVenc encoding appears to be about twice as slow as it was in 2.1.9.0 - I could encode an average length TV episode (1080p) in around 5 minutes, NVenc 5.38 is telling me 11 minutes. VE is still at 99% as per 2.1.9.0

[Baconce]

hmm third observation with Staxrip 2.8.0 - NVenc encoding appears to be about twice as slow as it was in 2.1.9.0 - I could encode an average length TV episode (1080p) in around 5 minutes, NVenc 5.38 is telling me 11 minutes. VE is still at 99% as per 2.1.9.0

Where did you find Nvenc 5.38 ??? :sly:

[craigpro]

Where did you find Nvenc 5.38 ??? :sly:

sorry my mistake.. it's NVenc 5.36 - looked like an 8 to me.

UPDATE 01/09 - today I noticed that even though Staxrip says NVenc 5.36, Staxrip 2.8.0 only comes with NVenc 5.35. So I downloaded 5.37 from Rigaya's github and I'm testing it now.. still seems to be about twice as slow than the much earlier NVenc 5.29 which I was using in Staxrip 2.1.9.0, but maybe the earlier version wasn't doing something correctly (I'm surprised no one has investigated the colourspace issue).

[chipxtreme]

hmm third observation with Staxrip 2.8.0 - NVenc encoding appears to be about twice as slow as it was in 2.1.9.0 - I could encode an average length TV episode (1080p) in around 5 minutes, NVenc 5.38 is telling me 11 minutes. VE is still at 99% as per 2.1.9.0

I had that before. Did fresh install and it worked at usual speed again.

[craigpro]

I had that before. Did fresh install and it worked at usual speed again.

I guess I can remove and then try a re-install, however this was a fresh install into a new folder and new settings from my old 2.1.9.0 installation.

EDIT: nope still the same processing time of around 10 minutes per hour's worth of video when encoding to h265 using NVenc.

[tormento]

I am trying to work with grayscale spaces but I am getting an error by StaxRip:

avs [INFO]: AviSynth+ 3.7.1 (r3431, master, x86_64)
avs [INFO]: 1296x1080 0:0 @ 24000/1001 fps (cfr)
avs [INFO]: color matrix: bt709
resize [WARN]: converting from gray16le to yuv420p16le

The script is:

SetMemoryMax()
SetFilterMTMode("DEFAULT_MT_MODE", 2)
LoadPlugin("D:\Eseguibili\Media\DGDecNV\DGDecodeNV.dll")
DGSource("F:\In\7,5 1_49 lighthouse, The\lighthouse.dgi",ct=0,cb=0,cl=312,cr=312)
ConvertToY()
ConvertBits(16)
SMDegrain (tr=4, thSAD=400, refinemotion=true, contrasharp=false, PreFilter=4, truemotion=true, plane=0, chroma=false)
Prefetch(6)

In other jobs, I get

resize [WARN]: converting from gray to yuv420p

Why should a resize happen if I never asked StaxRip to do it? And, above all, why does it want to change my colorspace? :p

[DJATOM]

Try --output-csp i400

[tormento]

Try --output-csp i400
Where?

[DJATOM]

In command line options (there should be a field to enter those, I didn't used Staxrip for a while).

[tormento]

In command line options (there should be a field to enter those, I didn't used Staxrip for a while).
Can't find. :scared:

[jlw_4049]

Can't find. :scared:Custom command in the codec options

Sent from my SM-G986U1 using Tapatalk