- From: gmandyam via GitHub <sysbot+gh@w3.org>
- Date: Fri, 23 Nov 2018 03:30:38 +0000
- To: public-web-and-tv@w3.org
>The tests @rjb1000 mentions were based on a wire format that requires always an 8 byte field for connection ID. A recent change to QUIC [1] now allows down to a 1-byte field. ... >By the previous claim methodology, you could say that QUIC is now 25% better than ROUTE. It's the clear winner, right? Wrong. a) ROUTE supports all services, not just media. This includes ESG, DRM entitlements, NRT data, application packages, and application related signaling. The ROUTE headers have clear identification of these different types of information. Connection ID does not include such identifiers and therefore is thoroughly inadequate for the purpose. b) Any overhead calculation has to include FEC. The ATSC has concluded that FEC is absolutely necessary for OTA transmission to account for (wireless) channel losses. The DVB project did not allow for FEC to be included in the calculation in part because of the lack of support in QUIC. That does not eliminate the absolute need for FEC in a wireless broadcast system. Note: Ironically, WebRTC already supports FEC for RTP transport in the form of FLEX FEC (https://tools.ietf.org/html/draft-ietf-payload-flexible-fec-scheme-11). Seems that QUIC is a step backwards in this regards. c) Any broadcast transport must have clear identification of the necessary information included in a RAP (Random Access Point), in order to allow for fast channel acquisition. This includes: broadcaster application for the channel, initialization segment, Connection ID does not include this information (as far as I can tell, and therefore channel acquisition will not be possible in an ATSC system. Note also that ROUTE is not a fiction - it has already been standardized and deployed. Perhaps QUIC may have a place for unicast transport of live media, but it is definitely a stretch to claim that is it suitable in its current state for OTA broadcast. -- GitHub Notification of comment by gmandyam Please view or discuss this issue at https://github.com/w3c/media-and-entertainment/issues/1#issuecomment-441149978 using your GitHub account
Received on Friday, 23 November 2018 03:30:39 UTC