StaxRip

[laserbones]

Originally Posted by Khun_Doug

Are you asking about these values for hardware (GPU) encoding? Or are you looking at software encoders, x264 and s265? That makes a difference in how you adjust the encoder and what quality you expect to get. It could also be the type of job you are trying to accomplish. If this is just final archiving of material and detail encoding isn't the goal, then hardware encoders are the way to go.

If you are looking for speed, GPU encoders are generally better. If you are interested in getting more control on how the encoder does its job, the software encoders are the way to go. I personally think software encoders, while they may take more time, are a much better choice.

I'm assuming I'm using software encoding. I'm selecting x264 from the encoding profiles. I'm not selecting NVEenC or any other hardware profile. Am I able to control if I'm using VBR or CBR? I actually just want to know what the x264 profile uses. I'm used to having a more direct option in Adobe Media Encoder or Handbrake to select CBR or VBR. I'm assuming these setting are different in Staxrip. I've gone through the settings and I'm confused on what settings control these options.

[N'Cha]

What would be the best "source" choice between FFVideoSource (default) FFM2, LWLibAvVideoSource and L-Smash? I don't understand the pros and cons in term of quality, speed, features, compression etc. for encoding .mkv of anime (from Bluray remux)

Also, is it possible (if yes, how?) to add DGDecodeNV as source filter in Staxrip?

Thanks for the help

[seagate]

The Train 1964 UHD100 2160p HEVC HDR10 DoVi DTS-HD MA 2.0

Complete name : 00004.m2ts
Format : BDAV
Format/Info : Blu-Ray Video
File size : 91,6 GB
Duration : 2 h 13 min
Overall bit rate mode : Variable
Overall bit rate : 98,6 Mb/s
Maximum Overall bit rate : 109 Mb/s
Frame rate : 24,000 FPS

Video #1
ID : 4113 (0x1011)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 2 h 13 min
Width : 3 840 pixels
Height : 2 160 pixels
Display aspect ratio : 16:9
Frame rate : 24,000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color pri : BT.2020
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2
Maximum Content Light Level : 1015 cd/m2
Maximum Frame-Average Light : 154 cd/m2

Video #2
ID : 4117 (0x1015)
Menu ID : 1 (0x1)
Format : HEVC
Format/Info : High Efficiency Video Coding
Format profile : Main 10@L5.1@High
HDR format : SMPTE ST 2086, HDR10 compatible
Codec ID : 36
Duration : 2 h 13 min
Width : 1 920 pixels
Height : 1 080 pixels
Display aspect ratio : 16:9
Frame rate : 24,000 FPS
Color space : YUV
Chroma subsampling : 4:2:0 (Type 2)
Bit depth : 10 bits
Color range : Limited
Color primaries : BT.2020
Transfer characteristics : PQ
Matrix coefficients : BT.2020 non-constant
Mastering display color pri : BT.2020
Mastering display luminance : min: 0.0001 cd/m2, max: 1000 cd/m2

Audio #1
ID : 4352 (0x1100)
Menu ID : 1 (0x1)
Format : DTS XLL
Format/Info : Digital Theater Systems
Commercial name : DTS-HD Master Audio
Muxing mode : Stream extension
Codec ID : 134
Duration : 2 h 13 min
Bit rate mode : Variable
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48,0 kHz
Frame rate : 93,750 FPS (512 SPF)
Bit depth : 18 bits
Compression mode : Lossless

Audio #2
ID : 4353 (0x1101)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 2 h 13 min
Bit rate mode : Constant
Bit rate : 384 kb/s
Channel(s) : 6 channels
Channel layout : L R C LFE Ls Rs
Sampling rate : 48,0 kHz
Frame rate : 31,250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 365 MB (0%)
Service kind : Complete Main

Audio #3
ID : 4354 (0x1102)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 2 h 13 min
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48,0 kHz
Frame rate : 31,250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 122 MB (0%)
Service kind : Complete Main

Audio #4
ID : 4355 (0x1103)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 2 h 13 min
Bit rate mode : Constant
Bit rate : 128 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48,0 kHz
Frame rate : 31,250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 122 MB (0%)
Service kind : Complete Main

Audio #5
ID : 4356 (0x1104)
Menu ID : 1 (0x1)
Format : AC-3
Format/Info : Audio Coding 3
Commercial name : Dolby Digital
Codec ID : 129
Duration : 2 h 13 min
Bit rate mode : Constant
Bit rate : 192 kb/s
Channel(s) : 2 channels
Channel layout : L R
Sampling rate : 48,0 kHz
Frame rate : 31,250 FPS (1536 SPF)
Compression mode : Lossy
Stream size : 183 MB (0%)
Service kind : Complete Main

Text
ID : 4768 (0x12A0)
Menu ID : 1 (0x1)
Format : PGS
Codec ID : 144

v.2.29.0 - error log

[Trench]

I had re-created my templates in StaxRip over the past few releases since it seemed wise, but now I'm encountering an issue which I'm not sure whether its new behavior of updated underlying tools, or something I forgot to include in my settings.

I have existing .MP4 files with x265 video and AAC audio. Using these as the source file in StaxRip, I make a project that uses Copy/Mux on the video track (I'm not re-encoding or changing anything in the video), but I will re-encode the audio track to make a 2-channel AAC version in addition to the existing 5.1 AAC audio track. The result is saved back to .MP4 format again.

The problem is that the resulting .MP4 can no longer seek during playback. It will play fine from the beginning, but attempting to seek hangs things up. Playing the ORIGINAL .MP4 FILE seeks just fine & successfully, which to me meant the x265 encode had everything it needed to seek.

So I'm keeping/muxing the video track from the .MP4 where seeking works successfully. But my re-packaged .MP4 using this Copy/Muxed video track now fails to seek, like some flag of the MP4 container is now missing even though the x265 encoding itself is unmodified.

Any hints for how I could have broken seeking when using StaxRip Copy/Mux with an MP4 source and destination container & a x265 video track would be appreciated.

[Glarioo]

Why does this happen?
Log file attached

[Glarioo]

Originally Posted by Glarioo

Why does this happen?
Log file attached

Found. Profile was set to main instead of main10.

[katzenjoghurt]

Has someone run into this yet?



Sorry, the second part of the log message is German as it seems to come from the system.
Essentially it is saying that the process can't access the Settings.dat file as it's already used by another process.

Happens to me SOMETIMES while batch processing multiple jobs...
It's super-annoying: I return to my PC expecting to see the result of my jobs... and instead I see this window.
I can then click retry and batch processing of the next StaxRip project would continue.

Probably it's got something to do with my setup though...
- I linked to my own installation of VapourSynth R64 and Python 3.11
- I added some VS functions to the profiles

Unless it's a common problem, I guess one of the two is triggering it.

I resetted/deleted the Settings.dat and also set up StaxRip completely anew... but the problem returned.

Totally looks like a race condition issue - like StaxRip is SOMETIMES blocking itself from accessing the settings file while switching to a new job.

Whether StaxRip is on HDD or SSD doesn't seem to matter.


Again - anyone ever seen that?
The randomness makes it so nasty to debug and fix....



edit: I looked at the respective code, looks all well handled with mutexes, and compiled my own version that should do a retry after two seconds and show a warning popup.
But the problem didn’t reoccur yet… hum.

Maybe NOD32 (my virus scanner) is/was sometimes locking the settings file briefly after it’s saved and before it’s reloaded?
Still puzzled…

[Atlantis]

I had to cut out a part of a video. I used trim and imported external audio which should be in sync after the trimming.

After a long encode I discovered that the audio is out of sync.
Is trimming with the preview windows also cut the audio? The audio is correct I don't want to touch it.

[katzenjoghurt]

Originally Posted by Atlantis

I had to cut out a part of a video. I used trim and imported external audio which should be in sync after the trimming.

After a long encode I discovered that the audio is out of sync.
Is trimming with the preview windows also cut the audio? The audio is correct I don't want to touch it.

It should be fine in 99% of all cases.
I've been using an older StaxRip version until recently and there I sometimes (!) also ran into async audio when reencoding older/odd clips, like interlaced DVD extras or so.

I would try with a different source filter in your case and a quick test encode (lower resolution / fast encoder settings).
Maybe you also notice a slight change in the reported fps after changing the source filter - that would be a good sign that that is the solution.

Another idea: as you imported an external audio track manually - maybe for the original audio track some delay was defined in the container that is lost after you add it manually?

[Atlantis]

The trimming video does also trim the audio. Found these in the log

----------------- Create avi file for audio cutting 1 -----------------

---------------- Create avi file for subtitle cutting ----------------

As I said, the audio is correct, It did not need to be cut.
Maybe there should be an option that when you trim the video, you can disable trimming the audio and subtitles.

[katzenjoghurt]

Originally Posted by Atlantis

As I said, the audio is correct, It did not need to be cut.
Maybe there should be an option that when you trim the video, you can disable trimming the audio and subtitles.

Ahh, you were trying to trim a video and add an external audio track that ALREADY was pre-cut to fit just into the section you were about to trim.

Yes, in that case you had to mux the audio track in as a second step after cutting the video stream / reencoding a trimmed section.
But you found that out yourself.
And it should be a quick process too.

Your use case sounds like a real edge case to me though.

[Atlantis]

For example to want to have both SDR and HDR track in a video which is a main stream case, having both SDR and HDR for maximum quality.
I had to cut one second from the SDR version to sync it with the HDR version.

[katzenjoghurt]

Originally Posted by Atlantis

For example to want to have both SDR and HDR track in a video which is a main stream case, having both SDR and HDR for maximum quality.
I had to cut one second from the SDR version to sync it with the HDR version.

Hm. You need an external Muxer anyway then to combine the two video streams and the audio stream.

So you can use StaxRip to just cut the first second of the video stream and ignore audio in your case completely.

Some lossless cutting tool would be better in this case though, so you don‘t have to reencode everything just to cut the first second. But the somewhat working ones I’m aware of cost money.

Theoretically there‘s also the option to delay the video stream in MKVToolnix by a negative 1000ms. That would mean the first second would be skipped.
Not sure how well this is supported by (hardware) players though.

[Atlantis]

I tried video delay, it does not work even on PC. If you add a delay to a video track in MKV, it does not register, it is not written in mkv. Only audio delay.

I do not need to cut audio, audio is from the HDR source and perfectly in sync. Yes at the end I use MKVToolnix to mux the 2 videos.

[katzenjoghurt]

I also tried out a negative delay in a video stream in MKVToolnix and it worked in VLC.
But as I said - it could very well be that it doesn‘t work in all players.

And yes, indeed - you don‘t need to cut the audio for your use case. So just ignore the audio track in StaxRip and just mux the resulting shortened SDR video track together with the HDR video track and the original audio track you already have.

[Atlantis]

When I use MediaInfo it does not show the delay for video. Can you see the delay in MediaInfo? Please copy paste it here.

[katzenjoghurt]

Originally Posted by Atlantis

When I use MediaInfo it does not show the delay for video. Can you see the delay in MediaInfo? Please copy paste it here.

Ok, had a third look.
What‘s actually happening under the hood of MKVToolnix is that a negative delay in a video stream will result in a real cut of the stream. Very probably unprecisely at a neighboring keyframe.

I tried it again with a smaller file and there I noticed that it became even smaller by setting a negative delay to the video stream.

Meh. Sorry about that bad advice.

[von Suppé]

Originally Posted by katzenjoghurt

Very probably unprecisely at a neighboring keyframe.

I tried it again with a smaller file and there I noticed that it became even smaller by setting a negative delay to the video stream.

Yes, setting negative videodelay results in video being cut, where indeed MTX can only cut at keyframes.
With TrueHD there can be a residual - positive - delay because it can't be cut at every frame. Somewhat similar to video, TrueHD has "major sync" frames where cuts can be made.

[von Suppé]

I'm currently looking into DoViBaker. From its repo at github I understand it's an avisynth plugin that processes FEL video, RPU and BL and merge all into one videostream. Initially looking for a all-in-one GUI I imagine StaxRip supports this for a recode. If so, I can use some help on workflow and probably what extra files in what folders should be placed.

I'm on Windows 7 64 bit. I already replaced MKVToolNix "mkv***.exes" with Qt5-build ones. Should Python be involved (I haven't the faintest) is there a way to let it work? I know -QfG- doviscripts have a Python folder that seems to work with Win7.

I'm asking a lot, hope you don't mind

[von Suppé]

Being at it, any idea why StaxRip reports different framerates at import on elementary hevc stream and when in mkv?
I checked the hevc stream; it's definitely 23.976fps, Staxrip shows 25fps.
mkv import shows correct 23.976 fps