StaxRip

[BobDig]

@Bobdig

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,
Well, what I meant was with all his other names.

And I will keep HDR and let the player correct it. Simple solutions are what I prefer, obviously.

[manolito]

If you have to convert HDR to SDR one day, you'll see how good this tool is.

After doing a couple of tests I agree, this tool is good, way better than the ffmpeg tonemap filter.

I do have a question about the difference between the latest version and the previous one. All I can see is that the "white" parameter has changed. The old default was 1500, the new one is 400. With the old version my conversions for PQ sources always came out too dark, so my standard value for white became 2000.

With the new version it looks like I need to use trial and error to get identical results, so my question is if there is a linear relation between the old and the new "white" parameter. If not, is there a formula to translate the values?

I know that DG wants folks to register at his own forum for such questions, but this is something I certainly do not want to do. If he refuses to help, maybe someone else has the information for me...

[44vince44]

I find it strange why you are reluctant to going to DG's forums.
I went there once (only reading posts) and I found them to be very good.
He is providing his tools for free, and if he asks in return, for any reason, that we register to his forum, I think we should do. And after finishing those lines, I will register there just to say Hi and Thanks.

About the difference between 1.3 and 1.4: yes the white value does not work the same.
There is no rule, you have to select the brightest frame of the movie, calibrate white. After calibrating white, you can calibrate the other stuff, then re-tweak white. White can be very low.
The last movie I converted, I used this script (with v1.4):
DGHDRtoSDR(white = 30, black = 0, gamma = 0.5, hue = 0.0,
\ r = 1.05, g = 1.06, b = 1.08, tm = 0.9,
\ roll = 0.7, fulldepth = true, mode = "pq",
\ impl = "255")

If you want to do that seriously, you need to use Preview a lot, and MOST IMPORTANT: a color picker that samples the color at the mouse pointer on the screen.
If you do it seriously, and have good knowledge, you achieve better results than the players who read HDR on SDR hardware.

Note: not only White has changed between 1.13 and 1.14. Roll has changed, and maybe tm also.

[44vince44]

@videoh:
DG, if we want to redistribute DGDecNV, we need at least a written permission from you, right ?

This is, in my understanding, one of the differences between closed source and open source....

(all the info I got it on this matter is from the internet, so I could be wrong)

[manolito]

I find it strange why you are reluctant to going to DG's forums.
I went there once (only reading posts) and I found them to be very good.
He is providing his tools for free, and if he asks in return, for any reason, that we register to his forum, I think we should do. And after finishing those lines, I will register there just to say Hi and Thanks.

I see that you are relatively new to this forum, so you cannot know the old stuff which caused a lot of bad blood. I won't warm up these old stories, suffice to say that I will never register to a forum where the admin once had the habit to ban folks from the forum for this reason: "Euroweenies not welcome here".

For the HDRtoSDR tool I am not someone who wants to adjust the params separately for different videos. Having a brightness which feels right is the most important thing, and otherwise I just use the defaults, and this always gave me very good looking results with HDRtoSDR 1.3.

[videoh]

@videoh:
DG, if we want to redistribute DGDecNV, we need at least a written permission from you, right ?

This is, in my understanding, one of the differences between closed source and open source Copyright applies to both source and binaries. You cannot redistribute (copy) copyrighted materials unless there is an active permissive license. Disclosure of source is another matter. If I don't release source with a permissive license, then I can assert copyright on it at any time.

You would need permission, but if I not mistaken, stax76 is not interested in bundling any DG stuff. That's OK; users know where to get it.

[44vince44]

Thanks for the explanation DG!

Indeed, I am aware of his reluctance to include your software, but I assume it was related to licensing issues. There might be other things I don't know of. So maybe once this is settled, it would be nice to bundle your free tools... But this is only my personal belief...


@manolito: my profile is new, but i am not new here. I always read posts since early 2000s, but I was not registered.
I read your explanation (omg !!). I dunno what to say and am not qualified to judge, so i prefer not to comment...

[stax76]

I've a certain opinion about DG and also madshi software, but it doesn't matter, note that I'm retired from staxrip because I don't encode since a very long time, mpv.net (https://github.com/stax76/mpv.net) is my new main projects, I use it every day.

[JKyle]

Good to hear from you, @stax76.

Although you're saying you've retired from the StaxRip project, I know you'll be keeping an eye on it, won't you? :)

[manolito]

Well, Stax already retired from StaxRip in 2018, and Revan654 took over at this time. Didn't last too long, it looked like Stax was not too happy with the direction Revan took his baby, so he kind of pushed him out of the project.

So be careful, the same thing could happen to the current StaxRip maintainers if Stax decides that he doesn't like the changes you guys implement. Good luck...

[JKyle]

@manolito,

I don't know on what grounds you say so, but basically, StaxRip is an open source project with MIT license. Anyone who's not happy with the current status of the project can always fork and make their own. The term "push out of the project" does not seem appropriate.

AFAIK, Revan still has the maintainer privilege to the GitHub repo. If he's willing, he can always modify the source code. If he's not happy with the current status, then he can fork out and start his own project. But I haven't heard of any project he's maintaining to the best of my knowledge.

Thank you for your 'advice' but I guess it's kind of too much.

[stax76]

@manolito

I announced retirement before because I suffered from psychosis for some time because of poor lifestyle choices...

See this post:

https://forum.doom9.org/showthread.php?p=1782385&highlight=breaking#post1782385

That was a very terrifying time.

There was a little disagreement regarding a .NET core port, I was and still am concerned that the core designer is unstable, the form designer was often unstable in the past. It's kind of pointless porting it because there are little benefits. This or next December core v6/v7 likely drops Win7 support.

https://devblogs.microsoft.com/dotnet/updates-to-net-core-windows-forms-designer-in-visual-studio-16-5-preview-1/#under-the-hood

I don't understand why you're posting this, how did you conclude that? Revan just disappeared, I don't know why. Maybe you don't know, the team has earned my trust and respect, we've been working together for a long time.

I know you'll be keeping an eye on it, won't you?

I read doom9 but on the staxrip GitHub repo only @mentions.

[JKyle]

I read doom9 but on the staxrip GitHub repo only @mentions.

OK. Then I'll try to mention you more often on GitHub. :D


...
...
Sorry, it was a lame joke. ;)

[Arkana]

@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)


Hi, I've done small test, It most likely wrong but here are what I did

1. Extracted hevc with ffmpeg (using ffmpeg -i input.mkv -c:v copy -vbsf hevc_mp4toannexb -f hevc - | dovi_tool demux -)
2. Extracted the rpu (base layer source) using dovi_tool extract-rpu video.hevc

Now I am getting 0kb on rpu file is that supposed to be like that?


https://i.postimg.cc/y8D7NpDW/screenshot-1451.png (https://postimages.org/)

--
On HDR10+ it was pretty easy to learn, I only need to extract the metadata then put it back to staxrip
But on DV I am will need a lot things to learn

[JKyle]

Can't tell 'cuz I don't know anything about the source.

[onekmilesbehind]

If the source is profile 5 (single layer, DoVi only), have you tried invoking -m 2 to convert the RPU to be profile 8.1 compatible?

i.e. dovi_tool -m 2 extract-rpu video.hevc

[Arkana]

Can't tell 'cuz I don't know anything about the source.
It says like this
Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible
If the source is profile 5 (single layer, DoVi only), have you tried invoking -m 2 to convert the RPU to be profile 8.1 compatible?

i.e. dovi_tool -m 2 extract-rpu video.hevc

source is profile 8.1

[JKyle]

Format profile : Main 10@L5.1@High
HDR format : Dolby Vision, Version 1.0, dvhe.07.06, BL+EL+RPU, Blu-ray compatible / SMPTE ST 2086, HDR10 compatible

source is profile 8.1

No.

dvhe.07.06 ⇒ Dolby Vision Profile 7, Level 6.

Try "Convert to 8.1 and discard EL"

dovi_tool convert -m 2 convert --discard file.hevc

as explained by the dovi_tool (https://github.com/quietvoid/dovi_tool) document.

Or maybe,

ffmpeg.exe -hide_banner -i INPUT -bsf:v hevc_mp4toannexb -c:v copy -f hevc - | dovi_tool -m 2 extract-rpu -

If it doesn't work, report an issue there to quietvoid along with your sample.

[Arkana]

No.

dvhe.07.06 ⇒ Dolby Vision Profile 7, Level 6.

Try "Convert to 8.1 and discard EL"

dovi_tool convert -m 2 convert --discard file.hevc

as explained by the dovi_tool (https://github.com/quietvoid/dovi_tool) document.

Or maybe,

ffmpeg.exe -hide_banner -i INPUT -bsf:v hevc_mp4toannexb -c:v copy -f hevc - | dovi_tool -m 2 extract-rpu -

If it doesn't work, report an issue there to quietvoid along with your sample.

the later command gave me this

https://i.postimg.cc/0QM8mhBz/screenshot-1454.png (https://postimages.org/)

So now I can just put the rpu.bin back to file using staxrip?

[JKyle]

So now I can just put the rpu.bin back to file using staxrip?

There's a catch with Profile 7 sources. They are dual-layers, and depending on what kind of ELs they have (MEL vs FEL), it can be hard or impossible to re-encode with open-source tools like x265. Even a 1:1 remux without re-encoding can pose a problem for LLDV(Low Latency Dolby Vision) devices. See this note (https://avdisco.com/t/demystifying-dolby-vision-profile-levels-dolby-vision-levels-mel-fel/95/2) by desray.

Matter of fact, you can't tell until you do the encoding hands on. You may need to convert the HEVC stream as well to Profile 8.1 along with the RPU itself before re-encoding... Maybe you don't have to. I can't tell. Plz try it yourself.

This all happens because Dolby Vision is not a free, open format like HDR10 or HDR10+.

In my experience, single-layer sources (Profiles 5, 8.1, 8.2) were not that difficult to re-encode, but dual-layer profiles were different.

[JKyle]

@Patman has updated his builds including SVT-AV1 0.8.7.
(aomenc, ffmpeg, Mp4Box, rav1e, SvtAv1EncApp, etc.)

Check out his cloud archive (https://www.mediafire.com/folder/vkt2ckzjvt0qf/StaxRip_Tools) if interested.

[44vince44]

manolito said:
So be careful, the same thing could happen to the current StaxRip maintainers if Stax decides that he doesn't like the changes you guys implement. Good luck...

What kind of talk is that ?

And you were criticizing DG forums ???

[Atlantis]

This Dolby Vision thing is a mess and you can't watch it on a normal computer. All look violet. At least with HDR10+ you can watch it normally on a computer.
Is that's right? You can't watch a Dolby Vision on a normal computer in SDR?

[stax76]

@videoh

So you are learning how open source and GitHub works, keep doing so.

[stax76]

I don't know what you did expect after the arguments and insults, I tried long and hard enough to get along, like 20 years, what goes around comes around.

[44vince44]

This is a real mess :-(

I am NOT addressing to any specific person here.

As part of the current maintainers, the only thing I will say is that we miss Stax76 very much when he doesn't drop a line every now and then. There is mutual appreciation, trust and respect. And a very nice work relationship.

This forum should not be a place for lies or empty threats.

[creeve4]

Since upgrading to 2.5.0 I am getting the following error when using mClean on 4K video:

Script Error

Resize: Planar destination height must be a multiple of 2.
(C:\StaxRip-v2.5.0-x64\Apps\Plugins\AVS\mClean\mClean.avsi, line 100)

A few more details:
This also happens in 2.4.0
I am using Avisynth+ and am not resizing the video, only cropping it. The cropped dimensions are all divisible by 2.
If I apply mClean before cropping I do not get this error. If I crop first then apply mClean I get it.
Using Vapoursynth I do not get this error.

[venom_dark]

Hello everyone! Hope you doing well!

Since I discovered this great GUI and their tools I can't stop using it, thanks to the creator and all the maintainers!

Ok, I know that high quality settings take some time to encode, so, I saw and I use everytime the OpenCL option for the x264 (CPU) settings and it gives me a very nice boost but only in the first pass, I'm doing 2pass because sometimes I need to set the bitrate and others the size, and my question is, is this a normal behavior? Is there a possible way to make OpenCL acceleration for the second pass too?

BTW, I just tested with Hybrid and OpenCL acceleration works with the first and second pass.

Thanks in advance!

P.S.: I use a Nvidia Graphics card for the OpenCL

[44vince44]

@creeve4 Internally there may be divisions by two again.
When using crop or resize, it is recommended that the size of the cropped video, both width and height, are divisible by 8.
Anyway, we can't help you if you don't provide with more information:
- mediainfo of the source (or at least resolution and bitrate)
- the script used (you can copy content of "Preview Code"

[JKyle]

@44vince44,

@creeve4 cross-posted the same issue on the mClean thread (https://forum.doom9.org/showthread.php?p=1942748#post1942748), and it turns out that mClean script has a bug when it comes to a 4K source.

I suggested a fix that addresses the issue on the same thread (https://forum.doom9.org/showthread.php?p=1942879#post1942879).

The mClean script will be updated in the next release of StaxRip.

---

@venom_dark,

If there are no logs, no analysis is possible.

Plz post your log in the Issue Tracker of GitHub (https://github.com/staxrip/staxrip/issues) along with a proper explanation.

[venom_dark]

@venom_dark,

If there are no logs, no analysis is possible.

Plz post your log in the Issue Tracker of GitHub (https://github.com/staxrip/staxrip/issues) along with a proper explanation.

I will! Thank you very much!

[44vince44]

@JKyle, thanks for the explanation !!! again, a tool issue ;-)

[Arkana]

There's a catch with Profile 7 sources. They are dual-layers, and depending on what kind of ELs they have (MEL vs FEL), it can be hard or impossible to re-encode with open-source tools like x265. Even a 1:1 remux without re-encoding can pose a problem for LLDV(Low Latency Dolby Vision) devices. See this note (https://avdisco.com/t/demystifying-dolby-vision-profile-levels-dolby-vision-levels-mel-fel/95/2) by desray.

Matter of fact, you can't tell until you do the encoding hands on. You may need to convert the HEVC stream as well to Profile 8.1 along with the RPU itself before re-encoding... Maybe you don't have to. I can't tell. Plz try it yourself.

This all happens because Dolby Vision is not a free, open format like HDR10 or HDR10+.

In my experience, single-layer sources (Profiles 5, 8.1, 8.2) were not that difficult to re-encode, but dual-layer profiles were different.
thanks for the detailed answer. appreciated

[Arkana]

@@JKyle so for now it's not possible to have a mkv file for re-encoded dolby vision stream using staxrip?

[manolito]

The last movie I converted, I used this script (with v1.4):
DGHDRtoSDR(white = 30, black = 0, gamma = 0.5, hue = 0.0,
\ r = 1.05, g = 1.06, b = 1.08, tm = 0.9,
\ roll = 0.7, fulldepth = true, mode = "pq",
\ impl = "255")


After doing more test encodes using LG, Sony and Samsung HDR demos (all PQ) I think that your HDRtoSDR parameters give way better results than the defaults. Especially the default for white (400) is ridiculously high. Is this only true for PQ sources, or does it also apply for HLG?

Since I did not find any HLG sources, I determined that just reducing the value for white to 30 gives already nice results, but they tend to look "cold". Your params fix this, and so far I have not found a source where they look bad. So I will use your params as my new defaults until I hit a source where the conversion result looks terrible... :D

And NO, I still do not want to tweak the params separately for each source using preview and a color picker. Especially since I have no way to compare the conversion results with the original. None of my software and hardware players supports HDR, and this won't change in the forseeable future.

So thanks for sharing your params, much appreciated...

[44vince44]

You're welcome manolito. I didn't find any HLG source either.

You can compare the output to one of players that do that conversion. I know of mpv or Stax76's mpv.net.
Although mpv (.net) tends to give a slightly bluish result, it is good as a guide.

@ to anyone who wants to know how I got those params:
those parameters were obtaines by adjusting on a source with the help of a color picker. It took me a couple of minutes only to find them.
First calibrate the brightest area you find in the whole feature, then calibrate the blacks. Then adjust gamma and roll to get the desired "contrast". Then adjust colors (r, g,b, values). Then re-tweak them all. With practice, it becomes easy.

[Atak_Snajpera]

You're welcome manolito. I didn't find any HLG source either.



https://4kmedia.org/travelxp-4k-hdr-hlg-sample/

[videoh]

@ to anyone who wants to know how I got those params:
Thank you, guys. I agree that the defaults are not so good. When you have a set of parameters for HLG that you like I'll update the tools with your values for both PQ and HLG.

[manolito]

After a lot more tests I think I know which settings I will use for PQ and HLG sources (until someone else comes up with much better settings)... :D

My results are in no way scientific, I just took some available sources, converted them to SDR (and SD with REC.601) and watched the results. What really helped me was the LG_Cymatic_Jazz clip which is available at Andy Tather's site as PQ (original LG) and HLG (from Astra satellite test broadcast). Both originate from the same master, and while I do not know how accurately the Astra engineers converted the PQ source to HLG I just assume they did a good job. Download here:
https://andytather.net/Panda/VideoGalleryPage.aspx

I converted the PQ source using the 44vince44 parameters which resulted in a nice looking SD clip. Then I tried to match this result using the HLG source, and the closest result I could get was using the HDRtoSDR default parameters with the exception of the "white" parameter which needed to be raised to 2000 (from the default of 400).

To sum it up my DGHDRtoSDR parameters are as follows:

HLG sources:
DGHDRtoSDR(mode="hlg", white=2000)

PQ sources:
DGHDRtoSDR(mode="pq", white=30, gamma=0.5, r=1.05, g=1.06, b=1.08, roll=0.7)


The results are here:
https://we.tl/t-LhX0RzobLJ

Far from perfect I guess, but at least for my needs this is a very good starting point.

[videoh]

Cool. Thank you manolito.

[bin.n2f]

https://ibb.co/rysw4x6

what wrong here am i messing some files ?:thanks:

https://ibb.co/rysw4x6



FileNotFoundException (2.1.7.1)



System.IO.FileNotFoundException:
File name: 'System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

[Atlantis]

FFT3DFilter v2.9 (https://github.com/pinterf/fft3dfilter/releases) is released

I already put this on the page request long before 2.6.0 release and it is still not included with 2.6.0
https://github.com/staxrip/staxrip/wiki/Tool-Update-Requests

[44vince44]

Must have been a mistake from our part. I'm checking this with @Dendraspis.

[44vince44]

Ok it has been accidentally deleted 19 days ago.
@Jkyle, it appears (if I'm not mistaken) it was deleted after your commit here (https://github.com/staxrip/staxrip/wiki/Tool-Update-Requests/c1e4e579c0619eb10df2f18ce399481b69bf8c92), please confirm there is no reason (read explanation below) ?

@Atlantis, it appears JKyle was cleaning up the page, at the exact same time you were editing. When someone edits a Wiki page, and stays long in edit mode, the page does not get refreshed, so they have no idea someone else has made a new addition.
I think that's what happened 19 days ago. A sync problem: 2 people editing at the same time...

Will be included in next release.

[JKyle]

I have no idea what happened. I didn't mean to delete anything intentionally.

Like @44vince44 said, maybe the document was opened almost at the same time, but it's highly possible that I opened it first and @Atlantis opened it just a little bit later before I finished editing.
And I guess I saved it later than @Atlantis.
That's why I couldn't see @Atlantis's edit when I opened the document, and his edit was overwritten when I saved it.
Hmm...

[guest]

FFT3DFilter v2.9 (https://github.com/pinterf/fft3dfilter/releases) is released

I already put this on the page request long before 2.6.0 release and it is still not included with 2.6.0
https://github.com/staxrip/staxrip/wiki/Tool-Update-Requests

Yes, from back in March.

Why don't you just add it / overwrite it, yourself !!!

[Atlantis]

Yes, from back in March.

Why don't you just add it / overwrite it, yourself !!!

What kind of question is that? What that has got to do with anything? I said it was not updated in staxrip.

[44vince44]

@Pauly Dunne

Atlantis has done the correct thing to do, and thanks for that Atlantis.

[chipxtreme]

AVG is picking up ffmpeg as containing a virus in latest build

[JKyle]

AVG is picking up ffmpeg as containing a virus in latest build

You need to be aware that some antivirus engines false detect executables compressed by UPX. See this thread on GitHub (https://github.com/staxrip/staxrip/issues/653) for detail.

I unpacked the same ffmpeg.exe file (27.48 MiB) by running the following command:

upx -d ffmpeg.exe

The resulting ffmpeg.exe is much bigger now. (81.17 MiB)

I uploaded it to VirusTotal and here's the scanning result: see this (https://www.virustotal.com/gui/file/b91cfd7ff6588d0f6bff17da8187bfacce4e3f607fc97cbbbb7319f879a5528d/detection).

This false detection issue comes up pretty often. Hmm...

On StaxRip, while the Audio Encoding, if we choose the normalize option, the gain output always becomes 0 dB. But what if I want to use the normalize option but same time I want the gain output upto -1 dB, then which custom parameter should I use?

AFAIK, normalizing to 0 dB is hard wired in the code. If you want this 'feature', you can make a feature request on the GitHub Issue Tracker (https://github.com/staxrip/staxrip/issues).