Hi
I'm trying the linux compilation but I have this error :cry:
Thanks

Welcome to the Linux incompatibities world :lol:

You'll should to have "at least" the same kernel version and libraries that vmesquita is using on his system.

What distribution are you using?
What kernel version?
GTK version?

-kwag

@vm,

vm wrote:
Didn't realize internal filters were available and will try this tonight.
This testing is helping me understand MEncoder much better. :wink:
There are so many options with MEncoder, it overwhelming at
times. The results are well worth the effort.:mrgreen:


Thanks

-BP

-What distribution are you using? I'm using Mdk 10
-What kernel version? 2.6..3-4
-GTK version? How check it?

Thanks

Bingo :!: :arrow: Kernel 2.6.3-4

I'm pretty sure that's the problem, because vmesquita is running a Knoppix derived version, which currently has kernel 2.4.2?

-kwag

Provably. I think the same.
What is the solution? :cry:
Would VMesquita have to compile each time for each kernel ? :? It's imposible. :cry: :cry:

I see you tomorrow!! :wink:

Either that, or he will specify for what version of kernel his executable is for. No, it's possible, but with a lot of kernel sets on vmesquita's side with many different compiles, or just a single compile forcing users to use a specific kernel (which is not likely to happen :!: )Good morning to you ;)

-kwag

@sertinell
Thanks for trying. I am using a Knoppix derived distro with Kernel 2.4.22. Other packages

libgtk1.2-dev
libexpat1-dev
libc6
libc6-dev

To discover GTK version, type
Mine is 1.2.10

About Kernel: I have a precompiled package to install an additional kernel 2.6 as a option on boot. I might install this kernel and see if my compile crashes, if it doesn't the problem is not kernel related.

edit:I'll check MDK 10 Packages (if I manage to find somewhere)
edit2:MDK doesn't feature gtk1.2, just 2.0:
http://www.mandrakelinux.com/en/10.0/features/15.php3
Looks like you need GTK1.2. You can have both GTK1.2 and 2.0 in your system, look here:
http://www.gtk.org/download/
Maybe I should compile for GTK2 because it's more recent...
:?

http://www.rpmfind.net ;)

-kwag

Thanks Karl, but Knoppix, as a debian derived distro, doesn't take RPMs. But I think the problem is the lack of gtk1.2, mdk10 doesn't come with it. BTW, is there a "debian dep find"? :D

It does :!:
RPM is already installed on Knoppix.Well, debian already handles all dependencies automatically, with apt-get.
Or you can issue: apt-cache search "YourKeywordHere"
But that's not the case for RPM, which only "alerts" of missing dependencies.
That's one reason I moved away from "Red Hat" based distros (like Mandrake, etc. ) :roll:

-kwag

Looks like it has been removed from my distro, then. But I think it was a good idea. RPMs can make such a big mess in the system... :roll: apt-get is much better than rpm.

I am currently recompiling wxGTK with GTK2. They say GTK2 support is experimental... Let's see how it goes. I'll check what GTK comes with most linux distros today to decied which one I should use.

BTW, thanks for the "apt-cache search" tip... I am trying to figure this out since yesterday! :D

It's helps to read "Linux Journal", "Linux Magazine" and "Linux Format" once in a while :)
It complements the Web very well :D
BTW, when you're ready to do your backup in Linux, don't forget "mondo" ;)
apt-cache search mondo ;)

-kwag

OK, WxGTK with GTK2 is really experimental. The redirected stdout doesn't work very well: text replacing in the textbox is not working perfectly. I'll stick with gtk1.2, looks more reliable. Besides, it's not such a big package to install. :roll:

EDIT: And for some reason, the gtk1 compile loads much faster. :wink:

FIFO FIFO FIFO :lol:
Hint: mkfifo :idea:

Redirect mencoder's output to a FIFO file, and grab the data from your program.
When you start your program (in Linux), make a FIFO, where mencoder will re-direct all output to, and you open the FIFO as a file from your application.
Then simply read the FIFO :!:

-kwag

Sorry for not reporting that Vbitrate problem by myself, but yesterday was my "bad luck" day!!! :evil:

- totally DVR-105 Burner problem ("fatal driver error" in TmpgEncDVDauthors burning enigin - never had probs before, DVDlabs burning engine stops in the middle ... only NERO could do the whole job correctly 8O )
- An AC3 german audio which came out "shorter" from the ripped DVD than the english one ... german audio was totally out of sync 8O
- etc. etc. etc. etc

- AND! DVDlab gave me several "gop size out of memory" errors when using my new mencoder streams (maybe mencoder gots a bug OR the new DVDlabPro likes more "Closed GOPs" which I dont know where to set in mencoder :( ... if using CCE Streams ... no problems :screwy:

Resumée: 2 DVD-R Media "trashed"! :evil: grrrrrrrrrrrr :arrow: a very "bad luck" day

Hi
God afternoon
I have GTK 1.2
The problem isn't GTK version.

Awesome program VM. I think I can help those having problems with 1-pass bitrates. I noticed if I click on the audio bitrate it does not always update with the correct bitrate. For example, if I choose 128 and i get say 2300 as a bitrate for video then click on say 224 and then back to 128 I get the bitrate for 224. To solve this I just go back and forth until it gives me a bitrate that makes sense or just enter it manually. Hope this makes sense. I actually found the 1-pass filesize results to be extremely accurate. Just yesterday I was shooting for video size of 720 Mb and got exactly 720.

Hi Dano!

Well I also did tests when I set bitrate manually :?
So this is calculator independend.

I went further and did the WHOLE encoding way via commandline using the exact .bat and .ini configurations like they will used by the GUI. And I could set what I want 1500kbit vbitrate or 4800kbit vbitrate .... result was still the same final size of the encoding. But maybe my machine was also in there playing "loco", so I will test that tomorrow again (tonight I gonna celebrate my birtday ;-) ).

Yep I also figured out (in the past) that (when using special parameter combinations) the setted vbitrate almost matches the avg bitrate on the final encoding, often, but not everytime.
Its shure that an encoder CAN't see what the further content of the source will bring during encoding, so that seems a bit as an asumption on the beginning ... that the actual average of moviecontend will be assumed for further treatment/complexibility ... and if a source keeps it complexibility through the whole source nearly constant ... this could match a little the wanted avg bitrate.

So conclusion .....: On 1pass VBR you still need to do a prediction using sampler() or slicer() via makeavis.

I didn't try till now the direct VOB way as this could only be done via 2pass for approaching the wanted final size.

Hi.
I've updated my kernel to 2.6.5-4 and all my old programs (compiled by me under 2.6.3-4) are runing wihtout any problem and apparently faster.

Kwag, are you sure that the kernel can be the problem?

Thanks