[AVTCORE] Comments on draft-westerlund-avtcore-rtp-simulcast-00

["Brandenburg, R. (Ray) van" <[e-mail]>]

Hi Magnus,

I reviewed your draft draft-westerlund-avtcore-rtp-simulcast-00 and have some questions/comments:


-          Section 3: This section lacks a summary/conclusion. A number of different scenarios are introduced, some of which are explicitly stated to be out-of-scope (e.g. 3.5), and some are stated to be in-scope (e.g. 3.3). Some scenarios however (e.g. 3.2) are not specified to be either in- or out-of-scope.



-          Section 3: This section talks quite a bit about the relation between Simulcast and Scalable Coding and in which situations one of the two is more suitable. I'm not sure why this is relevant. Simulcast and Scalable Coding might be two techniques that in some cases can be used to solve the same problem, the layer on which they do this is completely different (codec-level versus transport level). The fact that Scalable Coding might, in some situations, be a better solution than Simulcast does not mean that Simulcast should not be standardized to handle those situations. I understand that you've written this mainly from a video conferencing perspective, in which Scalable Coding might be used more often, but in a lot of situations, such as IPTV, Scalable Coding is just not an option due to its inherent complexity. In these situations Simulcast might be able to solve some real issues, despite the fact that Scalable Coding might be able to solve these issues more efficiently.



-          Section 3.1.1 See comment above. Why is this section relevant to the rest of the document?



-          Section 3.2.1: This scenario is the only one of the scenarios in section 3 to make a clear pro/con of SSRC versus Session based multiplexing. Furthermore, it does so before the actual discussion of SSRC vs. Session-based multiplexing is introduced in section 4.



-          Section 3.3: For the tiled streaming use case described below, this scenario is especially relevant. Is there any technical reason why it has less emphasis than the RTP-Mixer scenario?


-          Section 5.5: Your conclusion here is that Session Based Multiplexing is the best choice, since SSRC multiplexing seems to require a large amount of extensions in order to work. How does this conclusion relate to the draft-lennox-rtcweb-rtp-media-type-mux-00 which seems to suggest that SSRC multiplexing is not that difficult? (I should note that I have no experience with sending multiple streams inside a single RTP session, so it could be that I don't understand the issues correctly)



-          Section 6.2: How do you suggest the sequence numbers and RTP timestamps are handled between multiple alternative streams? Would it make things easier if these were aligned across multiple streams?


And one more remark:


-          In the introduction session you describe three different ways in which the encoding of a media content can differ: bit-rate, codec and sampling. Recent work in the area of immersive media has proposed a fourth method: tiled video. With tiled video (or spatial segmentation), the video resulting from a single camera is split into a number of areas, each focusing on a particular spatial area of the video (e.g. a single video source could be tiled into four separate video streams, one describing the topleft quarter of the video and three more describing the topright, bottomleft and bottomright quarters respectively).

Are you willing to extend the scope of this document to include the tiled video scenario?

Best Regards,

Ray van Brandenburg

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer