StaxRip

[44vince44]

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

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]

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]

Originally Posted by Atlantis

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]

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

[JKyle]

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.

[imhh11]

Originally Posted by JKyle

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.

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

you can use the mp4muxer (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...postcount=1050

[videoh]

Originally Posted by 44vince44

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]

Originally Posted by imhh11

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

you can use the mp4muxer (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...postcount=1050

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

[VincAlastor]

Originally Posted by Patman

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

Gesendet von meinem M2101K6G mit Tapatalk

Thank you very much!

SVT-AV1 v0.8.7 was released

https://gitlab.com/AOMediaCodec/SVT-AV1/-/releases

[BobDig]

Originally Posted by 44vince44

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

Originally Posted by 44vince44

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]

Originally Posted by 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.

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]

Originally Posted by 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

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 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...