[FFmpeg-user] Tactics for file splitting: Does -fs work when copying?

[Andrew Skretvedt]

On 2014-Jan-24 04:21, Carl Eugen Hoyos wrote:
> Andrew Skretvedt <andrew.skretvedt <at> gmail.com> writes:
>
>> ffmpeg -i input.avi -c copy -fs 600MiB output_part1.avi
>
> $ ffmpeg -i input.avi -c copy -fs 600M output_part1.avi
>
> (Where did you find "MiB"?)
>
> Carl Eugen
>

[SOLVED]

Carl, thanks, until you rewrote my command, I didn't understand that I 
was actually asking for 5 GB, not 600 MiB (human intuitive understanding 
vs. rote program parsing). Read on for in-depth discussion and 
suggestions for a documentation/UI improvement.

-----

Where did I find "MiB"? Here:

http://ffmpeg.org/ffmpeg.html

Section 5: Options
[opening paragraph, excerpted as follows]

If ’i’ is appended to the SI unit prefix, the complete prefix will be 
interpreted as a unit prefix for binary multiplies, which are based on 
powers of 1024 instead of powers of 1000. Appending ’B’ to the SI unit 
prefix multiplies the value by 8. This allows using, for example: ’KB’, 
’MiB’, ’G’ and ’B’ as number suffixes.

-----

Two items to raise here.

First, Carl, I see you suggested specifying a different suffix, just 
"M", instead of "MiB" as a reading of the documentation above might 
suggest as prudent for -fs. Testing with your suggestion produced the 
expected result! The file was limited to approximately 600 million bytes 
(great).

Second, the documentation might be reworded slightly. Do have a look at 
the paragraph I cited in the context of the full documentation. It 
suggests to me that this is a generic treatment applicable to all 
options which take a number. The number can be expanded by appending 
these suffixes. Disregarding any human factor, literally, adding a 'B' 
just multiplies the number by 8. But 'B' also implies 'bytes' or a human 
context of working with things sized in bytes, etc. (clearly, as Carl 
guessed right away where I was making my error). While this could be 
useful if the option you're working with operated at the level of 
individual bits (e.g. options controlling bitrates), when working with 
an option where bytes are already implied (as in -fs), proper use of the 
option gets counterintuitive.

-fs 600MiB

What do you suppose, reading that out of context, the user's intent was? 
Knowing -fs is for setting a limit to a file size, IMHO it's plain the 
user intended a file not more than 600*1024^2, or 600 mebibytes size.

A careful read of the documentation elucidates my mistake in using the 
option this way. I'd actually unwittingly specified 600*1024^2*8 bytes, 
or just about 4.7 GiB file size limit.

To get what I'd intended, I should have wrote my request for a 600 MiB 
limit as:

-fs 600Mi

So there's the rub. I think a caution in the documentation for the -fs 
and similar options, NOT to specify a 'B' suffix, would be in order. The 
error is totally mine, but in a human intuition sense, it's SO easy to 
make a mistake like this, wouldn't you agree?

Either adjust the documentation to highlight this, or perhaps adjust the 
coding of -fs and similar options to ignore any added 'B' when bytes are 
implied, or have the program ask the user to be more clear.

Even using verbose output didn't help me to catch my mistake, see here 
this output:

$ ffmpeg -v 9 -loglevel 99 -i input.avi -c copy -fs 10MiB test.avi


Input #0, avi, from 'input.avi':
   Duration: 00:14:15.28, start: 0.000000, bitrate: 879 kb/s
     Stream #0:0, 41, 1/25: Video: h264 (High) (H264 / 0x34363248), 
yuv420p, 640x480 [SAR 1:1 DAR 4:3], 1/50, 25 fps, 25 tbr, 25
tbn, 50 tbc
     Stream #0:1, 61, 1/12000: Audio: mp3 (U[0][0][0] / 0x0055), 44100 
Hz, stereo, s16p, 96 kb/s
Successfully opened the file.
Parsing a group of options: output file test.avi.
Applying option c (codec name) with argument copy.
Applying option fs (set the limit file size in bytes) with argument 10MiB.
Successfully parsed a group of options.
Opening an output file: test.avi.
File 'test.avi' already exists. Overwrite ? [y/N] y
Successfully opened the file.
Output #0, avi, to 'test.avi':
   Metadata:
     ISFT            : Lavf55.25.101
     Stream #0:0, 0, 1/25: Video: h264 (H264 / 0x34363248), yuv420p, 
640x480 [SAR 1:1 DAR 4:3], 1/25, q=2-31, 25 fps, 25 tbn, 25
tbc
     Stream #0:1, 0, 32/1225: Audio: mp3 (U[0][0][0] / 0x0055), 44100 
Hz, stereo, 96 kb/s
Stream mapping:
   Stream #0:0 -> #0:0 (copy)
   Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
No more output streams to write to, finishing.ime=00:10:39.60 bitrate= 
874.3kbits/s
frame=19184 fps=11162 q=-1.0 Lsize=   82681kB time=00:12:47.36 bitrate= 
882.7kbits/s
video:72516kB audio:8992kB subtitle:0 global headers:0kB muxing overhead 
1.438609%
0 frames successfully decoded, 0 decoding errors
[AVIOContext @ 04f531c0] Statistics: 10 seeks, 48656 writeouts
[AVIOContext @ 00272fc0] Statistics: 84596759 bytes read, 4 seeks


To highlight:
Applying option fs (set the limit file size in bytes) with argument 10MiB.

That suggested to me that ffmpeg understood what I was asking, yet I 
didn't get what I thought I should (actual limit 8-times larger than I 
thought I'd asked for). How about a callout, in this case like:
CAUTION: -fs takes its arguments in bytes; specifying 'B' multiplies 
your argument by 8, is that what you want? (83,886,080 bytes vs. 
10,485,760 bytes)

Thanks!
-Andrew