[MEncoder-users] Backup policies

[Peter Cordes]

On Mon, Nov 19, 2007 at 08:02:20PM -0600, James Hastings-Trew wrote:
> Michael Rozdoba wrote:
> > Loren Merritt wrote:
> >
> >   
> >> Where you went wrong is thinking of bit distributing. "Distribution" 
> >> carries a connotation that you have some bits and then decide where to 
> >> put them. That's not how x264 works, CRF nor 2pass. It's better to think 
> >> of "bit requisitioning"
> >>     
> >
> > /snip details
> >
> > Thanks very much. That's the clearest explanation I've come across & 
> > helps clear up my misunderstanding :) That should definitely be part of 
> > any doc explaining the basics of x264's approach. Most appreciated.
> It's not really doing anything for me.
> 
> I guess I just don't understand, unless x264 can "magically" know where 
> to requisition bits, and where not to, and still come out without 
> over-spending or under-spending by the end of the file. If I aim for a
> 2Gb file (because that is the max size that will fit in my devices' 
> storage), and it under-requisitions and ends up giving me a 1.8Gb file, 
> then I can reasonably assume that there are some scenes in that file 
> that could have been encoded at a higher quality, if only x264 had known 
> it could requisition more bits for them. If it over-requisitions and I 
> end up with a file that's 2.2Gb, well, maybe that is useless for my 
> needs and I am going to have re-encode it at a lower bitrate.
> 
> What am I missing?

 In the thread on doom9 linked to earlier, akupenguin says at one point that
both CRF and 2pass use heuristics which try to spend bits in a
rate-distortion-optimal manner.  i.e. where would spending another bit most
improve the subjective quality of the overall movie?  The main difference is
that 2pass constrains the total number of bits that can be spent, while CRF
targets a specific quality level, with unknown final file size.

 x264 pass=1 writes a file that says how complex each frame is, (in terms of
bits needed to code it with reference to previous frames...)  Frame
decisions (I, P, or B) are made in pass 1.  When pass 2 starts, it reads
that file, and decides (roughly?) where it's going to spend its bits before
even encoding the first frame.

  It takes a lot of bits to improve the quality of high-motion high-detail
scene.  Spending a bit improving the appearance of an I frame that is
referenced for a long time (e.g. a background in a scene with no camera
movement) will add more quality to the whole movie.  (i.e. PSNR or SSIM as
reported by x264).

 apparently crf does quite well.  On the doom9 thread, some people,
including akupenguin, say that crf is not worse than 2pass.
 
 OTOH, some guides I've seen say that some options don't really work with
crf, e.g. trellis=1.  (Also, some say that trellis and dct_decimate don't
work well together, so I usually use trellis=1:no_dct_decimate).  Since I
usually archive to dvd+r, I tend to use crf to see what kind of ballpark
bitrate I'm going to need (with crf=18 or 20, usually), then plan what all
I'm going to try to fit onto a dvd.  This is the biggest problem: do I group
movies with the same director, the same genre, the same year, or what.  And
if I have a good copy of one movie and a crappy looking copy of another,
I might find a better copy of the poor-looking one, so one of the movies on
the disc would be obsolete.  I usually keep movies like that on my hard
drive, and only burn HD quality stuff, because it's so big.  (and because it
takes up a whole disc by itself, thus making the decision trivial.)
Sometimes I'll transcode to 2.2GB and put 2 movies on a dvd, if they
compress well and I don't like the movie enough to want a very high qual copy.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter at cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC