[MPlayer-DOCS] [PATCH] new section: muxing

[The Wanderer]

Dominik 'Rathann' Mierzejewski wrote:

> On Tuesday, 12 April 2005 at 23:39, Guillaume Poirier wrote:
> 
>> Hi, Here's a new an improved patch that features Diego's
>> suggestions and Nico's tips.
>> In fact, not all of them as some (for instance -audio-demuxer 20
>> -rawaudio format=0xyyyy:channels=n:bitrate=m:rate=w) seem for the
>> time being a little to "hackist" for this document. Maybe they
>> should land in the FAQ...
>> 
>> Please comment and review for inclusion in -pre7.
> 
> I'm sure The Wanderer will add his 3 cents, too, but let's give it a
> try.

Well, it'd have taken me a bit longer, but since you mention it...

I'll start out by piggybacking on your own response, mostly to disagree
with a few things:

>> +<sect2 id="menc-feat-dvd-mpeg4-muxing">
>> +<title>Muxing</title>
>> +<para>
>> +  Now that you have your encoded video, you will more than likely want
> 
> Now that you have encoded your video, you will most likely want

I think the original was valid. It was using "encoded" as an adjective,
i.e. "video in encoded form as opposed to pre-encoding form", not as a
past-tense verb. I don't think there's anything really wrong with the
suggested change, but I also don't think there was anything wrong with
the original.

>> +  For example:
>> +  <screen>mencoder -oac copy -ovc copy  -o <replaceable>output_movie.asf</replaceable> -audiofile <replaceable>input_audio.mp2</replaceable> <replaceable>input_video.avi</replaceable> -of lavf -lavfopts format=asf</screen>
>> +  This will do the same thing as the previous example, except that
>> +  the output container whould be ASF.
> 
> ... the output container will be. Keep the same tense.

Not to mention the typo.

>> +  Although it is the most widely-supported container format after MPEG-1,
>> +  AVI also has some major drawbacks.
>> +  Perhaps the most obvious is the overhead.
>> +  For each chunk of the AVI file, 24 bytes are wasted on headers and
>> +  index.
>> +  This translates into a little over 5 MB per hour, or 1-2.5%
>> +  overhead for a 700 MB movie. This may not seem like much, but it could
>> +  mean the difference between being able to use 700 kbit/sec video or
>> +  714 kbit/sec, and every bit of quality counts.
>> +</para>
>> +
>> +<para>
>> +  In addition to gross inefficiency, AVI also has the following major
> 
> ... to this gross inefficiency, AVI has the ...

This is correct only if the described overhead problem is the only form
of gross inefficiency imputed to the format.

>> +<para>
>> +  With all of that said, <application>MEncoder</application> does not
>> +  support variable-fps output or Vorbis encoding.
> 
> "Having said all that, MEncoder does not even support"

I might say "currently support" or "currently even support" here.

>> +  Therefore, you may not see these as limitations if
>> +  <application>MEncoder</application> is the
>> +  only tool you will be using to produce your encodes.
>> +  However, it is possible to use <application>MEncoder</application>
>> +  only for the video encoding, and then use external tools to encode
> 
> "only for video encoding", without "the".

Not necessarily - this is equivalent to "only for encoding the video",
in parallel with the other part of the sentence. It could be made
clearer, if slightly clunkier, by using "only for the video part of the
encoding" - or "side" or "portion" or what-have-you.

>> +  the audio and mux it into another container format.
> 
> "encode audio".

See above.

>> +  older containers like AVI can not handle, on an extensible basis.
>> +  Matroska supports for example the storage of Variable Bitrate audio
> 
> Too elaborate and too complex.
> "For example, Matroska supports Variable..."

Also, you might want to separate out "Rate", or at least capitalize the
R ("BitRate", for better conformance with the succeeding acronym.
Similarly in the following cases.

>> +  content (VBR) without any hassles, Variable Framerates (VFR),
> 
> "hassles" seem too informal. I'd skip "without any hassles"
> altogether.

Or (alternatively, not necessarily better) use "difficulty" or
"difficulties" instead.

>> +  Chapters, attachment of files, Error Detection (EDC) and modern
> 
> "file attachments" to make the enumeration elements more compatible.

Also, is there any reason to capitalize "Chapters", since it isn't part
of an acronym? If it's just because "the rest of them are capitalized",
then by the same logic you should capitalize the file-attachment part as
well.

>> +  Unix platforms as well as <application>Windows</application>.
>> +  Matroska being an open standard, you may find other tools that suit
> 
> And here, too concise and - I think - ungrammatical.
> "Considering that Matroska is an open standard, you..."

Or "Given that" or even (although this is an obscure usage) "Being
that". The original was I think grammatically valid, but nonetheless
somewhat awkward.

>> +  you better, but since mkvtoolnix is the most common, and is supported
>> +  by the Matroska team itself, we will only conver its usage.
>> +</para>

"cover"

Also, I think there is excessive commage in the above sentence. To
retain the same divisions without using as many commas, I'd suggest
separating out "and is supported by the Matroska team itself" either by
hyphens or within parentheses.

>> +  <ulink url="http://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge-gui.html">
>> +  guide to mkvmerge GUI (mmg)</ulink>
>> +</para>
>> +
>> +<para>
>> +  You may also merge using the command line:
> 
> Merge what? "You may also merge source streams/files/whatever". And
> it'd be technically correct to say "multiplex" or "mux" instead.

While I agree that either would be more technically correct, I also
think that "merge" may be more accessible.

>> +  chapters, subtitles, spliting, etc...

"splitting"

>> +  Please have a look at the documentation of those applications for
>> +  more details.

Possibly "Please refer to" instead - less colloquial, and at least
equally clear.

> Phew. The Wanderer, your turn. ;)

I think I've probably covered most of it here, unless you snipped more
than I think you did; still, I'll go have a look at the rest now.

-- 
       The Wanderer

Warning: Simply because I argue an issue does not mean I agree with any
side of it.

A government exists to serve its citizens, not to control them.