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

[AlanFord54]

Post here a picture of the error message with the video that you can not load.

I don't get any error message. Just "File analysis in progress. Please be patient...". The GUI is like freezed, it's not able to open the file. However, usually the GUI works fine. The problem is just with some (few) 2160p video resolution files.

[ProWo]

This happens on files without scan type info (progressive/interlaced).
In this case an analysis is done with the ffmpeg idet filter.
So the gui isn't freezed, is working.
Wait until the analysis is done.

[AlanFord54]

Oh, you're right. But with these files the GUI really takes a lot of time : 13 minutes! Usually the GUI opens a file very quickly For this reason I tought the GUI was freezed. Is there a way to make this process faster ?

[ProWo]

The idet {interlaced detection) filter is really slow on high resolution files.
In the next beta I'll make this scan optional, so the user can do it or not.

[AlanFord54]

So on high resolution files it will be better to disable this scan (interlaced detection), right ? Waiting for the next beta...

[zahaqiel]

I'm having a bit of an issue with the cutting tool in the standard v3.0.8 and in the beta v3.0.8.04.

Essentially what seems to be happening is I enter a start time (11 minutes, 32 seconds), I click the "Read Times" button, the tool calculates that I mean the frame at 691.035 seconds... but then it re-assigns the value of the Start Time field to be 00:00:00.691 - it's assigning the seconds value to the field's milliseconds section. The value reassignment means that if I hit Cut at this point, it just shaves maybe one frame off the front of the video.

The end time value works fine and cuts fine, it's only the start time value that is having the issue.

[ProWo]

Newest beta (v3.0.8.05), online now.
The interlace detection scan is now optional and is only offered if the scan type cannot be determined.
This way, videos with large resolutions are read in faster.
The burn in subtitles handling has also been improved.
For text subtitles, the subtitle background can now be selected between no background, black background and semi-transparent black background.

[ProWo]

Essentially what seems to be happening is I enter a start time (11 minutes, 32 seconds), I click the "Read Times" button, the tool calculates that I mean the frame at 691.035 seconds... but then it re-assigns the value of the Start Time field to be 00:00:00.691 - it's assigning the seconds value to the field's milliseconds section. The value reassignment means that if I hit Cut at this point, it just shaves maybe one frame off the front of the video.
The end time value works fine and cuts fine, it's only the start time value that is having the issue.

The input mask for the start time is created for the fomat HH:MM:SS.MSS. When pressing the Read times button, the keyframe is determined BEFORE the entered time (because ffmpeg cuts exactly here). This exact cut point is given on the right in seconds, the corresponding time is automatically converted and displayed in the input field. So you don't need to enter anything here.
If you want to enter e.g. 691.035 seconds in the input mask, you first have to convert it to the given time format (in this example 00:11:31.035).

Anyway:
Cut 14 min of this file and post it here, so i can take a look.

[zahaqiel]

The input mask for the start time is created for the fomat HH:MM:SS.MSS. When pressing the Read times button, the keyframe is determined BEFORE the entered time (because ffmpeg cuts exactly here). This exact cut point is given on the right in seconds, the corresponding time is automatically converted and displayed in the input field. So you don't need to enter anything here.
If you want to enter e.g. 691.035 seconds in the input mask, you first have to convert it to the given time format (in this example 00:11:31.035).

Anyway:
Cut 14 min of this file and post it here, so i can take a look.

Yeah, you're misunderstanding me, so I'll take some screenshots. I am not entering the 691 value, and I have zero interest in entering a Start time that way.

I enter "00:11:32.000" as the Start time. I click "Read Times" and there is a brief flash in the "At Second" readout where it says 692.0 (the value I input, but in seconds), it then flashes up the "Keyframe before Starttime" value as 691.035 and the "Correct Starttime" as 691.202 (all good so far), but then the "At Second" value changes on its own to 0.691 (one thousandth of the time for the correct keyframe), and the "Start time" field changes on its own to copy that value into itself as "00:00:00.691". The "Keyframe before Starttime" stays displaying 691.035 and the "Correct Starttime" stays displaying 691.202, but if I click Cut those change again to match the newly assigned Start time field value/At Second value and the actual cut that occurs aligns with the 0.691 seconds value, not with the 691.035 seconds value.

Before and after using the Read Times button:

[Attachment 69193 - Click to enlarge]

There is nothing I can do to make it use the "00:11:32.000" input, because if I change the Start time again to correct it, it hides the Cut button and makes me run Read Times again, which just does exactly the same thing. And as stated above, using the Cut button cuts it at the bad Start time it's re-written my start time as, not the 00:11:31.035 keyframe it calculated that I asked for.

Also the source file I use does not affect this issue. It happens for every video file I've tested and any input time - if I put the Start time as 00:01:00.000 it calculates I want 60 seconds in, and then calculates the desired keyframe as 58.058 and then messes up the "At Second" value and Start time to be 0.058 seconds instead. Any Start time I input on any file gets divided into one thousandth of the value it ought to be, so it is not possible for me to set a meaningful Start cut point.

And unfortunately I can only put in double-digit hours, so I can't just input one thousand times the start time point to get it to math error itself into giving me what I want (which in this case would be 192 hours, 13 minutes, 20 seconds => 0 hours, 11 minutes, 32 seconds), not that I really expect that solution would have made it past the keyframe check anyway.

And I've now tested it across v3.0.8 and betas v3.0.8.04 and v3.0.8.05. Same issue in all three.

(NB: This issue does not occur with the End time value. It calculates correctly, and I have no issue cutting off stuff from the end of a video, only from cutting stuff out of the beginning of a video)

[ProWo]

There is nothing I can do to make it use the "00:11:32.000" input, because if I change the Start time again to correct it, it hides the Cut button and makes me run Read Times again, which just does exactly the same thing. And as stated above, using the Cut button cuts it at the bad Start time it's re-written my start time as, not the 00:11:31.035 keyframe it calculated that I asked for.

Try this and report here.

[zahaqiel]

Same issue in that version too.

No differences in any of the output values.

[ProWo]

Tried this with 10 videos, but can't replicate your error.


[Attachment 69196 - Click to enlarge]

[Attachment 69197 - Click to enlarge]

[zahaqiel]

What version of the ffmpeg build are you using with it (I tested with the 5.1.2 full build bin folder and the 2023-02-09 git release build bin folder), and are there any dependencies (.NET, Java version, etc) that I could potentially look at then?

Oh, and when I run the program's error check I get this:

[null @ 000002127201bac0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1440 >= 1440

But clearing the appdata/local folder doesn't change anything.

[ProWo]

What version of the ffmpeg build are you using with it (I tested with the 5.1.2 full build bin folder and the 2023-02-09 git release build bin folder)

they both work

, and are there any dependencies (.NET, Java version, etc) that I could potentially look at then?

no

Oh, and when I run the program's error check I get this:

[null @ 000002127201bac0] Application provided invalid, non monotonically increasing dts to muxer in stream 1: 1440 >= 1440

.

This is a ffmpeg error message.

But clearing the appdata/local folder doesn't change anything.

Of course, the error message has nothing to do with the application.

I think, there is a problem with your video.
You could try to remux it first and retry the cut with the remuxed one.

[zahaqiel]

Problem is the issue occurs with every video I've tried, regardless of filetype. (Edit: Nope, as predicted, issue persists even after trying on a remuxed version of the file)

And since it's correctly identifying the proper value for the starting keyframe, it seems unlikely to be a problem with the file - the problem occurs when it attempts to assign that value back across to the At Second value and Start time value.

Is there a preferred Windows OS compatibility mode?

[ProWo]

Try the following:
Delete this folder:
C:\Users\xxx\AppData\Local\clever_FFmpeg_GUI (where xxx=your user name on windows).
Then start the test version from post #520 and try the cut again.


PS
What's your OS and version?
Maybe the .NET Framework is outdated.

[zahaqiel]

Deleting the AppData\local folder and retrying with the test version you supplied does not fix the error - same output values again.

Windows 10 Pro (64-bit) version 21H2.
And that's why I asked about looking at possible dependencies - I've got the .NET Compact Framework 3.5 which may be a bit out of date, but I've also got the .NET Core SDK 2.1.509 (x64) which is less out of date.

[ProWo]

My app is developed for 4.8.
This could be the issue.
Update at least to 22h2 with all related updates.

[zahaqiel]

Yeah that seems more likely to be the issue. I'll get back to you on it, can't do that update immediately.

[zahaqiel]

Ran every possible Windows update available to me, including the update to 22h2. I now have .NET 4.8. I deleted and regenerated my AppData\Local folder. I'm using the test version you put up.

The issue is still occurring.

[zahaqiel]

I've attached a zip file of the executable and the ffmpeg bin folder I've been using, along with a test copy of the video I would like to be able to cut up.

At this point, short of just having a swing at editing the source code of the executable myself to throw in an extra comparison check between the keyframe values and the start values to correct them if they diverge, I don't really see what else I can do on my end.

[kayfam]

I ran the file thru VideoReDo TV Suite which uses ffmpeg and it spit out the following errors:
2023-02-13 21:35:47 H.264, Opening file: D:\Videos\test video.mkv, filetype is: H264 PIDs: x201 / x202
2023-02-13 21:35:47 FFmpeg (Error) - File is broken, keyframes not correctly marked!
2023-02-13 21:35:47 FFmpeg (Error) - File is broken, keyframes not correctly marked!
Obviously something is broken in the file.
Just my 2 cents worth..

[zahaqiel]

That's more likely to be due to it already having been cut by clever, and it had this issue during that cutting attempt (the original attempt was at the 00:11:32.000 mark and ending at a bit after 00:16:00.000, and it cut the end off fine, but it had the error and only trimmed off a few ms from the front, but that was obviously not aligned to the keyframes that it had detected that I asked for), than anything else. Because again the issue happens on every video file I try and I have about 9TB of video files to choose from?

[zahaqiel]

Also, just for shiggles, here's what happens in my log file when I try to open that same file in VideoReDo:

2023-02-14 17:12:25 H.264, Starting stream open for: C:\Users\[username removed]\Desktop\AnyCPU\test video.mkv
2023-02-14 17:12:25 Creating MKV reader.
2023-02-14 17:12:25 H.264, Opening file: C:\Users\[username removed]\Desktop\AnyCPU\test video.mkv, filetype is: H264 PIDs: x201 / x202
2023-02-14 17:12:25 Adding module to graph: H264 decoder
2023-02-14 17:12:25 Video Deinterlacer, Using deinterlace method: Smart, using 1 threads.
2023-02-14 17:12:25 Adding module to graph: Video Deinterlacer
2023-02-14 17:12:25 Connecting output of H264 decoder (0) to input of Video Deinterlacer (0)
2023-02-14 17:12:25 Setting graph input port: 0 to module: H264 decoder port: 0 Accepts EOF
2023-02-14 17:12:25 H264 decoder: Starting video, H264 decoder thread.
2023-02-14 17:12:25 StreamProcess: starting video deinterlacer thread.
2023-02-14 17:12:25 Movie window, using display driver: Direct3D 11
2023-02-14 17:12:25 Frame cache size: 100 frames, source frame size: 1280 x 720, cache frame size: 1280 x 720, Quality: 4, Cache size: 0.14 GB
2023-02-14 17:12:27 H.264, Starting stream open for: C:\Users\[username removed]\Desktop\AnyCPU\test video.mkv
2023-02-14 17:12:27 Creating MKV reader.
2023-02-14 17:12:27 H.264, Opening file: C:\Users\[username removed]\Desktop\AnyCPU\test video.mkv, filetype is: H264 PIDs: x201 / x202
2023-02-14 17:12:27 Adding module to graph: H264 decoder
2023-02-14 17:12:27 Setting graph input port: 0 to module: H264 decoder port: 0 Accepts EOF
2023-02-14 17:12:27 H264 decoder: Starting video, H264 decoder thread.

So, in case you need another sample, here's another video file that also gets the same 1/1000 error in cleverGUI. Different filetype and everything, but this time fresh and never been cut.

[ProWo]

@zahaqiel
Tested with your bin, the executable and your test video from your post #531.
Same with your video from post #534.
No errors.


[Attachment 69205 - Click to enlarge]

[Attachment 69206 - Click to enlarge]

At this point another try:
Download and install the latest Microsoft Visual C++ Redistributable for your OS (x64)

https://aka.ms/vs/17/release/vc_redist.x64.exe

[AlanFord54]

Well, I just tried the last beta (.05). Now the GUI took 7 minutes (with no interlaced detection) to open a file (problematic 2160p) instead of 13 minutes. It's still very slow but it's a lot better. Is there anything else you can do to make this process faster ?

[ProWo]

Well, I just tried the last beta (.05). Now the GUI took 7 minutes (with no interlaced detection) to open a file (problematic 2160p) instead of 13 minutes. It's still very slow but it's a lot better. Is there anything else you can do to make this process faster ?

That is incredibly slow.
Here, for example, a 5760x3240 video file is loaded in 0.5 seconds.


[Attachment 69212 - Click to enlarge]

It must be your system, either an extremely slow bus system, little ram or a weak CPU.

[zahaqiel]

@zahaqiel
Tested with your bin, the executable and your test video from your post #531.
Same with your video from post #534.
No errors.


[Attachment 69205 - Click to enlarge]

[Attachment 69206 - Click to enlarge]

At this point another try:
Download and install the latest Microsoft Visual C++ Redistributable for your OS (x64)

https://aka.ms/vs/17/release/vc_redist.x64.exe

That one also seemed likely - I only had up to v12, current is v14. Uninstalled all other Visual C++ redistributions, installed this one... error persists. -_-

Even ran a repair on the C++ redistribution and retested, and regenerated my appdata\Local folder and retested again, just in case. No change.

Weird question: what flavour of numerical variable type is that Start time field? Float? Double? Integer? Long? Decimal?

[ProWo]

The problem isn't The Start Time field (Masked Texbox), but the TimeSpan.FromMilliseconds function (returns a wrong value in your case), working everyware but not with your system.

Try a last thing:
Download https://files.videohelp.com/u/292773/Dism-Gui_1.2.9.7z
Start Dism-Gui and do a sfc scan (system files check scan).
If errors are found and repaired, repeat the scan.
The restart your system.


[Attachment 69216 - Click to enlarge]

[zahaqiel]

Mmm the reason I'm asking is because it seems like it may be a variable type re-assignment issue - the program is correctly identifying the Keyframe before Starttime value, and the Correct Starttime. Those values come out fine, and stay fine until it has to recheck them on the cut.

The problem occurs when those are assigned back to the Start time and At Second fields, so it seems like between the keyframe identification step and the start time reassignment step there might be a variable type change, and how conversion between numerical variable types occurs is sometimes environment-specific (since in this case, the decimal point is shifting three spaces it seems like the kind of shenanigans that can happen between int and double, or types with similar differences).

Care to share the TimeSpan.FromMilliseconds function code?

Edit: Running the scan now.