While producing mpeg videos, you have to give special attention to the desired image size of your output video (this is a big difference to avi-encoding). Because mpegs, especially VCD and SVCD can be played in consumer players, there are some restrictions in "resizing" ! Usually image sizes for VCDs are 352x240 (NTSC) or 352x288 (PAL), for SVCD 480x40 (NTSC) or 480x576 (PAL) -> some consumer players can play VCD sized videos as SVCDs too and vice versa.
As a further difference to AVIs, the aspect ratio of the video is stored in header of the mpeg-videos. Therefore most players (pc and consumer players) will display the right image proportions no matter what X/Y dimensions your video is encoded.
In your case of a 720x576 vob in 16:9 aspect ratio, you should use 480x576 as destination image format (PAL) and (force) apsect ratio to 16:9.
The resulting video will look like expected on PCs with e.g. mplayer, which will honore the aspect ratio, but many consumer players have problems switching to 16:9 format in VCD/SVCD mode -> in this case you need a resizer capable of generating black bars on top/bottom of your video.
This canŽt be done with the trancode resizer, but with the internal mpeg- module resizer (I mean -y mpeg not -y mpeg2enc). You can also mix the resizer of transcode with the resizer of the mpeg-module too. On base of this knoweledge you will concluse, that following options should produce a "original" looking picture on a 4:3 aspect ratio:
-B 5 -y mpeg -F s,3 ...
-B 5 => 720x416 (formats image near to 16:9),
-F s,3 => 480x576 (formats image to SVCD size with black bars on top (80 pixels) and botton (80 pixels), so it will look well on 4:3 display.
Because of using only high speed resizing options, the transcoding process will run in better speed than using zoom or other slow rescaling options. Unfortunately transcode itself canŽt handle black bars for output video (in AVI world there is no need of this feature and transcode begans as AVI transcoding tool). Of cause this described solution wonŽt work with other export modules e.g. "mpeg2enc" (it lacks of internal black bar resizer).
There is no suggestion to calculate filesize for mpegs with variable bitrate (usually used in SVCD mode), because filesize depends on kind of your source video (luminances, motion etc.) and the quality value (quant_value) you are using while encoding. Only the max. possible size is known by the max. bitrate restriction for SVCD and the count of frames. to avoid problems with oversized mpeg-files (wonŽt fit on CD), the mpeg- encoder module can forced to split the encoded file in several parts. The size per part in MB is given by the "max_file_size"-Parameter used in conjunction with a user-profile (-> remember option -F s,3,<name of user-profile>, where this profile may look like:
max_file_size = 700 ...
The encoding speed in SVCD-mode varies in a wide range, because of the big influence of bitrate control method: the encoder calculates the actual bitrate for all frames of one GOP (group of pictures) and if the max. bitrate limit is exceeded, the whole GOP will be encoded again with a higher quantizer value until bitrate fit into limit. Bitrate (for SVCDS) depends mainly from "quant_value" (lower value / better quality -> higher bitrate). In conclusion higher quality leads often to lower speed, so itŽs your decision what is more worth for you :-) But there there are some tricks to reduce bitrate for mpeg-2 typed streams without loosing much quality:
maximum effect results in combination of both hints.
To observe actual bitrate during encoding you should set transcode option "-q 2", so you can run short encoding turns to find out the best quant_value settings.
To test the maximum encoding speed you should use option -F 1,3 so YouŽll see how much the SVCD bitrate control will drop speed.
Using "-V" option (needed to encode mpegs) will force import modules to use internal YUV-format instead of RGB.
But there are several different YUV-Formats and for example some of it has swapped chroma (UV-) components.
Weird color on encoded mpegs is not a bug, therefore you can use the "-k" option to "reswap" the croma components.