[MPlayer-DOCS] CVS: main/DOCS/xml/en encoding-guide.xml,1.8,1.9

[Guillaume POIRIER]

Hi,

On 8/15/05, The Wanderer <inverseparadox at comcast.net> wrote:
> Guillaume Poirier CVS wrote:
> 
> > +  Experience shows that NTSC contents are a lot more difficult to encode
> > +  given that there more elements to identify in the source.
> 
> This says that in the case that there are more elements to identify in
> the source, NTSC contents are a lot more difficult to encode. Is that
> what you meant?
> 
> (I'm going to be correcting at least one other thing - the missing
> comma, and perhaps "material is" instead of "contents are" - anyway, but
> if the above isn't what you meant I can rephrase it a bit at the same
> time.)

I really struggled here to make a good sentence here, and I'm not
surprised that it doesn't suit you as it doesn't suit me as well.

What I'm trying to say here is that on NTSC content, more elements
have to be identified on the source. If you don't make make that
preliminary work, your encode is guaranteed to either fail or look
terrible.

With PAL content, you just have one element to take into account:
interlacing, which won't make your encode fail it you don't take it
into account, it'll just look bad.


> >    In order to produce a suitable encode, you need to know the original
> >    format.
> >    Failure to take this into account will result in ugly combing
> > -  (interlacing) artifacts in your encode.
> > +  (interlacing) artifacts, duplicated or lost frames in your encode.
> 
> I'm having a hard time expressing exactly why (even though this time I
> know it precisely), but this phrasing of the list is broken. It expands
> to "(interlacing) artifacts frames, duplicated frames or lost frames",
> and the first of those three is not what you meant. If there were a
> third thing to be listed, then "(interlacing) artifacts, duplicated or
> lost frames, and/or <foo>" would fix the problem; failing that, then the
> best fix I see offhand is something like "Failure to take this into
> account will result in various flaws in your encode, including combing
> (interlacing) artifacts and duplicated or even lost frames.". That isn't
> completely satisfactory, but it's better than nothing.

Good, the last proposition suits me well. :-)


> >    Besides being ugly, the artifacts also harm coding efficiency:
> >    You will get worse quality per bitrate.
> 
> I don't know if I've mentioned it before - I think I must have, since I
> know I've seen this line - but I don't like the phrasing "per bitrate".
> The simplest fix would be to say "per unit bitrate" instead, but that's
> a more formal type of language not necessarily well suited to something
> whose tone is not explicitly technical; I'd prefer something else if
> such a thing can be found.

If I were to use "unit" here, I'd write smth such as: "You will get
worse quality per bitrate unit", which sounds better to me. :)


> > +<para>
> > +  Another way to tell if your source is telecined or not is to watch the
> > +  the source appending <option>-vf pullup -v</option> to your command line
> > +  to see how <option>pullup</option> matches frames.
> 
> Two problems here: duplicated "the" (beginning and end of line) and the
> fact that it suggests that you watch the source append an option, when
> most likely the source will not be able to affect options on its own. A
> better phrasing would be something like "watch the source with the -vf
> pullup command line option".

As you suggest later, it should be play (back) the source with the -vf
pullup -v command line option.


> > +  If the source is telecined, you should see on the console a 3:2 pattern
> > +  with <systemitem>0+.1.+2</systemitem> and <systemitem>0++1</systemitem>
> > +  alternating.
> > +  This technique has the advantage that you do not need to watch the
> > +  source to identify it, which could be useful if you wish to automate
> > +  the encoding procedure, or to carry out said procedure remotely via
> > +  a slow connection.
> 
> Given that you just recommended to watch the source as part of the
> suggested procedure, this seems a little inconsistent. I think the
> simplest fix would be to say "play" or perhaps "play back" in the
> earlier location, instead of "watch".
> 
> (Note that I am, of course, open to suggestions and/or objections on any
> of this; for most of it, that's why I bothered to post rather than just
> committing what I think is better.)

I also struggled here too. I agree that it should be "play (back) the
source" earlier, and keep "watch" here. I don't see what I could
suggest here that would be significantly better.

Thanks,

Guillaume

-- 
A legend is an old man with a cane known for
what he used to do. I'm still doing it.
  -- Miles Davis