MetavidWiki extension has been written to take advantage of some of the scalability features of mediaWiki. So performance should be scalable in the same way that mediaWiki scales. (ie use a php accelerator, memchache, squid proxies, mysql slaves & masters etc). So while its requirements are certainly higher than just vanilla mediaWiki (metavidWiki also includes semantic mediaWiki)... it should scale in a similar way.
I can share the relative speed of the two ogg segmenting media serving solutions:
mod_annodex ... is not that scalable since it does not cache seek offsets and rewrites ogg pages as it sends out the stream. It takes around ~700ms for both a cold and hot seek segmented media serving.
oggz-chop .. is faster ~190ms for cold seek and since its just byte wise serving (does not rewrite media pages) the second request for that segment will come from OS RAM disk cache ie ~10ms so with a good raid and sizable amount of ram you could likely only be limited by the bandwidth of your media server.
oggz-chop is still kind of new but you can grab it from the svn at: http://svn.annodex.net/liboggz/trunk/src/tools/oggz-chop/ It has a few minor issues with a few frames freezes in VLC and possibly some audio sync issues with quick time component. I think Conrad/kfish may be soon addressing the above mentioned issues and pushing it into the Debian repos soon... I will have to check with him.
peace, --michael
Thanks, Michael.
On May 29, 2008, at 11:39 AM, Michael Dale wrote:
MetavidWiki extension has been written to take advantage of some of the scalability features of mediaWiki. So performance should be scalable in the same way that mediaWiki scales. (ie use a php accelerator, memchache, squid proxies, mysql slaves & masters etc). So while its requirements are certainly higher than just vanilla mediaWiki (metavidWiki also includes semantic mediaWiki)... it should scale in a similar way.
I can share the relative speed of the two ogg segmenting media serving solutions:
mod_annodex ... is not that scalable since it does not cache seek offsets and rewrites ogg pages as it sends out the stream. It takes around ~700ms for both a cold and hot seek segmented media serving.
oggz-chop .. is faster ~190ms for cold seek and since its just byte wise serving (does not rewrite media pages) the second request for that segment will come from OS RAM disk cache ie ~10ms so with a good raid and sizable amount of ram you could likely only be limited by the bandwidth of your media server.
oggz-chop is still kind of new but you can grab it from the svn at: http://svn.annodex.net/liboggz/trunk/src/tools/oggz-chop/ It has a few minor issues with a few frames freezes in VLC and possibly some audio sync issues with quick time component. I think Conrad/kfish may be soon addressing the above mentioned issues and pushing it into the Debian repos soon... I will have to check with him.
peace, --michael
MetaVid-l mailing list MetaVid-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/metavid-l