I set the encoder to encode to a video size of 250MB, and it ended up over 5GB. There's not much to add here. I mean, 250MB is 250MB, right? So how can the resulting video grow to over 5GB?? Audio is compressed as AAC 128kbps, jsyk.
I seriously don't know what else to add. If there's anything, just let me know, I guess.
Well I can't resist - Add details!
Seriously - compress what and how much into 250MB using what and which settings?
Input: MP4 H.264/AAC, about 800MB in size
Output video: H.264, Two-pass by video size (250MB)
Output audio: copy
Output container: MKV
Then, Ctrl+S, and save as the same file but change extention to .mkv.
First pass went by without a hitch. Second pass: the projected filesize started to add up quickly and near the end of the process it was over 5GB.
If more details are needed, then I'm terribly sorry, but I really don't know what else I could specify.
I haven't checked (yet) how reproducible this is.
I don't know why you get the very large video size but maybe we can find out.
There is a limit on how much you can compress a video.
So first thing is - how long in time is this video?
About a half hour or so. I can give you an exact number in 2 hours, when I'm back home ;)
If there's a limit, then it certainly shouldn't go over the original filesize.
Also, it works in Avidemux 2.5.6 (only A/V gets horribly out of sync, which is why I'm trying 2.6).
/edit
The video in question is 21 minutes, as it turns out.
Hello, Nice topic since i've got the same problem as thany.
I was using avidemux 2.5 encoding with H.264 codec compressing from 1.4 GB brut video to 200MB. It was working very well nothing to say. Then yesterday i decided to upgrade to the 2.6.4
My config for the H.264 codec was save and the 2.6 version recognize it. Start encoding and surprised, first it take longer than before even with a full CPU work (the CPU was running around 60% before and now 98%) and the video size jump from 1.4 GB to 8.7GB !!!!
For the details:
Output container .mkv
Outpur audio: copy
Output video:
x264, Video size (two pass)
Motion: Uneven Multi Hexagonal search(7)
Motion vector search range 16
Weigh prediction for B frames
Partition only 4x4, 4x8, 8x4 P frames NOT active
Frame encoding:
CABAC
Maximum consecutive B frame 16
B frame bias 0
B frame decision optimal
B frame as reference stricly hierarchical pyramid
I frame gop size 24 to 240
I frame threshold 40
That for the codec details.
The video is 1.48 GB and 00:42:16 and Standard raw DVD for the rest
It works out at a video bit rate of about 1400 kb/s and that isn't an issue for this codec.
I did a 250 MB, 2 pass, video size, test run on a 21 minute clip and it encoded just fine.
Using:
MKv muxer
H.264 with default settings
Audio set to copy
Time to encode the 2 passes was a few minutes.
Stream size 244 MiB
This is with 2.6.4 (r8840) 64 bit.
So, which version of 2.6.4 is being used with this issue?
2.6.4 r8696 32bits for me.
I took the 32bits version cause it was say to be less buggy than the 64bits version
I will give a try with your version see what happened
I tried the 2.6.4 r8846 64bits and it works well, seems the problem came from the 32bits version.
I used the 32-bits version, because that's the version for which a proper installer can easily be found...
I think it was Aquar who previously pointed me to nightlies of the x64 version, but I'd rather only use those for testing. A proper installer is not among the nightlies (http://www.avidemux.org/nightly/win64/), afaik.
Another problem is, I've got another box running XP where I do some nightly encodes, which cannot run 64-bits (being XP and all). So going for the x64 version is only half a solution for me ;)
Okay, so I thought I'd try the latest nightly (r8871, 32-bits). Still happening. Different file even.
Another thing to note: when I aborted the encode process, I got a "file is too short" message. Not sure what that's about. After that I got a generic "encode failed" kind of message. Both those messages are unneccesary when clicking the abort button.
Tried the x64 version of r8871 as well. Same problem.
Input is (yet another) 630MB MP4 around 20 minutes in length, 720p resolution. Output the same settings as mentioned earlier, and the resulting file becomes about 6.3GB in size. 10 times larger in this case :o
Interesting result when using "2 pass - video size" encoding.
Just did a AVC to XVID recode with (32 bit r8877) and the video size was half that specified.
I normally increase the file size by 50% to allow for the "inferior" compression of XVID over AVC.
Will fiddle a bit more and see what happens.
One for the developer?.
I could not reproduce on a small sample
If you have a small sample to shows the problem please share it
I was afraid you were going to ask that (never uploaded to a file sharing site before).
The video is AVC in AVI and I cannot cut edit it in avidemux to create a native sample.
I did remux it into MKV, then recoded that to XVID in AVI, and this size issue crops up.
Can cut edit a sample from the remuxed version and try to upload it somewhere.
Currently recoding this with "2 pass - video bit rate" encoding, to see if the file size changes.
I did retry "2 pass -video size" encoding with a different value, and the end result was a file of identical size.
I'll recode the original avi and see if this issue is still present.
Sample file:
http://www.datafilehost.com/d/0bc8d5ab
Recoded the sample with MPEG4 ASP (xvid4)
Container this time was mkv.
2 pass - video size at 10 MB gives video bit rate of 766 Kbps
2 pass - video size at 30 MB gives video bit rate of 1800 Kbps
2 pass - video size at 50 MB also gives video bit rate of 1800 Kbps
All cases the frame rate changed from constant rate to variable rate.
Maybe minimum possible quantization is somehow being exceeded by the larger sizes?
Using 2.5.6 the video size settings gives results as expected.
Strangely, I can no longer reproduce this issue. I did a couple of things:
1) upgrade to build 8874
2) set the H.264 parameters manually
3) save the whole thing as an auto script
One of these things must have worked around the problem for me.
/edit
Scratch that. I triggered the issue again. I honestly don't know what I did to cause this issue once again. I performed an encode like any other that worked normally...
Recoded the sample video a few times with 2.6.x and 2.5.6. (MPEG4-ASP xvid)
With a video size set to 50 MB, 2.5.6 provides a near 50 MB result.
With this generous video size the quantiser value sits mostly at 1 (presume this value defines some quantisation scale code?)
The bit rate can be quite high for complex scenes (~8000 Kbs).
With a video size set to 50 MB, 2.6.4 (32 bit) always greatly under sizes.
Even with this generous video size the quantiser value ranges between 1 and 4.
The bit rate at quantiser 1 also seems much lower than for 2.5.6 (`3000 Kbs).
I guess the encoder parameters for these XVID encoders must be quite different.
Tried with 2.6.4 (64 bit) but it doesn't like this exercise and crashes immediately on pass 1.
Created another sample video with different compression and container.
Results is a similar undersizing with 2.6.4.
Interesting!
The undersizing problem *may* be explained by avidemux not incorporating the audio track into the video size. I found that when this undersizing problem occurs, I can subract the size of the audiotrack to the total resulting video size, which is more or less the video size I had set in the encoder options.
For example,
I set a video size of 700MB. But the resulting file becomes 850MB. That means audiotrack is around 150MB (which in my case is about correct when I do the bitrate*time calculation).
So in this scenario I would have to set the video size to 550MB, and because the audio track is still the same, it will result in a total video size of around 700MB.
Thanks,
You are right in that the total file size comprises all of the container streams(video plus audio plus subs).
But in this case, I am comparing the size of the video stream (set by user input & is an encoder parameter) and the resulting video stream size.
It undersizes on both MPEG4-ASP (Xvid4) and MPEG4-ASP (ff) so it seems more than just encoder related.
If you try constant bitrate encoding with a 'higher' bitrate than what you get from the video stream size result, you also run into the same problem.
Now increasing the compression level eventually results in avidemux complying with user input but the compression is too high for my aim.
My target aim is to encode for a specific average bits per pixel metric, and that is not possible at the moment because setting the target video size isn't working (or is being code limited).
Okay, it's happening again. Got a MP4 file about 1,5GB in size, tried to convert it to H264/AAC in MKV, and results in 18GB. Another one became 38GB, would you believe it?! This shouldn't even be possible.
It's definately not an isolated case. But it has thus far only happened on the 32-bits version.
This time I was using r8882 on Windows XP.
And another one.
Just a friendly reminder. Would it make sense to install the latest nightly at all?
/edit
And another one. I keep the failed ones in one place, but there's no real pattern to them. It's WMV, AVI and MP4, some of them 720p, some 1080p, some 480p or less. Supplying example files is of no use, it seems to have nothing to do with the files themselves. I suppose the devs should take a good look at why this happens so oftenly on the 32bits version, and never (seems to) on the 64-bits version.
Just a thought
Does this happen if you run the programs as portables?
Both 32 bit and 64 bit adress the same data location and maybe there is some cross contamination.
Will try it for the undersizing issue.
No, I'm running the two on separate machines. One cannot run 64-bit, and the other can. One is Windows XP, and the other is Windows 7.
Said to say... This morning I had to find out the exact same thing happens on linux (Ubuntu 13.04, Avidemux 2.6.5 final, built from sources).
I simply copied over the video file and the py-file from the windows box (the one that was showing this issue in the first place), changed the path in the py-file, and executed it just from the GUI.
I'm itching to try this on Windows x64, because I still haven't seen it happening there.
On Windows x86 it keeps happening for yet different videos, now using nightly 8894.
This time two MP4s that are just over 2GB in size, became MKVs over 30GB when finished. The files are perfectly well playable, so I don't really understand what it is exactly that's taking up so much extra space.
For completeness sake, the settings are:
Input: MP4 with H264/AAC, 1920x1080, duration = 1:02:27.
Video: AVC (x264), Avg bitrate = 2500kbps, motion estimation method = 9, the rest is default.
Video filter: resize to 1280x720 bicubic.
Audio: Copy (input was AAC 128kbps).
Container: MKV
/edit
When I do a rough calculation of the actual outputted bitrate for these 30GB files, my calculator says 30GB should be around 64000kbps. The files are a bit bigger and there's audio. So my suspicion is that Avidemux might somehow be using a bitrate of 65536kbps (or 0xFFFF for the uninitiated ;)). Could this perhaps be the case?
could you post the output on linux ?
avidemux3_qt4 >& logFile
Sure, no problem. But it's gonna take a while if I have to do the encode again... Should I let both passes finish?
up to beginning of pass 2 is enough
Thanks
I let the second pass go to 17%, not on purpose. I just walked away and came back to see 17% :)
Anyway, I hope the attached logfile will be of help. Ans sorry about it being a zip, it was too large otherwise.
Is this issue still going to be resolved? I was kinda hoping for a status update... Something that tells me someone is working to resolve it.
In the mean time, I tried again with a newer nightly. Build 8913 this time. And back to Windows XP as well. Well, see attached screenshots. There's very little to add, but to point out that I explicitly set it to 2500kbps, but it's encoding at over 55,000kbps.
cannot reproduce
On Windows XP you can't? I can, every single time. On different pc's.
What else do you need from me in order to reproduce it? I think I have given all the information I could find, apparantly you need more... All you have to do is ask!
Hello guys.
I'm certainly no expert on this so i'm afraid i have nothing to add in terms of potential solutions. I just logged in here for the first time in years to report the very same issue that Thane have. I went through the nice guide you guys have for x264 in your wiki and managed to get nice quality video for my purposes of around 22 MB per minute in Avidemux 2.6.1. I now tried upgrading to 2.6.5 and used the same profile and exact same settings everywhere and the processing of one minute of the same file ended up being 465 MB, using two-pass average bitrate.
Where the average bitrate value during the second pass showed around 30K during the most motion-intense parts in 2.6.1, it shows as 130K in 2.6.5. The image quality doesn't even seem better either.
Are there any logs i could send you to further help investigate this? I'd hate this to turn into one of those problems that people randomly experience for years to come since nobody can find the reason behind it.
Does it work better with that version
http://avidemux.org/nightly/win_installer/avidemux_2.6.5_r8919_win32.exe
(32bits!)
There were some other posts by thany that seem to "maybe" point to issues attributable to file naming.
As a wild thought - is avidemux being run on a non English OS when these oversize issues arise?
Quote from: AQUAR on September 15, 2013, 11:11:25 AM
- is avidemux being run on a non English OS when these oversize issues arise?
Use of WinXP SP3 32bit German here, and to date I had NEVER one of these problems.
I mostly encode in 2-pass mode with an average bitrate, and it always works perfect.
Maybe a clean install and deleting all avidemux directories and registry entries could help?
Luckily very few seem to have this random oversizing issue.
Reasons for inconsistent/odd behaviour like this are hard to trackdown, especially
if it isn't reproduceable by those able and willing to investigate.
Quote from: AQUAR on September 15, 2013, 11:11:25 AM
There were some other posts by thany that seem to "maybe" point to issues attributable to file naming.
As a wild thought - is avidemux being run on a non English OS when these oversize issues arise?
English language OS, Dutch locale setting. US-int'l keyboard layout.
Quote from: cliffshit on September 15, 2013, 12:04:13 PM
Maybe a clean install and deleting all avidemux directories and registry entries could help?
I already tried that. Meaning a wipe of the directory in Program Files, and trashing the one in the user profile. I think that's all there is to throw out. Perhaps I missed something? If it might possibly help, I do like to know where else to look for files to throw away.
Another thought: Avidemux is very much dependent on CPU features, as proven by it prominence in the preferences dialog. Would it help if some of those are disabled (and consequently, how do I do that), and/or would it help to know which CPU's I'm running?
One pc that's showing this problem is running Windows XP in a ESXi virtual machine on three of the four cores of a Core i5-3470S, without HTT, but VT-d enabled in the BIOS. No real GPU to speak of, being a VM.
Another one is a real machine, running Windows 7 x64 on a Core i7-2630QM, with VT-d and HTT enabled in the BIOS. GPU is an AMD FirePro M5950.
(I'm sure the GPU or the VT-d setting has nothing to do with Avidemux, but one never knows, I suppose).
Quote from: AQUAR on September 15, 2013, 01:33:26 PM
Luckily very few seem to have this random oversizing issue.
Reasons for inconsistent/odd behaviour like this are hard to trackdown, especially
if it isn't reproduceable by those able and willing to investigate.
Luckily for them :)
One thing we know is that the problem is not specific to a video file. It happens all the time. Another thing we know is that a clean install doesn't help, because I tried it on a machine that has never had any version of Avidemux installed. We can also conclude that some pc's tend to show this problem and others don't, but (at least according to my findings) such pc's may be very different from one another, while two pc's that seem very similar may produce very different results.
Will try again later today with another newer version. Will post back results when available.
Same problem in r8919. I tried the aforementioned 32 bits installer on Windows XP.
Disabling CPU features in the preferences (assuming that actually does disable them - I can't check if it does anything) makes no difference at all. So we have that at least.
It happens all the time but only on a few PCs (mostly yours!).
Hence, your best bet to resolve this is by trying to isolate what is different with your PC's from the norm.
Try running avidemux in "XP mode without the Dutch language pack" on your windows 7 64 bit machine.
The fact that this thread exists might flush out more people with this issue, that would give it some impetus.
If you disable threading, i.e. encode with only one thread, does it work ?
@AQUAR
I don't have the Dutch language pack (assuming you refer to the type of langpack that transforms an English Windows into a fully translated Windows). Just the locale setting is Dutch, so I will see proper decimal points and currency symbols and stuff like that. Windows is still fully English from tip to toe.
I can, however, do a complete virgin install of an English Windows 7 with US locale on a separate physical computer and see what that does. If that reproduces the problem, would you believe my pc is not causing it? ;)
@Mean
Trying it now. It'll take a while, though.
/edit
Okay, so there seems to be an issue with that, too. When I set it to Multi-threading: disabled, it still uses all CPU cores simultaneously. When I set it to "custom", it doesn't allow setting it to 1. 2 is the minimum. But even if setting it to 2 threads, it still uses all 3 cores. On top of that, in all situations the original bitrate-problem persists (as expected, because the threading option appears to do nothing).
/edit2
Also tried to force it by setting an affinity mask in the task manager (and Multi-threading: auto, in the preferences). It appears to have started only a single thread, because resetting the affinity mask to all three cores doesn't improve processing speed and keeps cpu utilization around 33-35%. But, it doesn't do anything for the bitrate problem.
@ thany
I really don't have any belief about what is causing your issue.
BUT, the fact that I responded should tell you that I believe in the existence of the issue.
It might be caused by - avidemux - PC harware - the OS - a software conflict etc etc.
What is very apparent at this moment is that it is very uncommon.
That status might of course change if more endusers start reporting similar experiences.
Staying broadminded about any suggestions offered to help out is your best bet at the moment.
Which is why I offered to install a brand new Windows on a separate physical box. I'll do that probably later today or tomorrow. It takes some time, but if it helps make avidemux better, than that's good.
In the mean time, do you have any idea about what kind of software might be conflicting? Then I can test that as well... I don't have a whole lot of software on the pc that's showing this problem, but maybe one of them is misbehaving. And now that I'm typing this, I realize I do have AVG installed and enabled on-write scanning (I'm sorry, I should have thought of this sooner)... I'll do some testing with (or without) that, too. After all, virus scanners are prone to cause weird things...
Excellent idea to start with a minimum number of variables - clean install WINDOWS 7 - full admin account - NTFS file system - short/simple file/user/path names (no ". ~"!) - just an english version - no other software - and put it in a standard folder (not the special security beefed up "programs" folders).
That is what I was doing a few weeks ago when I came looking for avidemux updates, and I am still working on it.
Although I am tempted to do this clean install inside a virtual machine, since that will allow to easily and accurately rollback to a previous state... But I can't know for sure that avidemux will behave identically in a VM as compared to a physical box, being quite a hardware-stressing program and such.
Just food for thought!
A really clean way is to create a pristine OS in a dedicated primary partition, and use it for testing.
Image it for quick and easy recovery in case things go pear shaped.
Then you can really go wild and see what happens with any program of interest.
You could do it in a virtualised environment but this in itself adds lots of testing uncertainty.
You could add a sandbox to the pristine OS and create a non-persistent test bed.
But of course it adds that little bit of test uncertainty in exhange for an easy return to pristine status.
Quote from: thany on September 18, 2013, 06:59:21 PM
@AQUAR
I don't have the Dutch language pack (assuming you refer to the type of langpack that transforms an English Windows into a fully translated Windows). Just the locale setting is Dutch, so I will see proper decimal points and currency symbols and stuff like that. Windows is still fully English from tip to toe.
I can, however, do a complete virgin install of an English Windows 7 with US locale on a separate physical computer and see what that does. If that reproduces the problem, would you believe my pc is not causing it? ;)
You also could try to delete the "i18n" sub folder in avidemux folder and use the default English language only.
Well, the problem seems to have disappeared since r8962. Fancy that.
If this was intentional: thanks, great work!
If not: try to figure out what was done to fix it, so it won't break again in a future version (and thanks ;))