On Thu, Aug 6, 2009 at 8:17 PM, Gregory Maxwell<gmaxw...@gmail.com> wrote: > On Thu, Aug 6, 2009 at 8:00 PM, Michael Dale<md...@wikimedia.org> wrote: >> 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 > > Not using two-pass on the rate controlled versions? > > It's a pretty consistent performance improvement[8], and it eliminates > the "first frame blurry" issue that sometimes comes up for talking > heads. (Note, that by default two-pass cranks the keyframe interval to > 256 and makes the buf-delay infinite. So you'll need to set those to > sane values for streaming).
I see r54562 switching to two-pass, but as-is this will produce files which are not really streamable (because they streams can and will burst to >10mbits even though the overall rate is 500kbit or whatever is requested). We're going to want to do something like -k 64 --buf-delay=256. I'm not sure what key-frame interval we should be using— Longer intervals lead to clearly better compression, with diminishing returns over 512 or so depending on the content... but lower seeking granularity during long spans without keyframes. The ffmpeg2theora defaults are 64 in one-pass mode, 256 in two-pass mode. Buf-delay indicates the amount of buffering the stream is targeting. I.e. For a 30fps stream at 100kbit/sec a buf-delay of 60 means that the encoder expects that the decoder will have buffered at least 200kbit (25kbyte) of video data before playback starts. If the buffer runs dry the playback stalls— pretty crappy for the user's experience. So bigger buff delays either mean a longer buffering time before playback or more risk of stalling. In the above (30,60,100) example the client would require 2 seconds to fill the buffer if they were transferring at 100kbit/sec, 1 second if they are transferring at 200kbit/sec. etc. The default is the same as the keyframe interval (64) in one pass mode, and infinite in two-pass mode. Generally you don't want the buf-delay to be less than the keyframe interval, as quality tanks pretty badly at that setting. Sadly the video tag doesn't currently provide any direct way to request a minimum buffering. Firefox just takes a guess and every time it stalls it guesses more. Currently the guesses are pretty bad in my experience, though this is something we'll hopefully get addressed in future versions. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
