You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
105 lines
4.8 KiB
105 lines
4.8 KiB
4 years ago
|
From Gerhard Monzel AT sap.com
|
||
|
|
Date: Mon, 21 Jan 2002 09:36:34 +0100
|
||
|
|
|
||
|
|
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:
|
||
|
|
- use of parameter "qscale_type = 0" in your own user-profile (worth to try)
|
||
|
|
- use image size 352x288 instead 480x576, but with smaller "quant_value"
|
||
|
|
(3-5) in your user-profile
|
||
|
|
(most consumer SVCD players have no problem to play such sized streams)
|
||
|
|
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.
|
||
|
|
|
||
|
|
Common problems:
|
||
|
|
----------------
|
||
|
|
Green artefacts may be caused from wrong resizing too, please try with
|
||
|
|
options of the above description.
|
||
|
|
|
||
|
|
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.
|
||
|
|
|
||
|
|
|
||
|
|
_______________________________________________
|
||
|
|
transcode-users mailing list
|
||
|
|
transcode-users@theorie.physik.uni-goettingen.de
|
||
|
|
http://www.theorie.physik.uni-goettingen.de/mailman/listinfo/transcode-users
|
||
|
|
|
||
|
|
|