need moral support in switching to linux for encoding

[((( atom )))]

i started thinking about using linux for xvid-encoding in the future.

i am using linux for building servers, many standalone-devices, video-players, etc. but some little things kept me from using it for xvid-encoding so far:

(1) lazyness.. when encoding started, 99% of the tools were windows-based.. getting into them took years..

(2) afaik, there is no comp-test, is there? actually there should be.

(3) since autokg point (1) is getting very strong again. on the other hand, using autogk and understanding its mathematics, the wish for a similar linux-solution packed into a script actually came up very strong.

so since i am obviously lacking experience in this sector, i would be very thankfull for some advices/infos from others..

[unixfs]

[mpeg1video @ 0x8622e90] Pos:1287,9s 32201f (87%) 103fps Trem: 0min 172mb A-V:0,034 [875:96]

This is a 352x288 encode to mpeg1, but on average xvid at 720x352 encodes at 52 fps. I hope these examples are motivating enough

This is a script I use for a two pass encode:

#!/bin/bash

INPUT=$1
BITRATE=$2
OUTPUT=$3
EXTRA=$4

shift 4

rm -f xvid-twopass.stats
mencoder "$INPUT" -o /dev/null -vc ffmpeg12, -ovc xvid -xvidencopts pass=1:hq_ac:chroma_me:chroma_opt:quant_type=mpeg:bitrate=$BITRATE:me_quality=6:max_bframes=0:max_key_interval=125:vhq=0:turbo -sws 2 $EXTRA -nosound
mencoder "$INPUT" -o $OUTPUT -vc ffmpeg12, -ovc xvid -xvidencopts pass=2:hq_ac:chroma_me:chroma_opt:quant_type=mpeg:bitrate=$BITRATE:me_quality=6:max_bframes=0:max_key_interval=125:vhq=0 -oac mp3lame -lameopts cbr:br=96 -sws 2 $EXTRA

[The Shemeta]

Originally posted by ((( atom )))
so since i am obviously lacking experience in this sector, i would be very thankfull for some advices/infos from others..

Hi, maybe you can try Avidemux2 . Mean is working non-stop on it to improve it. it's a very nice tool with lots of options & filters. it's worth it giving a try.

Shemeta

[((( atom )))]

unixfs, on what machine do you get this much fps for encoding? i actually use a duron 1400 as a vcr, but when i tried using xvid instead of lavc i can't get more then 17fps on a 512xXXX picture. source is terribly noisy, though, so it might be different with dvd inputs..

so, you just encode, no cropping/resizing/comp-test?

[unixfs]

on a P4 2.6 with 512 MB DDR400.
If the source is noisy you sould use -vf hqdn3d, but that decreases the
speed a lot (at least 10%).

"$EXTRA" may contain something like
"-vf crop=720:432:0:72,scale=720:304,hqdn3d=4:3:7"
to crop, resize and denoise.

I use xvid-beta3.

[((( atom )))]

If the source is noisy you sould use -vf hqdn3d, but that decreases the
speed a lot (at least 10%).

i have to check, if maybe all the noise possibly causes a slowdown. according to your fps-values at your resolution, i guess i should be able to encode a 512 width in 16:9 (dunno the exact height hy hard..).

i have a couple of more questions:

(1) is there any function similar to the autocrop-function of avisynth?

(2) how do you evaluate the final image dimensions? on the command-line you can't see anything like if there are black bars to crop and if it is anamorphic..

(3) is there an easy way to make dual-channel audio-avis, let's say with an ac3 and a mp3 track?

having these points cleared, i could actually start thinking about a little more complex script that would work similar to autogk and crop, comp-test, decide over the final res, two-pass encode and mux and be whole..

[unixfs]

Originally posted by ((( atom )))
i have to check, if maybe all the noise possibly causes a slowdown. according to your fps-values at your resolution, i guess i should be able to encode a 512 width in 16:9 (dunno the exact height hy hard..).

i have a couple of more questions:

(1) is there any function similar to the autocrop-function of avisynth?

mplayer -vf autocrop + some seeking will give you the cropped dimension, then do the real encode

(2) how do you evaluate the final image dimensions? on the command-line you can't see anything like if there are black bars to crop and if it is anamorphic..

I guess you want to keep AR, right?
well: if a movie has 720x576 @ 16/9 then it's rescaled to 1024x576.
So a cropped movie follows the proportion:
1024:cy = 720:y' ==>>> y' = (cy * 720) / 1024
where cy = the cropped y. Remember to crop to multiples of 4 and
to rescale to multiples of 16.
You can rescale to a lower value than 720, but the less you
scale the better the quality (the best choice is to only crop and
use the new :aspect=x/y: option in xvid4).

(3) is there an easy way to make dual-channel audio-avis, let's say with an ac3 and a mp3 track?
having these points cleared, i could actually start thinking about a little more complex script that would work similar to autogk and crop, comp-test, decide over the final res, two-pass encode and mux and be whole..

no: only 1 track

[((( atom )))]

thx for the response. slowly i should have everything together.

[pyt0n]

finally i can post at this forum after some waiting.

ok, ive been searching around for some good source
of information, namely linux dvd -> xvid encoding.


i am not satisfied with the results im getting so by
joining up here i could hopefully learn something new.

1st of all i am looking for quality based encoding,
no matter how long time it takes.

* i use -only- original ac3 sound
* video as good as it gets - multiple passes, etc
* video size ,normally 600 x XXX (correct aspect ratio applied)

ive looked at autogk and he uses some comp-test,
is this possible with linux (mencoder or transcode) ?


any input is appreciated, please help out

im on xp1400\512\1Tb

[unixfs]

You can use a modified version of the script I posted above.

-oac copy copies the audio stream, and if you use -aid <AUDIO_PID> you
can choose the audio stream you want.

If you don't resize (only crop) and use xvid's A/R settings you
will have a better image quality (e.g. -xvidencopts ...:aspect=1024/480: ) but no standalone that I know of will play the video.

Some say that adding vhq=1 to the options improves the quality; I never tried it because it's much slower.

In my experience bitrate=1200 is already enough to get excellent quality, but a more mathemathical formula is width*height*fps*K
where K varies: I usually use 0.13, but the higher the better.

[Manao]

@pyt0n : change your resolution : 600 is only dividable by 8, not by 16, which leads to a certain loss of compressibility. You should use 608 instead.

@unixfs : no wonder why you get such good speed results if you're deactivating vhq. Really, when quality matters, you should use it.

@((( atom ))) : video encoding is one of the domains where linux is behind windows. It still lacks an equivalent of avisynth ( GStreamer isn't yet ready for that ).

[pyt0n]

ok as of now im doing a 4:3 encode,
output to 512x384, which is \16.

im getting there but i have a feeling
its going to take quite some time to
get a result i am satisfied with.

about vbr and desired filesize.....

is this enabled by default with transcode
and xvid or do you have to specify in cmd line?

-w 900 is desired bitrate ?
-R 1 and R 2 sets the passes


now, how to set either filesize or vbr?

[mikeX]

@ pyt0n:
vbr is enabled by transcode by using -R 2
yes -w x is average bitrate of x (for vbr too)
currently that's the only thing you can set through transcode (avg bitrate). for desired filesize you may wanna try mencoder or just use a bitrate calculator to tell you the bitrate value to use for a given filesize (more about that here: http://forum.doom9.org/showthread.php?threadid=67510)

[unixfs]

Update: my ESS-based standalone DOES read A/R settings when I encode
with libavcodec's mpeg4 and set -lavcopts ....:autoaspect.

Can anyone with a standalone confirm or deny?

In my opinion this is really very useful, because not resizing preserves more quality.

On the other side this means that XVID's AR settings maybe are still buggy.