[MPlayer-DOCS] [PATCH] Choosing the video codec
The Wanderer
inverseparadox at comcast.net
Tue Dec 27 17:39:01 CET 2005
On 12/27/2005 04:33 AM, Guillaume Poirier wrote:
> The Wanderer wrote:
>
>> On 12/26/2005 06:02 PM, Guillaume POIRIER wrote:
>>
>>> +<sect2 id="menc-feat-dvd-mpeg4-codec">
>>> +<title>Choosing the video codec</title>
>>> +
>>> +<para>
>>> + Choosing the video codec to use depends on several factors, some of
>>> + which widely depend on personal taste and technical constraints.
>>
>> As this is phrased, you are saying a verb ("to choose") depends on
>> something. To the best of my ability to assess matters at the
>> moment, I believe that only a noun can be used with "depend" like
>> that. Technically speaking what you mean is something like "Which
>> video codec(s) would be good choices to use depends on" et cetera -
>> I would not recommend that exact phrasing, because it's awkward
>> enough on its own, but it avoids the base problem. Do you see what
>> I mean?
>
> No, I'm afraid I don't.
Okay. The form you have can be condensed to "Verbing ... depends on ...
plural noun", that is, "Choosing ... depends on ... factors". While this
*may* be a valid usage, what it would mean is that "the ability to
choose ... depends on ... factors", which is not what you intend.
Saying "Jumping ... depends on ... dogs" would either be meaningless or
mean that "in order to jump, there must be dogs".
A form of "Noun ... depends on ... noun", i.e. "Security ... depends on
... the dog", is valid. Similarly, I now think that "Verbing ... depends
on ... verb phrase" may be valid - i.e., "Jumping ... depends on ...
being able to stand" (or is that latter actually a noun phrase??).
The problem, as I now think I understand it, is that you are using
"depend on" to mean roughly "vary according to", but are using it in a
grammatical context in which it means some variant of "rely for its very
existence upon".
>> In this case I do not think that the double use of "depend" in such
>> quick succession is a problem.
>
> Ok, then I'll just leave it as it is now. I don't see how I'd fix
> this sentence anyhow without re-writing it.
Neither do I, but for the other reason cited above, I do think it needs
to be done. (It's not necessarily worth holding up the main commit over,
though.)
>>> + <listitem><para>
>>> + <emphasis role="bold">Best quality per fps</emphasis>:
>>
>> Per FPS?? What does the frame rate have to do with quality, unless
>> it's 'way too low (say, below 20 frames per second)?
>>
>> Unless you're referring to "the time it takes to encode" or "the
>> time it takes to decode", in which case all I can say is that this
>> is a very strange way of talking about matters.
>
> I meant "Best quality per encoding time", so the version I'll commit
> will use that form.
That works, then.
>>> + If you are after blazing speed you should stick around the default
>>> + settings of the video codec (which doesn't mean you should not experiment
>>> + with some of the options which are mentioned in other sections
>>> + of this guide).
>>
>> "stick around" - does that mean "stay in the close vicinity of", as
>> in, "do not adjust very far from"? Or do you simply mean "stick
>> with"?
>
> I meant "stay in the close vicinity of the defaults"
In that case "stay close to" works better than "stick around".
> BTW, I think that while this advice is appropriate for XviD and x264,
> I'd not advise anyone to use lavc's default.
>
> I hope a patch to change lavc's defaults would be ok.
With me, probably yes, but I don't have any say in that matter. It most
likely depends very strongly on what you'd want to change them *to*, and
what your justifications were.
>> I'll note that x264 can, in fact, be undesirable if the video will
>> have to be played back on a slower system - not every computer out
>> there is remotely powerful enough to play back even reasonably
>> low-resolution H.264 at full speed.
>
> Yes, that's right, but I mentionned that earlier.
Okay - I must have missed noticing that in this context.
--
The Wanderer
Warning: Simply because I argue an issue does not mean I agree with any
side of it.
Secrecy is the beginning of tyranny.
More information about the MPlayer-DOCS
mailing list