[MPlayer-users] Bug report for mencoder on DVB files...

Corey Hickey bugfood-ml at fatooh.org
Sat Mar 4 12:43:38 CET 2006


George Styles wrote:
>>>>Very strange that it doesnt happen there, are you using the same command
>>>>line as me? here is the complete session of processing that file:
>>>
>>>Yes, I've got no error on my x86-64 system. I've made a rapid test on
>>>an outdated version 32bits version on my 32 bit chroot, but it was
>>>quite inconclusive: mencoder was deadlocking, but was deadlocking on
>>>pretty much any file anyhow.
>>
>>Heh, 32-bit chroots are annoying. Eventually I'll get rid of mine...
>>
>>Anyway, I can't reproduce this on my amd64, nor on a family-15
>>spepping-7 Xeon I have access to.
>>
>>If anybody else has a CPU more similar to the original poster's
>>(family-15 stepping-9), they could test that...
>>
>>-Corey
>>
> 
> Thats really wierd... i swear it happens every time on my 'puter!

I just noticed that an earlier mail from you mentioned badseg2.mpg
whereas I had been testing brokenseg.mpg. I found it in the obvious place:

http://files.ripnet.co.uk/badseg2.mpg

Anyway, I tested that on my Athlon64, somebody elses Xeon, my old P4
laptop, and my old Athlon (thunderbird) server. All four of them cranked
right through.

$ mencoder badseg2.mpg -oac mp3lame -lameopts mode=2:cbr:br=128 -vf \
scale=320:240 -sws 2 -ovc lavc -lavcopts vcodec=mpeg4:vhq:vbitrate=256 \
-ffourcc DIVX -o out.avi -vfm ffmpeg

By the way, notice how I've broken up the line above manually and used
backslashes? That makes it much easier to paste into a shell all at
once. Also, it's generally good to try to simplify the command by
removing options that aren't necessary to reproduce the error. For
example, your command could probably be reduced to:

$ mencoder badseg2.mpg -nosound -vf scale=320:240 -sws 2 -ovc lavc \
-o out.avi

Of course, I can't confirm that, since both of them work for me.

> Maybe this is a niave statement, but the only reason I can think of for it
> to work on a 64 bit processor and not a 32 bit is because something
> overflows a 32 bit register. ... am i missing something? is there a
> completely seperate 64 bit implemention of some of the ffmpeg code optimized
> for 64 bits?

Thing is, though, it works for 32-bit systems as well -- just not yours. :)

Anyway, you've piqued my curiosity; I don't know anything about the code
in question, but I want to see if it's in any way build-related.

http://fatooh.org/files/tmp/mp.tar.bz2

Download that. It's the build I used to test on the AthlonXP and the
Xeon. It's dynamically linked and includes all the necessary libraries.
You can run it like this:

$ tar jxf mp.tar.bz2
$ cd mp
$ LD_LIBRARY_PATH=. ./mencoder (your options here)

It might not work if you have a rather old libc, but give it a try.

> ive been looking for an excuse to buy a 64 bit processor anyway :)

Well, if you need an excuse, consider that (at least according to a bit
of recent testing I've done) an Athlon64 will chew through video
encoding much faster than a P4.

$ time mencoder lotr_test.vob -really-quiet -frames 400 -nosound \
-vf crop=712:354:4:62,scale=688:288 -sws 9 -ovc lavc -lavcopts \
vcodec=mpeg4:vbitrate=800:mbd=2:mv0:trell:cbp:vqcomp=0.6:qpel:\
sc_factor=6:vratetol=80000:qns=2:precmp=2:cmp=2:subcmp=2:predia=2:\
dia=2:preme=2:v4mv:last_pred=2:vmax_b_frames=2 -ofps 24000/1001 \
-o /dev/null &> /dev/null

Divide 400 (frames) by the user time (in seconds) to get fps. Divide fps
by CPU GHz to get fps/GHz.

Pentium 4 Mobile   1694.790 MHz  ...  2.46 fps   1.45 fps/GHz
(Pentium 4) Xeon   2399.806 MHz  ...  3.57 fps   1.49 fps/GHz
Athlon64 Newcastle 2556.109 MHz  ...  6.63 fps   2.59 fps/GHz

I digress...

-Corey




More information about the MPlayer-users mailing list