Create a receiver app for handling video sharing commands. Here is the command set I proposed (very similar to RTP protocol): Setup: send media url to remote screen. (direction: client to remote screen) { type: ’setup’, seq: <sequence number>, url: <video URL>, } Play: play media at current time, seek to given time if “start” is specified. (direction: client to remote screen) { type: ‘play’, seq: <sequence number>, sessionId: <session Id>, [start: <start time in ms>,] } Pause: pause media. (direction: client to remote screen) { type: ‘pause’, seq: <sequence number>, sessionId: <session Id>, } Teardown: stop media session. (direction: client to remote screen) { type: ‘teardown’, seq: <sequence number>, sessionId: <session Id>, } ACK: ack message for every command, corresponding command failed if “error” is specified. (direction: remote screen to client) { type: ‘ack’, seq: <sequnce number of received command>, sessionId: <session Id>, [error: <error message>,] }

(In reply to Shih-Chiang Chien [:schien] (UTC+8) (use ni? plz) from comment #0) > Play: play media at current time, seek to given time if “start” is > specified. (direction: client to remote screen) > { type: ‘play’, > seq: <sequence number>, > sessionId: <session Id>, > [start: <start time in ms>,] } > > Pause: pause media. (direction: client to remote screen) > { type: ‘pause’, > seq: <sequence number>, > sessionId: <session Id>, } > > Teardown: stop media session. (direction: client to remote screen) > { type: ‘teardown’, > seq: <sequence number>, > sessionId: <session Id>, } > > ACK: ack message for every command, corresponding command failed if “error” > is specified. (direction: remote screen to client) > { type: ‘ack’, > seq: <sequnce number of received command>, > sessionId: <session Id>, > [error: <error message>,] } Since we only had one connection between client and remote screen, do we really need the "sessionId" field? We may base on the session object.

One more question, do we really need "setup"? IMHO, we may use "play" to send the url and let the player load and play.

(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #1) > Since we only had one connection between client and remote screen, do we > really need the "sessionId" field? We may base on the session object. Echo to John's concern about sessionID but I have another reason. Since the message will be sent and received by dedicated session object, the app should know this message is aimed for which session object already no matter sender or receiver side. So any other reason for this field?

Per discussion with @johnhu, sessionId and Teardown is unnecessary. Separating Play and Seek will be more intuitive for implementation. Periodic status report from remote screen can help doing UI synchronization between client and remote screen. Here is the updated command protocol: Load: send media url to remote screen. (direction: client to remote screen) { type: ’load’, seq: <sequence number>, url: <video URL>, } Play: play media at current time. (direction: client to remote screen) { type: ‘play’, seq: <sequence number> } Pause: pause media. (direction: client to remote screen) { type: ‘pause’, seq: <sequence number> } Seek: seek video to specified time. (direction: client to remote screen) { type: 'seek', seq: <sequence number>, [time: <start time in ms>,] } ACK: ack message for every command, corresponding command failed if “error” is specified. (direction: remote screen to client) { type: ‘ack’, seq: <sequnce number of received command>, [error: <error message>,] } Status: report remote screen status periodically. (direction: remote screen to client) { type: ‘status’, seq: <remote screen sequence number>, status: ['playing'|'stopped'|'buffering'], time: <current video time in ms>, [error: <error message>,] }

IMHO, we should add few extra status, and include more information for status event: *. loaded, which means the load command had been executed and metadata had got. The following information are included in `detail` object: #. width: width of video #. height: height of video #. length: total length of video *. sought, which means the seek command had been executed. *. playing, which means the play command had been executed. *. stopped, which means the pause command had been executed. *. buffering, which means media stream is buffering.

(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #5) > *. sought, which means the seek command had been executed. To be compliant with video element, this field is renamed as "seeked".

(In reply to John Hu [:johnhu][:johu][:醬糊小弟] from comment #5) > IMHO, we should add few extra status, and include more information for > status event: > *. loaded, which means the load command had been executed and metadata had > got. The following information are included in `detail` object: > #. width: width of video > #. height: height of video > #. length: total length of video > *. sought, which means the seek command had been executed. > *. playing, which means the play command had been executed. > *. stopped, which means the pause command had been executed. > *. buffering, which means media stream is buffering. One more type is needed: buffered. Since we have `buffering` which may be happened at both playing/paused state, we should have a buffered state to tell client that the video is ready for playing. This event is useful while buffering at paused state.

Let me recap the whole API: --------------------------------------------------------------- Load: send media url to remote screen. (direction: client to remote screen) { type: ’load’, seq: <sequence number>, url: <video URL>, } Play: play media at current time. (direction: client to remote screen) { type: ‘play’, seq: <sequence number> } Pause: pause media. (direction: client to remote screen) { type: ‘pause’, seq: <sequence number> } Seek: seek video to specified time. (direction: client to remote screen) { type: 'seek', seq: <sequence number>, [time: <start time in ms>,] } ACK: ack message for every command, corresponding command failed if “error” is specified. (direction: remote screen to client) { type: ‘ack’, seq: <sequnce number of received command>, [error: <error message>,] } Status: report remote screen status periodically. (direction: remote screen to client) { type: ‘status’, seq: <remote screen sequence number>, status: ['loaded'|'playing'|'stopped'|'buffering'|'buffered'|'seeked'|'timeupdate'|'error'], time: <current video time in ms>, detail: <video metadata when loaded> [error: <error message>,] } ---------------------------------------------------------------

dwi2, Please review this patch.

You may use the following commands to test: ** since we don't have presentation API now, initEvents should be called manually. fp._connector.initEvents(); ** normal play/pause fp._connector.handleRemoteMessage({'type': 'load', 'seq': 1, 'url': 'http://....... test video url/...'}); fp._connector.handleRemoteMessage({'type': 'play', 'seq': 2}); fp._connector.handleRemoteMessage({'type': 'pause', 'seq': 3}); fp._connector.handleRemoteMessage({'type': 'seek', 'seq': 4, 'time': 100});

Comment on attachment 8553604 [details] create fling-player app The overall architecture looks good to me. Although I think we might need some follow-up works to do when presentation API is ready.

merged to master: https://github.com/mozilla-b2g/gaia/commit/6fa6cd149089841495113b92e064860f899c7dbd gaia try is all green with 2 known errors: https://treeherder.mozilla.org/ui/#/jobs?repo=gaia-try&revision=836ea474dfa3