Avidemux (with emphasis on x264/h264 GUI)

[LoRd_MuldeR]

Although R644 is available, anything after R641 causes Avidemux to crash immediately upon encoding.

Akupenguin has posted information on the problem:
http://forum.doom9.org/showthread.php?p=979857#post979857


//EDIT

Possible workaround:
http://forum.doom9.org/showpost.php?p=979922&postcount=9

[LoRd_MuldeR]

Avidemux v2.4 Revision 2922 + x264 update
http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=avidemux&file=latest&mirror=brhack

This package contains revision 645 of x264 with Akupenguin's patch included. Works like a charm here :)

[Bigmango]

Awesome, :thanks: Lord Mulder

[gruntster]

Avidemux 2.4 R2926 is available here:
http://www.razorbyte.com.au/avidemux

[LoRd_MuldeR]

Avidemux v2.4 Revision 2926 with x264 r648
http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=avidemux&file=latest&mirror=brhack

Mirrored. Thx :)

[LoRd_MuldeR]

Here is a complete re-write of my ADM Tools:
http://mulder.brhack.net/public/downloads/ADM_Tools.2007-04-08.zip

http://img460.imageshack.us/img460/341/fileadmtoolsnewmc9.png

This one should be much 'cleaner' than my first attempt and also save some CPU cycles.
Feedback welcome. Sources are included.

[kinematic]

@ LoRd_MuldeR:
I'm a member of a private torrent site and i just wanted to let you know that i used your explanation over there to make a sticky post about why packed bitstream is bad.
Hope you don't mind :thanks:

[Bigmango]

Here is a complete re-write of my ADM Tools:
http://mulder.brhack.net/public/downloads/ADM_Tools.2007-04-08.zip

This one should be much 'cleaner' than my first attempt and also save some CPU cycles.
Feedback welcome. Sources are included.

This is great !

I have 1 question though: isn't it possible to implement these functions directly into avidemux instead of making a separate app ?

[LoRd_MuldeR]

This is great !

I have 1 question though: isn't it possible to implement these functions directly into avidemux instead of making a separate app ?

Yea, it should be possible. And I doubt it's much work.
BUT: Those features are OS specific and Avidemux' primary platform is Linux.
So Mean said it's "low priority" work....

[LoRd_MuldeR]

Right another optimization to the window detection code *sigh*
http://mulder.brhack.net/public/downloads/ADM_Tools.2007-04-09.zip

[LoRd_MuldeR]

I'm currently updating/extending the article about x264 at Avidemux' Wiki in order to make a more complete encoding guide.
Especially I'm working on the "H.264/AVC options explained" section of that article.

The work is still going on, but I made some progress today:
http://www.avidemux.org/admWiki/index.php?title=H264#H.264.2FAVC_options_explained

Feedback is very welcome :)

[Bigmango]

I'm currently updating/extending the article about x264 at Avidemux' Wiki in order to make a more complete encoding guide.
Especially I'm working on the "H.264/AVC options explained" section of that article.

The work is still going on, but I made some progress today:
http://www.avidemux.org/admWiki/index.php?title=H264#H.264.2FAVC_options_explained

Feedback is very welcome :)

This is excellent.

I have learned a lot of things thanks to this. Especially regarding conflicting settings like Trellis, DCT, Quant. mode, etc...

This should be in the software help, or there should be a link to the wiki available from within the application.

[LoRd_MuldeR]

I'm currently updating/extending the article about x264 at Avidemux' Wiki in order to make a more complete encoding guide.
Especially I'm working on the "H.264/AVC options explained" section of that article.

The work is still going on, but I made some progress today:
http://www.avidemux.org/admWiki/index.php?title=H264#H.264.2FAVC_options_explained

Feedback is very welcome :)

Work should be done for now. At least until someone finds my mistakes :)

PDF version is mirrored here:
http://mulder.dummwiedeutsch.de/pub/x264/

[DarkZell666]

I'm posting just to let you know I've just tried your latest ADM tools and it seems to work without any fuss. When the encoding starts, avidemux's priority switches to "below normal", and when the encode finishes, it switches back to "normal".

I'm surprised you decided to make the adm_tools.exe process "above normal" priority though, is there any particular reason ? It doesn't bother me the least because it doesn't actually do anything (it just sits there monitoring avidemux2_gtk.exe), I'm just being curious =) Is it "necessary" in order to catch the avidemux more accurately or something like that ?

PS: Quickly reading your pdf version, I fell on a couple of typos :rolleyes:. I'll have a more extensive read later on when I've finished my workload for today =)

[LoRd_MuldeR]

I'm surprised you decided to make the adm_tools.exe process "above normal" priority though, is there any particular reason ? It doesn't bother me the least because it doesn't actually do anything (it just sits there monitoring avidemux2_gtk.exe), I'm just being curious =) Is it "necessary" in order to catch the avidemux more accurately or something like that ?

The priority of adm_tools.exe should even be "high", not only "above normal". I did this, because the tool is checking for the "Encoding in Progress" Form to appear. Currently the check will be performed constantly every 1500 milliseconds. So I wanted to make sure no other CPU hungry app will "delay" the checkings. I'm not sure if this required at all, but as far as I can see, the CPU usage of adm_tools.exe is negligible anyway (ProcExp shows the total CPU time of adm_tools.exe is far below one second and doesn't increase) So I guess the higher priority won't hurt :)

BTW: You can test the "Automated Shutdown" feature safely! It won't shutdown your computer immediately. There is a countdown of 60 seconds and you can abort it at any time :cool:

PS: If you find any typos or bad English, please tell me. So I can correct ASAP...

[LoRd_MuldeR]

Avidemux v2.4 Revision 2926 with working FAAC
http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=avidemux&file=latest&mirror=brhack

This package is a re-build of previous build. This time FAAC should work.

[DarkZell666]

Hmm FAAC "worked" for me with the last build you had mirrored (except for the "no-sound-in-mpc & wmp" problem because of that objectTypeIdentification stuff). No crash what so ever. Oh well :rolleyes: Upgrading now ^^

Edit: just saw your post about the b0rked bitrate, great news :)
http://www.avidemux.org/admForum/viewtopic.php?pid=18238#p18238

[LoRd_MuldeR]

Edit: just saw your post about the b0rked bitrate, great news :)

I just did a quick "96 kbps FAAC" test and I really got a file with ~96 kbps audio. Last time I got something arround 148 kbps ;)

Also some work has been done again:
http://mulder.dummwiedeutsch.de/pub/x264/

[LoRd_MuldeR]

Avidemux v2.4 Revision 2934
http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=avidemux&file=latest&mirror=brhack

This build includes a new deinterlacing filter: Yadif (Yet Another DeInterlacing Filter)
It was ported form MPlayer to Avisynth by Fizick and then ported form Avisynth to Avidemux by Mean.
Yadif can do both: Keep the number of frames (like KernelDeint/TDeint) or framerate-doubling/bobbing (like DGBob)
While Yadif seems to give pretty nice results, it's also very fast. More info can be found in this (http://forum.doom9.org/showthread.php?t=124284) thread.

Also this time I have mirrored Gruntster's new installer, instead of using 'zip2exe' tool.

:thanks:

[DarkZell666]

A couple of observations recently :

Gruntster's two latest builds encode FAAC alone (video=copy) at something like 250fps. Much faster than the 140fps from the official 2.4-prev1 build. Good job =)

However, the volume of the audio encoded by FAAC is louder than the original. See my post here: http://www.avidemux.org/admForum/viewtopic.php?pid=18323#p18323

All revisions/builds seem to be affected.

[gruntster]

Avidemux 2.4 R2945 is now available here:
http://www.razorbyte.com.au/avidemux

The Avidemux executables are larger because a higher compiler optimisation level is now used. This should hopefully result in a speed increase.

The installer now uses improved compression so it's actually smaller than the last release.

[Selur]

Can avidemux remux mp4(xvid/mp3) to avi(xvid/mp3) ?

[Kurtnoise]

Yes...w/o problems.

[gruntster]

Can avidemux remux mp4(xvid/mp3) to avi(xvid/mp3) ?

I've experienced problems with this:
http://www.avidemux.org/admForum/viewtopic.php?id=3067

[LoRd_MuldeR]

Avidemux 2.4 R2945 is now available here:
http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=avidemux&file=latest&mirror=brhack

The Avidemux executables are larger because a higher compiler optimisation level is now used. This should hopefully result in a speed increase.

The installer now uses improved compression so it's actually smaller than the last release.

Mirrored:

Avidemux v2.4 Revision 2945, x264 Revision 650
http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=avidemux&file=latest&mirror=brhack

Thanks Gruntster. Nice you have added my ADM Tools to your installer.
But I think the Shortcut for GTK+ version should point to adm_tools.exe if the user checks AMD Tools in the installer.
Of course ADM Tools should be checked by default ;)


BTW: I doubt there will be much speedup due to compiler optimizations. Avidemux uses most decoders/encoders from libavcodec, which is highly "Hand Optimized" with Assembler code. Same applies to x264. So the most speedup (if any) is to be expected with certain filters that are plain C-Code...

BTW 2: To get H.264 video from MP4 to AVI container, I'd use MP4Box to extract RAW H.264 stream and then mux to AVI via avc2avi commandline-tool. Then add the Audio stream via AVI-Mux GUI.

BTW 3: Did you think of 'packing' the EXE's and maybe the larger DLL's with UPX before compiling the installer? This will definitely make the installer a little bigger, as compressing already compressed files isn't good, but it should make Avidemux startup faster: The time you save by loading the smaller UPX'd executables from HDD to RAM is more than you loose for UPX' decompression step inside RAM.

[IceManZ]

Same here.

But in earlier build I could mux with no trouble video (H.264, XiVD,...) + MP3 to AVI but not to MP4.

With 2945, neither AVI or MP4 work

[LoRd_MuldeR]

But in earlier build I could mux with no trouble video (H.264, XiVD,...) + MP3 to AVI but not to MP4.

With 2945, neither AVI or MP4 work

Are you encoding in Avidemux or do you want to re-mux an existing file? In the latter case, what is the source container?

[IceManZ]

Only re-mux

Source are avi (only video) + MP3.

[LoRd_MuldeR]

Only re-mux

Source are avi (only video) + MP3.

I just tried to remux an AVI (H.264 + MP3) to MP4 in Avidemux.
The resulting MP4 plays fine in MPlayer, but no video in MPC+Haali+ffdshow :(

[IceManZ]

Yes. Same here. A new build, 2948, is out.

Can't try it, since can't compil it.

[Selur]

Are there any plans to support .mov as output container?

[gruntster]

Avidemux 2.4 r2948 is available here:
http://www.razorbyte.com.au/avidemux

[Jalavera]

When you run adm_tools.exe then avidemux2_gtk.exe runs only in english (language ignored)

[LoRd_MuldeR]

When you run adm_tools.exe then avidemux2_gtk.exe runs only in english (language ignored)

That is correct. I have to enforce the ENGLISH translation by setting the environment variables accordingly. The problem is, that in some translations the caption of the "Encoding in process..." window is just blank (empty string), which makes it impossible to detect that window...

// EDIT

Avidemux v2.4 Revision 2948
http://mulder.dummwiedeutsch.de/home/?page=guestbook&app=avidemux&file=latest&mirror=brhack

[gruntster]

The problem is, that in some translations the caption of the "Encoding in process..." window is just blank (empty string), which makes it impossible to detect that window...


There seems to be a bug somewhere, maybe in GTK that prevents window captions from being displayed because "Encoding in process" exists in all translations. From what I can tell the issue seems to only affect non-Latin character sets. Unless it's a font issue but window labels display ok...

I can't find anything similiar on Google about it.

Anyone else come across this?

[DarkZell666]

I thought that thanks to Unicode & UTF-8 all this "codepage translation" business was over ... If the translations are stored in an UTF-8 file (instead of ANSI or latin-X) and that avidemux becomes UTF-8 aware (if it isn't already), the problem should be solved. Fonts would need to be Unicode-aware too, but having some squares displayed instead wouldn't stop the window from being detectable ...

[LoRd_MuldeR]

This version of ADM Tools supports translations now:
http://mulder.brhack.net/public/downloads/ADM_Tools.2007-04-18.zip

Change the translation with the provided .reg files. CS and RU are not supported yet...

[gruntster]

I thought that thanks to Unicode & UTF-8 all this "codepage translation" business was over ...

The GTK runtimes don't seem to be fully Unicode compliant. Using an API spy, CreateWindowExA is used to create windows so I'd assume only ANSI captions will be handled correctly. Perhaps the maintainer forgot to set a UNICODE preprocessor flag when compiling and therefore CreateWindowEx doesn't get mapped to CreateWindowExW.

Other Windows packages that use GTK+ suffer from the same problem, including GIMP.

I'll try to chase it further.

EDIT:
The latest SVN version of GTK uses CreateWindowExW explicilty. Looks like we'll have to wait for the next GTK release before the Russian and Czech translations will work correctly.

[Jalavera]

Sounds great! Thanx

I'll check it asap!

[gruntster]

Change the translation with the provided .reg files. CS and RU are not supported yet...

Is it possible for ADM Tools to detect when the regional settings are set to Czech or Russian and automatically set the LANG environment variable to English? :)

The GetThreadLocale API should be able to tell you this info.

[LoRd_MuldeR]

Is it possible for ADM Tools to detect when the regional settings are set to Czech or Russian and automatically set the LANG environment variable to English? :)

The GetThreadLocale API should be able to tell you this info.

hmm, how reliable is GetThreadLocale when you can overwrite the locale with Environment Variables ???
I guess I'd have to check both...

[gruntster]

Yes, both would be nice. :D

However, at least the environment variables can be managed by the user on a per application basis if need be via a batch file whereas regional settings seem to be a global thing.

[Bigmango]

Grunster, waiting on your r2951 build :)

With this build avidemux can now open Blue Ray HD mpeg2 files.

[CruNcher]

I really beginn to like Avidemux very much it's integration of stuff becomes better from day to day, and so i have a bug (incompatibility) report and feature request useing Sony HDV (HDVSplit 188 byte packet streams with Camera Metadata) seems those Transport Streams aren't supported in the newest build r2948 (would be nice if it would also show the Camera Metadata in the Properties Dialog or even better read it live and show it as a subtittle overlay on/off).
DGMPEGDEC has no problems with this kind of Transport Streams (tough it can't display the Metadata).
I also have a problem with A Blue-Ray stream crashing on Indexing 23 GB but again runs fine with DGMPGDEC (oops didn't saw Bigmangos post :P )

[Bigmango]

I really beginn to like Avidemux very much it's integration of stuff becomes better from day to day, and so i have a bug (incompatibility) report and feature request useing Sony HDV (HDVSplit 188 byte packet streams with Camera Metadata) seems those Transport Streams aren't supported in the newest build r2948 (would be nice if it would also show the Camera Metadata in the Properties Dialog or even better read it live and show it as a subtittle overlay on/off).
DGMPEGDEC has no problems with this kind of Transport Streams (tough it can't display the Metadata).
I also have a problem with A Blue-Ray stream crashing on Indexing 23 GB but again runs fine with DGMPGDEC (oops didn't saw Bigmangos post :P )

I suggest you report your bugs on the avidemux forums, Mean responds daily and is offering great support. Mean is the main guy in the saddle fixing and implementing things:
http://www.avidemux.org/admForum/viewforum.php?id=14


Edit: yes build r2951 fixes this 188 bytes problem with the blue ray files. If you are lucky its the same problem with HDV ? Anyway talk to Mean ;)

[gruntster]

Avidemux 2.4 R2951 is now available:
http://www.razorbyte.com.au/avidemux

[CruNcher]

@ Bigmango
Thx i posted the bug report on the Avidemux forum the Blue-Ray fix didn't fixed it seems to be more of a correct PID detection problem so Avidemux shows "Aspect Ratio not Supported" and stops. The Blue-Ray Stream works now :)

[Bigmango]

Avidemux 2.4 R2951 is now available:
http://www.razorbyte.com.au/avidemux

Awesome !

:thanks:

[LoRd_MuldeR]

Avidemux 2.4 R2951 is now available:
http://www.razorbyte.com.au/avidemux

Mirrored:
http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux

:thanks:

[CruNcher]

gruntster could you compile r2953 it should make Avidemux now HDV compatible too, oh boy i love it :)

also i found another interoperability problem but im not sure where this arises from yet but it's a very interesting problem that can couse a slowdown on playback with Cyberlinks H.264 Decoder (only in DXVA mode) and certain .mp4 files (CoreAVC is ok) im still investigating if it's coming from Avidemux Mp4 muxer part, Haalis Media Splitter (maybe somekind of timestamp problem wich couses some buffer problem after some seconds of playback) or Cyberlinks Decoder itself.
Also it seems Cyberlinks Decoder has a pading problem the same that XviD's/Neros decoder had ages ago (only in DXVA mode).

Edit: Seems to be entirely a Bug inside Cyberlinks Decoder and DXVA