$ ffmpeg -i source-file.foo -ss 0 -t 600 first-10-min.m4v
$ ffmpeg -i source-file.foo -ss 600 -t 600 second-10-min.m4v
$ ffmpeg -i source-file.foo -ss 1200 -t 600 third-10-min.m4v
...
Wrapping this up into a script to do it in a loop wouldn't be hard.
Beware that if you try to calculate the number of iterations based on the duration output from an ffprobe call that this is estimated from the average bit rate at the start of the clip and the clip's file size unless you give the -count_frames argument, which slows its operation considerably.
Another thing to be aware of is that the position of the -ss option on the command line matters. Where I have it now is slow but accurate. The first version of this answer gave the fast but inaccurate alternative. The linked article also describes a mostly-fast-but-still-accurate alternative, which you pay for with a bit of complexity.
All that aside, I don't think you really want to be cutting at exactly 10 minutes for each clip. That will put cuts right in the middle of sentences, even words. I think you should be using a video editor or player to find natural cut points just shy of 10 minutes apart.
Assuming your file is in a format that YouTube can accept directly, you don't have to reencode to get segments. Just pass the natural cut point offsets to ffmpeg, telling it to pass the encoded A/V through untouched by using the "copy" codec:
$ ffmpeg -i source.m4v -ss 0 -t 593.3 -c copy part1.m4v
$ ffmpeg -i source.m4v -ss 593.3 -t 551.64 -c copy part2.m4v
$ ffmpeg -i source.m4v -ss 1144.94 -t 581.25 -c copy part3.m4v
...
The -c copy argument tells it to copy all input streams (audio, video, and potentially others, such as subtitles) into the output as-is. For simple A/V programs, it is equivalent to the more verbose flags -c:v copy -c:a copy or the old-style flags -vcodec copy -acodec copy. You would use the more verbose style when you want to copy only one of the streams, but re-encode the other. For example, many years ago there was a common practice with QuickTime files to compress the video with H.264 video but leave the audio as uncompressed PCM; if you ran across such a file today, you could modernize it with -c:v copy -c:a aac to reprocess just the audio stream, leaving the video untouched.
The start point for every command above after the first is the previous command's start point plus the previous command's duration.
For ffmpeg, I always recommend using -sameq. During testing you can create a smaller test source. I assume 420x350 is lower resolution than the source. Try creating a source matching this to speed up testing.
ffmpeg -i "$in" -sameq -s 420x350 -an "$testin"
Where $testin is a filename with the same extension as $in. ffmpeg should keep the video codec and container the same, but drop the audio stream and drop the resolution. This will speed up testing since the source video will be a little smaller and you can just focus on making the codec conversion work well. I can't find -me_range documented in my ffmpeg. I would focus on playing with different values of -b and -r and use of -sameq until you get an output file size and quality you want.
ffmpeg -i "$testin" -sameq -r 20 -b 270k "$out"
Best Answer
You are using the wrong tool for the job. Instead of piping the output into OpenSSL, write the output to a file which is located on an encrypted filesystem. Encrypted filesystems are designed for random access, file encryption tools such as
openssl encrarely are.Furthermore
openssl encis bad crypto and should never be used. You're using DES3, which while still legally admissible by some standards is strongly deprecated in favor of AES. And the worst bit is that the wayopensslderives a key from a password is ridiculously bad — it doesn't use a proper key stretching function, so brute-forcing through passwords is easy. Using theopensslcommand line tool for encryption is hard to do right and is never the best tool for the job. Just forget thatopensslexists and use proper tools for the job, e.g. LUKS for full disk encryption, Ecryptfs for home directory encryption, gpg or 7z for per-file encryption. Even EncFS to mount an encrypted directory, while flawed, is a lot less broken thanopenssl.