Avidemux (with emphasis on x264/h264 GUI) [Archive] - Page 23

billqs

6th April 2009, 21:16

Hey!

I use AviDemux to edit my Xvid and Divx encoded tv caps to remove commercials, etc.

Recently, I was using "showsqueeze" in BeyondTV and reset it to wmv mode instead of a Divx 5 encoded avi. I did this despite my dislike of M$ codecs because I had the option of deinterlacing upon reencode. (This option was not available for Divx in BeyondTV.

I loaded up a couple of wmv files and had the following problems:

1. Using a recent Avidemux 2.5 beta build from mid-March the program would just literally disappear when I hit play on the file (I imagine that it crashed, but no error messages or anything.)

2. Using Avidemux 2.44 final I could edit the file, remove commercials and make many filter adjustments to the video. However, after re-encoding the video to Vxid and the audio to mp3 (lame) for the final product, I had the edited video but the audio still had the commercial breaks included.

My first thought was that for some reason I had accidentally left the audio stream at copy, so I pulled up another wmv file, edited it down, reencoded both video and audio and the same error occurred.

After I got the error a second time, I pulled up an old avi file, edited it and encoded to Xvid and mp3 and it was perfect both video and audio.

I am running XP SP3 with a quadcore procecessor and 3Gig of RAM.

Does anyone have a suggestion?

LoRd_MuldeR

7th April 2009, 13:13

Probably Avidemux doesn't support WMA streams properly. I have no experience with WMV/WMA editing in Avidemux.

Try converting your WMV file to a more useful format before you do the editing in Avidemux...

BTW: I don't see how "deinterlacing" is related to your choice between MPEG-4 ASP (DivX) and WMV, as deinterlacing is pre-processing. It's not part of the encoding!

LoRd_MuldeR

7th April 2009, 14:19

libx264 SVN-r1137:

libx264-r1137, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-core2-fprofiled.7z)
libx264-r1137, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-k8-fprofiled.7z)
libx264-r1137, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc433-pentium2-fprofiled.7z)
libx264-r1137, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc421-pentium2-fprofiled.7z)
libx264-r1137, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1137M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

billqs

7th April 2009, 18:30

Thanks for the idea Mulder. I'm going to do that and change the "showsqueeze" option in BeyondTV back to Divx since it makes for much easier editing.

BTW: I don't see how "deinterlacing" is related to your choice between MPEG-4 ASP (DivX) and WMV, as deinterlacing is pre-processing. It's not part of the encoding!

I'm aware it's preprocessing... it's just that Snapstream in their "infinite wisdom" made deinterlacing an option before re-encoding in wmv, but not in Divx. I had previously had issues fixing interlaced videos, particularly those with letterboxing so in my "inifinite wisdom (not)" I wanted to save a step and have all files of tv caps progressive both the divx, and ts files (which already are progressive as they are captured in 720p.)

Since what I have actually done is add a step rather than save a step, I am going back to Divx on the showsqueeze option. I would not use anything, but I have a couple of hundred Gigs in videos backed up waiting for me to process and I hate to see how huge the files would be if I had them all in glorious MPEG-2.

Thanks!

LoRd_MuldeR

7th April 2009, 18:36

Why you don't capture to some lossless format and then deinterlace with the deinterlacer of your choice and re-encode with the encoder of your choice?

billqs

7th April 2009, 18:46

Why you don't capture to some lossless format and then deinterlace with the deinterlacer of your choice and re-encode with the encoder of your choice?

Well, all three capture cards I own are hardware capture cards. Two capture to MPEG-2 and one captures to h.264. If I can clear the backlog of videos out, then I may stop all reencoding from within BeyondTV and then use MeGui, Ripbot or AviDemux to process and encode the video.

I know that I lose quality every time there is a reencode. I appreciate all your help!:)

LoRd_MuldeR

7th April 2009, 19:09

If you capture interlaced in MPEG-2 at high enough bitrate, the capture quality should be transparent (visually lossless).

Then you can do the further processing (deinterlacing, encoding, etc) in Avidemux, RipBot, MeGUI or whatever application you prefer for that step.

I used to capture at 15 MBit/s CBR with my analog MPEG-2 hardware encoder card...

billqs

7th April 2009, 22:33

Thanks, that's a really good suggestion!

LoRd_MuldeR

9th April 2009, 12:51

libx264 SVN-r1139:

libx264-r1139, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-core2-fprofiled.7z)
libx264-r1139, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-k8-fprofiled.7z)
libx264-r1139, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc433-pentium2-fprofiled.7z)
libx264-r1139, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc421-pentium2-fprofiled.7z)
libx264-r1139, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1139M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

Kurtnoise

11th April 2009, 14:26

it seems that there is a small bug in the OCR Tool (TS -> srt) using the latest windows build (rev4685). When you open a TS file, it's not opendialog event but savedialog event which is used...

LoRd_MuldeR

15th April 2009, 01:47

libx264 SVN-r1140:

libx264-r1140, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-core2-fprofiled.7z)
libx264-r1140, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-k8-fprofiled.7z)
libx264-r1140, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc433-pentium2-fprofiled.7z)
libx264-r1140, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc421-pentium2-fprofiled.7z)
libx264-r1140, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1140M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

Jalavera

16th April 2009, 20:36

it seems that there is a small bug in the OCR Tool (TS -> srt) using the latest windows build (rev4685). When you open a TS file, it's not opendialog event but savedialog event which is used...

Yes, it also happens in ALL previous 2.x svn Qt versions. In order to have a correct opendialogbox is needed to install latest 2.4.4 stable with GTK+ versions (Qt version also fails).
Please check new 2.5.x Qt-only versions...

LoRd_MuldeR

16th April 2009, 20:45

Yes, it also happens in ALL previous 2.x svn Qt versions. In order to have a correct opendialogbox is needed to install latest 2.4.4 stable with GTK+ versions (Qt version also fails).
Please check new 2.5.x Qt-only versions...

You may want to file a bugreport (http://bugs.avidemux.org/) then ;)

Jalavera

17th April 2009, 11:15

Ok. Done & wait...
:thanks:

LoRd_MuldeR

19th April 2009, 13:31

libx264 SVN-r1143:

libx264-r1143, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-core2-fprofiled.7z)
libx264-r1143, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-k8-fprofiled.7z)
libx264-r1143, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc433-pentium2-fprofiled.7z)
libx264-r1143, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc421-pentium2-fprofiled.7z)
libx264-r1143, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-66-r1143M-gcc345-pentium2-fprofiled.7z)

All builds are fprofiled. Tested with Avidemux 2.5 SVN-r4685 -and- 2.4.4 Final.
The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

LoRd_MuldeR

20th April 2009, 23:23

Avidemux 2.5 SVN-r4741 (2009-04-20)
http://www.avidemux.org/

Revision 4741 (20 Apr 2009)
# Updated GLib to version 2.20.1-1.
# Updated GTK+ to version 2.16.1-1.
# Updated Pango to version 1.24.0-1.

4741 - [script] change PSP auto wizard to check appropriateness of target audio track
4740 - [script] add AudioTrackInfo class and sourceTrackInfo/targetTrackInfo properties to Audio class
4739 - [ocr] use open dialog instead of save dialog (FS#599)
4721 - [ffmpeg] update FFmpeg to r18300 & libswscale r29120
4688 - [script] only apply resize filter when necessary when using scripted auto wizard
4687 - [script] clean up naming of methods & props for audio object
4686 - [script] make video & audio methods return null when no video is open
4685 - [Win32] update installer to install system scripts

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

LoRd_MuldeR

22nd April 2009, 23:46

Avidemux 2.5 SVN-r4758 (2009-04-22)
http://www.avidemux.org/

Revision 4758 (22 Apr 2009)
# Updated Avisynth Proxy GUI to version 2.08.
# Updated x264 to r1145.

4758 - [x264] support core 67
4757 - [rgb] use SWS_ACCURATE_RND to temporarily fix broken swscale RGB conversion
4756 - [cmake] use ffmpeg tarball first if available otherwise svn
4755 - [cmake] move svn retrieval of ffmpeg to separate script
4754 - [cmake] move patching of ffmpeg to separate script
4746 - [src] update Secret Rabbit Code to 0.1.7 for speed improvements
4745 - [auto] add more device auto wizards
4744 - [qt] use complete base name for auto wizards so full stops are handled in name
4743 - [x264] add additional device presets
4742 - [x264/xvid] use complete base name of xml config file so full stops are handled in name

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

LoRd_MuldeR

22nd April 2009, 23:54

libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-k8-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc421-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4 any longer. Please update to Avidemux 2.5 SVN-r4758 (http://forum.doom9.org/showpost.php?p=1276998&postcount=1118) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

fxtech

23rd April 2009, 18:04

4758 - [x264] support core 67

Hi lord , there is a reason for the change of the name on the last x264 dll ? them are libx264-67 instead 66 , and have to be renamed to work with the last build

LoRd_MuldeR

23rd April 2009, 19:06

4758 - [x264] support core 67

Hi lord , there is a reason for the change of the name on the last x264 dll ? them are libx264-67 instead 66 , and have to be renamed to work with the last build

Yes, there is a reason! The API of x264 has changed once again and therefore it's now core-67 instead of core-66. Consequently the filename now is "libx264-67.dll" instead of "libx264-66.dll". In fact this change in the x264 API was long ago. Unfortunately Avidemux was not updated for that change. Hence I had to patch x264 in order to make it work with existing Avidemux builds. But yesterday Gruntster finally updated Avidemux to support x264 core-67. So I don't need to patch x264 any longer. From now on I will simply build x264 core-67 as-is. Thus all new builds of libx264 will require a recent build of Avidemux. You need Avidemux 2.5 SVN-r4758 or later. And be warned that renaming the "libx264-67.dll" to "libx264-66.dll" will NOT work with older Avidemux builds! Different x264 core versions have different filenames for a reason...

fxtech

23rd April 2009, 21:17

right i did not see also the svn revision build , i was using the 4741 , thx a lot

Pulstar

24th April 2009, 23:02

LoRd_MuldeR

24th April 2009, 23:09

Hello it's me again. I've abandoned the concept of using VCD and now switched to WMV to distribute videos (less hassles this way, just load 'em in WMP and go!).. Btw I need a way to load and run a job file (generated using the GUI) in AVIDemux automatically. Is there a switch in AVIDemux CLI that supports this?

See the Avidemux Wiki:
http://avidemux.org/admWiki/index.php?title=Command_line_usage

Edit - Another question.. When it comes to encoding HuffYUV video (ffmpeg, adaptive) postproc isn't really needed is it?

If you are encoding from a lossy source, then postprocessing can be used to reduce blocking and ringing - at the cost of reduced sharpness.

This doesn't change at all, if you are encoding to a lossless format, such as HuffYUV.

Even if you are encoding from a lossless source, there still may be blocking/ringing in the video, if the video originally came from some lossy format.

(Just because a video is stored in a lossless format the content isn't necessarily of good quality)

Schrade

25th April 2009, 21:30

LoRd_MuldeR

26th April 2009, 01:24

LoRd_MuldeR, what's the difference between the GCC 4.3.3, 4.2.1 and 3.4.5 builds? (Other than compiler used..) Is it for speed reasons?

The GCC 4.3.3 builds should be the preferred ones, as that's the current GCC series. Well, there's GCC 4.4.0 now, but no MinGW build yet.

Anyway, in the past we had crashes in x264 that obviously were caused by miscompliation. So I make builds with older GCC versions too, as these should be more stable.

So if you encounter any problems with my GCC 4.3.3 builds, please try the GCC 4.2.1 or GCC 3.4.5 builds and report back...

Schrade

26th April 2009, 04:00

Aha.. thanks. Yeah, I've had crashes in the past. Will keep this in mind.

Pulstar

26th April 2009, 14:04

See the Avidemux Wiki:
http://avidemux.org/admWiki/index.php?title=Command_line_usage

If you are encoding from a lossy source, then postprocessing can be used to reduce blocking and ringing - at the cost of reduced sharpness.

This doesn't change at all, if you are encoding to a lossless format, such as HuffYUV.

Even if you are encoding from a lossless source, there still may be blocking/ringing in the video, if the video originally came from some lossy format.

(Just because a video is stored in a lossless format the content isn't necessarily of good quality)

Thanks.. my source is analogue so postproc makes it smoother than absolutely needed. I wish I could get MPEG4 to look as sharp as MPEG2. Can you please recommend any quant. matrices for PAL VHS material?

Oh and I get GUI bugs like this one when using AVIDemux 2.5
http://img24.imageshack.us/img24/9156/image5dom.png

GTK works better on my WinXP SP3 computers.. Is there a way to fix this? Unlike GTK I think QT comes built-in with the runtimes :confused:

LoRd_MuldeR

26th April 2009, 14:12

Thanks.. my source is analogue so postproc makes it smoother than absolutely needed.

Post-processing only makes sense for over-compressed sources that have a lot of ugly blocking/ringing in them...

I wish I could get MPEG4 to look as sharp as MPEG2.

There is NO reason why MPEG-4 should look less sharp than MPEG-2. In fact MPEG-4 compresses much more efficient than MPEG-2. Consequently at the same bitrate you should get significant better quality (better detail retention) with MPEG-4. As an alternative, MPEG-4 AVC (x264) compresses even more efficient than MPEG-4 ASP (Xvid).

Also: Please make sure that you are looking at the unprocessed(!) MPEG-4 video, when you compare the "sharpness" of MPEG-4 to MPEG-2. Many MPEG-4 decoders (e.g. the Xvid decoder filter, the DivX decoder filter and even ffdshow) have built-in "post-processing" filters. These will sacrifice sharpness for deblocking and derininging. Hence you must disable these filters for a proper comparision!

Last but not least you must be aware that any re-encoding from a lossy format to a lossy format will unavoidably cause a quality degradation of some degree...

Can you please recommend any quant. matrices for PAL VHS material?

No, I can't. But generally the "MPEG" quantization should be more sharp (and more prone to blocking) than the "H.263" quantization.
Custom quant matrices can be used for MPEG quantization only...

Some CQM's for MPEG-4 ASP can be found here:
http://forum.doom9.org/showthread.php?s=&threadid=83125

Oh and I get GUI bugs like this one when using AVIDemux 2.5 ... Is there a way to fix this?

I can reproduce this (very minor) glitch. You may want to file a bug report (http://bugs.avidemux.org/), if it annoys you ;)

Unlike GTK I think QT comes built-in with the runtimes :confused:

No idea what that is supposed to mean :confused:

LoRd_MuldeR

26th April 2009, 16:19

Avidemux 2.5 SVN-r4763 (2009-04-26)
http://www.avidemux.org/

Revision 4763 (26 Apr 2009)
# Added Netscape Portable Runtime version 4.7.4.
# Updated Pango to version 1.24.1-1.
# Updated Qt to version 4.5.1.
# Updated SpiderMonkey to version 1.7.0.

4763 - [Win32] update Win32 build scripts and installer to use own SpiderMonkey
4762 - [script] add option to use system version of SpiderMonkey
4761 - [script] revert part of r4760
4760 - [script] output new property names in scripts
4759 - [js] remove pointless resolving of path for include scripts
4758 - [x264] support core 67

libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K8 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-k8-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc421-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

Download Mirror #1: http://mulder.dummwiedeutsch.de/ (http://mulder.dummwiedeutsch.de/home/?page=projects#avidemux)
Download Mirror #2: http://avidemux.razorbyte.com.au/ (http://avidemux.razorbyte.com.au/#avidemux2.5)

LoRd_MuldeR

1st May 2009, 23:02

libx264 SVN-r1145:

libx264-r1145, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-amdfam10-fprofiled.7z)
libx264-r1145, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc440-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-core2-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-amdfam10-fprofiled.7z)
libx264-r1145, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc433-pentium2-fprofiled.7z)
libx264-r1145, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1145M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4 any longer. Please update to Avidemux 2.5 SVN-r4758 (http://forum.doom9.org/showpost.php?p=1276998&postcount=1118) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

Yobbo

1st May 2009, 23:58

There's no "Auto - DVD" preset anymore?

LoRd_MuldeR

2nd May 2009, 00:32

There is an overhaul going on for the "Auto" menu currently...

Yobbo

2nd May 2009, 08:30

Thanks a lot, Lord Mulder. I'm looking forward to the next milestone build. I appreciate all the work you do to make this excellent software accessible to us lay folk!

roozhou

6th May 2009, 11:00

@MuldeR
Maybe an off-topic question.
I noticed you are providing tdm 4.4.0 libx264 builds, but I have problem compiling x264 with tdm 4.4.0 from git. Configure failed and returned ./configure: line 320: die: command not found

There are no such problems using GCC 3.4.5/4.3.3/4.2.4. And configuring with 4.3.3 and compiling with 4.4.0 also works fine. Have you encountered such problem?

There is also problem compiling mplayer/mencoder with tdm 4.4.0, but this is far more off-topic.

LoRd_MuldeR

6th May 2009, 12:40

I noticed you are providing tdm 4.4.0 libx264 builds, but I have problem compiling x264 with tdm 4.4.0 from git. Configure failed

Try this patch:
http://mplayer.somestuff.org/misc/libx264/patches/configure-gcc440-fix.diff

More info here:
http://forum.doom9.org/showpost.php?p=1279759&postcount=534

There is also problem compiling mplayer/mencoder with tdm 4.4.0, but this is far more off-topic.

Apparently Sherpya is using GCC 4.5.0 for his MPlayer/MEncoder builds. But he doesn't provide his GCC 4.5.0 binaries (unless I missed something).

fxtech

6th May 2009, 13:46

anyone noticed that since the last svn all the custom script stop to work ? all of the give an interpreter error from the spidermonkey engine , also the conversion on mpeg4 asp using lavc on mp4 mov container becoming unreadable

LoRd_MuldeR

6th May 2009, 13:48

My custom scripts still work. For example I use scripts to load my x264 configuration and this works like a charm in latest SVN version.

So there must be some specific problem with your script...

fxtech

6th May 2009, 15:22

could you paste it here please ?

LoRd_MuldeR

6th May 2009, 15:26

Here we go:
http://pastie.org/469980

fxtech

6th May 2009, 15:56

i have to investigate

http://i39.tinypic.com/nxvmog.jpg

avidemux 2.5.0 svn 4762 just installed i am using the QT gui

LoRd_MuldeR

6th May 2009, 16:08

You must open a video first before you execute that script. That script will only setup the video encoder, it doesn't open any video ;)

(It's probably not the best idea to post huge screenshots. You may post a thumbnail or a hyperlink to the full-size image instead)

fxtech

6th May 2009, 16:20

It works !!!

LoRd_MuldeR

10th May 2009, 13:31

libx264 SVN-r1148:

libx264-r1148, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc440-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc433-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc421-pentium2-fprofiled.7z)
libx264-r1148, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1148M-gcc345-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 (http://forum.doom9.org/showpost.php?p=1278405&postcount=1130) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location.

LoRd_MuldeR

13th May 2009, 15:41

libx264 SVN-r1148 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1148, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1148, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1148, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1148M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 (http://forum.doom9.org/showpost.php?p=1278405&postcount=1130) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Again using the "force_align_arg_pointer" attribute to avoid crash, so only GCC 4.x builds this time.

LoRd_MuldeR

19th May 2009, 18:48

libx264 SVN-r1153:

libx264-r1153, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc440-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc433-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.2.1, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc421-pentium2-fprofiled.7z)
libx264-r1153, MinGW GCC 3.4.5, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/libx264-67-r1153M-gcc345-pentium2-fprofiled.7z)

libx264 SVN-r1153 using experimental AutoVAQ patch v0.2 by BugMaster:

libx264-r1153, MinGW GCC 4.4.0, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.4.0, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc440-pentium2-fprofiled.7z)

libx264-r1153, MinGW GCC 4.3.3, optimized for Core 2 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-core2-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for K10 (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-amdfam10-fprofiled.7z)
libx264-r1153, MinGW GCC 4.3.3, optimized for Pentium 2 and later (http://mplayer.somestuff.org/misc/libx264/test_builds/libx264-67-r1153M-autovaq-gcc433-pentium2-fprofiled.7z)

These builds will NOT work with Avidemux 2.4.x any longer. Please update to Avidemux 2.5 SVN-r4763 (http://forum.doom9.org/showpost.php?p=1278405&postcount=1130) or later now!

The patches used for my builds can be found at this (http://mplayer.somestuff.org/misc/libx264/patches/) location. More info on BugMaster's patch in this (http://forum.doom9.org/showthread.php?t=147067) thread!
Using the "force_align_arg_pointer" attribute to avoid crash in AutoVAQ builds, hence only GCC 4.x builds.

Inspector.Gadget

24th May 2009, 20:25

LoRd_MuldeR,

I've found a bug in rev 4763 when opening a VOB file directly. The source is 16:9 NTSC (Region 1) Aqua Teen Hunger Force Season 6 Disc 2. Included below is an image showing the problem and a link to a 10-second sample cut with Avidemux. Hopefully you can reproduce the problem. The same file is fine in DGIndex and MPC-HC. If it is of any relevance, the problem persists throughout the file; the top fields are garbled but the bottom fields seem to decode correctly.

http://i39.tinypic.com/11jvhwi.jpg

Problem.vob (12.6 MB, ~10 seconds): http://www.mediafire.com/?sharekey=971922f6b4415a77d956df2962098fcbe04e75f6e8ebb871

:thanks:

Edit: I thought this might have been a problem with starting on a P-frame rather than an I-frame (unless Avidemux's frame type detection is wrong), but it persists for numerous GOPs.

Edit #2: This only happens when I don't choose to append all the VOB files in the program chain - Avidemux thinks VTS_01_1.VOB (the problematic file) starts with a P frame when opened on its own, but when I append the rest of the VTS_01_X.VOB files, Avidemux correctly begins on an I-frame and the problem disappears. Any idea what's going on here? So far as I know the missing I frame can't be in the second or third VOB...

LoRd_MuldeR

24th May 2009, 23:19

I can't see any problems with your sample, except that there are a few garbled blocks in the very first frames (1 to 7). But these are present in MPlayer and MPC+ffdshow as well!

http://img193.imageshack.us/img193/8100/vobgarbled.th.png (http://img193.imageshack.us/img193/8100/vobgarbled.png)

So it's not an Avidemux problem. The rest of the clip looks 100% fine for me. This is with Avidemux 2.5 r4763.

Inspector.Gadget

24th May 2009, 23:43

Yes, unfortunately upon a second look the sample does not have the same problem as the stream I cut it from using Avidemux. I don't know why this happened, as I made sure to begin with the first frame rather than the first keyframe. Here are two screenshots I've taken that may help illustrate this problem.

In this first screenshot, I opened VTS_01_1.VOB, declined to append the rest of the VOBs at the prompt, and wound up starting on a P-frame: hence the garbled image.
http://img190.imageshack.us/img190/8716/singlevobproblem.th.png (http://img190.imageshack.us/my.php?image=singlevobproblem.png)

In this second screenshot, I opened VTS_01_1.VOB, allowed Avidemux to append the rest of the VOBs, and everything was fine: the stream started on an I-frame.
http://img190.imageshack.us/img190/8427/multiplevobnoproblem.th.png (http://img190.imageshack.us/my.php?image=multiplevobnoproblem.png)

But shouldn't the first frame in a given VOB be the same anyway if it's alone or the first in a sequence? I know that VTS_01_0.VOB was not prepended to the others in the second case.