Last modified: 2011-02-25 05:30:40 UTC
Things we need are: 1: A fileformat parser to retrieve the metadata and determine the codecs used in the matroska files. 2: Support in Cortado 3: Split off the OggHandler player from the OggHandler filesupport, so that it can be shared by other mediatypes.
It seems getID3() is a PHP lib that claims to have matroska support. Investigating if we could reuse some of that to parse the metadata of mkv files. http://getid3.sourceforge.net/
Upload support and filetype recognition added in r70103.
So next to do is added a MatroskaHandler and a Matroska Metadataextracter + parser. It is probably also best is we move the 'player' functionality from OggHandler into a core VideoHandler, of which both OggHandler and MatroskaHandler would be children. Adding mdale and Tim to the ticket, since both seem relevant to such a move.
:: WebM support :: 1) Any update on metadata support in getID3? 1.5) We need to fallback to recent version of ffmpeg for thumbnails where the assets are WebM. i.e we need to deploy a recent version of ffmpeg. 2) I don't think support in cortado is that essential since the flash runtime should be supporting WebM natively and has much broader adoption and 'virtual machine consistency' than java. 3 ) I would promote the html5 player 'embedPlayer' that is part of TimedMediaHandler extension. It already has WebM support and capacity to switch among available playback engines. Its also well positioned to support the flash based playback with a consistent html5 like api. It has other important features like multilingual timed text, a consistent player interface, fullscreen, share this media embed code, credits screen etc. 4) I would add that transcoding and derivatives support is pretty essential. A single video asset should not be tied to its source upload format. Often users upload a HD source asset that causes confusing long buffer times when embedded in an article at 200px wide. We should transcode uploaded assets into both WebM and ogg formats at web stremable resolutions and let the client software automatically chose what will work best. i.e something like the TimedMediaHandler transcode support: http://prototype.wikimedia.org/s-9/index.php?title=Transcode%20Test This runs into the the classical bug 4421 where file extension does not match embed file but I don't see that as blocker to making progress here. I don't think it would be hard to add support for WebM to TimedMediaHandler since it already has a lot of the other pieces in place. But we need a process to review and make note of any thing that needs to be changed as a path towards deployment.
going to mark this as duplicate / similar to bug 27699 ( since Timed Media Handler supports WebM in the way we outline above ) *** This bug has been marked as a duplicate of bug 27699 ***
