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

[oniiz86]

@ProWo I ran into a weird issue with a file duration of 04:13:05.378, I created an AVC encoded video stream from the 4K UHD file then add the original source file to the mux deselecting the HEVC video track & forgot to swap the idx numbers which I thought wouldn't be an issue as I'm simply deselecting that extra unnecessary video track, the mux was successful but when inputting it into eac3to it did not recognise the file & reported "The format of the source file could not be detected. <ERROR>" & my OPPO BDP-105D & UDP-203 players would not play the file, when you select the file on an OPPO if you wait a few seconds some metadata will populate like resolution & framerate, it should've displayed 1920 x 800 & 23.976Hz but it displayed 0 x 0 & 0.000Hz instead & refused to play but MPC-HC & VLC player had no issues with this file, what could the issue be?

I remuxed the file with MKVToolNix & now eac3to accepts the file also MediaInfo had shown no issues with this file, all metadata was present & correct.

I'm not sure if this has always been the case with FFmpeg's muxer but is there any reason when muxing DTS-HD MA & DD+ audio tracks the "Default Duration" isn't populated & the header field is empty unlike when I mux with MKVToolNix, the Default Duration for DTS-HD MA will report 10666667 & DD+ will report 32000000. The FFmpeg muxed mkv file has an empty header field, I'm only showing the DTS-HD MA selected track but DD+ track shows the same thing.


[Attachment 94025 - Click to enlarge]

Edit: I did another AVC encode & now when selecting the original source file & deselecting the HEVC video track (which is idx 1) & swapping the idx numbers for the audio tracks & subtitle tracks, the FFmpeg muxed mkv file is now recognised by eac3to & can be played in my OPPO players, not sure how that could've made any difference by simply swapping the idx numbers.

[ProWo]

@ProWo I ran into a weird issue with a file duration of 04:13:05.378

Is the video duration really 04:13:05.378?

I created an AVC encoded video stream from the 4K UHD file then add the original source file to the mux deselecting the HEVC video track & forgot to swap the idx numbers which I thought wouldn't be an issue as I'm simply deselecting that extra unnecessary video track

You're right, no need to swap the streams here.

the mux was successful but when inputting it into eac3to it did not recognise the file

Tested now. Muxed hevc video with DTS-HD MA + DD + ac3, imported in eac3to without problems.

Please post a small cut from this video here, so i can take a look.

[oniiz86]

@ProWo I ran into a weird issue with a file duration of 04:13:05.378

Is the video duration really 04:13:05.378?

I created an AVC encoded video stream from the 4K UHD file then add the original source file to the mux deselecting the HEVC video track & forgot to swap the idx numbers which I thought wouldn't be an issue as I'm simply deselecting that extra unnecessary video track

You're right, no need to swap the streams here.

the mux was successful but when inputting it into eac3to it did not recognise the file

Tested now. Muxed hevc video with DTS-HD MA + DD + ac3, imported in eac3to without problems.

Please post a small cut from this video here, so i can take a look.

@ProWo Yes, the file duration really is 04:13:05.378, it's the recent release of Kill Bill - The Whole Bloody Affair both Vol.1 & Vol.2 combined with extended sequences, total runtime is 4 hrs 13 mins. I unfortunately cannot give you a sample as I use MKVToolNix to cut a sample with the "Split by timestamps" setting & by doing so there is no longer an issue, the issue only presented itself with FFmpeg's muxer, also do you know why when muxing with FFmpeg the Default Duration header has an empty field for DTS-HD MA & EAC3 (DD+) tracks but when muxed with MKVToolNix they are populated? TrueHD & AC3 (DD) tracks are unaffected & do have their Default Duration headers with this figure "32000000" when muxed with FFmpeg, why would the other DTS-HD MA & EAC3 (DD+) formats have an empty header field?

Does your sample with DTS-HD MA & I'm assuming you meant DD+ (EAC3) above as you wrote DD + AC3 which are the same thing have Default Duration's of 10666667 & 32000000 respectively when imported into MKVToolNix's header editor?

[ProWo]

I unfortunately cannot give you a sample as I use MKVToolNix to cut a sample

Use clever instead. Load your video (muxed with clever, not with mkvtoolnix), click cut, wait for indexing, insert start and end as in the picture, click add cut mark, then click cut.


[Attachment 94026 - Click to enlarge]

Post the result here.

Does your sample with DTS-HD MA & I'm assuming you meant DD+ (EAC3) above as you wrote DD + AC3 which are the same thing have Default Duration's of 10666667 & 32000000 respectively when imported into MKVToolNix's header editor?

Yes.

BTW:
Default Duration has no meaning.

[oniiz86]

@ProWo Thanks for that, I don't know why but I was unaware of Clever's cutting feature, thanks for letting me know. I'm sorry but I accidentally deleted the problematic file that couldn't be imported into eac3to & play on my OPPO players, I can't believe I did that, I did another AVC encode of the original 4K UHD file & this time it works without issues, I don't quite understand how this happened & can no longer duplicate the issue, what was different this time around is that when the AVC encoded video track finished & I selected the purple "Multiplex" button, the AVC track was the last track when it has always been the first track & then I'd add the source file but this time it appears to be reversed as you can see below, not sure if it has anything to do with the different beta versions from 3.5.9.02 to 3.5.9.03.


[Attachment 94027 - Click to enlarge]

I thought Default Duration was important for audio tracks to maintain seamless AV synchronisation & to ensure the broadest compatibility amongst hardware & software-based media players.

[ProWo]

... the AVC track was the last track when it has always been the first track & then I'd add the source file but this time it appears to be reversed as you can see below, not sure if it has anything to do with the different beta versions from 3.5.9.02 to 3.5.9.03.

It was changed in 3.5.9.03.
The order now is:
source streams
preprocessed streams
new added streams

[AlanFord54]

Hi ProWo, I've got a question for you: do you think it could be possible to add a feature to open file .iso and then mux to .mkv or .mp4? Please let me know. Thanks.

[ProWo]

Hi ProWo, I've got a question for you: do you think it could be possible to add a feature to open file .iso and then mux to .mkv or .mp4? Please let me know. Thanks.

Are you referring to DVD ISOs?
On newer operating systems (Windows 10 or 11), the ability to open ISO files is already built in. Double-clicking on one opens the ISO in a virtual drive.
After that, you can use the DVD rip feature in clever FFmpeg-GUI to access the VOB files, rip the movie, and then process it further (re-encode audio/video, mux, etc.).
So there's no need to implement that.

[cerian]

@ProWo
3.5.9.03 feedback

HDR10+ is no longer displayed in the Video's stream text once the file is scanned, it just shows Dolby Vision HDR10

Tested, HDR10+ is recognized and displayed correctly with 3.5.9.03.
Your file is Dolby Vision.
If you don't agree, post a snippet from your file here so I can test it.

Hi ProWo, just tested again after cutting 10 seconds from the file. 3.5.9.03 recognized that 10 seconds as HDR10+, but any file that that I have either long or have a high file size is displayed as the screenshot below.

[Attachment 94048 - Click to enlarge]

[ProWo]

Hi ProWo, just tested again after cutting 10 seconds from the file. 3.5.9.03 recognized that 10 seconds as HDR10+, but any file that that I have either long or have a high file size is displayed as the screenshot below.

During file analysis, smart FFmpeg-GUI searches the “side_data_list” for “dv_profile” data.
Only Dolby Vision videos contain this “dv_profile” entry; HDR10 and HDR10+, on the other hand, do not.
The detection should therefore be accurate.

[cerian]

Hi ProWo, just tested again after cutting 10 seconds from the file. 3.5.9.03 recognized that 10 seconds as HDR10+, but any file that that I have either long or have a high file size is displayed as the screenshot below.

During file analysis, smart FFmpeg-GUI searches the “side_data_list” for “dv_profile” data.
Only Dolby Vision videos contain this “dv_profile” entry; HDR10 and HDR10+, on the other hand, do not.
The detection should therefore be accurate.

Thank you ProWo, in the previous versions I was able to see the HDR10+ displayed even when dv_profile existed in the file. It was quite helpful, I'm sad that it's no longer displayed but thank you for the efforts, it's an amazing program you're building

[ProWo]

... in the previous versions I was able to see the HDR10+ displayed even when dv_profile existed in the file. It was quite helpful

Why helpful? it was simply wrong.

[AlanFord54]

Hi ProWo, I've got a question for you: do you think it could be possible to add a feature to open file .iso and then mux to .mkv or .mp4? Please let me know. Thanks.

Are you referring to DVD ISOs?
On newer operating systems (Windows 10 or 11), the ability to open ISO files is already built in. Double-clicking on one opens the ISO in a virtual drive.
After that, you can use the DVD rip feature in clever FFmpeg-GUI to access the VOB files, rip the movie, and then process it further (re-encode audio/video, mux, etc.).
So there's no need to implement that.

Thanks for the answer, but I'm not talking about DVD ISO. I'm talking about Bluray .iso and bluray UHD .iso. These kind of files are not supported by the GUI right now. Do you think it could be possible to implement this feature?

[ProWo]

Thanks for the answer, but I'm not talking about DVD ISO. I'm talking about Bluray .iso and bluray UHD .iso. These kind of files are not supported by the GUI right now. Do you think it could be possible to implement this feature?

Right now, I have no idea about the Blu-ray structure, what the video and audio files are, how they're muxed, and how the individual parts can be seamlessly stitched together.
If I can get my hands on an ISO, I'll take a look at it.
If the entire process can be done with FFmpeg, I'll incorporate that in the future.

EDIT: Just tested, clever can process the M2TS files directly (muxing, re-encoding/converting video, audio, and subtitles).
You have to mount the ISO first:
Enter in a PowerShell console:

Mount-DiskImage -ImagePath "Full path to\Iso_file.iso"

and press enter.

[oniiz86]

@ProWo I'm trying to use the Cut feature but for some reason it hangs on the "Indexing video" screen with a (Not Responding) message, I thought it was because the file was too large at 29.5 GB & will take a while indexing but then I tried another file at 14.6 GB & still the same issue, I guess it's an issue on my end somehow as you had shown me earlier that you accessed the Cut screen without any issues with the unreleased beta v3.5.9.04.


[Attachment 94052 - Click to enlarge]

Edit: False alarm it eventually arrived at the Cut screen, I guess I'm a little impatient with the file being 04:13:05:378 long, I shouldn't expect it to be so quick, still not sure why the program had to add the (Not Responding) message after a few seconds after clicking the Cut button.

I've attached a short sample of the file https://transfer.it/t/KlPHsIwnQbaK that when muxed with DTS-HD MA & EAC3 (DD+) audio tracks leaves the Default Duration blank, you had mentioned above that your sample with DTS-HD MA had the Default Duration of 10666667 when checked with MKVToolNix's header editor, can you please determine why it doesn't work with my file when muxed with Clever? If it's not too difficult is there something that you could implement for DTS-HD MA & EAC3 (DD+) formats so the Default Duration is always set during the muxing process like you've done for TrueHD (Default Duration 833333) & AC3 (Default Duration 32000000) formats?

[ProWo]

@ProWo I'm trying to use the Cut feature but for some reason it hangs on the "Indexing video" screen with a (Not Responding) message, I thought it was because the file was too large at 29.5 GB & will take a while indexing but then I tried another file at 14.6 GB & still the same issue

The way a video is indexed is complex, so it takes some time.
For very large files (>10 GB) on an HDD, it can take several minutes; with an SSD, it's faster. So just wait.

I've attached a short sample of the file https://transfer.it/t/KlPHsIwnQbaK that when muxed with DTS-HD MA & EAC3 (DD+) audio tracks leaves the Default Duration blank

As I said, this default duration value has no meaning.
FFmpeg does not provide a way to actively set this value.

[oniiz86]

I've attached a short sample of the file https://transfer.it/t/KlPHsIwnQbaK that when muxed with DTS-HD MA & EAC3 (DD+) audio tracks leaves the Default Duration blank

As I said, this default duration value has no meaning.
FFmpeg does not provide a way to actively set this value.

@ProWo I know you said it has no meaning this Default Duration entry & there is no way for FFmpeg to set this value but it apparently does set the value for TrueHD & AC3 audio streams when checking with MKVToolNix's header editor just not for EAC3 (DD+) & DTS-HD MA for some strange reason when muxed by FFmpeg, I believe this setting must've had some importance at some point, this is from the MPC-HC player's FAQ that was concerning DTS-HD MA audio stutters, crackles & pops during playback in a mkv file.


[Attachment 94056 - Click to enlarge]

[ProWo]

... this is from the MPC-HC player's FAQ that was concerning DTS-HD MA audio stutters, crackles & pops during playback in a mkv file.

If you're encountering these errors with DTS-HD, you'll need to use mkvtoolnix.
I've converted several movies with DTS-HD and TrueHD audio and haven't noticed any such errors.
The default duration (nanoseconds per audio frame) values for these outputs are missing.

[oniiz86]

I've converted several movies with DTS-HD and TrueHD audio and haven't noticed any such errors.
The default duration (nanoseconds per audio frame) values for these outputs are missing.

@ProWo Well actually the Default Duration value "833333" for TrueHD audio is not missing when muxed with Clever FFmpeg-GUI only DTS-HD MA & EAC3 (DD+) audio tracks are an issue. I think the Default Duration value may matter for older software like my OPPO BDP-105D player uses, it sometimes would experience random crackling sounds with DTS-HD MA tracks if that value wasn't present, I prefer the FFmpeg muxer as it has resulted in better playback with TrueHD audio tracks, not sure why but was experiencing unusual motion dropped frames effect with mkvtoolnix muxed mkvs which Clever didn't exhibit this issue at all, anyway It's not that big a deal to manually enter those values in the header editor for my Clever muxes.

[AlanFord54]

Right now, I have no idea about the Blu-ray structure, what the video and audio files are, how they're muxed, and how the individual parts can be seamlessly stitched together.
If I can get my hands on an ISO, I'll take a look at it.
If the entire process can be done with FFmpeg, I'll incorporate that in the future.

EDIT: Just tested, clever can process the M2TS files directly (muxing, re-encoding/converting video, audio, and subtitles).
You have to mount the ISO first:
Enter in a PowerShell console:

Mount-DiskImage -ImagePath "Full path to\Iso_file.iso"

and press enter.

Thanks for the answer. At the moment I'm using MakeMKV to open file .iso and muxing to .mkv. Is it possible enabling the GUI to open directly file .iso (as well as MakeMKV) ?

[ProWo]

Is it possible enabling the GUI to open directly file .iso

Will add this.

[oniiz86]

@ProWo I ran into a weird issue with a file duration of 04:13:05.378, I created an AVC encoded video stream from the 4K UHD file then add the original source file to the mux deselecting the HEVC video track & forgot to swap the idx numbers which I thought wouldn't be an issue as I'm simply deselecting that extra unnecessary video track, the mux was successful but when inputting it into eac3to it did not recognise the file & reported "The format of the source file could not be detected. <ERROR>" & my OPPO BDP-105D & UDP-203 players would not play the file, when you select the file on an OPPO if you wait a few seconds some metadata will populate like resolution & framerate, it should've displayed 1920 x 800 & 23.976Hz but it displayed 0 x 0 & 0.000Hz instead & refused to play but MPC-HC & VLC player had no issues with this file, what could the issue be?

@ProWo I guess I spoke too soon but this issue has presented itself again also with another file now, could it be an issue with the latest FFmpeg 9.0.2 release, I tried to cut a sample using Clever but the cut sample exhibits no problems, only the HDR-SDR converted AVC encoded muxed file has issues with my OPPO players & cannot be imported into eac3to, I've never experienced this with Clever before, it has always been smooth sailing with my conversions, has there been any recent changes with the HDR-SDR conversion code that may have an effect on this? Could it be the unusually long "Track Title" names, perhaps too many characters that is causing a problem?

I've attached the problematic file in full here, sorry it is a rather large file but is the only way for you to actually see what I'm experiencing. https://transfer.it/t/viGdDgxXxTjA

[Columbo]

cannot be imported into eac3to

I would be happy to look at any file that is expected to be welcomed by eac3to but which fails. I'm sure that with a sample we can quickly determine the pathology.

EDIT: I downloaded the MKV and see your problem. Investigating...

[Columbo]

RFC 9559 section 6.1 says the first Info and first Tracks elements "either MUST be stored before the first Cluster element or SHALL both be referenced by a SeekHead element occurring before the first Cluster element." This file takes the second route: its SeekHead sits ahead of the first Cluster and points to both. The RFC's recommended muxer layout (25.3.1) does put Tracks before the Clusters, so the file is legal but unusual, and eac3to's front-to-back parser simply can't currently handle it. I am attempting a fix now and will report results. If it succeeds I'll make a 4.02 test build containing it.

As usual, bugs arrive immediately after a release is made.

[Columbo]

Workaround while I test the proper fix: mkvmerge -o fixed.mkv "Dune Part One 2021.mkv". mkvmerge writes Tracks at the front.

The zeroed 754-byte Void at 296 sits exactly where Tracks normally goes, and the final Tracks is 787 bytes. It looks like the muxer reserved a slot, the final Tracks outgrew it by 33 bytes, and the muxer voided the slot and appended Tracks at the end. The writer is Lavf63.1.102, which is FFmpeg git master newer than 8.0, run through "clever FFmpeg-GUI".

Thank you for bringing this to my attention, guys!

Even before I make the 4.02 test build, oniiz86 has secured the first spot on the contributors list.

[ProWo]

...the mux was successful but when inputting it into eac3to it did not recognise the file

Thx for your file.
The HDR to SDR conversion is fine, the videotrack also.
Tested with eac3to it gives an error.
I've done a simple remux with clever (multiplex, simpe remux checkbox), and the problem is gone.
I'm using the latest ffmpeg nightly.

[Columbo]

There's a fix here:

https://rationalqm.us/eac3to/eac3to_4.02_test.rar

Thank you for reporting this and for the sample file. It was worth
raising, because it turned up a limitation eac3to has had from the
start.

The file is a valid MKV, but its Tracks element (the list of tracks
and their codec settings) sits at the very end of the file, after all
the audio and video data. The Matroska specification allows that, as
long as the directory at the front of the file (the SeekHead) points
to it. Every eac3to version so far reads an MKV from front to back and
expects the track list before the first data, so it found no tracks
and reported that the format could not be detected.

The file most likely got that way in two steps. It was muxed by
FFmpeg, which writes the track list near the start with no spare room
after it. Afterwards its track properties were edited with MKVToolNix
(mkvpropedit or the header editor in the GUI), and the edit made the
track list slightly bigger. When an edited element no longer fits in
its old place, MKVToolNix blanks the old spot and writes the element
at the end of the file instead. The track list now carries language
entries in a newer format that MKVToolNix writes and FFmpeg does not,
which points to the edit rather than to FFmpeg itself.

eac3to 4.02 test handles this layout and reads such files normally.
Remuxing the file with mkvmerge also works with any eac3to version,
because mkvmerge puts the track list back at the front.

[oniiz86]

@Columbo Unbelievable, is there anything the DG team cannot do, you guys working that magic again, I can happily confirm that using the latest eac3to 4.02 test build all is fine now, thanks so very much for the quick fix, it's oh so greatly appreciated.

@ProWo Thanks for testing the file & for the Simple Remux suggestion but is there something that you could adjust with the FFmpeg muxer so that I don't have to run the FFmpeg muxed file again using the Simple Remux option?

[Columbo]

You can use the workaround I gave to "repair" the file.

[oniiz86]

Yes thanks I had discovered that a remux with MKVToolNix would fix it too but was curious why the original FFmpeg muxed file would not play on my OPPO players when previously I had no issues when muxing using the Clever FFmpeg-GUI program, this has only been a recent issue & that is why I was hoping an improvement could be made by @ProWo for the FFmpeg muxer.