Subject: IP/VBI discussion of EACEM document

From: "Dave Rayers" <[email-masked]>
Date: Thu, 17 Dec 1998 10:11:29 -0000

This discusses the points raised since the circulation of the EACEM
document. I do not discuss the bundle interleaving here, except to say that
if it is adopted, then presumably there will be a suggestion for the EACEM
document to follow to maintain compatibility?

Points on the EACEM document:

1) Changes to Channel Selection.

Victor Papanaoum suggested that the data channel address, which the document
selected as 15. Should be replaced by one of the ones currently used by
Format A (packet31).

This would work technically, as bit1 in the format type does distinguish
between format A and format B, but we assume that existing Format A decoders
do in fact ignore packets with bit1 set - they should but I doubt if this
bit of the software was ever tested by most manufacturers (most
manufacturers do not make encoders and therefore cannot test non-standard
bit patterns easily, and I would estimate that there have been well over 20
manufacturers of format A encoders). We have no way of knowing if this is
the case without testing. Does anyone else know?

If there are no problems with existing decoders then this suggestion seems
sensible to me.

2) Adding extra insertion points.

The EACEM specification currently allows just one IP stream to be carried
for a network (as IP has its own addressing), and in principle if a second
insertion point was used, the IP off the first insertion point would have to
be decoded, multiplexed with the new IP stream and then recoded. This is
actually quite easy - the same principle is used for 'local teletext' here
where the stripping down is not done for technical reasons, but to remove
unwanted content and add wanted local content.

The alternative is to put the two (or more) IP streams on different
addresses (as NABTS allows). This works well if we expect decoders to
receive either one or other of the services, but not if we expect the
decoders to receive both services simultaneously where in effect we have to
run two (or more) copies of the decoding algorithm. This makes the decoding
much more complex.

If we have IP streams on different addresses then the decoder must be set up
to receive the correct one. This is an extra control at the receiver - and a
source of confusion for a novice user.

I propose we have one address for the 'normal' IP stream which is used by
default for IP reception, and decoders must be programmed to receive this.
We then have one (or more) extra addresses for use with any independent IP
stream which can be used only for services which are not expected to use the
'normal' IP stream at the same time. In short we allow multiple insertion,
but at the same time give one channel the status of 'default' or 'priority'.
The would be no requirement for decoder makers to implement simultaneous IP
channel reception.

If we do adopt this approach then we can use the 'format A' channel
addresses to distinguish between channels. There are four of these which is
just about right. Use the first one as the 'normal default' channel.

3) FEC choice.

As you know this is being discussed by EACEM and just to confuse further,
other parties who are not members of EACEM. I suggest we bake a christmas
cake with a quarter in it and give everyone a piece. The person with the
quarter either gets to choose the FEC or chokes to death.

I would just like to reinforce the comments (I think by David Putzolu of
Intel), that anything can be improved, but if we take that approach then
nothing will ever work as we will always be in development mode.

The (Norpak) FEC was for NABTS was presented a year and a half ago. The
(Philips) FEC for WST was presented over a year ago. Both these work
competently (and have not been changed from the original presentation - i.e.
they are stable) and various companies have done work on both of them, but
we continually get requests to change both.

The way for a standardisation body to manage this is to fix the
specification with a working system (i.e. if it a'int broken don't fix it)
and allow for upgrade. If a company is happy with the fixed standard then
use it. If there is some technical reason why an improvement is required
then each individual company has the choice or a) either following the
standard or b) doing something non-standard and argue the case that it is
better and present it for future (not - present) standardisation. We DO want
to leave open the route for improvement, but not at the expense of stopping
the present.

The EACEM document does this. It presents a standard which competent and
works, but also allows for upgrade if anyone thinks of better things in the
future.

Summary

The choice remains to tie up this specification very quickly now. We have
documents for NABTS and WST. The NABTS document can go off now if desired
and the EACEM document (subject to some odd details discussed above) can be
fixed and go off to both ETSI and the IETF in parallel. We can then all go
off and get on with applications as we have been doing for the past few
years until this basic transport debate came up.

It is the applications which are the key to success much more than the FEC.

regards

Dave Rayers