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

[oniiz86]

Close clever and stop all running instances of ffmpeg in task manager.
Restart clever, drag your video, click extract, select your attachment only and click to batch this time.
Close the app. In your target folder you'll find a new BT_open.txt file.
Post this file here.

@ProWo I've attached the BT_open.txt file, I just realised that the "Simple Remux" option changed the Attachment which is listed at the end of the subtitle streams in the original file to a Video #2 Stream after the main video stream according to MediaInfo, is that meant to happen?

MediaInfo - Original File

Image
Format : JPEG
Muxing mode : Attachment
Width : 600 pixels
Height : 900 pixels
Color space : YUV
Chroma subsampling : 4:4:4
Bit depth : 8 bits
Compression mode : Lossy
Stream size : 146 KiB (0%)

MediaInfo - Clever FFmpeg-GUI "Simple Remux"

Video #2
ID : 51
Format : V_MJPEG
Codec ID : V_MJPEG
Width : 600 pixels
Height : 900 pixels
Display aspect ratio : 0.667
Frame rate mode : Constant
Frame rate : 90 000.898 FPS
Color space : YUV
Default : No
Forced : No
Color range : Full
Matrix coefficients : BT.470 System B/G

[oniiz86]

@ProWo That 4K file above was fine during the "Simple Remux", it created that mux successfully but for some reason when I created an AVC video stream encode using Clever's HDR-SDR conversion which I then used with the original 4K file's select audio/subtitle streams muxed with MKVToolNix as it retains the attachment, it creates this "a zero byte file was generated" error when using the "Simple Remux" option, not sure why as the MKVToolNix muxed file isn't corrupted.


[Attachment 93724 - Click to enlarge]


[Attachment 93725 - Click to enlarge]

Edit: After several attempts it finally completed with "Success" but I noticed it was hanging on 93% for awhile then jumped to 99% then completed shortly after, I'm not sure why this time it worked, the only difference I did was remove the file titled "Monster Hunter 2020" from within a folder titled "Monster Hunter" that was already in a folder, I tried to extract the Attachment or what Clever now refers to "V_MJPEG" of the AVC video stream encoded MKV "Simple Remux" file & according to the FFmpeg: line's activity this time it completes within about 5-6 seconds with "Success" & goes back to the "Main Page" like it should.


[Attachment 93726 - Click to enlarge]


[Attachment 93727 - Click to enlarge]

[ProWo]

@ProWo I've attached the BT_open.txt file

Thx for the file, the commandline into is ok, but your filepaths are long and confusing.

I just realised that the "Simple Remux" option changed the Attachment which is listed at the end of the subtitle streams in the original file to a Video #2 Stream after the main video stream according to MediaInfo, is that meant to happen?

That's ok.

I'm glad it worked out after all.

[oniiz86]

@ProWo Sorry for the confusion but the issue still persists, I've attached another BT_open.txt file from another file, the one success that I had was from one file that I have when it eventually created a successful "Simple Remux" but why doesn't it work after I've created an AVC video stream encode using Clever's HDR-SDR conversion from the original 4K file which also is problematic when extracting an attachment, the issue is that it does extract but it never returns to the "Main Page" with Success, is there anything you can do to refine this extracting attachments process within Clever?

[ProWo]

@ProWo Sorry for the confusion but the issue still persists, I've attached another BT_open.txt file from another file, the one success that I had was from one file that I have when it eventually created a successful "Simple Remux" but why doesn't it work after I've created an AVC video stream encode using Clever's HDR-SDR conversion from the original 4K file which also is problematic when extracting an attachment, the issue is that it does extract but it never returns to the "Main Page" with Success, is there anything you can do to refine this extracting attachments process within Clever?

Test this:
Close clever, replace your BT_open.txt file with the attached one.
Then start clever, click Open tasks and execute the task.
It works this time?

[oniiz86]

Test this:
Close clever, replace your BT_open.txt file with the attached one.
Then start clever, click Open tasks and execute the task.
It works this time?

@ProWo I just tested this but unfortunately nothing happens, this is what I see below,


[Attachment 93733 - Click to enlarge]

Edit: I guess I spoke too soon, it does work but doesn't produce an attachment in my target folder & it takes around 3-4 minutes to complete & goes to the "Main Page" with Success. Is there any particular reason why something so small in size is taking so long to process? Could it be the FFmpeg version, I'm using 9.0.1?

Would you be able to show a small clip on how quick it is for your setup which I presume is on a Windows 11 PC, I'm still using Windows 7 perhaps that is the issue with patched for Win 7 FFmpeg builds.

[ProWo]

@ProWo I just tested this but unfortunately nothing happens
Edit: I guess I spoke too soon, it does work but doesn't produce an attachment in my target folder

The attachment is saved in your source folder (T:\) this time.

Test this file and try to extract the attachment pic.

[oniiz86]

@ProWo I just tested this but unfortunately nothing happens
Edit: I guess I spoke too soon, it does work but doesn't produce an attachment in my target folder

The attachment is saved in your source folder (T:\) this time.

Test this file and try to extract the attachment pic.

@ProWo Sorry yes, you're quite right, it was there in (T:\), I just tested your video with attachments & it was just fine, it was very quick to get back to the "Main Page", thanks so much for that sample, I know what may be the issue here, your sample only has 7 streams but my files that have the attachments, one has 51 streams & the other 28 streams but why should that matter, this is simply extracting an attachment & should go back to the "Main Page" rather quickly, is that correct, why would I be experiencing such a delay?

[ProWo]

...but my files that have the attachments, one has 51 streams & the other 28 streams but why should that matter, this is simply extracting an attachment & should go back to the "Main Page" rather quickly, is that correct, why would I be experiencing such a delay?

It's not as easy as it seems.
To extract a stream, FFmpeg has to scan the entire file. That can take some time.
But I think your video files weren't muxed correctly, which is why the timestamps aren't perfect.
Scanning the entire file obviously causes problems.
Remuxing should fix that, perhaps with fewer streams (let’s be honest, who needs 51 streams in a video file?).

[oniiz86]

...but my files that have the attachments, one has 51 streams & the other 28 streams but why should that matter, this is simply extracting an attachment & should go back to the "Main Page" rather quickly, is that correct, why would I be experiencing such a delay?

It's not as easy as it seems.
To extract a stream, FFmpeg has to scan the entire file. That can take some time.
But I think your video files weren't muxed correctly, which is why the timestamps aren't perfect.
Scanning the entire file obviously causes problems.
Remuxing should fix that, perhaps with fewer streams (let’s be honest, who needs 51 streams in a video file?).

@ProWo Sure I understand, thanks so much for your time, sorry for what seems like an exercise in tedium, it was more of a torture test to see how FFmpeg behaves with such a scenario, it's probably also my Win 7 PC being rather old too, I was curious though what did you do to the BT_open.txt file that did seem to improve the speed, was the batch task optimised somehow?

[ProWo]

I was curious though what did you do to the BT_open.txt file that did seem to improve the speed, was the batch task optimised somehow?

No, I just changed the target folder to T:\.
You should make sure you have full permissions (read and write) on your target folder.

[oniiz86]

@ProWo I was wondering why if one wants to mux an AAC audio only track, no video track, there is only the .mkv option not .mka? MKVToolNix recognises only audio is present & will set the matroska container variant accordingly. Also just a minor thing with the language codes tooltip when you hover it mentions "Show valid 3digit ISO-639 2 language codes.", there should be a space between 3 & digit "3 digit".


[Attachment 93797 - Click to enlarge]

[ProWo]

@ProWo I was wondering why if one wants to mux an AAC audio only track, no video track, there is only the .mkv option not .mka?

This are cosmetics, mkv and mka are both containers.

Also just a minor thing with the language codes tooltip when you hover it mentions "Show valid 3digit ISO-639 2 language codes.", there should be a space between 3 & digit "3 digit".

Thx for the hint, will change it.

[billw6560]

I really like this mp4 tool, using it mostly for demuxing, but there's one annoying function that seems to be missing, or at least I can't find it.

There doesn't seem to be an option to set the Output (source) to the Source folder by default. It seems that this tool forces you to pre-select the Output to a specific folder.

It's a PITA to have to reset the Output folder to the Source folder every time.

Thanks,
Bill

[ProWo]

It's a PITA to have to reset the Output folder to the Source folder every time.
Bill

Hi Bill,

click the Toggle Destination button once.
Right below you'll see Output: Source folder.
The setting is saved, so it remains the same at the next start.

[billw6560]

If it was a bug, it would have bit me, lol. Thanks!