[MEncoder-users] MENCODER Hard Locks System - FC14x86

[Bill McClintock]

Its interesting that this hardware is my home server that runs 24/7 for 
everything else in the house.  Everything was good until I put fc14x86 
on it.

Something interesting to note also as I forgot until this AM.  I tried 
updating mplayer/mencoder on the fc6x86 build manually and oddly enough 
I was getting random lockups.  I never put it together until just now.  
I just assumed that I had library issues and gave up. and went in for 
the full rebuild.  The reason I pushed the rebuild was 1 fc6 was way 
beyond EOL but 2 the version of mencoder didn't handle flash video types 
well and aborted.  So time to upgrade.

Interesting also is I have migrated most of the script to using the 
latest SVN of HandbrakeCLI and it seems to work OK for about 6 hours.  
To be honest I like mencoder better but...  It did lock up last night 
but surprisingly,(I left top running remotely via putty hopefully to get 
a glimpse at what dies), mplayer was at the top.  The only command left 
in the script that uses mplayer is one that scrapes the VIDEO: line so I 
can get some basic info.  Probably not the best idea but seemed to work 
for years...

mplayer -ao null -vo null <file.mpg> 2>/dev/null | grep "VIDEO:"

I would get something along the lines...VIDEO:  MPEG2  1280x720  (aspect 
3)  59.940 fps  38810.4 kbps (4851.3 kbyte/s)...which I scraped all 
things relevant to build the custom command line.

Anyway, since I saw the mplayer command in top I suspected again the 
something in the mplayer suite.  I added -frames 0 to the line to get it 
to stop immediately as I also noticed in the top freeze frame that 
HandbrakeCLI started also but at a very small time slice 0:00.05 where 
as mplayer was going for 0:00.96.  I suspect that mplayer was finishing 
while HandbrakeCLI was starting up.

Anyway its off to the races again and the script is kicked off again. It 
compressed 6 before it gave up the ghost.  It's cron has been off for a 
while as I get time to decipher what's going on so there is a huge backlog.

To answer your last statements...SD and HD content create the same temps 
53c as the Athlon is really slow so both push 100% for the duration of 
the transcode.  I'll try mdb=1 / 2 if I move back to mencoder.  You 
mentioned my command line is suboptimal.  Given the command line below 
do you have a suggestion for a more optimal one?  All I am really 
looking for is a way to get the streams down to a reasonable size.  
Faster the better.  I log compression ratios in a file and they average 
from 23-27 percent of original size.  This is good as 40GB HD streams 
eat a lot of space vs. 10-12GB.

Again thanks for the insight.

On 2/6/2011 4:08 AM, Reimar Döffinger wrote:
> On Sat, Feb 05, 2011 at 09:49:24AM -0700, Bill McClintock wrote:
>> Can anyone suggest anything to help me isolate the problem.
> Hangs are either hardware or kernel bugs.
> Run tools to check CPU temperature and compare CPU usage for HD
> and SD to see if this might be the cause.
> Also try if anything changes if you use mbd=1 or mbd=2 (recommended anyway,
> but maybe a bit slow).
>
>> /usr/bin/mencoder -quiet -ffourcc DIVX -oac mp3lame -lameopts
>> cbr:preset=128 -ovc lavc -lavcopts vcodec=mpeg4:vbitrate=4000 -vf
>> expand=1280:720:0:0:0:0,tinterlace=1,crop=1280:720:0:0,scale=960:544
>> -ofps 30000/1001 /storage/mythtv/recordings/2594_20110102185900.mpg
>> -o /storage/mythtv/recordings/2594_20110102185900.avi
> Single-pass, bitrate-based encoding is suboptimal btw.
> _______________________________________________
> MEncoder-users mailing list
> MEncoder-users at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users