On 8/3/09 9:56 PM, Gregory Maxwell wrote: [snip]
Based on 'what other people do' I'd say the low should be in the 200kbit-300kbit/sec range. Perhaps taking the high up to a megabit?
There are also a lot of very short videos on Wikipedia where the whole thing could reasonably be buffered prior to playback.
Something I don't have an answer for is what resolutions to use. The low should fit on mobile device screens.
At the moment the defaults we're using for Firefogg uploads are 400px width (eg, 400x300 or 400x225 for the most common aspect rations) targeting a 400kbps bitrate. IMO at 400kbps at this size things don't look particularly good; I'd prefer a smaller size/bitrate for 'low' and higher size/bitrate for "medium" qual.
From sources I'm googling up, looks like YouTube is using 320x240 for low-res, 480x360 h.264 @ 512kbps+128kbps audio for higher-qual, with 720p h.264 @ 1024Kbps+232kbps audio available for some HD videos.
http://www.squidoo.com/youtubehd
These seem like pretty reasonable numbers to target; offhand I'm not sure the bitrates used for the low-res version but I think that's with older Flash codecs anyway so not as directly comparable.
Also, might we want different standard sizes for 4:3 vs 16:9 material?
Perhaps we should wrangle up some source material and run some test compressions to get a better idea what this'll look like in practice...
Normally I'd suggest setting the size based on the content: Low motion detail oriented video should get higher resolutions than high motion scenes without important details. Doubling the number of derivatives in order to have a large and small setting on a per article basis is probably not acceptable. :(
Yeah, that's way tougher to deal with... Potentially we could allow some per-file tweaks of bitrates or something, but that might be a world of pain. :)
As an aside— downsampled video needs some makeup sharpening like downsampled stills will. I'll work on getting something in ffmpeg2theora to do this.
Woohoo!
There is also the option of decimating the frame-rate. Going from 30fps to 15fps can make a decent improvement for bitrate vs visual quality but it can make some kinds of video look jerky. (Dropping the frame rate would also be helpful for any CPU starved devices)
15fps looks like crap IMO, but yeah for low-bitrate it can help a lot. We may wish to consider that source material may have varying frame rates, most likely to be:
15fps - crappy low-res stuff found on internet :) 24fps / 23.98 fps - film-sourced 25fps - PAL non-interlaced 30fps / 29.97 fps - NTSC non-interlaced or many computer-generated vids 50fps - PAL interlaced or PAL-compat HD native 60fps / 59.93fps - NTSC interlaced or HD native
And of course those 50 and 60fps items might be encoded with or without interlacing. :)
Do we want to normalize everything to a standard rate, or maybe just cut 50/60 to 25/30?
(This also loses motion data, but not as badly as decimation to 15fps!)
This brings me to an interesting point about instant gratification: Ogg was intended from day one to be a streaming format. This has pluses and minuses, but one thing we should take advantage of is that it's completely valid and well supported by most software to start playing a file *as soon* as the encoder has started writing it. (If software can't handle this it also can't handle icecast streams). This means that so long as the transcode process is at least realtime the transcodes could be immediately available. This would, however, require that the derivative(s) be written to an accessible location. (and you will likely have to arrange so that a content-length: is not sent for the incomplete file).
Ooooh, good points all. :D Tricky but not impossible to implement.
-- brion