clever FFmpeg-GUI, small FFmpeg UI, fully portable, no installation.

[Lathe]

If possible, try the following script to use FFmpeg directly and let's see what happens.

setlocal

set src=Test.mkv
set start=1:00:00
set length=10
set npl=203

ffmpeg -ss %start% -i "%src%" -map 0:v:0 -vf zscale=m=gbr:t=linear:dither=none:npl=%npl%,format=gbrpf32le,tonemap=mobius:desat=0,zscale=1920:-1:f=spline36,zscale=m=709:t=709:p=709:r=limited:dither=error_diffusion,format=yuv420p,sidedata=delete -c:v libx264 -crf 18 -t %length% "test.mp4"

endlocal
pause

Change the variables src, start, and length: the last two so that you don't have to encode the whole file. Place the code in a BAT file, along with an ffmpeg executable in the same folder, and run.

Thanks! I just now also updated comparisons between how this program and Handbrake's encodes look above this post. There is definitely something that changed with Clever FFMpeg since I've used it before.

I am NOT conversant in using this kind of code, but I can save the text you gave me as a .bat file and I guess place it in the FFMpeg folder where the .exe is and try it. I have NO idea what it is doing though... :)

***EDIT

Oh, I see (I think...) it is executing the same text that is in the BE_text file.

[GeoffreyA]

It takes "Test.mkv" and converts it from HDR to BT.709 SDR, scaling down to 1080p as well, and encodes with x264. The problem with FFmpeg's conversion, and I expect programs that are using FFmpeg behind the scenes, is that the result is over-saturated. I think it's a bug somewhere. (This is of interest to me because, as it turns out, this week I've been cleaning up my HDR scripts, getting them down to a final version, so that I can convert 4K LOTR Theatrical to 1080p SDR. So far, I've settled on using VapourSynth.)

[ProWo]

@ProWo... Bro, I'm sorry to keep pestering you, but I just started another enode from an UHD full 4k Blu-ray source and with the exact same settings that I ALWAYS use, yep, it is turning out all weird and dark again!

You might want to check to see if maybe you changed something, because this is 2 in a row that are not turning out right. Now the ONLY thing that I can see that is superficially different, is that when you choose 'Various' and you select HDR-SDR, the saturation used to default to '2', now it shows '0' when the window opens, so you actually have to set it to '2' which was what the default was before. Other than that, I don't see any other obvious changes, but these movies are not coming out right and you should know so you can see what is going on. Here is the BE_text:

Video ---> x264 (avc) - Stream ID 0 from?G:\___TL\HEVC.mkv?6672167?-hide_banner -loglevel error -stats -y -fflags +genpts -i "G:\___TL\HEVC.mkv" -vf fps=24000/1000,scale=1920:1080,zscale=t=linear:npl=200,tonemap=mobius:desat=2,sidedata=delete,colorspace=all=bt709:iall=bt2020,format=yuv420p -map 0:0 -c:v libx264 -profile:v high -preset medium -tune film -crf 18 -aspect 1.78 -an -sn -dn -metadata:g encoding_tool="clever FFmpeg-GUI" ?D:\__HEVC.mkv

These are with the exact same settings with BOTH programs that I have always used for UHD to SD and HDR-SDR.
Hi Lathe,
you're right, I have changed the npl value from 100 to 200, after many tests. You can edit the BT_open.txt, change the npl=200 to npl=100, save the file and fire up clever FFmpeg-GUI and click execute.
You will get the exact same result as before.

#EDIT:
There are other changes to investigate on. I'll come back to you soon with the results.

In the next beta I'll add a possibility to change this value (lower is brighter).

[Lathe]

It takes "Test.mkv" and converts it from HDR to BT.709 SDR, scaling down to 1080p as well, and encodes with x264. The problem with FFmpeg's conversion, and I expect programs that are using FFmpeg behind the scenes, is that the result is over-saturated. I think it's a bug somewhere. (This is of interest to me because, as it turns out, this week I've been cleaning up my HDR scripts, getting them down to a final version, so that I can convert 4K LOTR Theatrical to 1080p SDR. So far, I've settled on using VapourSynth.)

Ah, good to know, thanks!

ProWo just sent me an .exe to try and so far it is doing a great job! I like the encode a little better than the Handbrake, it is a tad clearer and sharper.

[Lathe]

Hi Lathe,
you're right, I have changed the npl value from 100 to 200, after many tests. You can edit the BT_open.txt, change the npl=200 to npl=100, save the file and fire up clever FFmpeg-GUI and click execute.
You will get the exact same result as before.

#EDIT:
There are other changes to investigate on. I'll come back to you soon with the results.

In the next beta I'll add a possibility to change this value (lower is brighter).

Thanks Bro! Yep, the .exe you just sent me seems to be doing a great job! Really appreciate it man!

[GeoffreyA]

Ah, good to know, thanks!

ProWo just sent me an .exe to try and so far it is doing a great job! I like the encode a little better than the Handbrake, it is a tad clearer and sharper.

That's good news!

Yesterday, I was experimenting with libplacebo and it blew the other methods out of the water. Its "Spline" tone-mapping operator beats Mobius, Reinhard, and Hable, and its colour-gamut conversion mechanism as well. Even a challenging scene, Galadriel coming down the stairs in front of the candles, comes out excellent without overblown highlights.

[GeoffreyA]

Hi Lathe,
you're right, I have changed the npl value from 100 to 200, after many tests. You can edit the BT_open.txt, change the npl=200 to npl=100, save the file and fire up clever FFmpeg-GUI and click execute.
You will get the exact same result as before.

#EDIT:
There are other changes to investigate on. I'll come back to you soon with the results.

In the next beta I'll add a possibility to change this value (lower is brighter).

ProWo, you may be able to improve the conversion further by downscaling in linear light, using Spline36, and using zscale instead of colorspace for the conversation to BT.709 and YUV420 at the end. Also, scaling after tone mapping can eliminate some rare artefacts related to text.

[Lathe]

That's good news!

Yesterday, I was experimenting with libplacebo and it blew the other methods out of the water. Its "Spline" tone-mapping operator beats Mobius, Reinhard, and Hable, and its colour-gamut conversion mechanism as well. Even a challenging scene, Galadriel coming down the stairs in front of the candles, comes out excellent without overblown highlights.

Hmmm... I'll hafta try that 'Spline' operator, I THINK it is a choice on the Clever program.

[Lathe]

Hi Lathe,
you're right, I have changed the npl value from 100 to 200, after many tests. You can edit the BT_open.txt, change the npl=200 to npl=100, save the file and fire up clever FFmpeg-GUI and click execute.
You will get the exact same result as before.

#EDIT:
There are other changes to investigate on. I'll come back to you soon with the results.

In the next beta I'll add a possibility to change this value (lower is brighter).

Yes, as the PM I sent you shows, I did change that value on the Various tab when converting HDR-SDR from 200 to 100, and the movie I was doing, the UHD of 'THE FACULTY' then looked really good. I think I sent you comparative screen shots.

[ProWo]

Newest beta (v3.3.4.01), online now.

Added:
Set npl value for HDR to SDR tonemapping.
aac_mf audio encoder,
h264_mf video encoder (thx to Findu for the latter two hint).
Error check during task processing.

Fixed:
Bug in HDR to SDR tonemapping (thx to Lathe for the hint).

[Lathe]

Newest beta (v3.3.4.01), online now.

Added:
Set npl value for HDR to SDR tonemapping.
aac_mf audio encoder,
h264_mf video encoder (thx to Findu for the latter two hint).
Error check during task processing.

Fixed:
Bug in HDR to SDR tonemapping (thx to Lathe for the hint).

U Da Man!

[ProWo]

...The only difference is that when I imported the UHD file, your program gave me a prompt that I will post below. So, I don't know in that case if I should still use HDR-SDR, although the prompt seems to state that the movie is indeed in HDR. So, what exactly should I do and why is it all dark again now with the new .exe? And, what do I do if I see that prompt, should I go ahead and set it to do HDR-SDR or should I not?

If the HDR metadata is missing, you can no longer re-encode the video as HDR, but everything else remains the same.
Re-encode to SDR with the usual HDR to SDR settings.

[Lathe]

If the HDR metadata is missing, you can no longer re-encode the video as HDR, but everything else remains the same.
Re-encode to SDR with the usual HDR to SDR settings.

Yep, that is what I ended up doing. And, when I changed the setting from 200 to 100 on this particular movie then it seemed to look fine. I guess on some films if it starts to come out really dark I will need to do that.

[Z2697]

ProWo, you may be able to improve the conversion further by downscaling in linear light, using Spline36, and using zscale instead of colorspace for the conversation to BT.709 and YUV420 at the end. Also, scaling after tone mapping can eliminate some rare artefacts related to text.

libplacebo can handle the scaling and conversion as well

[GeoffreyA]

libplacebo can handle the scaling and conversion as well

This is the command-line I setted on:

ffmpeg -init_hw_device vulkan [...] -vf libplacebo=peak_detect=true:tonemapping=spline:gamut_mode=perceptual:w=1920:h=-1:downscaler=spline36:colorspace=bt709:color_trc=bt709:color_primaries=bt709:range=limited:dithering=blue:deband=false:skip_aa=true:disable_linear=false:format=yuv420p,crop=%crop%,sidedata=delete [...]

[Z2697]

This is the command-line I setted on:

ffmpeg -init_hw_device vulkan [...] -vf libplacebo=peak_detect=true:tonemapping=spline:gamut_mode=perceptual:w=1920:h=-1:downscaler=spline36:colorspace=bt709:color_trc=bt709:color_primaries=bt709:range=limited:dithering=blue:deband=false:skip_aa=true:disable_linear=false:format=yuv420p,crop=%crop%,sidedata=delete [...]

I don't think skip_aa=true is a good idea.
"Applying AA" is actually what most resize filter do.

[GeoffreyA]

I don't think skip_aa=true is a good idea.
"Applying AA" is actually what most resize filter do.

That part confused me because I was under the impression that enabling AA would damage detail. But what you say makes sense. Thanks for the tip. I'll have to re-encode "Fellowship" and the encode has been running (and still is) for nine hours :)

Any other tips for maximum quality with libplacebo? I noticed that it uses 16-bit float by default. If I convert to 32 bit beforehand (with zscale), it creates the internal textures at 32-bit float (r32f) but then uses rgba16haf, I think, before running the shader programs.

[Z2697]

That part confused me because I was under the impression that enabling AA would damage detail. But what you say makes sense. Thanks for the tip. I'll have to re-encode "Fellowship" and the encode has been running (and still is) for nine hours :)

Any other tips for maximum quality with libplacebo? I noticed that it uses 16-bit float by default. If I convert to 32 bit beforehand (with zscale), it creates the internal textures at 32-bit float (r32f) but then uses rgba16haf, I think, before running the shader programs.

I guess the precision of fp16 is not plenty, but enough. It should have "11-bit precision" (10 bits fraction field) according to wikipedia.

Another thing I would keep an eye out is chroma location, at least something similar, could be general chroma shift but less likely. I saw some weirdness with vs-placebo (sgt's fork) but not sure what's the case with FFmpeg.

[Lathe]

That part confused me because I was under the impression that enabling AA would damage detail. But what you say makes sense. Thanks for the tip. I'll have to re-encode "Fellowship" and the encode has been running (and still is) for nine hours :)

Any other tips for maximum quality with libplacebo? I noticed that it uses 16-bit float by default. If I convert to 32 bit beforehand (with zscale), it creates the internal textures at 32-bit float (r32f) but then uses rgba16haf, I think, before running the shader programs.

You guys are SO far above my paygrade it's not even funny... https://lh3.googleusercontent.com/pw/AP1GczNbHYEU7SXU6hiIPoDFs1zcmEvyx9P0WbGl6ruemF25_PdeDrslBGUr23QjuMeRv-fuYNHz7cKN9Eskl7F5jMx1Yz1XUHCBJIqo5kSqgGrhTmAkRWMa59XctCb1XFFTpOIf1-RMl_0BlSQfE23bufCL4w=w15-h15-s-no-gm?authuser=0

[GeoffreyA]

You guys are SO far above my paygrade it's not even funny... https://lh3.googleusercontent.com/pw/AP1GczNbHYEU7SXU6hiIPoDFs1zcmEvyx9P0WbGl6ruemF25_PdeDrslBGUr23QjuMeRv-fuYNHz7cKN9Eskl7F5jMx1Yz1XUHCBJIqo5kSqgGrhTmAkRWMa59XctCb1XFFTpOIf1-RMl_0BlSQfE23bufCL4w=w15-h15-s-no-gm?authuser=0

With encoding always changing (how different were the DivX days!), I think we're all beginners in a way. But that's why we love it :)

[GeoffreyA]

Another thing I would keep an eye out is chroma location, at least something similar, could be general chroma shift but less likely. I saw some weirdness with vs-placebo (sgt's fork) but not sure what's the case with FFmpeg.

Basically, I've ignored chroma location because I didn't fully understand it. Today, digging into this topic and testing, it seems that FFmpeg causes the source CL to go through to the end. For an HEVC source, that would be top-left, and an AVC encode derived from this would also be top-left. (I think AVC is supposed to be left.)

[ProWo]

Newest beta (v3.3.4.02), online now.

Added:
Readded start at last position (request by Findu).
Mux vc1 video to asf, avi, mkv, mov, mp4, wmv.

Fixed:
Bug in audio encoding with keep open checked.
Typo on update message (thx to Findu for the hints).

[ProWo]

----------------------------------------------------------------------------------
December 17, 2024 release version 3.3.5.
----------------------------------------------------------------------------------

Added:
Set npl value for HDR to SDR tonemapping.
aac_mf audio encoder,
h264_mf video encoder (thx to Findu for the latter two hint).
Error check during task processing.
Readded start at last position (request by Findu).
Mux vc1 video to asf, avi, mkv, mov, mp4, wmv.

Fixed:
Bug in HDR to SDR tonemapping (thx to Lathe for the hint).
Bug with multiple cuts in cut and join section.
Bug in audio encoding with keep open checked.
Typo on update message.
Graphical error in the audio encoding grid (thx to Findu for the hints).
Bug in update process.

Improved:
Update process.

Changed:
The whole information system. from messagebox to centered Info window.

----------------------------------------------------------------------------------

NOTE: If you're already using clever-FFmpeg-GUI, replace the exe only with the new version.
Leave the other files to keep the previous settings.

[Lathe]

----------------------------------------------------------------------------------
December 17, 2024 release version 3.3.5.
----------------------------------------------------------------------------------

Added:
Set npl value for HDR to SDR tonemapping.
aac_mf audio encoder,
h264_mf video encoder (thx to Findu for the latter two hint).
Error check during task processing.
Readded start at last position (request by Findu).
Mux vc1 video to asf, avi, mkv, mov, mp4, wmv.

Fixed:
Bug in HDR to SDR tonemapping (thx to Lathe for the hint).
Bug with multiple cuts in cut and join section.
Bug in audio encoding with keep open checked.
Typo on update message.
Graphical error in the audio encoding grid (thx to Findu for the hints).
Bug in update process.

Improved:
Update process.

Changed:
The whole information system. from messagebox to centered Info window.

----------------------------------------------------------------------------------

NOTE: If you're already using clever-FFmpeg-GUI, replace the exe only with the new version.
Leave the other files to keep the previous settings.

Awesome, thanks Bro!

So, about the npl (which I have NO bloody idea what it is... :)) the default I believe is 200. Only in ONE case did it seem that I needed to change it to 100 because the movie was so dark ('THE FACULTY' UHD) what exactly determines what it should be? Is it set to 200 because that is the default setting for most movies that works best, or what determines if we should change it, just by how it looks and doing it based upon our own perception of how bright it should be?

I just did the UHD film 'CAT O' NINE TAILS', and the 200 setting in comparing the Clever encode to the original was indeed brighter and looked fine. So, is this value just kind of a 'Floating' thing, or how should I look at it.

Thanks!

[ProWo]

So, about the npl (which I have NO bloody idea what it is... :)) the default I believe is 200. Only in ONE case did it seem that I needed to change it to 100 because the movie was so dark ('THE FACULTY' UHD) what exactly determines what it should be? Is it set to 200 because that is the default setting for most movies that works best, or what determines if we should change it, just by how it looks and doing it based upon our own perception of how bright it should be?

The npl value indicates approximately the nits value for the HDR to SDR conversion. For your information: HDR10 can be mastered with up to 10000 nits, normal SDR content is mastered with 100 nits. So nlp=100 should actually be the correct value for the HDR10 to SDR conversion. However, I have found that a slightly higher value, such as npl=200, produces a more vivid image. But that's ultimately a matter of taste. There is no default value.

[ProWo]

Newest beta (v3.3.5.01), online now.

Improved:
DVD Movie rip completely recoded. (unprotected DVD's only).

Changed:
File already exists! messagebox recoded to new type.
Column alignment in batch task grid (thx to Findu for the hint).
New info message system: increased fontsize from 8 to 9, buttons centered now.

[Lathe]

The npl value indicates approximately the nits value for the HDR to SDR conversion. For your information: HDR10 can be mastered with up to 10000 nits, normal SDR content is mastered with 100 nits. So nlp=100 should actually be the correct value for the HDR10 to SDR conversion. However, I have found that a slightly higher value, such as npl=200, produces a more vivid image. But that's ultimately a matter of taste. There is no default value.

Ah, that's what I thought, thanks!

[ProWo]

Newest beta (v3.3.5.02), online now.

Added:
New automatic updater (for Windows 10 & 11, thx to Findu for the hints).
Batch grid: Action column fits content now.

Fixed:
Bug with streams detection in VTS_vobs.
Bug in mux code.
Bug with automatic correction of start position values out of screen bounds.

Improved:
Update info for earlier Windows versions.

[ProWo]

Newest beta (v3.3.5.03), online now.

Added:
Update reminder (if update wasn't done).

Fixed:
Bug with DVD rip aborting (thx to Findu for the hint).

[ProWo]

Attention!
There was a bug in the latest beta v3.3.5.03.
It has already been fixed.
If you have updated before 13:09 CET 21 December 2024, please download the latest beta again.

EDIT:
If you have an error message at startup, open the portable.config file with a text editor, delete the line
<upd_reminder>...</upd_reminder>
and save the file.

[ProWo]

Newest beta (v3.3.5.04), online now.

Added:
Audio volume detection result info.
Check for raw videostream adding in multiplex grid; it's blocked now (thx to Findu for the hint).
Settings button in select source grid; you can now change target folder and ffmpeg bin folder locations (thx to Findu for the hint).

Fixed:
Bug in update reminder.
Bug in wrong start position values automatic correction.

[Lathe]

It's interesting, I was doing the full UHD movie 'STIR OF ECHOES' and I noticed that at the 200 nit setting it was coming out rather dark. So, just to try, I changed the nit setting to 150 and it came out beautifully!

I wonder why certain UHD movies with the default 200 setting come out just fine whereas occasionally a few others need to be set at either 150 or in one case 100?

[GeoffreyA]

It's interesting, I was doing the full UHD movie 'STIR OF ECHOES' and I noticed that at the 200 nit setting it was coming out rather dark. So, just to try, I changed the nit setting to 150 and it came out beautifully!

I wonder why certain UHD movies with the default 200 setting come out just fine whereas occasionally a few others need to be set at either 150 or in one case 100?

Each film has a different average brightness, which, I think, leads to varying results. If possible, I recommend giving libplacebo in FFmpeg a try. It computes average brightness frame by frame, and the results are drastically better than the static NPL way of handling it.

Last week, after months of breaking my head, I converted all three "Lord of the Rings" and the results were truly excellent, beating, I think, even the official SDR versions in range of brightness and darkness. The brightness was spot on, and best of all, there's no NPL setting to fiddle with.

[Lathe]

Each film has a different average brightness, which, I think, leads to varying results. If possible, I recommend giving libplacebo in FFmpeg a try. It computes average brightness frame by frame, and the results are drastically better than the static NPL way of handling it.

Last week, after months of breaking my head, I converted all three "Lord of the Rings" and the results were truly excellent, beating, I think, even the official SDR versions in range of brightness and darkness. The brightness was spot on, and best of all, there's no NPL setting to fiddle with.

Yes, I remember you talking about that and doing all that work to figure it out. But, without a nice, EASY interface like Clever (or Handbrake) I don't think I have the complex encoding knowhow to do that. I wouldn't mind trying it, but I have no idea where to start.

I can do very simple CMD line stuff and I can do very simple AVS stuff, but that's about it. The coding to do what you are talking about would probably be too complex for me to understand. But, I'm glad you figured it out, it would be kinda nice to be able to understand it though...

[GeoffreyA]

I agree it would be a great help to many if Clever or Handbrake added libplacebo as a choice.

If you would like to give it a go, you can paste the following into a BAT file, place ffmpeg.exe in the same folder, and drag your UHD MKV onto the BAT file:

ffmpeg -init_hw_device vulkan -i %1 -map 0:v:0 -vf libplacebo=peak_detect=true:tonemapping=spline:gamut_mode=perceptual:w=1920:h=-1:downscaler=spline36:colorspace=bt709:color_trc=bt709:color_primaries=bt709:range=limited:format=yuv420p,sidedata=delete -c:v libx264 -profile:v high -level 4.1 -crf 18 TEST.mp4

[ProWo]

Newest beta (v3.3.5.05), online now.

Added:
Output filename check with automatic rename.

Fixed:
Bug in cutted parts list reset.
Bug in cutting/muxing videos with hidden data streams (thx to Lexi for the hint).
Bug im mux maps handling.
Several small bugs.

[Lathe]

I agree it would be a great help to many if Clever or Handbrake added libplacebo as a choice.

If you would like to give it a go, you can paste the following into a BAT file, place ffmpeg.exe in the same folder, and drag your UHD MKV onto the BAT file:

ffmpeg -init_hw_device vulkan -i %1 -map 0:v:0 -vf libplacebo=peak_detect=true:tonemapping=spline:gamut_mode=perceptual:w=1920:h=-1:downscaler=spline36:colorspace=bt709:color_trc=bt709:color_primaries=bt709:range=limited:format=yuv420p,sidedata=delete -c:v libx264 -profile:v high -level 4.1 -crf 18 TEST.mp4

Wow, thanks! Heh, I THINK I can do that... :) Awesome, I'll look forward to giving it a try.

So, is this kind of a 'Universal' script that I can apply to any UHD film? Are there parameters that I will need to adjust or change for any reason?

Thanks again Bro!

[GeoffreyA]

Wow, thanks! Heh, I THINK I can do that... :) Awesome, I'll look forward to giving it a try.

So, is this kind of a 'Universal' script that I can apply to any UHD film? Are there parameters that I will need to adjust or change for any reason?

Thanks again Bro!

No problem, brother.

It should work for any film. Note that the audio isn't handled, so you'll have to do that separately and mux it. (We can put that into the script, but from a quality point of view, I wouldn't because of FFmpeg's AAC encoder. But if you want, it's easy.)

It's going to encode the video with x264. You can adjust the CRF parameter for the quality-size tradeoff. Try 22 if 18 results in too big of a file. And this is just testing but if you're doing a permanent encode, add "-preset veryslow -tune film" after CRF.

[Lathe]

No problem, brother.

It should work for any film. Note that the audio isn't handled, so you'll have to do that separately and mux it. (We can put that into the script, but from a quality point of view, I wouldn't because of FFmpeg's AAC encoder. But if you want, it's easy.)

It's going to encode the video with x264. You can adjust the CRF parameter for the quality-size tradeoff. Try 22 if 18 results in too big of a file. And this is just testing but if you're doing a permanent encode, add "-preset veryslow -tune film" after CRF.

Yeah, that will be interesting, I've never tried this kind of script before and it does look fairly straightforward. I always mux the audio later anyway with TSMuxer, especially if I have to take a TrueHD audio file in an MKV container and use UsEac3to to create a TrueHD+AC3 file. So, I always just concentrate on the video by itself.

Oh, just an observation, but I find it interesting that when taking say a 65 Gig UHD file and depending of course on the film, many times I can get away with a CRF of 17 or even 16 and still render a Blu-ray compatible file around 12-18 Gigs or so. But, of course when a movie has perhaps a lot of grain or action, I have to raise that up to 19 or 20 sometimes so that it will fit on a Blu-ray after muxing the audio and allowing for the M2ts headroom.

In order to be Blu-ray compatible, I usually use the 'Medium' setting, and with Handbrake where you can add specific x264 parameters, I then tweak the Psychovisual, Trellis, and a couple of other settings a tad higher, but I don't know if you can do that with this script (that is the ONE thing I wish I could do with Clever FFMpeg... :))

Thanks again, I look forward to trying this!

[GeoffreyA]

Yeah, that will be interesting, I've never tried this kind of script before and it does look fairly straightforward. I always mux the audio later anyway with TSMuxer, especially if I have to take a TrueHD audio file in an MKV container and use UsEac3to to create a TrueHD+AC3 file. So, I always just concentrate on the video by itself.

Oh, just an observation, but I find it interesting that when taking say a 65 Gig UHD file and depending of course on the film, many times I can get away with a CRF of 17 or even 16 and still render a Blu-ray compatible file around 12-18 Gigs or so. But, of course when a movie has perhaps a lot of grain or action, I have to raise that up to 19 or 20 sometimes so that it will fit on a Blu-ray after muxing the audio and allowing for the M2ts headroom.

In order to be Blu-ray compatible, I usually use the 'Medium' setting, and with Handbrake where you can add specific x264 parameters, I then tweak the Psychovisual, Trellis, and a couple of other settings a tad higher, but I don't know if you can do that with this script (that is the ONE thing I wish I could do with Clever FFMpeg... :))

Thanks again, I look forward to trying this!

You've got a solid process. Indeed, for my part, I just encode for playing on the computer and TV, so Blu-ray compatability hasn't been on my mind. For the audio, I just downmix to stereo, normalise with EBU R128, which solves the classic soft-dialogue problem, encode with qaac, and use MP4Box to put it all together.

Yes! CRF can be a pain with heavy grain and other sorts of material. I'm struggling to get a decent size for Arrow's 1080p RoboCop, whose grain is a nightmare; and even Criterion/StudioCanal's 1080p Mulholland Drive is giving me a hard time, despite the grain being quite fine.

As for x264 parameters, yes, you can set them in the script. Look at the following reference and use a hyphen: for example, "-bluray-compat 1 -aq-mode 3 -aq-strength 0.8" or you can do it with "-x264-params bluray-compat=1:aq-mode=3:aq-strength=0.8" and so on. I'm not too sure about VBV settings for Blu-ray compatability, though.

https://ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb

[Lathe]

You've got a solid process. Indeed, for my part, I just encode for playing on the computer and TV, so Blu-ray compatability hasn't been on my mind. For the audio, I just downmix to stereo, normalise with EBU R128, which solves the classic soft-dialogue problem, encode with qaac, and use MP4Box to put it all together.

Yes! CRF can be a pain with heavy grain and other sorts of material. I'm struggling to get a decent size for Arrow's 1080p RoboCop, whose grain is a nightmare; and even Criterion/StudioCanal's 1080p Mulholland Drive is giving me a hard time, despite the grain being quite fine.

As for x264 parameters, yes, you can set them in the script. Look at the following reference and use a hyphen: for example, "-bluray-compat 1 -aq-mode 3 -aq-strength 0.8" or you can do it with "-x264-params bluray-compat=1:aq-mode=3:aq-strength=0.8" and so on. I'm not too sure about VBV settings for Blu-ray compatability, though.

https://ffmpeg.org/ffmpeg-codecs.html#libx264_002c-libx264rgb

Excellent, thanks!

[ProWo]

----------------------------------------------------------------------------------
December 26, 2024 release version 3.3.6.
----------------------------------------------------------------------------------

Added:
Automatic updater.
OS check for automatic/manual update.
Update reminder.
Audio volume detect result info.
Check to prevent the addition of raw video streams when multiplexing.
Settings button; you can see and change ffmpeg and target folder location, ffmpeg version info.
Outfile name check for already existing files and automatic rename.
Automatic file rename with stream extraction (request by Findu).

Fixed:
Bug in DVD-Rip.
Bug in DVD-Rip aborting (thx to Findu for the hint).
Bug in automatic start position correction with wrong values.
Bug in cutting/muxing videos with data streams (thx to Lexi for the hint).
Bug with mux maps.

Improved:
Code stability.

Changed:
FFmpeg version from start screen to settings.
Some cosmetics.
Output file destination (source or target folder) with button instead of checkbox.

----------------------------------------------------------------------------------

[Lathe]

Thanks Bro for all the hard work! https://lh3.googleusercontent.com/pw/AP1GczP_acttxFxsxDHaQZvU8S0KwkhLppEefBFtDgYWJrfj1xhuuaHZMgFVCWL1jAm6OQcD7970CQbcyu-J-UPq5bWk189v_AV4sMKMA7KsgYunR5b5VMYRhLsx_vaq8aXDJ1Yuz6KDOIoQ60d2kHqvxSwYhg=w25-h18-s-no-gm?authuser=0

[ProWo]

Newest beta (v3.3.6.01), online now.
(Changelog will follow in the next full release).

[Lathe]

Newest beta (v3.3.6.01), online now.
(Changelog will follow in the next full release).

I like that new 'Settings' button on the front, sharp!

[ProWo]

Newest beta (v3.3.6.02), online now.
(Changelog will follow in the next full release).

[ProWo]

Newest beta (v3.3.6.03), online now.
(Changelog will follow in the next full release).

[ProWo]

Newest beta (v3.3.6.04), online now.
(Changelog will follow in the next full release).

[ProWo]

Newest beta (v3.3.6.05), online now.
(Changelog will follow in the next full release).

[ProWo]

Newest beta (v3.3.6.06), online now.
(Changelog will follow in the next full release).