Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

A new interface using ffmpeg "h264vid.exe"

Started by hutch--, November 27, 2017, 11:15:53 AM

Previous topic - Next topic


I have done a completely new version of this interface and to date it has been particularly useful in tweaking h264 format video. The app is supplied with full 64 bit MASM source and to use it you need to have "ffmpeg" set in your computer's path as its easier to develop this way. I have disabled the check for ffmpeg in the local directory for the moment. It is designed to size the output video to a range of 16/9 standard sizes up to 4k, it can set the bitrate to control the output file size and quality and it has 2 adjustments for the unsharp mask so that you can carefully tweak the sharpness level. I have set this to the maximum range to handle video from very good to very ordinary and with high res video (1080 & 4k) the settings above and below zero are incremented very finely so you can avoid the outlining defect of over sharpening.

To set it up you need to download ffmpeg from and place both "ffmpeg.exe" and "ffplay.exe" in a directory that is in the computer's path. The logic of the application is one of getting the required settings and writing a conventional batch file that then runs ffmpeg and displays the result in ffplay. The batch file is left in the target directory so it can be modified and re-used. As usual the app is subject to change but is currently doing all of what I need it to do so it is pretty stable. I have not had any trouble loading a non mp4 video file as the source file and outputting mp4 files. Tested so far on FLV, MOV and a few other common file formats.

The MASM code is a reasonably straight forward dialog interface and a reasonable example of coding an app of this type.



I have just updated the app so that it remembers the last directory it was used in. I found that it was starting to drive me NUTZ having to climb up a directory tree each time I started it. Install is simple, delete the complete set of files for the earlier version(s) and replace them with the contents of the attached zip file.

The first time it is run it will create a default settings file "h264vid.set". It is a binary file that is not designed to be edited. If for some obscure reason it ever gets damaged, delete it and run the app again and it will create a new default settings file.

As before you need to have "ffmpeg and ffplay" in your PATH settings and it is worth downloading the later versions of ffmpeg as they keep adding capacity to it, ffplay now has sound which you can turn off by pressing "m" on your keyboard.


Amazing. Tks you so much, Steve

Do you think you can make it convert and export a mkv to Hls file as i reported here ?

And, maybe on a 32bit version ?
Coding in Assembly requires a mix of:
80% of brain, passion, intuition, creativity
10% of programming skills
10% of alcoholic levels in your blood.

My Code Sites:



What I have found using ffmpeg is that it will read almost anything and will come close to writing anything in terms of video formats so I think you will need to test the 2 formats you have mentioned.

The app itself is simply an interface using a dialog with a range of controls on it that gets the settings required and writes a batch file to call ffmpeg. The ffmpeg documentation is a nightmare and generally you just have to keep testing until you get it to work.

A 32 bit version that does the same task of calling ffmpeg should be reasonably easy to write as the interface between the app and ffmpeg is simply a batch file.


Ported this to linux x86-64, gtk3 (probably gtk4 too), uasm.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything


I have a question, is the app ported to native Linux or alternatively to a WINE emulator on Linux ?


hello sir hutch;
This is to work on linux, I'm using wine to see your program running (with fake ffmpeg.exe and ffplay.exe), so I can see your dialog and reproduce that.

Thats not working? Let me know. If you launch program in console mode that give you some error messages.
One thing that I perceived was about version. When I execute program in other linux distro program simply don't work. So, I run glade (resource editor), open glade file and changed to a version bellow, like 3.22 to 3.0 and program run without error.

I'm now working in creating a standalone (embebeding resouces (.glade and .ico)) to final binary. Initial tests was ok, so need test in other linux versions before post that.
For a while, program posted version need glade file and icon in same folder to run.

I have a question: In your program I don't understand about that batch file in others folders. Can you explain whats happening; so, I can update that.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything


If I understand you properly, the app always writes the batch file in the target folder and any re-runs simply overwrite the same batch file. Now in the Windows app, the common dialogs off the first button sets the target directory and the second dialog can either just have a file name typed into it OR it can set a different output file path if you select that from the second button.


Quote from: hutch-- on August 19, 2020, 12:44:13 AM
If I understand you properly
hehehe  :toothy:

Now I think that I understood. First button (source file) set folder path to both, source and target. Second button (target file) set path to target only if it was pressed, if was not pressed so use source file path as base. So user can open source file with full folder name and just type destination (target) filename in edit box. And batch file is saved in target path.
If is this whats happening, a new version will be released soon.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything


This is version 001 to linux x86-64, gtk3, uasm.
Executable is now standalone, do not need resource file or ico file in same folder.
Config file is stored in program path.
Script file is stored in target dir, if target dir is not acessible so script file is stored in user home dir.
Do this way because user can mount a partition and deal with file. But user can umount that partition so last dir/file is not available. Source code have more explications.

I'd rather be this ambulant metamorphosis than to have that old opinion about everything


Forgot to say some comments:
If script file is stored in a ntfs partition so it cannot be executed by default, but can be load and spawn (execute). Select target folder so script path will be updated and can be load.

Proceed (apend) button will send actual configuration to multiline text edit, so user can select other files to be processed and append that to multiline. But user probably don't like to watch (ffplay) all of then, so can remove that line from multiline text edit and save script. Script will be saved in last target folder.

I spend some time testing with deleted/not mounted files/folders. Last user action was inside a folder/filename that was removed. So, instead of cleaning edit control and set a user home folder I just set choose dialog path to home folder. This way user can see last path/file in edit control and mount that partition in choose dialog. If that does not exist, so home user folder can be set in edit control.
I'd rather be this ambulant metamorphosis than to have that old opinion about everything