[MEncoder-users] So does "target size" in xvid actually do anything?

Padraig Hogan padraig_hogan at yahoo.com
Fri Sep 16 20:10:38 CEST 2011


>________________________________
>From: "larrystotler at netscape.net" <larrystotler at netscape.net>
>To: mencoder-users at mplayerhq.hu
>Sent: Friday, 16 September 2011, 18:51
>Subject: Re: [MEncoder-users] So does "target size" in xvid actually do anything?
>
>-----Original Message-----
>From: Padraig Hogan <padraig_hogan at yahoo.com>
>
>> I steered clear of target size before, but I thought I'd give it
>> another go. This time I would encode the audio first and then the 
>video. The
>> following is the relevant part of my batch file: 
>
>Target size would ignore bitrate from what I remember.  However, some movies I've done ended up smaller due to less need of bitrate(I encode at 1536, but I have some that only  "needed" 1100).
>


Yes, but that would not appear to be happening here as I explained. 


>> if %2==2 "C:\mencoder\mencoder" %1 -oac mp3lame -lameopts abr:br=128 
>-ovc copy -o %1.btw
>
>Why not use mencoder for the audio?  Is your mencoder compiled with mp3lame support?  Also, mp3lame is only stereo, so if you want 6 channel, you shouldn't encode with mp3lame(found that out the hard way after a friend assured me mp3lame did 6 channel).
>


I do use mencoder for the audio, it just does the audio first to avoid the "because xvid can't see or misinterprets the audio" argument for why it gets the wrong size. The source is mp3 anyway, and the device I want to play it on doesn't support AC3. 




>> if %2==2 "C:\mencoder\mencoder" %1.btw -oac copy -ovc xvid 
>-xvidencopts
>> bitrate=-1024000:threads=2 -vf scale=720:-2 -sub %filename:~0,-4%srt"
>> -utf8 -subfont-text-scale 2.7 -o %1.avi
>> del %1.btw
>
>I've found that "threads=" in xvid is pretty useless.  It's not very good at multithreading.  I can re-encode 2 movies at the same time MUCH faster on a dual core than using threads and doing them 1 after the other.  xvid gets maybe 20-30% faster.  x264 is MUCH better at multi-threading than xvid.
>


Wow. threads= is NOT useless, I cannot use the second processor in my encoding if I don't use it. The only time I would consider not to use threads is when I want the encoding to be quieter. 


I am using xvid for a specific reason, I cannot use x264. Please stick with the topic at hand and don't be making frankly stupid allusions to other things I should be doing. I did suspect that I might get something like: "why are you using xvid, x264 is sooooo much better" or "why are you using mp3? ac3 is sooooo much better", why not ask why I'm hardcoding the subtitles? After all there are many advantages to not hardcoding subtitles, I must be an idiot.  


>> But it still just completely ignores the 1024,000 kb and it comes out 
>as 800mb.
>
>Probably because it only needs 800k for that file.  What's the original source?  mpeg2?  And why not do 2 pass on xvid?  Use "pass=1,turbo" for the first pass and you will see much better quality.
>


No, it's not mpeg2 it's x264 or another advanced mp4 format. I don't see much better quality and prefer to just give it a higher bitrate as perfect compensation so it will encode much faster. This is a black and white movie does it shouldn't need such a high bitrate.  


>> I've had similar problems with it before. It's almost as though it 
>doesn't even
>> matter what size you put it, mencoder will just choose it's own size 
>that's
>> around 750mb for a typicalk movie.
>
>here's a handy calculator for calculating xvid bitrates and sizes:
>
>http://quadpoint.org/projects/simplerip#audio_and_video_bitrates
>
>a 1 hour 30 minute movie at 700mb only needs a bitrate of 953 to get a 700MB file with 128kb/s audio


I have to say, your post was completely useless to me. Is this by any chance a joke email or are you being serious? 


>


More information about the MEncoder-users mailing list