I'm getting this error now. A search through the forums quickly reveals that this has to do with the filename, but in my case I have only US characters in the filename. Only letters, numbers, a normal dash and a normal underscore (I even retyped it to be absolutely sure - yes, on a US keyboard).
The input video is AVI, DX50 1280x720 29.97fps, MP3 192kbps.
The output is MKV, x264 video size (two pass) = 800MB, no filters, Vorbis 128kbps.
Input filename is "AIKA-091611_175.avi"
Output filename is "AIKA-091611_175.mkv"
The problem is not exclusive to this encode. It happens for multiple files (all actually, as far as I have tried).
Even if it fails, two files are being created as is normal in a two-pass encode. One is called "AIKA-091611_175.mkv.stats.temp", which I will attach. The other is called "AIKA-091611_175.mkv.stats.mbtree.temp", and is 0 bytes (so I could attach it, but it's kinda pointless).
Running Windows 7 x64 and Avidemux 2.6.5 r8897 (fresh download).
and if the same created file is called foobar.mkv it works ?
No, it does not. Filename seems to have nothing to do with it.
This isn't the first time I'm typing a filename for encoding output, btw. It's only the first time running Avidemux 2.6.5 on this computer. I've been able to run it perfectly (which means getting different problems, but certainly not this one) on a couple of other computers.
Just tried a totally different file (a 720p MP4 from youtube to be exact) and the same problem occurs.
/edit
I'll attach the admlog. Hopefully it helps.
Just guessing here: I see a ~ in your windows account folder name.
Ussually means some name truncating is being encountered.
Probably avidemux is lost trying to find your files.
Use simpler account and file names would be my first thought.
I believe you hit the same bug as me.
http://www.avidemux.org/smf/index.php/topic,12722.0.html
It seems only happen when 2-pass is used and related to log file filename...
This is my work pc. I can't change my profile directory.
But why would it need to revert to the age-old tilde-notation for long directory names? Moreover, my profile name, as you can see near the top of the log file, is "m.saly" not exactly long, and not exactly any strange characters in there. In any case, I didn't put the tilde there, something else did. Not blaming avidemux, but sure enough avidemux is the only program so far showing a problem related to the name of my profile directory.
Okay, it started happening on my private pc as well. Exactly the same thing. Mind you, a previous version 2.6 did not show this problem (although I can't remember which one again). So something must have been changed to cause this message.
/edit
As virus scanners are a general culprit, on both my work pc and private pc (which are both having this issue) I do have a virus scanner. On the work pc, I've got MS ForeFront Protection (which I cannot uninstall or disable, sadly), and on my private pc I've got Avast (on-access and on-write scanning is disabled). Any known issues with that before I start testing?
I've been able to transcode a couple of videos again, but this problem surfaced again. I'm on r8962 x64.
I've seen people claiming resolution is the problem - it is not. Even without any filters this problem persists.
I've seen people claiming filename is the problem - it is not. Even naming the output file "a.mkv" gives the same trouble.
What exactly causes this error message to pop up? Someone must know this, right?
/edit
Forgot to mention, this is specific to one file (one for now, that is). Regardless, the question remains ;)
/edit2
I mean, I'm probably oversimplifying this, but... In the source code, this message must be called at some point or another. I'd say if you look for that, and see which conditions are met to trigger that message... But sadly, I'm not that good with code. But there *must* be more going on than "if filename contains weirdcharacters then displaymessage", but you know, there has to be *something* going on that decides when and why to display this error message.
I had this problem, and it was caused by IDC Level:
http://www.avidemux.org/smf/index.php/topic,11552.msg60447.html
You could try changing the IDC Level.
I will, whenever I stumble upon this problem again. Thanks.
Developer note: the program could do this automatically... You shouldn't bother the user with a message that makes absolutely no sense, especially not if the problem can be fixed "under water", and entirely especially if the "auto" setting for IDC is apparantly not "auto" enough. Just saying.
@ thany
Quotemakes absolutely no sense
Pity Nothing makes sense to you.
Now Nothing and Absolute here are used as expletives (google it!).
I've said it before - using expletives results in counter productive reporting.
Ever heard the expression "you can catch more flies with honey than vinegar".
How about trying your problem file with the suggested fix and respond with a Yay or Nay.
Message is fine as it warns you of an issue from a broader perspective.
Such feedback is more than that provided by lots of payed for video editors.
I think that thany just has to have thany perfection.
Sadly for thany that is 'Absolutely' 'Impossible', as that perception and reality are 'Nothing' short of light years apart.
Dude, I'm trying to be helpful. I'm reporting a bug, and you treat it as complaining and moaning and yadayada. Aren't you getting tired of yourself?
Ranting aside, this is a real problem. The simple fact that the "Cannot setup codec. Bitrate too low?" message holds no relevance to the bitrate being too low, is a serious problem, because it leads users to looking in the wrong place for a workable solution (increasing the bitrate). The actual solutions that have been reported, such as non-ansi characters in the filename and the IDC level, hold no relevance to the message. Therefore no sane person would think of looking in those places after seeing this message, unless they somehow know what *actually* causes this message to appear.
@ thany
Obviously you just can't see the forest for the trees.
Now I tried a few times to get you to report "bugs" in a more respectful, matter of fact, manner.
Ask yourself why?
At the practical end, how dare you demand pin point accurate diagnostics on intangible bugs.
Are you going to pay for that? Are you spending your time on developing that? Do you understand the complexities involved?
I know its - no No NO!.
And, NO I am not getting tired of myself.
And, NO I am not treating your bug reports as complaining or moaning.
And, YES I am treating the manner of your bug report to have an inconsiderate attribute.
And YES I am treating your expectations as unrealistic.
Now you said the IDC level has no relevance to bit rate limitations - sure!
You will be happy that I will only read your bug reports from now on.
Apparantly, any way I try to speak of that something being wrong, it is taken offensively.
Why?
If something is wrong, then that's that. I can't make it sound like flowers and whistles. It's just what it is. Call me negative, but I'm just another user sometimes frustrated by obvious bugs, sometimes frustrated by long-outstanding problems, sometimes positive when something's fixed.
If you keep responding like that, well... I could put some expressive words here like you did, but I won't lower myself to that level.
Now, let's FINALLY focus on the bug and stop making personal attacks, okay?
Well, setting the IDC level manually definately doesn't help (nor do all the other "known" fixes).
I stumbled upon another video that somehow has this problem. I found something. Well, I may have.
When I change the video encoder setting from "Average Bitrate (Two Pass)" to "Constant Bitrate (Single Pass)" with all the same settings otherwise, I get this when trying to start the encode:
"Too short
The video has been saved but seems to be incomplete."
After that it has saved roughly 4KB of data, while the original video is definately more than that. It looks like it's literally only saved a matroska header.
When I choose the video codec "HuffYUV" and container AVI, and then start the encode (leaves everything else alone), the process is almost instantly finished, after having saved just 32KB of data. Again, probably just a header. It looks to me like it cannot find a single frame to work with, even though the video is loading fine and is navigable like any other - so from that perspective I see no reason why it wouldn't find the first frame... But who knows.
When I choose "Copy" for the video codec, it does work. Well sort of, it's not doing any kind of video recoding of course, but it does happily copy the video track over to the destination file.
I am also getting this error under Windows 10 with Avidemux 2.6.12 . In this case it only happens when I select the H264 output.
How do I find the option to set the IDC level or the Average Bitrate setting?
Video Output
set [Copy] to [Mpeg4 AVC (x264)]
[Configure] <- click
------
[General]
Basic
IDC Level [Auto] <- click and select wanted
Rate Control
Encoding Mode: change [Constant Rate Factor (Single Pass) to [Average bitrate (Two Pass)]
------
notice when doing so Target Bitrate will change to Average Bitrate
Hi
I had problem with error "Bitrate too low". After a lot of time and many attempts I added filter "swsResize" with checked option "Round to nearest multiple of 16" and voila. It works.
I have tried all the suggestions in this thread, I still get the same error. I don't have a ~ in the username, I have set the IDC level to 3.1,I have set the swsResize to Round to the nearest 16, and I have tried to set the Encoding Mode to 2 pass.
So I guess another data point for whoever wants to take a whack at solving it (or maybe just remove the BitRate limit, let us encode even if you think the result will end up looking bad).
Edit: I could not post new post, it says I'm spammer. But I updated to the latest version, it works. Thanks.
The suggestion in the error message doesn't mean that the reason for setup() of the particular encoder to return false has anything to do with bitrate. If you have tried with the latest nightly build of Avidemux 2.7.4 and the problem persists, please compress (zip or 7z) and attach admlog.txt from %localappdata%\avidemux\ originating from the failed re-encoding attempt.
64 bits Windows executables (https://avidemux.org/nightly/vsWin64/) built with VC++ from git master on Windows
64 bits Windows executables and ZIP packages (https://avidemux.org/nightly/win64/) built with MinGW from git master on Linux
32 bits Windows executables (https://avidemux.org/nightly/win32/) built from the legacy-compat branch with MinGW on Linux
DMGs (https://avidemux.org/nightly/osx_mojave/) for macOS Mojave 64 bits (should work with Sierra too) built from git master
64 bits appImages (https://avidemux.org/nightly/appImage4) for Linux built from git master
I had this problem with on old video file. The simplest solution is to read it with VLC and stream it to a new file after letting vlc reformat it. VLC is very robust program an seems to be able to fixall ofthe issues relating to aged video formats.