Ordinality of listing does not imply priority.
- Machine learning
- Speech translation/emotion analysis - sending audio/video data from client to server for analysis and receiving translated data/text/audio in return.
- Security camera analysis - data and/or video sent to cloud service for analysis. Service may return data instructions.
- Multiplayer Gaming - web and consoles
- Game play instructions sent from client to cloud based game engine. Some instructions are time sensitive (such as location data), others are stateful (avatar selection). Dataflow is bi-directional between client and server.
- AR gaming requires real-world interaction, including virtual theatre - geo-separate actors with virtual backgrounds.
- Low-latency live streaming
- Unidirectional Broadcast - one to many - sports events, news, wagering, latency equivalent to social media delay and quality to support UHD, HDR, HFR, DRM.
- Bi-directional few-to-few video chats via server, reduced connection time/complexity compared to WebRTC. Example - Apple Facetime
- Cloud Game Streaming
- Server-side game rendering (such as Google Stadia) transmitted to thin client with low latency.
- Bi-directional Game play instructions (between server and client).
- Server-based video conferencing
- Simpler session establishment
- Censorship circumvention - preventing fingerprinting and identification during session establishment.
- Remote desktop
- Transmission of screen capture/sharing and control instructions.
- Collaborative work on a shared screen.
- Including scaling to very large audiences.
- Online document sharing
- Remote assistance temporarily "taking over" control of a system
- Time Synchronized Multimedia Web communications
- Showing a HUD-type overlay over received video with time synchronized information from sensors or game data.
- Add HUD overlay on top of received video from sensors or game data.
- IOT sensor and analytics data transfer
- Efficient and intermittent transmission of data. For example - sending a 1 bit flag, GPS position updates, mouse clicks on site etc.
- Sensor data upload - including filters, aggregation, triggers.
- PubSub Models - avoid long-polling
- Social feeds - Twitter etc, Financial tickers
- Messaging platforms, including Enterprise messaging infrastructure
The purpose of defining these use-cases is to extract requirements to drive and constrain the API design. These requirements are listed in the table below:
Note to editors: these requirements need to be verified and completed by persons familiar with the various fields listed above.
Requirement | Description |
---|---|
R01 | Deliver ordered and reliable data (streams) |
R02 | Deliver unordered and unreliable data (datagrams) with minimal latency |
R03 | Deliver unordered but reliable data (use new stream for each data object?) |
R04 | Deliver ordered and unreliable data (cancelable streams) |
R05 | Performant integration with existing media components such as MSE/EME. |
R06 | Let web applications be able to handle large amounts of data without visible user-experience degredation. |