diff options
Diffstat (limited to 'debian/transcode/transcode-1.1.7/docs/README.vcd')
| -rw-r--r-- | debian/transcode/transcode-1.1.7/docs/README.vcd | 104 |
1 files changed, 104 insertions, 0 deletions
diff --git a/debian/transcode/transcode-1.1.7/docs/README.vcd b/debian/transcode/transcode-1.1.7/docs/README.vcd new file mode 100644 index 00000000..98f868aa --- /dev/null +++ b/debian/transcode/transcode-1.1.7/docs/README.vcd @@ -0,0 +1,104 @@ +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 +http://www.theorie.physik.uni-goettingen.de/mailman/listinfo/transcode-users + + |