[MPlayer-DOCS] [PATCH] improving encoding guide

[Guillaume Poirier]

Hi,

The Wanderer wrote:

> Guillaume POIRIER wrote:
>
>> Hi,
>>
>> Le mardi 15 mars 2005 à 22:56 +0100, Guillaume Poirier a écrit :
>>
>>> Here's an updated version. It contains more things than previous
>>> version.
>>>
>>> I'm now looking for people with some language knowledge, (such as
>>> The Wonderer, who has been of a great help for me this summer)
>>
>>
>
> Nice typo... it's not my name, but I'll admit I do a good bit of that.

;-)

> I might actually have gotten around to this sooner if I'd noticed this
> comment specifically... for some while now, I've been mostly almost
> skimming the mailing lists, sometimes barely reading each message.

Would it be okay if I were sending a copy of my patches to you in
private mail next time?


>>
>> Here's the same patch spell-checked.
>> Any comments are very welcome!
>
>
> Use a spellchecker, Luke...
>
> (After writing the below:)
>
> Phew! Quite a bit more than I expected there to be. Hopefully this is
> helpful, rather than being unnecessarily nitpicky...

Yes, This IS helpful. Thank you so much for your time!


>>    <option>vqmin</option>, which is 2 by default). As soon as you specify a
>>    low enough bitrate that <systemitem
class="library">libavcodec</systemitem>
>>    is forced to use a higher quantizer, then you're almost certainly ruining
>> -  the quality of your video. In general, you should avoid CBR altogether if
>> -  you care about quality.
>> +  the quality of your video.
>> +  In order to avoid that, you should probably down-scale your
video, according
>> +  to the method that will be exposed later.
>> +  In general, you should avoid CBR altogether if you care about quality.
>
>
>
> I don't understand what "the method that will be exposed later" means.

I'm referring to the technique to compute the right scaling factor,
later on the guide.
Maybe I should put a hyperlink to it to make this connection more obvious?


>> +  You can also extract the AC3 stream in order to mux it into
containers such
>> +  as Nut, Matroska or OGM.
>
>
>
> This is a minor point: the NUT standard does not yet appear to specify
> what the correct capitalization is. Some places in what documentation
> there is (both in FFmpeg and in MPlayer) use "NUT", others "Nut", and I
> think a few even use "nut". I don't know what the 'correct' form is,
> since as I said it doesn't appear to have been specified anywhere;
> however, I've seen recent commits using NUT, and it would be nice if we
> could standardize on a single form.

I consider the manpage to be the reference in terms of consistency and
nits, so as I reads "NUT", I settled for NUT, even if I'm pretty sure
that when it'll be popular, it will probably be called Nut, just like
OGM that became Ogm or ogm in the mind of people.


>> +  For example:
>> +  <screen>oggenc -q1 destination_sound.wav</screen>
>> +  will encode destination_sound.wav with the encoding quality 1, which is
>> +  somewhat equivalent to 80Kb/s, and is the minimum quality at which you
>> +  should encode if you care about quality.
>
>
>
> "somewhat" > "roughly"
>
> The use of "at which you should" is the grammatically correct form,
> since the alternative is to end a sentence segment with a preposition,
> and I'm not going to recommend changing it - but it is also not standard
> everyday usage, and as such feels a little awkward. As I said, that's
> because standard usage is incorrect, but I felt the point might be worth
> mentioning.

Great! It's good to know that my English is not as crappy as I think
it is when I re-read some of my posts on the ML. ;-)


>> +  That would probably be nice, but unfortunately hard to implement
as different
>> +  encoding options yield different qualities depending on the
source material.
>> +  Anime and live action are for example two very different materials that
>> +  require different care.
>
>
>
> "different care" seems a little odd to me, but I've got no suggestions
> to improve it, and I'm not completely certain that it needs to be
> changed at all.

I had the same problem. I wanted to translate into English a sentence
such as "les dessins animés et les films sont deux types très
différents, qui nécessitent chacun une attention particulière"... but
I just couldn't find an equivalent that wouldn't be a literal
translation.



>> +<listitem><para>
>> +  <emphasis role="bold">vlelim, vcelim</emphasis>: Sets the single
coefficient
>> +  elimination threshold for luminance chroma planes.
>
>
>
> I could be remembering wrong, but aren't luminance and chroma different
> things? If so, you probably accidentally omitted the word "and" in the
> middle there.

You're right, they are indeed different, and an "and" is missing.


>> +  These are encoded separately in all mpeg-like algorithms.
>
>
>
> Should "mpeg" be lowercase here, or not?

I corrected it to uppercase.


>> +</para></listitem>
>> +
>> +<listitem><para>
>> +  <emphasis role="bold">psnr</emphasis>: doesn't affect the actual encoding,
>> +  but writes a log file giving the type/size/quality of each frame, and
>> +  summarizes psnr at the end.
>
>
>
> "prints a sumary of", perhaps?
>
> It might be worthwhile to explain what PSNR stands for, since not
> everyone is necessarily going to know that, and it isn't trivial to
> figure out from context. (I got it, but I'm good with acronyms.)


;-) I figured that too when  re-reading it to correct the mistake you
pointed out just above.


Well, Thanks a lot The Wanderer!

I imagine that this was quite a lot of work, and I really appreciate your input.

I think I'll commit this part tomorrow and submit the section about
muxing with third parties software soon after, so that the patch will
be smaller. As you said, this was quite a big patch, so I guess it's
better to break the re-witting of the guide in several chunks.

Thanks,

Regards,
Guillaume