initial text on common stream encoding #114
Conversation
| - One Stream per Group of Pictures/Group of Obejcts (like with WARP) | ||
| - One Stream per frame (like with RUSH) | ||
| - One Stream per Track/Rendition (like with QUICR) | ||
|
|
There was a problem hiding this comment.
I understand why you will want commonality, but the "single stream per track/rendition" is harder, or at least is harder today. The initial prototype used the same QUIC stream for control and for data, and that's definitely a different format than using one bidirectional stream for control and an unidirectional stream for data. I guess that we could change that, but maybe that should be a separate PR.
There was a problem hiding this comment.
Also, do we have a definition of "track/rendition"?
| @@ -355,3 +355,62 @@ errors, which means that the same fragment could very well be received multiple | |||
| Relays may forward fragments even if they arrive out of order. | |||
|
|
|||
|
|
|||
| # Common Encoding For Media over QUIC Streams | |||
|
|
|||
There was a problem hiding this comment.
I am not sure that we should have a section on "common encodings for streams", by opposition to just adding section for RUSH and WARP, and updating the architecture part to indicate that we support 4 encodings: single stream, WARP, RUSH, Datagrams. Define how the 'subscribe" and "post" messages indicate these types. Then have a section for each of those types.
There was a problem hiding this comment.
I feel the subscribe/post message shouldn't carry a particular grouping in them. The common format ensure you get some data that can be related to a mediaId, groupId and objectId. If it comes in one stream (for all the media - QUICR), one stream per gop (warp), one stream per frame (rush) , it can still group things as we do today
There was a problem hiding this comment.
The receiver can certainly be ready to receive data in any format. However, when we start an experiment, it is nice to have an easy way to specify whether we expect data in one or another format. Plus, we may well have some future clients that can have only implemented a subset of the transmission types...
Also, currently the subscribe messages only carry the mediaId (or datagram stream ID) when the client selects the "datagram" mode -- but that one is an easy fix, just send the media ID all the time.
There was a problem hiding this comment.
I see what you mean here. The scope here is quicrq prototype implementation, but are you ok with this general direction if i do a PR for the ietf draft ..
| ## RUSH | ||
|
|
||
| For mapping with RUSH, each QUIC Stream shall have the following elements | ||
|
|
There was a problem hiding this comment.
That's a bit dry. You want first to define the general structure of the RUSH stream, as in explain that in that setup a "track/rendition" is carried by a series of unidirectional QUIC stream, that each of them starts with a particular header, and contains a single object.
| In this case, there exists atmost one ``` quicrq_media_object ``` with the ```quicrq_media_message``` | ||
|
|
||
| ## Warp | ||
|
|
There was a problem hiding this comment.
Same remark as above. Actually, I would put the WARP section before the Rush section, because it is easier to explain the message types as part of the RUSH description.
No description provided.