But I'm wondering if there's a way to determine a "good" target bitrate …
A good target bit rate is the bit rate that either:
- is supported by the network you're streaming the material from (e.g. a 3G network, home WiFi, etc.), which is pretty easy to calculate
- looks good to you, which is a very subjective measure
22 Mbit/s or 45 Mbit/s are indeed quite high for the average user, and especially for already compressed video like h.264. You could definitely go ahead and reduce the bit rate to a "sane" value, always with regards to how much storage capacity you can afford and how much quality you want to lose.
You could also resize 1080p video to 720p if you don't really need the size or don't have the processing capability to edit it.
… or if there's any point in trying to do variable bitrate
The point of constant bit rate is to adapt to a streaming media scenario where there's a bottleneck that limits the maximum bit rate of the transmitted video. In today's multimedia world, this doesn't necessarily make sense anymore.
When you squeeze a video into a constant amount of bits per second, you basically tell an encoder to always use the same amount of bits to encode the same time frame. Is that the best approach? As you may have guessed by now, it's not. Quoting the CRF Guide from Handbrake (I will come back to this later):
The eye perceives more detail in still objects than when they're in motion. Because of this, a video compressor can apply more compression (drop more detail) when things are moving, and apply less compression (retain more detail) when things are still. Subjectively, the video will seem to have higher quality.
So, it does make sense to use variable bit rate whenever you can. It will make the video look better, even at the same file size of a constant bit rate video.
Even more so, most encoders – the most famous one being x264 – often perform very bad when you tell them to use a constant bit rate. It's better to give them a bit more "freedom" in the sense of how many bits they want to spend on a frame. After all, that's the job of the encoder, and not you. And that's called "constant quality".
Enough of that – what does that mean in practice? If you use FFmpeg to encode videos, then you're already using a good enough tool. If you now also have x264 installed, and use the latest version of both, then you're using one of the best encoders that's currently available for free. Instead of encoding with a fixed bit rate, let x264 choose how much it wants to spend. Do this by using the Constant Rate Factor option.
In a very simple case this means setting a value between 17 and 23. I choose MP4 as output container instead of MOV because there are better tools for remultiplexing available:
ffmpeg -i input.mov -c:v libx264 -crf 22 output.mp4
The lower the value, the better the quality, and the larger the output. Vice versa, the higher, the lower the quality. At the same time, you will of course reduce the average bit rate needed. Check the x264 encoding guide for more info about ffmpeg.
Your task is now to find a CRF value that:
- reduces the overall bit rate to the point you can afford
- doesn't reduce the quality too much, so that the video still looks good
Yes, this involves a lot of encoding and trial-and-error, but this is daily business when you're tuning and encoding video.
Oh, and if you don't like the command line, Handbrake is a free, cross-platform tool that does exactly the same. It even has a CRF slider:
According to YouTube › Help articles › Video encoding › Suggested resolutions and bitrates
the preferred resolutions are:
- 1080p: 1920x1080
- 720p: 1280x720
- 480p: 854x480
- 360p: 640x360
- 240p: 426x240
Of these, 360p, 720p and 1080p have both dimensions as multiples of 4. The smallest one of them is 360p. If your encoder creates something slightly smaller than those, the player app is supposed to automatically add suitable letterboxing without this affecting the published file.
However, it is possible (I can't find any good, recent references) that Youtube re-encodes everything that is uploaded, in which case the quality will always be a bit worse on the published video than on your uploaded file. I would choose to encode the video exactly after the specs here to minimise the likelihood of meaningless transcoding. (Not exact bitrates, though.)
Edit:
Sorry, I don't have the experience to reasonably answer the revised question.
Best Answer
My gut says that your camera's using MJPEG with some kind of PCM audio. To say it's inefficient as a storage codec is being charitable. I'll bet it was relatively easy for Canon to implement in firmware though.
As far as "something else" to compress to, MPEG-4 AVC (h.264) is the current king of popular codecs. For the moment. It's also hard to go wrong with MPEG-2, the codec used on DVDs. It requires a higher bitrate, but gives you files that you can very easily drop onto DVDs without further re-compression. MPEG-4 SP/ASP (XviD, DivX, etc.) fall in an odd space between the other two. Most software/devices that can play back XviD can also play back h.264 which has a higher quality at a given bitrate, but it lacks the future that h.264 does and the widespread availability and implementations of MPEG-2. There's also the new WebM format from Google, which is On2's VP8 codec with Vorbis audio in a Matroska (subset?) container.
For audio, it's best decided upon once you pick your container and codec. If you're creating a DVD-ready format, you'll want to stick with something like AC3, MPEG-1 Layer 2, or even PCM. If you aim at a more future ready Matroska file with h.264, you can use MP3 or AAC easily. WebM specifies Vorbis.
As far as parameters go, you'll have to tinker a bit until you hit on a balance that you like yourself. A good encoder frontend like Handbrake will probably give you acceptable results with default (or close to default) settings.