The packet formatter next shall replace the 3-byte MPEG header place holder with an MPEG
header having an MHE packet PID. Ron John Willkie wrote:
More foolishness. MPEG-2 is a specific form; the mpeg-2 packet; one sync byte, three heaer bytes, optional adaptation field, and payload. The only thing that M/H has with this is the packet size of 188 bytes. It's simply absurd to aver that M/H is being carried over MPEG-2 ts, since an MPEG-2 ts requires the packet form, not just the 188 byte length. John Willkie -----Mensaje original----- De: opendtv-bounce@xxxxxxxxxxxxx [mailto:opendtv-bounce@xxxxxxxxxxxxx] En nombre de Manfredi, Albert E Enviado el: Monday, January 05, 2009 3:19 PM Para: opendtv@xxxxxxxxxxxxx Asunto: [opendtv] Re: ATSC Mobile DTV Mark Aitken wrote:The A/153 Candidate Standard has been published on the ATSC Web site. See:http://www.atsc.org/standards/candidate_standards.php Very interesting. I have a few preliminary comments, some of which I might adjust after having digested this longer: 1. Not sure what made this more desirable than A-VSB. Without an equivalent document for A-VSB, from which to compare details, the two seem functionally very similar. Both layer an additonal 1/2 rate and/or 1/4 rate convolutional code on top of the legacy 2/3 rate, to lower the required C/N margin, and both introduce additional training sequences to expedite receiver sync and improve performance with dynamic echo. 2. I didn't find any table quantifying the C/N margin requirements in the different M/H modes. Would be nice to include such info in Part 2, Tables 6.1 and 6.2, for instance. 3. I quibble with Figure 4.1 of Part 2, and similar ones in other parts (Figure 4.3 of Part 3), which show that ATSC legacy is carried over "MPEG-2 Transport," whereas M/H is carried over "IP Transport." Both are carried over MPEG-2 TS frames. M/H has an added IP layer on top of that, but in truth, the IP and UDP layers are only used to identify packets. There's no actual IP routing going on here. It's broadcast. So M/H service is encapsulated within MPEG-2 TS, just like legacy ATSC service, and there are additional link layer functions added for the MH Ensembles (see Figure 5.2 of Part 2). In a (one way) broadcast environment, essentially the functions of the network, transport, and session layers become rather trivial. I mean, for example, can I support a single M/H service using the facilities of multiple non-synchronized, TV transmitters, as one can do with a single TCP/IP or UDP/IP session using multiple underlying layer 2 networks and multiple different routes? (Meaning, I'm not talking about fancy link layer tricks, akin to Ethernet link aggregation, but rather basic routing of IP datagrams independent of the underlying networks.) 4. On a similar note, I quibble with the mention of RTCP, e.g. Fig 5.3 of Part 1. Only part of RTCP functionality is used here. QoS is provided entirely by the carefully built, time divided, synchronous, link layer of M/H, all of which occurs "underneath" the IP and UDP layers. QoS is not provided by any feedback signaled by RTCP to the source of a transmission, as RTP/RTCP are expected to operate. This is the crux of my disagreement with the layered model as shown here. RTP/RTCP are specifically written to NOT depend on a synchronous link layer. Whereas M/H cannot function without the M/H synchronous link layer. 5. Leaving aside the OSI layer quibbles, I got a real kick out of Section 7.5 of Part 3. Some months ago, I posted a sketch of a "true" broadcast cellular service, in which each translator in the multi-frequency network would transmit the frequencies of adjacent cells, to allow receivers to seamlessly switch from one tower to the next, as the signal from a new tower becomes stronger than the previous tower's signal. Lo and behold, that's already supported in M/H, on a program by program basis. A "no apologies" cellular broadcast network. 6. Also enlightening is Section 6.1 of Part 2, which shows that M/H service can take increments of data rate away from the main ATSC service as low as 130 Kb/s. Tables 6.1 and 6.2 of Part 2 show that if M/H takes up 0.917 Mb/s of a 19.39 Mb/s multiplex, it can provide a 1/2 rate M/H channel of 312 Kb/s, and the added training, framing, etc. takes up the remaining 147 Kb/s. Or half that payload data rate if all groups are set to 1/4 rate. 7. So, let's compare this to DVB-T HM. We don't know the C/N margins, so the comparison is not very meaningful, but let's look at this anyway. If we take a 4.58 Mb/s chunk out of the 19.39 Mb/s main channel, it can provide as much as 1.58 Mb/s of 1/2 rate robust channel, or half that much for 1/4 rate. In DVB-T, 6 MHz channels, a 1/2 rate QPSK HM channel provides about the same robust bit rate capacity, with C/N margin in gaussian channels of 8.9 dB, if you want the rest of the channel to be used in 64-QAM mode, comparable to the M/H case. My bet is, these two are similar, however M/H also offers a 1/4 rate option. But without the C/N margins, hard to tell. Also, an advantage of doing the robust channels this way, vice changing the constellation as HM does, is that you can fine-tune just how much you want to take away from the main channel. (For example, a single 312 Kb/s robust stream only tales 0.917 Mb/s away from the main channel.) (Sidebar: A-VSB, using the 1/4 rate and turbo code, managed ~4 dB C/N margin, with a single receive antenna. Don't know what the 1/2 rate robustness was, but a 9 dB C/N margin comparable to DVB-T HM does not sound out of the realm of possibilities.) Bert ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways: - Using the UNSUBSCRIBE command in your user configuration settings atFreeLists.org- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line. ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways:- Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org- By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.
