StaxRip [Archive] - Page 85

BobDig

4th May 2021, 13:24

StaxRip 2.5.0 has a sync problem. I did a fresh install and encoded a BR. Both tracks are async (opus). I don't do BRs often though.
Media Info in MPC-HC is not showing any Delays if I open the file in the STREAM folder, so this might be the reason in the first place?
Also the delay seem to change all the time in the end file, no problem with the source. :scared:
The cocktail app worked without this problem.

videoh

4th May 2021, 15:13

I've updated this wiki document (https://github.com/staxrip/staxrip/wiki/If-QTGMC-raises-errors-right-after-the-fresh-install...) for users who may run into errors with QTGMC and other filters depending on JPSDR.
I'm surprised you didn't add DGDecNV to the mix ?!?!? Not sure what DGDecNV has to do with QTGMC etc. Care to elaborate?

44vince44

4th May 2021, 17:07

@videoh, I think user Pauly Dunne only meant he was expecting, along all other changes and improvements and new wikis, that DGDecNV would be added as source. Which will most certainly be done one day (soon, I hope :) )
Edit: I forgot to say thanks to you :-)

@BobDig, it would help us if you provide us with the log. Anyway, for BR encoding, it is recommended to mux the BR folder to an mkv (MakeMKV works very well), then encode it with StaxRip.
I agree that the direct BR folder processing in StaxRip is somehow incomplete or inaccurate, and outdated.

videoh

4th May 2021, 18:07

JKyle

4th May 2021, 18:23

I think a problem is that stax76 does not recommend DGDecNV. I believe it is a personal and not a technical matter.

So do you basically agree that DGDecNV can be redistributed/shipped in future StaxRip releases?
If so, I believe @stax76 will not object to including it in StaxRip. :)

JKyle

4th May 2021, 18:38

@Patman,

The current release version of x264 is 161-r3053 (April 13, 2021) and your build is based on 161-r3048. I guess you may want to update it.

And aomenc v3.1.0 was released yesterday (https://aomedia.googlesource.com/aom/+/562fcd4ab0aa2c49c12df4bd2b76dca7a837ad4c), just a day after you released your build 3.0.0-375. Build update is also expected for this one as well. :)

videoh

4th May 2021, 19:00

So do you basically agree that DGDecNV can be redistributed/shipped in future StaxRip releases?
If so, I believe @stax76 will not object to including it in StaxRip. :) I'll send you a PM about it.

guest

5th May 2021, 02:25

So do you basically agree that DGDecNV can be redistributed/shipped in future StaxRip releases?
If so, I believe @stax76 will not object to including it in StaxRip. :)

Hi JKyle,

Sorry for the noobie question, but I just wanted to bump this :-

I did manage to set it up myself, thanks to your instructions, now I just need to get the "NV" part to co-operate.

So to utilize this, of course you need a compatible nVidia GPU, and drivers, but is there anything else it needs ??

videoh

5th May 2021, 02:43

So to utilize this, of course you need a compatible nVidia GPU, and drivers, but is there anything else it needs ?? Should be good to go. Tell us the details if you have an error.

guest

5th May 2021, 06:47

Should be good to go. Tell us the details if you have an error.

OK, I will give it a try on my Ryzen 3950X, with "only" a GTX1080, and see what happens.

Will report back either way :)

Cheers

BobDig

5th May 2021, 07:51

Anyway, for BR encoding, it is recommended to mux the BR folder to an mkv (MakeMKV works very well), then encode it with StaxRip.
I agree that the direct BR folder processing in StaxRip is somehow incomplete or inaccurate, and outdated.

Good to know!
:thanks:
Edit: In free mode it will not produce a mkv-file, even if there is no cp in the first place. :(
Edit2: At least it worked, all in all very gefrickel though.:sly:

Patman

5th May 2021, 10:19

tormento

5th May 2021, 11:08

The current release version of x264 is 161-r3053 (April 13, 2021) and your build is based on 161-r3048. I guess you may want to update it.
Testing 0.162 with native 16 bit HBD support and internal dithering for lower bitplanes. Hope to see it soon officially. It needs some tweaks on StaxRip as it complains that 16 bit source needs some piping for x264.

VincAlastor

5th May 2021, 16:07

AOMEnc has been updated.
x264 will be updated at the weekend, new commits on x264 since today ;)

thank you very much for updating SVT-AV1 some days ago, too :)

On 09 May 2021 version 0.87 should finally be released.

The argument -n seems to be optional finally, if you wanna change it in staxrip

https://gitlab.com/AOMediaCodec/SVT-AV1/-/blob/master/Docs/svt-av1_encoder_user_guide.md

Patman

5th May 2021, 16:32

I'll updated SVT-AV1 if the final version is released.

Gesendet von meinem M2101K6G mit Tapatalk

JKyle

6th May 2021, 00:56

Testing 0.162 with native 16 bit HBD support and internal dithering for lower bitplanes. Hope to see it soon officially. It needs some tweaks on StaxRip as it complains that 16 bit source needs some piping for x264.

That's because the x264 build you're testing does not support direct avs reading of 16-bit inputs. It is what is called a "tool issue", and is not related to StaxRip per se.

That said, since this happens because StaxRip assumes avs scripts can be read directly by the encoders (x264 and x265) by default, this is somehow related to how StaxRip administers the encoding jobs to encoders.

However, this cannot be called an "issue with StaxRip" since you can always adopt an alternative approach easily by setting Input/Output > Pipe to avs2pipemod in encoder options.

For comparison, the x264 build currently shipped with StaxRip (Patman Mod) takes a 16-bit avs input (YUV420P16) without any issues.

This is one of the reasons why StaxRip ships with mod builds instead of the unmodded ones.

JKyle

6th May 2021, 01:07

AOMEnc has been updated.
x264 will be updated at the weekend, new commits on x264 since today ;)

:thanks:

It happens that x264 was updated to 163-r3059 on May 5, 2021. Good timing. :)

guest

6th May 2021, 03:54

BUMP

Originally Posted by Pauly Dunne
So to utilize this, of course you need a compatible nVidia GPU, and drivers, but is there anything else it needs ??

Originally Posted by videoh
Should be good to go. Tell us the details if you have an error.

OK, I will give it a try on my Ryzen 3950X, with "only" a GTX1080, and see what happens.

Will report back either way :)

Cheers

So I think I've made a mistake, I set DGEncNV up on an AMD GPU PC, and I was hoping that I could simply copy the Staxrip folder over to my nVidia GPU PC, but the DGEncNV settings didn't come with :(

Do I have to go thru that whole integration process AGAIN ?? :(

ANOTHER BUMP

Ok, I have gone thru the integration process again :(, and I am getting error's :(

Choose DGSource as the "Source", load an .mkv file, and it throws up this error :-

ERROR: cuinit failed [100]

clear that, then this :-

GPU decoder: Failed to create video decoder [100]. Exiting...

So there's something wrong somewhere, I've installed the latest nVidia drivers, and even CUDA tookit.

Just after posting this, I tried again, loading a small HEVC file, and I got those other error's, and I got a new one:-

GPU decoder: HEVC not supported on this device [100]. Exiting...

tormento

6th May 2021, 07:53

That's because the x264 build you're testing does not support direct avs reading of 16-bit inputs. It is what is called a "tool issue", and is not related to StaxRip per se.
I really enjoy when people answer without even knowing the topic I am talking about. :p

Please have a look at this (https://forum.doom9.org/showthread.php?p=1937617#post1937617).

Every build, before the experimental one build from jpsdr with FranceBB contribution, was able to read 16 bit but it understood that bit depth as Interleaved16 and not plain one.
That ended in halved resolution output.

And, yes, the new jpsdr build natively support AVS and eventually the solution for the problem to completely disable piping in StaxRip.

44vince44

6th May 2021, 08:34

I really enjoy when people answer without even knowing the topic I am talking about.

That was not funny. JKyle is trying to help.

videoh

6th May 2021, 13:16

So I think I've made a mistake, I set DGEncNV up on an AMD GPU PC Two things:

1. My tools are DGDecNV, not DGEncNV.

2. DGDecNV requires an nVidia GPU. It won't work on an AMD GPU.

guest

6th May 2021, 14:44

Two things:

1. My tools are DGDecNV, not DGEncNV.

2. DGDecNV requires an nVidia GPU. It won't work on an AMD GPU.

Yeah, that was a big typo, sorry 'bout that.

But I cant get it to work on a GTX 1080 !!

Please read the errors I got (above)

videoh

6th May 2021, 16:49

Try to run DGIndexNV standalone on your 1080-based system, i.e., without staxrip. Does that work?

guest

6th May 2021, 19:04

Try to run DGIndexNV standalone on your 1080-based system, i.e., without staxrip. Does that work?

No, pretty much the same errors.

videoh

7th May 2021, 01:55

OK, so not a staxrip issue. If you want support please use the DG Tools forum. Make sure you have the latest nVidia driver installed and try with the latest DGIndexNV version.

guest

7th May 2021, 03:18

OK, so not a staxrip issue. If you want support please use the DG Tools forum. Make sure you have the latest nVidia driver installed and try with the latest DGIndexNV version.

OK, well that's no help...the ONLY reason I'm going thru this procedure is because of this post :-

https://forum.doom9.org/showthread.php?p=1941590#post1941590

I have the latest driver, the CUDA toolkit (which is a large download, wasted), and the latest DGIndexNV !!!

Having said that, using the x64 version creates the errors, yet using the x86 version, it doesn't.

I'm running the very latest Windows 10 x64.

I think someone else needs to do some "homework".

BTW, the error msg is culnit, not cuinit.

guest

7th May 2021, 04:10

I was just looking thru the 3, KNLMeansCL filters, and noticed that the scripts for both Medium & Strong are the same.

The "h" value for both is 4, but I would think that "Strong" should be 6.

Just sayin'.

Cheers

videoh

7th May 2021, 04:27

OK, well that's no help...the ONLY reason I'm going thru this procedure is because of this post :-

https://forum.doom9.org/showthread.php?p=1941590#post1941590

I have the latest driver, the CUDA toolkit (which is a large download, wasted), and the latest DGIndexNV !!!

Having said that, using the x64 version creates the errors, yet using the x86 version, it doesn't.

I'm running the very latest Windows 10 x64.

I think someone else needs to do some "homework".

BTW, the error msg is culnit, not cuinit. Not gonna do support here. If you want support use the DG Tools forum. Bye!

http://rationalqm.us/board/index.php

guest

7th May 2021, 05:16

Not gonna do support here. If you want support use the DG Tools forum. Bye!

http://rationalqm.us/board/index.php

Hey, I am trying to let ppl know that if they choose to integrate this into Staxrip, they are going to have issues !!!

JKyle wrote a very good guide on how to set this up for Staxrip, which worked well, BUT, there is a serious issue, when it comes to actually wanting to use it...that's what I meant about homework..no use adding something, that doesn't seem to work :(

And don't say "Bye" to me, either...

Lada1

7th May 2021, 15:35

Is there a way to export (encode to) Canopus Grass Valley HQ(x) codec within StaxRip?

44vince44

7th May 2021, 17:05

@Lada, there is an option to use command line encoders in Staxrip, but you have to write the command line syntax yourself, and provide the executable...

videoh

7th May 2021, 17:33

there is a serious issue, when it comes to actually wanting to use it...that's what I meant about homework..no use adding something, that doesn't seem to work Lots of people have it working just fine. I offered to support you at my forum. It's up to you whether you want to actually solve your problem or just rant. Bye!

JKyle

8th May 2021, 00:29

@44vince44 and I have made wiki documents on Dolby Vision/HDR10+ re-encoding.

Encoding Dynamic HDR10plus with StaxRip using x265 or NVEnc.H265 (https://github.com/staxrip/staxrip/wiki/Encoding-Dynamic-HDR10plus-with-StaxRip-using-x265-or-NVEnc.H265)
Encoding Dolby Vision with StaxRip using x265 (https://github.com/staxrip/staxrip/wiki/Encoding-Dolby-Vision-with-StaxRip-using-x265)

guest

8th May 2021, 01:44

Lots of people have it working just fine.

This DGDecNV has only been up (as a free option) for about a week, JKyle posted the instructions for it, and other than me, I haven't seen ANY comments about it.

I would expect someone to chime in with a "fix", if "Lots of people have it working just fine"

I offered to support you at my forum.
It's up to you whether you want to actually solve your problem or just rant. Bye!

I have looked thru all your replies to me, and I don't see any offer to support me, unless "your" forum is

http://rationalqm.us/board/index.php

I did have a look around there, but couldn't find anything relevant.

I have checked & replied on the suggestions you made....

Of course I want to solve the problem, but when I don't get the help needed, then maybe I rant....

Now I know that you're around my age, (according to a poll I stumbled across the other day), so don't treat me like some young kid.

videoh

8th May 2021, 01:56

guest

8th May 2021, 03:34

Sorry, Pauly, thought everyone knew I am the author of DGIndexNV and the owner of the DG Tools website. You can call me DG if you like. I mentioned a couple times that I do my support there. If you want help please register and start a thread there. I am very fast for support when posted at my forum. When you join, put up a nice avatar; otherwise you get a default faceless guy.

The data you gave suggests a DGIndexNV problem rather than a staxrip problem (you said it fails standalone in 64-bit). I am likely the only guy that can help you with that as it is closed source. If you want help with it you know what to do. ;)

If it's not a staxrip problem we shouldn't clutter up this thread.

Onward and upward, my friend. I agree, the young whippersnappers need guidance from the wise guys like us. :helpful:

Hi "DG",

Well, what can I say, I am very, very happy, thankyou :)

I am a real noobie to not only Staxrip, but this Forum, so I wasn't aware of your "status", but I have seen your "name" around the place, I generally hang out on the Ripbot Forum.

OK, I will sign up on your Forum, and lets see if "we" can get to the bottom of this problem...it will help ppl here, as well, I'm sure.

Cheers

videoh

8th May 2021, 04:56

Rocky will take care of you.

44vince44

8th May 2021, 09:08

Happy to see this was all a misunderstanding:
First, written comments lack tone and can sometimes be misinterpreted. So let's all be forgiving.
Second, for those who still don't know: videoh = rocky = DG = rationalqm = Donald Graft, the author of the amazing DG tools (DGIndex, DHHDRtpSDR etc...)

BobDig

8th May 2021, 11:24

Thanks for the clarification @44vince44, didn't know him either, probably because I like free stuff. ;)

And I have a question regarding the future of StaxRip. Has Stax left? Will StaxRip be for novice users too, who don't know about avisynth, scripts and stuff or will it become a tool for pros only? I am somewhat concerned about the toxicity here, if novice users like me ask a question. And I am of the mindset that, if you put a nice GUI on it, you have some responsibility...

Also reading the new "guides", which are probably only used by a very small minority of staxrip users, we need this integrated in the GUI and not something, that will be deleted every time I delete the folder in app-data, which looks to me is the recommendation, if I update StaxRip in the first place. But maybe I am getting it wrong, not a native English speaker here. Same with the br-folder as source problem...

I am concerned more then ever, I use this tool for ages. :(

JKyle

8th May 2021, 15:45

Will StaxRip be for novice users too, who don't know about avisynth, scripts and stuff or will it become a tool for pros only? I am somewhat concerned about the toxicity here, if novice users like me ask a question.

StaxRip has never been and can never be a tool for novices by nature. It employs hundreds of tools and even the most complicated open source media tool, ffmpeg, is only a member of the employees. Although @stax76 and other developers/participants have done their best to keep StaxRip as easy to use as possible, there are complex things going on inside, and users are supposed to understand at least how the processes are going on. It is clearly stated in the GitHub intro document.

StaxRip is no One-Click Encoder!

StaxRip is capable of performing a wide variety of jobs for video/audio processing. To unleash its full power, users are required to know what they want to achieve and how to set up StaxRip to meet their needs. If you are a first-time user, it is especially strongly recommended that you learn the basics referring to the documents and do some tests to understand how StaxRip works and what you can achieve with it.

Since there are so many tools involved, it is no wonder unexpected issues - both internal (=related to StaxRip itself) and external (=tool-related) - arise along the way. That's why StaxRip is updated so frequently.

On users' side, they are supposed to understand at least the basics of encoding. That's the minimum requirement.

But does it mean that StaxRip is for pros only? No. We have a term for that kind of users: intermediate. IMHO, users need to be equipped with at least intermediate knowledge about encoding in order to use StaxRip without major difficulties.

And I am of the mindset that, if you put a nice GUI on it, you have some responsibility...

So you're demanding donors to be more responsible for the stuff that they're giving away and you've acquired at no price just because it looks nice...? What kind of logic is this? :o

44vince44

8th May 2021, 18:13

@Bobdig
Thanks for the clarification @44vince44, didn't know him either, probably because I like free stuff.
Well then you should know him, because DGIndex is free, and DGHDRtoSDR is free to use but not free to redistribute.
If you have to convert HDR to SDR one day, you'll see how good this tool is. It can be added easily in StaxRip by the user (there is a guide for that, made by JKyle)
And recently, DGDecNV is free... BUT I just noticed it still closed source, so it can't be redistributed!
So users who want to use DGDecNV are invited to read the guide (made by JKyle) that explains how to add DGDecNV to Staxrip.

And I totally agree with JKyle's post above !

Atlantis

8th May 2021, 18:24

StaxRip is definitely a power tool and not for users who don't want to do a little effort. For easy to use tool people recommend HandBrake.

Thank you for the Dolby Vision and HDR10+ guides.

Atlantis

8th May 2021, 18:51

You need to manually mux the output hevc video stream with audio files using tsMuxeR (nightly portable). Currently, other muxers like mkvmerge, MP4Box, or ffmpeg do not seem to be able to preserve Dolby Vision info in the video stream.

I saw this in the Dolby Vision wiki. I have never re-encoded a Dolby Vision file. I don't know if this is relevant and helps but I have been able to re-mux a Dolby Vision file with Staxrip and MP4Box as output.

I open the file in staxrip use Copy/Mux and MP4Box and the output file still has the Dolby Vision info in the video stream.

JKyle

8th May 2021, 19:08

I open the file in staxrip use Copy/Mux and MP4Box and the output file still has the Dolby Vision info in the video stream.

You're right. MP4Box preserves the DoVi(Dolby Vision) info in the stream-copied video stream unlike mkvmerge.
I'll be doing more testing with re-encoded DoVi HEVC stream to see if MP4Box does preserve the DoVi info in the video stream.
I need to update the wiki document then.
Thanks for the info.

---

[UPDATE]

Unfortunately, MP4Box (1.1.0-DEV-rev802-gc0ea96c7b-x64-gcc10.2.0 Patman in v2.5.0) fails to preserve the DoVi info for re-encoded DoVi HEVC stream unlike in stream-copy.
So the wiki document is correct.

I'll be putting some notes regarding this matter.

Atlantis

8th May 2021, 21:28

Strange. Why MP4Box can't for re-encoded DoVi streams? What the original source has that the re-encoded stream doesn't?

JKyle

8th May 2021, 21:34

imhh11

8th May 2021, 23:18

It may be a bug with MP4Box.

Strange thing is, even if the re-encoded mp4 doesn't show Dolby Vision info in the video stream mediainfo, it (Dolby Vision info) shows up again if the same mp4 file is remuxed to a ts file using tsMuxeR.

I've found the same phenomenon with mkv (mkvmerge).

Very strange...

Maybe a report is due, but... well... not for now, 'cuz I'm already tired. :rolleyes:
yep, it's a bit more work to preserve the metadata from an encoded stream ...

you can use the mp4muxer (https://github.com/DolbyLaboratories/dlb_mp4base) (well the old version: I'm having issues with the latest one). Then mp4box will retain the metadata.

Same workflow for mkv output: output your encode to mkv and then import into MakeMKV create a new mkv with the metadata back and then mkvtoolnix can process the file properly too.
@quietvoid is attempting to do it straight in mkvtoolnix: https://forum.doom9.org/showpost.php?p=1941844&postcount=1050

videoh

8th May 2021, 23:24

BUT I just noticed it still closed source, so it can't be redistributed Redistribution has nothing to do with it being closed source.

JKyle

8th May 2021, 23:56

yep, it's a bit more work to preserve the metadata from an encoded stream ...

you can use the mp4muxer (https://github.com/DolbyLaboratories/dlb_mp4base) (well the old version: I'm having issues with the latest one). Then mp4box will retain the metadata.

Same workflow for mkv output: output your encode to mkv and then import into MakeMKV create a new mkv with the metadata back and then mkvtoolnix can process the file properly too.
@quietvoid is attempting to do it straight in mkvtoolnix: https://forum.doom9.org/showpost.php?p=1941844&postcount=1050

:thanks: for the info.
So it's more complicated than can be naively guessed about. Hmm...