dvd::rip

->ABOUT / NEWS

->DOCUMENTATION
-TABLE OF CONTENTS
-INSTALLATION
-USING THE GUI
-CLUSTER MODE
-FAQ

->KEY FEATURES

->DOWNLOAD

->SUPPORT

->TRANSLATIONS

->MAILING LIST
-SEARCH ARCHIVE

->CHANGE LOG

->CREDITS

->TODO

->LINKS

http://www.exit1.org/


Re: [dvd::rip] I'm tryin' to understand Video (re)size in dvd::rip

Subject: Re: [dvd::rip] I'm tryin' to understand Video (re)size in dvd::rip
From: Francesco Romani <fromani@xxxxxxxxx>
Date: Thu, 5 Apr 2007 20:43:48 +0200
On Thu, 05 Apr 2007 17:30:29 +0000
"Rick Nekus" <solarux@xxxxxxxxxxx> wrote:

[...]
> -Summarily, I'm not interested how big the final file needs to be (upto 
> 4.5G), I just want as flawless a (dvd)backup as possible.

(WARNING: following explanation is rough and not accurate following
codec and video compression theory)

So, evaluate the feasibility (if space constraints are still met) of a 
constant-quantizer encoder. Constant quantizer (-R 3 in transcode) tries
(roughly) forces the encoder to a given compression ratio, at expense of
final output space need.

Since all mpeg* variants (as well as almost any popular codec) are lossy
compressors, this allow to retain more details, so to have higher image
quality.

Normally, variable quantizer mode does exactly the opposite: the final output
size (as function fo bitrate) is given, and encoder modulate the compression
factor at best.

> "... increasing the source video resolution increases that amount of 
> information in the input,
> therefore the video quality will suffer more as a result, unless you higher 
> the encoding bit-rate (if possible.)"
> -Is this latter statement reflect the "trancode" limitations of preventing 
> any higher quality. ?

The problem is approximatively the following.
Considering a plain raw RGB image, more the image dimensions (width x height)
increases, the more detail is delivered since avery single pixel approximate
a lower area of original image. This is quite straightforward.
Now we have a problem: the more the raw image is big, the more bits are
needed to represent it:
image size = width * height * channels * bits per sample
considering normal RGB24 images we have 3 channels, 8 bit per sample.
Pretty expensive for a single picture, absolutely unfeasible for a stream of
pictures (= a movie).

Enter image encoders. They lossily compress a raw image in a bitstream.
During compression, a (mpeg-like) codec just throws away some details to save
space. Those codecs can't do miracles, they still need (much lower) amount of
bits to represent images. The higher is the avalaivle space (= bitrate), the
much details can be preserved.

Back on above statement.
If input image becomes larger (video resolution higher), the more bits are
needed to accurately represent it (= viewer don't see [too much] compression
artifacts). So, if encoder bitrate (= amount of space avalaible) for
compression is fixed, the compressed image will look worse.

Solution: give more bits to encoder (increase bitrate, -w) or use a better
codec, capable to deliver better image quality as fixed bitrate.

Examples: given the same bitrate, codec on the right COULD USUALLY deliver
better results that codec on the left

mpeg2 -> mpeg4
mpeg4 -> h.264

> anyway, I'm sorry for the askin too many questions, any insight would be 
> appreciated.

Get into transcode-users ;)

bests,

-- 
Francesco Romani - Ikitt ['people always complain, no matther what you do']
IM contact    : (email first, Antispam default deny!) icq://27-83-87-867
tiny homepage : http://fromani.exit1.org (see IDEAS if you want send code!)
known bugs    : http://tcfoundry.hostme.it/mantis (EXPERIMENTAL)

 

Archive powered by MHonArc. Search powered by ht://dig.

[ top ]