id,summary,reporter,owner,description,type,status,priority,milestone,component,version,resolution,keywords,cc,moscow,impact_analysis,related_to,tested,accepted,estimated_hours
262,play response=metafile support for Wowza-server,Michiel.Schok,arjen,"When using wowza (1.7 or 2.0) server for streaming content of flv or mp4 containers, the play-request returns a playlink where the protocol is RTMP.

At the moment (version 1.7.3), the &mode=metafile parameter on the /asset/{id}/play request yields the following result:
||container||result||
||flv||is not specified||
||mpeg||.qtl file with an rtmp-link within. Quicktime launches and complains because rtmp is not supported||

It would be nice if for both of these containers, the &mode=metafile would result in a smil-type file.
That file could then be used to instruct JW-player to play the file. See http://developer.longtailvideo.com/trac/wiki/Player5Formats#RTMPStreaming for an ultrashort example.

Ideally, what would be realized, is that an end-user is capable of
* on his own site,
* using an own JW-player,
* using a 'permanent EGA-link' which returns a MediaMosa metafile,
* have a streaming experience.

For instance, using the SURFmedia call 
http://www.surfmedia.nl/app/video/{asset_id}/play?format_id={mediafile_id}&mode=metafile returns to the client the metafile that VP-core generates with a 
{{{
[get] /asset/{asset_id}/play?mediafile_id={mediafile_id}&response=metafile&user_id=foo
}}}

On a POC-server at http://richmedia.showcase.surfnet.nl/20100108/ is a demo, which works after a manually obtained ticket is entered in the playlist.txt .
That playlist.txt in a smil-file, and should be 'generated' by the core.
",enhancement,closed,major,MediaMosa 2.1,Core,2.1.4,fixed,,,Must Have,,none,yes,yes,