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

[The Wanderer]

Guillaume Poirier wrote:

> +  This would merge the video file <replaceable>input_video.avi</replaceable>
> +  and the audio file <replaceable>input_audio.mp2</replaceable>
> +  the AVI file <replaceable>output_movie.avi</replaceable>.
> +  This command works with MPEG-1 layer I and II audio, WAV and few other
> +  audio formats too.

"a few other"

I also would prefer to have a comma after WAV, but I believe Diego has
objected to similar commas recently, so he'd probably veto that.

> +  MEncoder features an experimental support of
> +  <systemitem class="library">libavformat</systemitem> which is a
> +  library from the FFmpeg project that supports muxing and demuxing
> +  a large variety of containers.

Missing comma after "libavformat".

The indefinite article "an" is inappropriate. I'd probably say "MEncoder
features experimental support for libavformat, which is", or similar.

> +  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.

As noted in my previous mail, that's "would". As Dominik noted, you have
a tense inconsistency between "will" and "would", although I forget the
names of the respective tenses...

Nice catch, by the way, Dominik; I'd probably have skimmed right past
it.

> +  Please note that this support is highly experimental (but getting
> +  better every day), and will only work if you compiled
> +  <application>MPlayer</application> with the support of
> +  <systemitem class="library">libavformat</systemitem> enabled (which
> +  means that a pre-packaged binary version won't work most of the
> +  time.

Missing close-paren after "time". See also Dominik's rephrasing suggestion.

> +  Only fixed-fps content can be stored. This is particularly limiting
> +  if the original material you want to encode is mixed content, for
> +  example a mix of NTSC video and film material.

Should "FPS" be capitalized, or not? I think the standard we've settled
on is that it should. The same usage occurs in at least one place below,
as well.

> +  Actually there are hacks that can be used to store mixed-framerate
> +  content in AVI, but they increase the (already huge) overhead
> +  fivefold or more so they are not practical.

This doesn't flow quite right. I see at least two ways to fix it, but
only one which doesn't introduce other problems which would need to be
fixed: "fivefold or more and so are not practical", i.e., insert an
"and" and drop the "they".

> +  Unfortunately, the most efficient codec, Vorbis, does not meet
> +  either of these requirements.

I'm not sure the first comma here is appropriate, but I'm also not sure
it isn't. Any opinions on what having or not having it does to sentence
flow, here?

> +  The tools required to create Matroska files are called
> +  <application>mkvtoolnix</application>, and are available on most
> +  Unix platforms as well as <application>Windows</application>.

Perhaps "are collectively called"? Unless that is in fact the name of
the only program involved (which I don't think it is), in which case you
want to say "tool", singular.

> +  Matroska being an open standard, you may find other tools that suit
> +  you better, but since mkvtoolnix is the most common, and is supported
> +  by the Matroska team itself, we will only conver its usage.

See the comment in my previous response.

-- 
       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.