So I committed ~basic~ derivate code support for oggHandler in r54550
(more solid support on the way)
Based input from the w...@home thread; here are updated target
qualities expressed via the firefogg api to ffmpeg2thoera
Also j^ was kind enough to run these settings on some sample input files:
http://firefogg.org/j/encoding_samples/ so you can check them out there.
We want to target 400 wide for the web stream to be consistent with
archive.orgs which encodes mostly to 400x300 (although their 16:9 stuff
can be up to 530 wide) ...
Updated mediaWiki firefogg integration and the stand alone encoder app
these default transcode settings. in r54552 r54554 (should be pushed
out to http://firefogg.org/make shortly ... or can be run @home with a
trunk check out at:
/js2/mwEmbed/example_usage/Firefogg_Make_Advanced.html
anyway on to the settings:
$wgDerivativeSettings[ WikiAtHome::ENC_SAVE_BANDWITH ] =
array(
'maxSize'= '200',
'videoBitrate'= '164',
'audioBitrate'= '32',
'samplerate'= '22050',
'framerate'= '15',
'channels'= '1',
'noUpscaling'= 'true'
);
$wgDerivativeSettings[ WikiAtHome::ENC_WEB_STREAM ] =
array(
'maxSize'= '400',
'videoBitrate'= '544',
'audioBitrate'= '96',
'noUpscaling'= 'true'
);
$wgDerivativeSettings[ WikiAtHome::ENC_HQ_STREAM ] =
array(
'maxSize' = '1080',
'videoQuality'= 6,
'audioQuality'= 3,
'noUpscaling'= 'true'
);
--michael
Brion Vibber wrote:
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
