[FFmpeg-devel] doc/faq: replace "Mo" with Bytes

Submitted by Werner Robitza on Sept. 18, 2017, 1:27 p.m.

Details

Message ID 1505741267-4685-1-git-send-email-werner.robitza@gmail.com
State New
Headers show

Commit Message

Werner Robitza Sept. 18, 2017, 1:27 p.m.
Replaces French "Mo" with "Bytes".

Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
---
 doc/faq.texi | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

Comments

Ricardo Constantino Sept. 18, 2017, 1:45 p.m.
On 18 September 2017 at 14:27, Werner Robitza <werner.robitza@gmail.com>
wrote:

> Replaces French "Mo" with "Bytes".
>
> Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
> ---
>  doc/faq.texi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/doc/faq.texi b/doc/faq.texi
> index ff35c89..07af0d9 100644
> --- a/doc/faq.texi
> +++ b/doc/faq.texi
> @@ -450,8 +450,9 @@ work with streams that were detected during the
> initial scan; streams that
>  are detected later are ignored.
>
>  The size of the initial scan is controlled by two options:
> @code{probesize}
> -(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s).
> For
> -the subtitle stream to be detected, both values must be large enough.
> +(default 5000000 Bytes) and @code{analyzeduration} (default 5,000,000 µs =
> +5 s). For the subtitle stream to be detected, both values must be large
> +enough.
>

Why not MB instead? It's still more readable than Bytes/B.


>
>  @section Why was the @command{ffmpeg} @option{-sameq} option removed?
> What to use instead?
>
Werner Robitza Sept. 18, 2017, 1:55 p.m.
On Mon, Sep 18, 2017 at 3:45 PM, Ricardo Constantino <wiiaboo@gmail.com> wrote:
> Why not MB instead? It's still more readable than Bytes/B.

Because -probesize takes the number of Bytes by default.
Nicolas George Sept. 18, 2017, 3:06 p.m.
Le jour du Génie, an CCXXV, Werner Robitza a écrit :
> Replaces French "Mo" with "Bytes".
> 
> Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
> ---
>  doc/faq.texi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

No. "Octet" originated from French but has been imported to English
because "byte" causes a lot of confusion with "bit". RFCs and other
texts where accuracy matters have started to adopt it since long ago
(although not all of them did consistently, of course). With audio-video
tools, the confusion with bits is quite frequent, that makes a good
reason to take all steps to avoid it.

Regards,
Werner Robitza Sept. 18, 2017, 4:54 p.m.
On Mon, Sep 18, 2017 at 5:06 PM, Nicolas George <george@nsup.org> wrote:
>
> Le jour du Génie, an CCXXV, Werner Robitza a écrit :
> > Replaces French "Mo" with "Bytes".
> >
> > Signed-off-by: Werner Robitza <werner.robitza@gmail.com>
> > ---
> >  doc/faq.texi | 5 +++--
> >  1 file changed, 3 insertions(+), 2 deletions(-)
>
> No. "Octet" originated from French but has been imported to English
> because "byte" causes a lot of confusion with "bit". RFCs and other
> texts where accuracy matters have started to adopt it since long ago
> (although not all of them did consistently, of course). With audio-video
> tools, the confusion with bits is quite frequent, that makes a good
> reason to take all steps to avoid it.

Hum, okay. Didn't think this was a conscious decision. I frequently
see speakers of French using "Mo" without knowing that (most of) the
rest of the world barely has an idea what this is. And I do understand
that octets are used in networking and RFCs – but then as "octet" –,
and that you may want to avoid ambiguity.

But this is literally the only place in FFmpeg's documentation where
this abbreviation is used, with more than 50 mentions of "Byte" in
http://ffmpeg.org/ffmpeg-all.html alone. So… is "-probesize" is doing
something special?
Nicolas George Sept. 18, 2017, 4:57 p.m.
Le jour du Génie, an CCXXV, Werner Robitza a écrit :
> Hum, okay. Didn't think this was a conscious decision. I frequently
> see speakers of French using "Mo" without knowing that (most of) the
> rest of the world barely has an idea what this is. And I do understand
> that octets are used in networking and RFCs – but then as "octet" –,
> and that you may want to avoid ambiguity.

I would not mind a patch that expands Mo into mega-octet.

Nor a patch to replace all occurrences of byte, for that matter.

Case in point: the Vim spell file for English knows mega-octet.
(Hum, not sure if it knows it or mega and octet separately.)

Regards,
Werner Robitza Sept. 20, 2017, 3:54 p.m.
On Mon, Sep 18, 2017 at 6:57 PM, Nicolas George <george@nsup.org> wrote:
> I would not mind a patch that expands Mo into mega-octet.

Attached with that change.

(Sorry, earlier mail didn't go to the entire mailing list.)

Patch hide | download patch | download mbox

diff --git a/doc/faq.texi b/doc/faq.texi
index ff35c89..07af0d9 100644
--- a/doc/faq.texi
+++ b/doc/faq.texi
@@ -450,8 +450,9 @@  work with streams that were detected during the initial scan; streams that
 are detected later are ignored.
 
 The size of the initial scan is controlled by two options: @code{probesize}
-(default ~5 Mo) and @code{analyzeduration} (default 5,000,000 µs = 5 s). For
-the subtitle stream to be detected, both values must be large enough.
+(default 5000000 Bytes) and @code{analyzeduration} (default 5,000,000 µs =
+5 s). For the subtitle stream to be detected, both values must be large
+enough.
 
 @section Why was the @command{ffmpeg} @option{-sameq} option removed? What to use instead?