On Fri, Jan 20, 2012 at 08:35:49PM +0200, Martin Storsjö wrote:
>
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -142,6 +142,67 @@ Note also that the pattern must not necessarily contain
> "%d" or
>
> +@section mov/mp4/ismv
> +
> +The mov/mp4/ismv muxer supports fragmentation. Normally, a mov/mp4
> +file has all the metadata about all packets stored in one location
I'd capitalize the format names. You possibly want to keep the names
of the muxers spelled in the way they are used on the command line.
Same below..
> +it isn't properly finished), and it requires less memory if writing
> +very long files (since writing normal mov/mp4 files stores info about
s/if writing/when writing/
> +@table @option
> +@item -movflags frag_keyframe
> +Start a new fragment at each video keyframe
.
> +@item -frag_duration @var{duration}
> +Make fragments that are @var{duration} microseconds long.
> +@item -frag_size @var{size}
> +Make fragments that contain up to @var{size} bytes of payload data.
"Make" is somewhat generic, I'd replace by "write" or "generate" or
"create".
> +Additionally, the way the output file is written can be adjusted with
> +a few other options:
s/with/through/
> +@table @option
> +@item -movflags empty_moov
> +Write an initial moov atom directly at the start of the file, without
> +describing any samples in it. Normally, a normal mdat/moov pair is
Normally, a normal? Sounds like you can drop "normal".
> +written at the start of the file, as a normal mov/mp4 file, containing
"normal" again - replace "Normally" by "Generally".
> +@item -movflags separate_moof
> +Write a separate moof (movie fragment) atom for each track. Normally,
> +packets for all tracks are written in a moof atom (which is slightly
> +more efficient), but with this set, the muxer writes one moof/mdat
with this option set
> +Smooth Streaming content can be pushed in real time to a publishing
> +point on IIS with this muxer. An example of doing this:
muxer. Example:
Diego
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
