Ticket #262 (closed enhancement: fixed)
play response=metafile support for Wowza-server
| Reported by: | Michiel.Schok | Owned by: | arjen |
|---|---|---|---|
| Priority: | major | Milestone: | MediaMosa 2.1 |
| Component: | Core | Version: | 2.1.4 |
| Keywords: | Cc: | ||
| MoSCoW: | Must Have | Estimated time after impact analysis: | |
| Related to project: | none | Tested: | yes |
| Accepted: | yes | Estimated Hours: |
Description
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.
