Re: [gentoo-user] mencoder: error encoding, following howto

[fire-eyes]

On Wednesday 21 June 2006 12:45, Hans-Werner Hilse wrote:
> Hi,
>
> On Wed, 21 Jun 2006 10:01:51 -0400 fire-eyes <sgtphou@×××××××××.org>
>
> wrote:
> > I opt to go for the supposedly higher quality x264, so I do two
> > passes:
> >
> > 1:
> >
> > mencoder -v ../vob/title1.vob -alang en -vf
> > crop=720:352:0:62,scale=752:320 -ovc x264 -x264encopts
> > subq=4:bframes=4:b_pyramid:weight_b:pass=1:psnr:bitrate=4452:threads=2:tu
> >rbo=1 -oac copy -ofps 24000/1001 -vobsubout subtitles -vobsuboutindex 0
> > -slang en -o pass1.avi
>
> Hm, threading, eh? Ever tried disabling it?

Sure have, no change on either system.

> > 2 (which whines about not finding the log file, so I have to rename
> > divx2pass.log.temp to divx2pass.log manually -- donchya love having
> > to figure things out):
>
> The question is rather why mencoder doesn't name it like this. The
> mencoder man page clearly tells that it should. It supposedly wasn't
> existing at that point, right?

Correct, I did not understand that one, either.

> > mencoder -v ../vob/title1.vob -alang en -vf
> > crop=720:352:0:62,spp,scale,hqdn3d=2:1:2 -ovc x264 -x264encopts
> > subq=5:4x4mv:8x8dct:frameref=3:me=2:bframes=4:b_pyramid:pass=2:psnr:bitra
> >te=4450:threads=3 -oac faac -faacopts object=0:tns:quality=100 -ofps
> > 24000/1001 -o pass2.avi
>
> Oh, 3 threads now. Again: Did you try using only one thread? Are all
> those additional libraries you might have compiled into mplayer
> thread-safe? BTW: Is there a reason why in pass one you're using a
> cropped, scaled version of the movie and in pass two a _not_ scaled
> version? This will probably result in different blocks and will
> probably have (minor) bad influence on b/w calculation...

Just following the URL. I haven't a clue what i'm doing with all this stuff, i 
find it very confusing.

> > However there is a problem with pass 2. I have tried this on two
> > seperate systems, and the exact same thing happens:
> > [...]
> > Segmentation fault
>
> Segfaults are not that uncommon if you have problems with interfering
> threads. If you have a little time, you may also want to do an "emerge
> -e mplayer" to sort out problems that are due to compiler change and
> similar. BTW: Are you overriding the mplayer ebuild's own CFLAG
> settings?

Sure, maybe I'll do the emptytree some day. Sounds like it would be easiest to 
not use threads and in fact disable it in the x2whatever encoder, i would 
hate to have to stick with that though as I do have two cpus... better than 
segfaults tough.

I am using custom cflags on that, though I've never had a problem with that.

I think what I'll try is disabling threading support in the apps, try again. 
If that fails, move away from custom-cflags in mplayer.

So many factors :) Thanks.

-- 
"When you walk across the fields with your mind pure and holy, then from
all the stones, and all growing things, and all animals, the sparks of
their soul come out and cling to you. And then they are purified, and
become a holy fire in you." -- Ancient Hasidic Saying
-- 
gentoo-user@g.o mailing list