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

[ProWo]

When asked to select another container, what does it mean?

Not all stream types can be muxed into every container (avi, mp4, mov, ts, mkv, etc.).
The container that accepts the most stream types is mkv.
If you see this message, select mkv as the container.


[Attachment 92947 - Click to enlarge]

[Findu]

@ProWo
3.5.6 feedback 3

The preview does not display when I select Pixel format amf or qsv.

[Findu]

@ProWo
3.5.6 feedback 4

Can the messagebox buttons be moved further down?


[Attachment 92948 - Click to enlarge]

---

It's good that the first settings page close when the second one opens.
Why not jump back to the first page from the second page?


[Attachment 92949 - Click to enlarge]


[Attachment 92950 - Click to enlarge]

[BlueSky]

When asked to select another container, what does it mean?

Not all stream types can be muxed into every container (avi, mp4, mov, ts, mkv, etc.).
The container that accepts the most stream types is mkv.
If you see this message, select mkv as the container.


[Attachment 92947 - Click to enlarge]

Thanks, I'll do that the next time. Incidentally, those subtitle streams that couldn't be multiplexed were contained inside the original .mp4 file that I converted from 3180 to 1920.

Correction: The original file was indeed an .MKV. I was able to extract the subtitle file I wanted and OCR'd it with Subtitle Edit.

[ProWo]

3.5.6 feedback 4
1) Can the messagebox buttons be moved further down?
2) Why not jump back to the first page from the second page?

Should all be fixed now. You have PM.

[Findu]

@ProWo
3.5.6.01 feedback

The Settings page switch is working.
But (not important), is it possible to close page 1 when page 2 opens?

The preview is now working with Pixel format amf or qsv.

And thank you for moving the messagebox buttons.

[Findu]

@ProWo
3.5.6.01 feedback 2

While testing vf frc_amf (AMF Frame Rate Converter), I noticed the following:
If you disable Keep duration at video encoding, the preview uses the original size rather than the scale you set under Preview window height.

[oniiz86]

@ProWo I have an AVI file with two durations "01:33:13.000" & "01:22:36.720", yes I know it's weird & how that is even possible, I certainly don't know but I was curious if you could hazard a guess as to why Clever FFmpeg-GUI's muxer selects the correct longer duration "01:33:13.000" when muxing to MKV but MKVToolNix's muxer selects the shorter incorrect duration "01:22:36.720", what is FFmpeg doing so right that MKVToolNix is having an issue muxing the correct longer duration?

The only way I can get MKVToolNix to mux the correct longer duration is if I extract the streams first with Clever FFmpeg-GUI then it will be okay like Clever's muxer, also is there any reason why when Clever muxes this file to MKV it adds 40ms, the file duration is "01:33:13.000" but Clever's muxer will make the MKV file become "01:33:13.040"?

MKVToolNix muxed MKV

[Attachment 92959 - Click to enlarge]

Clever-FFmpeg-GUI muxed MKV

[Attachment 92960 - Click to enlarge]

I have the file here if you'd like to take a look at it https://transfer.it/t/K7JUQIlVibAb

MediaInfo

Format : AVI
Format/Info : Audio Video Interleave
Format settings : BitmapInfoHeader / WaveFormatEx
File size : 701 MiB
Duration : 1 h 33 min
Overall bit rate mode : Variable
Overall bit rate : 1 051 kb/s
Frame rate : 25.000 FPS
Writing application : VirtualDubMod 1.5.10.2 (build 2542/release)
Writing library : VirtualDubMod build 2542/release

Video
ID : 0
Format : MPEG-4 Visual
Format profile : Advanced Simple@L5
Format settings : BVOP2
Format settings, BVOP : 2
Format settings, QPel : No
Format settings, GMC : No warppoints
Format settings, Matrix : Default (H.263)
Codec ID : XVID
Codec ID/Hint : XviD
Duration : 1 h 33 min
Source duration : 1 h 22 min
Bit rate : 894 kb/s
Width : 624 pixels
Height : 352 pixels
Display aspect ratio : 16:9
Frame rate : 25.000 FPS
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Compression mode : Lossy
Bits/(Pixel*Frame) : 0.163
Stream size : 528 MiB (75%)
Writing library : XviD 1.2.1 (2008-12-04)

Audio
ID : 1
Format : MPEG Audio
Format version : Version 1
Format profile : Layer 3
Format settings : Joint stereo / MS Stereo
Codec ID : 55
Codec ID/Hint : MP3
Duration : 1 h 33 min
Source duration : 1 h 22 min
Bit rate mode : Variable
Bit rate : 126 kb/s
Channel(s) : 2 channels
Sampling rate : 48.0 kHz
Frame rate : 41.667 FPS (1152 SPF)
Compression mode : Lossy
Stream size : 76.3 MiB (11%)
Alignment : Aligned on interleaves
Interleave, duration : 24 ms (0.60 video frame)
Interleave, preload duratio : 142 ms
Writing library : LAME3.90.
Encoding settings : -m j -V 4 -q 2 -lowpass 17.6 --abr 126

[ProWo]

@ProWo
But (not important), is it possible to close page 1 when page 2 opens?

Will be done

If you disable Keep duration at video encoding, the preview uses the original size rather than the scale you set under Preview window height.

Already fixed in my actual nightly I'm working on.

[ProWo]

@ProWo I have an AVI file with two durations "01:33:13.000" & "01:22:36.720", yes I know it's weird & how that is even possible, I certainly don't know but I was curious if you could hazard a guess as to why Clever FFmpeg-GUI's muxer selects the correct longer duration "01:33:13.000" when muxing to MKV but MKVToolNix's muxer selects the shorter incorrect duration "01:22:36.720", what is FFmpeg doing so right that MKVToolNix is having an issue muxing the correct longer duration?

The only way I can get MKVToolNix to mux the correct longer duration is if I extract the streams first with Clever FFmpeg-GUI then it will be okay like Clever's muxer, also is there any reason why when Clever muxes this file to MKV it adds 40ms, the file duration is "01:33:13.000" but Clever's muxer will make the MKV file become "01:33:13.040"?

Your avi was converted from another framerate to 25 fps.
The original duration tag was preserved as source duration "01:22:36.720", but the new correct duration is "01:33:13.000".
I don't know why Mkvtoolnix takes the "source duration" tag into account.
The little difference of 40 ms (01:33:13.000 vs 01:33:13.040) is caused by ffmpeg mkv muxers overhead.
But it doesn't matter.

[oniiz86]

Your avi was converted from another framerate to 25 fps.
The original duration tag was preserved as source duration "01:22:36.720", but the new correct duration is "01:33:13.000".
I don't know why Mkvtoolnix takes the "source duration" tag into account.
The little difference of 40 ms (01:33:13.000 vs 01:33:13.040) is caused by ffmpeg mkv muxers overhead.
But it doesn't matter.

@ProWo Thanks for that, did you happen to have a look at the file? I didn't personally encode this AVI & are you sure it was converted from another framerate as I believe it was from a PAL DVD 25 fps as it's a British film, the 23.976 fps to 25 fps conversion wouldn't account for the 11 min difference, what is strange is that there are no sync issues at all despite the source duration/duration discrepancy, thanks once again for your time.

[ProWo]

...are you sure it was converted from another framerate as I believe it was from a PAL DVD 25 fps as it's a British film, the 23.976 fps to 25 fps conversion wouldn't account for the 11 min difference, what is strange is that there are no sync issues at all despite the source duration/duration discrepancy, thanks once again for your time.

Source duration : 1 h 22 min

This tag in the mediainfo report shows that the original source was 1h 22 min long.

[Findu]

@ProWo
3.5.6.01 feedback 3

All transpose methods, like cudatranspose, _opencl, _vaapi, _vulkan and vpp_qsv offer at least these four options out of a total of seven.

transpose AVOptions:
cclock_flip 0 ..FV....... rotate counter-clockwise with vertical flip
clock 1 ..FV....... rotate clockwise
cclock 2 ..FV....... rotate counter-clockwise
clock_flip 3 ..FV....... rotate clockwise with vertical flip

So how about adding 0 and 3 to the app list so that you only need one coding process instead of two?


[Attachment 93033 - Click to enlarge]

By the way: the code transpose=1,transpose=1 is just as fast as transpose=4 (rotate by half a turn)

[ProWo]

So how about adding 0 and 3 to the app list so that you only need one coding process instead of two?

Thx for testing, will add 0 and 3.
BTW, The numerical values don't seem to be working anymore.

Numerical values are deprecated, and should be dropped in favor of symbolic constants

Will replace them.

[Findu]

So how about adding 0 and 3 to the app list so that you only need one coding process instead of two?

Thx for testing, will add 0 and 3.
BTW, The numerical values don't seem to be working anymore.

Numerical values are deprecated, and should be dropped in favor of symbolic constants

Will replace them.

Good to know.
Thank you.

---

For those who aren't familiar with the subject.

Raw video streams:

[Attachment 93060 - Click to enlarge]

How about adding a text like: Usual values are 23.976, 24, 25, 30 or 60 fps.

[oniiz86]

@ProWo I was doing a HDR-SDR conversion and noticed the "npl" tooltip suggests a higher nits value makes for a darker image which I don't believe is correct, surely 200 is brighter? You had said the following over at Doom9, "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."

[Attachment 93062 - Click to enlarge]

EDIT: I just noticed another earlier Doom9 post when you had introduced this "npl" setting suggesting a lower value is brighter, "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.


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

EDIT 2: Please excuse my ignorance, I had to school myself on how FFmpeg's tonemapping filter works regarding the Nominal Peak Luminance "npl" value & you are quite correct, please ignore my unnecessary post.

[pchan]

@ProWo,
I have taken a look at your latest version and the menu has changed quite a bit.
Just one suggestion that will be helpful for a newbie to use your app i.e. a process flow chart. A step by step process flow from selecting video to the finale encoded video, demux audio/video etc. This process flow chart steps should be clickable by users for setting up. It should appear in all windows for ease of navigation.

[ProWo]

For those who aren't familiar with the subject.
Raw video streams:

How about adding a text like: Usual values are 23.976, 24, 25, 30 or 60 fps.

This has nothing to do with raw streams. This message appears when ffprobe's video analysis detects two different frame rates. This allows you to select one of the two, and that selection then determines how the video is processed.

[ProWo]

@ProWo,
I have taken a look at your latest version and the menu has changed quite a bit.
Just one suggestion that will be helpful for a newbie to use your app i.e. a process flow chart. A step by step process flow from selecting video to the finale encoded video, demux audio/video etc. This process flow chart steps should be clickable by users for setting up. It should appear in all windows for ease of navigation.

My GUI has a wide variety of different functions.
Your suggestion would unnecessarily bloat the program and wouldn't provide any real added value.
I think the program's workflow is fairly clearly structured, and that users will be able to navigate it easily after a short learning curve.
In addition, I've linked some tutorial videos addressing specific issues on the first page of the program thread.

[jopavirando]

In addition, I've linked some tutorial videos addressing specific issues on the first page of the program thread.

Thanks Prowo. If you can, please keep the tutorial updated as needed.

[oniiz86]

@ProWo I came across this blog on FFmpeg's HDR-SDR Tonemapping conversion here https://32blog.com/en/ffmpeg/ffmpeg-hdr-to-sdr-tonemapping which I'm a little confused about it mentioning that if using the "Hable" algorithm & output is too dark, it suggests to increase the "npl" to 200 for brighter output, I thought my understanding of it in my above post caused confusion at first but then I thought I had a clearer understanding of it but I guess not, does the concern only apply to the "Hable" algorithm & not "Mobius"?

[Attachment 93097 - Click to enlarge]

[ProWo]

@ProWo I came across this blog on FFmpeg's HDR-SDR Tonemapping conversion here https://32blog.com/en/ffmpeg/ffmpeg-hdr-to-sdr-tonemapping which I'm a little confused about it mentioning that if using the "Hable" algorithm & output is too dark, it suggests to increase the "npl" to 200 for brighter output...

This info is wrong. Higher npl values gives darker output.
Test is yourself.

[oniiz86]

@ProWo I came across this blog on FFmpeg's HDR-SDR Tonemapping conversion here https://32blog.com/en/ffmpeg/ffmpeg-hdr-to-sdr-tonemapping which I'm a little confused about it mentioning that if using the "Hable" algorithm & output is too dark, it suggests to increase the "npl" to 200 for brighter output...

This info is wrong. Higher npl values gives darker output.
Test is yourself.

@ProWo Okay because I wasn't certain, I may have to experiment, as I said above, I saw you had mentioned this over at Doom9 "However, I have found that a slightly higher value, such as npl=200, produces a more vivid image.", the term "vivid" does suggest the image is brighter, that is where some of the confusion lies.