DVB-SI Panel Questions, Answers and Discussion
On Wednesday 10 March 1999, FACTS sponsored a seminar discussing the DRAFT Australian DR 99047, Digital television -- Terrestrial broadcasting -- Part 1: Characteristics of digital terrestrial television.
Three guest presenters from Europe were assisted by Australian experts in explaining the Digital Video Broadcasting (DVB) standards and their proposed application in an Australian environment.
The Guest Speakers were
Peter McAvock from the DVB Project Office
Ken McCann from NTL in the UK who is an expert on SI and CA systems
Dr Martin Gold from NDS who is also an expert on SI data systems
The following is a transcript of the Questions, Answers and Discussion, which took place during the panel session. Many interesting issues, which are in need of further investigation, were raised during this session.
Here is a list of topics covered during the afternoon panel question and answer session as part of the DVB-SI seminar.
Datacasters, Conditional Access and mixing CA systems
Use of Electronic Program Guides with Datacasting & Video
Use of Statistical Multiplexing with Datacasters
Reviews of Datacasting
Use of a Telecommunications Return Channel with DTTB
Conditional Access and Software download requirements
Conditional Access and the use of Satellite Distribution + EPGs & Software Download
How many CA systems should we have and how do we choose
Product Safety Standards. Is it a TV or a Computer?
Minimisation of the number of CA Systems
How is AC3 accommodated within DVB + Update on DVB Java
The reasons to regenerate the SI for various time zones
Network ID's for Australia + Reference Test Lab to Test IRDs
Handling differences between carriage mediums in a country
IRD Problems, Testing and Lockups
Market Requirements for AC3
Use of AC3 leading to major change in DVB standards
Implementation in Australia of a 6 MHz channel in the amongst the 7 MHz DTTB channels
Close of Seminar
David Sice (CBAA)
One of the interesting things about the DTTB legislation, is the role of the datacaster, in the equation. One of the peculiar things is that there is a mandatory requirement for a standard definition television service to be contained within a datacasters transport multiplex. I would like to ensure that that will be receivable or resolvable by your bulk standard receiver, that the consumer will have. The sort of questions that flow into my mind are the channel bandwidth issues, the conditional access issues, (same or compatible systems operating on a datacaster as the standard Free to Air television service). I just wanted to float some of those issues and see where some of those questions needed to go, and how they might be resolved.
Dick Barton (FACTS)
The legislation provides for capacity for what we call datacasting. Within that datacasting there is a provision that the first datacaster in each area will be asked to carry a community broadcaster, which will be standard definition. That is the essence of it, but I think what David is saying is that there is some difficulty in matching the requirements within the one multiplex of handling a free to air community broadcaster plus a datacaster, which may be a conditional access organised.
Ken McCann (NTL)
If I understand the situation correctly, this would be a multiplex where the majority of the bandwidth would be set aside for data, but there would be one standard definition service which is free to air within that.
Dick Barton (FACTS)
That is correct
At the moment we don't actually have a definition of a datacaster for the present
Ken McCann (NTL)
In that situation, you only have the one potential CA system for the data then you don't have the type of simulcast issues that martin referred to earlier. It is a simplification at least from that point of view. In terms of what the standard will actually support, then it is totally flexible, what data rate to set aside for data against the actual television service? One thing you may choose to do is to allow the data rate for the television service to vary depending on the difficulty of the video material. If you have some non-time critical data that you can usefully use the residual capacity for. Typically, if you have 1 standard definition service, let it vary between 2 & 6 Mb/s depending on how tricky the material is. You would need to have one organisation in control of that multiplex, producing the relevant service information to describe everything within that multiplex, and there is also a whole pile of issues depending exactly what is meant by datacasting, which one of the various data broadcast options are used. What the total channel is going to be. Is it something that one organisation has got total control of, or is it something that is used as a pipeline that other organisation can also get involved in? I think that probably doesn't answer the question, but it does raises some more.
Dick Barton (FACTS)
If there is one multiplex organiser, then he has to have control of the whole multiplex? He can set it up to do whatever is necessary.
Ken McCann (NTL)
Yes. If there is not one, then there needs to be a group getting together at the earliest stage possible to define, just what the parameters are. It would simplify things a lot if there was just one organisation totally in control of it.
Dick Barton (FACTS)
Can we separate datacasting, which may have conditional access and have free to air at the same time?
Ken McCann (NTL)
Yes. There is no particular problem in mixing information that is controlled by one CA system with free to air. Where there are potential problems is where you have more than one CA system in the same multiplex. If I understood the situation correctly, there would only be one CA system possibly for the data, plus a free to air for the standard definition television service.
David Sice (CBAA)
My question relates to the datacaster EPG information or the tables normally associated with a community television service on a datacaster. Would that be resolvable as part of EPG information, alongside other television services, on the standard television receiver?
Ken McCann (NTL)
Yes, there is fundamentally no difference between an EPG that is describing a variety of TV services, or a variety of Data services.
Dr Martin Gold (NDS)
Well a comment on an EPG aimed at describing TV services probably doesn't want to describe data services and vica versa. Fortunately, the DVB-SI have a service type associated with each service and so it is very easy for the receiver software to list out the TV services, or to list out the data services. I don't see any particular problems with any combination in the transport stream.
Dick Barton (FACTS)
This is another case where we actually need to specify how we are going to do it. So that the receiver manufacturers know what we're going to be doing in that context. The sooner you can sort it out, what the implications, what the arrangements need to be, the better. That way it can be accommodated in the description of how it will in fact function.
Dick Barton (FACTS)
There was another interesting question, which David has not asked yet. Is there some use that can be made of statistical multiplexing which would allow optimisation of the Free to Air channel in the relation to the data, so there might be a little bit better sharing of the spectrum available. Is there any problem with that at all?
Ken McCann (NTL)
No. That was what I touched on earlier by saying the television service may be allowed to vary a bit in relation to the difficulty the of the material. It is essentially the same sort of algorithm that you would use where you have several television services in the multiplex which are all allowed to vary to some extent. The difficulty is where there only have only one TV service where you are trying to maintain constant quality at variable bit rate and you utilise the extra bit rate for data services when that is available. It would be more efficient use of the multiplex that way.
Dr Martin Gold (NDS)
Just commenting on statistical multiplexing between data and video. It does require an understanding of what the parameters are that are going to control the data bit rate and what parameters are going to determine the video bit rate. They are not equivalent items. If you are statistical multiplexing a few video channels, it is quite easy to determine how to share the perceived video quality between them. With data, the issue may be that you are always trying to achieve a satisfactory video quality and the data takes second-place. Or you may be trying to achieve a particular data capacity and the video takes second place. There is some agreement between the video supplier and the data supplier as to what the trade-off is between video and data. There is no automatic answer as it is an implementation detail.
Ken McCann (NTL)
If you have something like a data carousel or an object carousel where you have information, which is being repeated, then that mixes quite well with the video because, during very difficult video the data rate goes down, so the repetition rate increases. You get a slight reduction in the quality of the data service to the end user. If on the other hand you have very time critical data and you need to maintain a constant rate stream from the data, that's very different. You can't then squeeze that down. That's got a fixed rate. So in the multiplexing you would have to set a priority of things, so something that is fixed rate data would be the cluster priority, something that is carousel data would be the lowest priority with the video somewhere in between.
Dick Barton (FACTS)
I guess what I'm hearing is 'yes but it ain't easy'. The sooner someone sets the rules by which that provision in the legislation can be honoured the better. I think Dr Pelling that may be an issue that your committee needs to look at, how that framework needs to be structured for the data Broadcasters and the community Broadcasters.
Dr Simon Pelling (DCITA)
As you may be familiar, there are these series of statutory reviews, which we have to undertake in the legislation. One of those is into the regulations that will apply to the allocation of spectrum for datacasting including carriage of community TV service. The Australian Communications authority has been working with us and the ABA to put together an issues paper on that, which is going to be raising a whole lot of issues associated with how to allocate the datacasting channels once we know what they are. I hope all these sorts of issues can come up in that context so that we can make decisions about the allocation of spectrum in the full knowledge of all of the peoples concerns and what the technical issues are. I encourage you, if you have got those concerns about spectrum allocation issues and the carriage of community TV to make it in that context. The paper should be released fairly shortly I think by the ACA.
John Begini (DVB)
Just a follow-up question to Ken McCann. He said that in relation to data channels, one of the things you have got to specify is the return channel. Can you not have a multiplicity of return channels? For instance, can you not operate through a telephone line on one hand and some other subscriber might well operate through GSM or something like that. Is that not possible?
Ken McCann (NTL)
You could do, but if you have more than one organisation involved, then it just increases the operational problems. In principle, yes you can, just from the sheer practicality of it; the simple system is more likely to work successfully on day one.
Keith Jones (Panasonic)
My question is on the issue of Conditional access and software download, from the receiver manufacturer point of view. That is an important issue for us. Does the panel have a view on what is the most appropriate way to do the software download, whether using private data as discussed in the CT2C meeting is appropriate or whether using conditional access approach is the more appropriate. Could the panel explain one more time, if it was the CA approach, how would that work and impact on normal free to air terrestrial broadcasters?
Geoffrey Tomes (GTV-9)
We think that because we are free to air broadcasters for the 3 commercials at least, that there won't be a CA system, so we have to find an alternative means of doing software download, presumably using either the DSMCC carousels or alternatively cooking up a completely private way of doing it.
Dr Martin Gold (NDS)
I think the choice is between either using a CA system that already has that capability or effectively building a mini CA system that's purely for this purpose. By the time a receiver has an authentication mechanism to be able to identify that this is correct receiver software for it, and also has an addressing mechanism to be able to filter for software that is relevant to that receiver, that sounds like some of the functions of a CA system. One of the key functions that is missing out of a full CA implementation is that you are not decrypting and descrambling services. The basic CA mechanisms are actually being implemented in the receiver. If there are no other services that would take advantage of a CA system, this kind of mini CA system might be the best approach for the market. If there are going to be CA services then making use of the CA system you already need, seems like the simpler way of doing it. The Key issue is. Are there any CA services involved in the market, and if there are then CA is a good mechanism, however if there are not then you are basically saying, lets have a mini CA system, dedicated to the software downloads.
Justin Melhorn (Ozemail)
It seems to be very important that we recognise that there will be more than just Free to airs that will use this box. Some of those people will be interested in having CA systems, some of those people will be datacasters. The draft standards we have at the moment for the Box and some of the things we are doing, (No doubt it is our fault for not speaking up sooner.), look at this whole process only from the point of view of the commercial free to air stations. But, we will have multiplexing on the ABC and SBS, we will have datacasting. The DVB gentleman may know that the government envisages at the moment the provision of bandwidth for a number of datacasters. Certainly the possibility of one of the scenarios that is happening at the moment, so that it is notable that your figure 7.1 for example shows 7,9,10,2 and SBS but doesn't even have an other slot there. I think that we should broaden our horizon here a bit and think about what are the things that might happen that we haven't even thought of yet. One of those is certainly CA. Just because the free to airs don't need CA is not great news for us.
Dick Barton (FACTS)
I'm not sure that we actually said we don't need CA, because we have datacasting too, that's part of the package. I'm not sure wether the ABC and SBS went together on multiplexes. That's certainly something new for me. One of the things I mentioned earlier today is, one of the things we want to specifically look at is the datacasting issues and address them. That's the very issue that needs to get through to the parent committee CT2 to identify what you want to have looked at, how we want to have it looked at and to make sure it is addressed. Please it's not too late, yes we would welcome you in to participation and to see what is happening, I don't think we have done anything at this point that would not allow a comfortable fit with what we envisage as being the likely technology to be used by the datacasting.
Bob Greeney (ABA)
I think Justin the point that has been made a number of times today and yesterday in CT2C, is that basically what we are doing is adopting the DVB-T suite of standards. The other thing we are doing is where things are unique or different in the Australian case, we are looking at how standards need to be changed to make them operate in Australia. The key point is the DVB standards are there and they work, now for datacasting the data broadcasting standards are already specified in the DVB suit, and we have not changed those at all. Now the CA requirements are there, and so are the SI, and of course SI we are talking about from the point of view, at the moment, of the free to air broadcasters. It is not just the commercials. The ABC and SBS have played a very important role in all this sub-committee and committee work, as have a number of members of your industry too. I think if you have concerns, we certainly need to know about them, the point I want to make is, we are not changing the DVB standards in respect of datacasting. They exist.
Geoffrey Tomes (GTV-9)
Right throughout the FACTS PGSI process and in fact the CT2 process, we have always had this paradigm that the ABC, being allowed multiplex, the ABC will multiplex and probably will have CA on some services whereas the free data airs probably will not be allowed to multiplex, at least for sometime, and therefore probably will not have CA. So the model that we're trying to create and that's model that we use when we study DVB and make sure that everything within DVB is going to operate within this model and provide us with the toolkit for this model, is that there will be CA on some systems, not CA on others, maybe a scheme for the ABC where there is only CA on some particular streams within the overall transport stream. The basic ABC service remains free to Air and only some of the other embedded multiplexes are encrypted. I can't for the life of me see where this would not fit the datacasting model. You have a certain amount of bandwidth allocated to data in a certain amount of bandwidth. The allocation of data space is entirely up to you. How much you allocate to the public TV channel and how much allocate to your commercial data casting requirement. I deny that the three commercials have put this up, it has been a very heavy process all the way down the line involving the ABC the ABA and everybody.
Colin Knowles (ABC)
Jeff has very kindly suggested that we may have a new business opportunity in terms of running conditional access services, that isn't so in fact. But we will be using conditional access. We need conditional access because we are a national broadcaster and sometimes we have programs that we are not able to show in New South Wales and have to isolate people from seeing that. If we do choose to distribute by satellite, one of the likely ways of doing the distribution, we have to be able to isolate out certain parts of the marketplace. So therefore CA is a fundamental requirement, as it already is on our satellite service, and so CA has to be alive and well in system to make it work. Likewise datacasting for all those other sorts of reasons.
Bob Greeney (ABA)
CA has to be there for remote commercial television services, which are delivered to regional parts of Australia by satellite, but not to all of Australia, so they have to be able to address receivers in some parts of the country and not others.
David Soothill (SBS)
I wish to be slightly controversial. To speak at variance to the last two speakers. SBS are also looking at distributing their transport stream around Australia by satellite. I think that's the way we will go. But if we do it will be a layered system. The transport streams we are carrying may contain embedded conditional access using a conditional access system. And that is for the data service and anything else that might happen to be there. The distribution system we will have will be a layered system sitting on top of that probably running with a DVB-S. technology with its own separate conditional access system. There is no need for the conditional access system on the satellite distribution system to be anyway related to the conditional access system being used on the DVB-T system. This is because the satellite one is only managing the receivers that are receiving the satellite service whereas the terrestrial transport stream is for the 18 million receivers in the terrestrial environment, in the longer term.
I have a couple of questions. There has been view at times here that each of SBS commercial networks and affiliates ABC and SBS will want to run their own EPGs and want to download software into the receiver. I am not sure in practice whether that really works. It was mentioned earlier today and I would like someone to comment. There are two issues. Firstly, none of us own the receivers; they are owned by consumers. You take a risk if you download some software without asking would you like to have this, click here if you don't want it. Click here in five seconds if you don't want it. And then our SBS one wipes out the channel 9 one. They get upset and ring me up and say why have you wiped out our EPG. Secondly, with conditional access systems, if we have boxes in Australia with two smart card slots and two PCMCIA slots, I really to see us running 5 or 10 separate conditional access systems. I do think there has to be some kind of process to manage that. I am not talking here of anybody who might be using the system for a totally private system with boxes they give subscribers which are set up with its own unique conditional access for some data service. There are a couple of areas there that I would not mind hearing some responses to.
Dr Martin Gold (NDS)
The downloading software issue depends whether we are talking about permanent downloads or temporary downloads. In the later case the data is only in RAM and the user has the ability to basically believe that particular program execution. So if it is a temporary download the user recovers from it if it is not right or what he wants. The broadcaster has not permanently taken over the box. In the case of a permanent download, where it goes into permanent non-volatile memory usually flash memory, then clearly the broadcaster is taking on a lot of responsibility in what he does when he changes the box software. I would have thought the receiver manufacturers would have some interest in that process, as well as the consumers who own the boxes. Permanent software download is not something to be taken or entered into lightly at all. The temporary type of software download is dependent on the development of an environment with an API, probably a virtual machine environment, so you can download the same to all the receivers, and it is a temporary program on top of the operating system.
It does seem like if you fragment a marketplace with too many systems being required, the consumer isn't going to be able to afford five or ten CA to system modules. It's not going to be a practical implementation. simualcrypt does give you the ability to have a small number, greater than 1, CA systems being used in the marketplace.
Ken McCann (NTL)
The first point you raised about any CA system that applied to satellite distribution could be totally independent of the system used for terrestrial. I'd agree with that. It is precisely that which is being used in the UK at the moment for the satellite distribution network.
Dick Barton (FACTS)
David also raised the question of what happens if another broadcaster fills up the RAM for the EPG information and wipes out every other one. The reality is we have to sort that out so it doesn't happen.
Peter McAvock (DVB)
You will be not surprised to hear that in discussions in the DVB which are ongoing, on the MHP, perhaps the most vivid of those discussions is the life-cycle of applications. If we take the highly competitive environment that exists in Europe where you have one application coming along squashing somebody else's application, and continuing to operate over a long period of time. Simply, an application that sits in memory and uses up system resources, rather than actually doing anything. That is one of the big issues for a software download application. It's a bit like your laptop.
Colin Wright (Seven Network)
This question is a continuation of David's question. Being involved with the receiver manufacturers in connection with the receiver guidelines document the question came up about Conditional Access. In the document we have said Conditional Access is not required, the question is, which Conditional Access system, whether it is embedded or a software implementation with smart cards, a separate hardware solution, receiver manufacturers feel that is a very expensive solution with PCMCIA cards. Even if the commercial networks are not going to have CA but other networks may, there will be other applications that require the receivers go on to the market with some sort of CA facility in them, or provision for some sort of CA facility. What is the process that determines which system gets incorporated the boxes? Do the individual manufacturers go and talk to individual CA supplier's or is it up to the manufacturers. Will there be one or two preferred CA suppliers. So to the ACCC does not get to upset about the fact that they have got to deal with just one CA supplier. Are there any thoughts from overseas in regard to this situation?
Ken McCann (NTL)
You certainly make things easier for yourselves if all the uses get together and decide on one CA system and decide that at the earliest stage possible. Other scenarios are certainly possible but with eighteen months to go, eighteen months is not a huge amount of time for the number of decisions that need to be put in place at the fundamental architectural level. The choice of CA vendor is one of those.
Dick Barton (FACTS)
There may be some trade practices implications of choosing any-one proprietary system. There may be some legislative difficulties. We might need legislative relief if we get together and choose a particular manufacturer for supply of that aspect in Australia.
Paul Robinson (IBM)
I am looking at the receiver or diagram in the draft Australian standard for receivers, and it looks awfully like a piece of information technology equipment with bits off TV stuff hanging off it. Where I am coming from is product safety. We have in Australia and internationally two competing product safety standards, which are currently applied to two distinct technologies. There is AS3250, which is based on IEC65, which covers sound and vision equipment, which is currently used for television equipment in Australia, and there is AS/NZ3260, which covers information technology equipment. The two standards have vastly different approaches to product safety. Although AS3260 or IEC9250 tends to be regarded as the latest and greatest IEC65 is catching up with it and adopting and harmonising with them. From the area of product safety I really need to know which product safety standard is going to be applied to these devices.
Dick Barton (FACTS)
I think that's a question that needs to be addressed in the standards Australia forum. It's certainly something the receiver manufacturers need to get clear before they start putting products on the market.
Andrew Hill (Scientific Atlanta)
As of the first of January, we have had to go through a compliance procedure for every product we have bring into the country, and this very issue hits our current IRDs. And all the competent bodies, you will get one that will take a box and look at it, one of the standards applies to it and the other doesn't. It is a great issue at the moment as to; is this a computer or is this a bit of television receiving equipment, that I have got now.
Dick Barton (FACTS)
What we need to do is ask the chairman of CT2 to identify that this is a substantial and significant question that needs to be addressed to the appropriate authorities within standards and possibly regulatory bodies such as the ACA and ACIF so that the matter is sorted out. My understanding is actually we would get around the system to a degree with modems. This is essentially a set-top box where you get into the phone business, if you are going by a modem which is approved to a AS3260 and the rest is AS2350, maybe we would get by that way. If Bob Greeney makes note of it and CT2 raises it as an appropriate question to be addressed within the standards forum that are appropriate.
Andrew Hill (Scientific Atlanta)
In terms of the selection process and the number of different CA systems, the CA system surely would be more a selection of the service provider rather than a thing from the consumer end. I don't know how many people, for example, actually have a Foxtel cable box and an Optus vision cable box. I see consumers picking up free to air television, but then they may choose from a service provider a number of services from that service provider, and therefore really need one CA system in their box. They would not be changing channels and grabbing different service providers on a very dynamic basis that needs them changing their CA system in the box hourly or minutely, whatever.
Dick Barton (FACTS)
I think there is room for the service providers to get together to minimise the number of different formats. I take a little bit of heart from hearing that we need to keep it down to a minimum but not necessarily down to one.
Brian Roberts (TVNZ)
We understand that the DVB system is an open system. Being an open system means that anything goes, but now that we've brought in AC-3, which is a proprietary system, the first question is, how is that accommodated within the DVB philosophy?
The second question is, can you give ask a progress report on DVB Java.
Peter McAvock (DVB)
I will answer both those questions but I will refer to others on the panel for appropriate clarification. Question number one was concerning AC-3 audio. The DVB project received a number of requests to document a mechanism for carriage of AC-3 audio and in addition to that we have also had a new member which is Dolby labs. They have actually joined the project. That carriage of AC-3 audio does not mean that the DVB specification supports AC-3 audio in the sense of actually specifying the details AC-3 audio, however what it does mean is that the AC-3 audio system can be carried using certain SI and MPEG implementation guideline mechanisms within the standard. The fact that Dolby is a member means they have signed a clause at the end of the MOU that says they will license under fair, reasonable and non discriminatory terms their technology, which is related to DVB products or systems. To my mind this raises and issue which is an issue about how standards are progressed and upgraded, and the way that DVB project works is that we are a system which delivers MPEG 2 transport stream's to the home. That defines an area of responsibility for DVB and an area of responsibility, which is not DVB's. When we have a problem with the MPEG specifications, and we would like to see developments made to MPEG specifications, we flag that to MPEG. We will provide all that necessary information in order to sort the problem out, but we won't actually solve the problem. That has arisen on a number of occasions, and we are lucky in that MPEG is a Standardisation body, is an open system both in terms of its licensing policy and in terms of a transparent development mechanism. It seems consistent what we would do in the Dolby case, say Dolby we have a problem, sort it out. Actually DVB does not enter into any arrangement with Dolby beyond them being the members of the project and therefore their obligation to license under fair, reasonable and non discriminatory terms.
If I go to your second question, which is very related. The detailed discussions with Sun Microsystems about the licensing of Java, that is a bit more difficult. Java will form the core of the MHP specification, and therefore if we are to place that much faith in a system we need to be absolutely sure that not just of the licensing under fair, reasonable and non discriminatory terms is respected by our member Sun, but also we need to be able to insure that as DVB we can be involved in the upgrade process for new revisions of the Java system. Our current negotiations with Sun centre around to what extent they can adhere to the letter of the law, which is the MOU and fair, reasonable and non discriminatory turns for licensing of the technology, but also the spirit of the law, means that if we adopt them as a DVB system, and place for the first time all our faith in a particular area of work, in one organisations intellectual property, then we would like to know to what extent we can become involved as DVB in any future upgrades. I hope you can see the difference between that, and any arrangement we might have with Dolby which is purely where we are saying there is this third party system out here. They as members of the project have said they will license, and we say if you want to carry these streams and whatever licensing arrangement you have to enter into with Dolby is your own business. If you want to carry the streams, this is how you go about it.
Dick Barton (FACTS)
Open systems do not imply there is no licensing cost to use them. Certainly if you want to use MPEG audio there is a licensing cost, in that case it is applied to the manufacturer of the consumer equipment, in DVB's case of OFDM there is a licensing cost which is going to be applied to the transmission system. Hopefully it will get down to just the Modulator but there is intellectual property right in the use of these technologies which those owners of the rights say well yes we will license that under reasonable terms but that doesn't necessarily say it is always for free.
Peter McAvock (DVB)
There are two issues we are dealing with. One is the provision of product that complies to a standard, and you buy that from a vendor. The other is the intellectual property that goes into that product. Dolby is in the unique position of being one of the very few if not only suppliers of audio equipment based on the Dolby audio specifications, and therefore the bundling of their production and manufacturing costs with their intellectual property costs is all easier to do than would be the case for a standard such as DVB which is based on a technology with a large diverse membership which then needs to find some mechanism for recouping the cost associated with research and development.
Ken McCann (NTL)
In respect of the DVB-J situation, there is currently a team from DVB in discussion with Sun on that. The current proposal from Sun is to license its essential patents and copyrights at zero charge, for third party implementers, has long as they will undertake to offer reciprocal arrangements for any other essential IPR that's contained within DVB-J, but would also have to be licensed on a royalty free basis. That's only for third party implementers. Sun would of course reserve the right to charge for its own implementation of DVB-J. that is the current proposal but it is still under discussion. Sun are very keen on conformance issues and would make it a condition there of that there is some formal conformance testing. That is something that is under discussion on how that will be implemented.
Wayne Dickson (TEN)
I would like to discuss the subject of time and time zones. Even though there might be other reasons to regenerate the SI for Various time zones, i.e. program differences, if there are no program differences we have concluded that you do have to regenerate SI. Just in this forum I'd like a brief discussion on that particular item to get clarity in that area.
Dr Martin Gold (NDS)
I think the simple answer is yes. The Time Offset Table provides the facility to indicate to the receiver the difference between UTC and the local time for particular regions. The SI data is all in UTC so there are no issues in terms of the presentation of that information. It is the same wherever you are provided that the schedule is the same. The time Offset Table allows different time zones to have different time Offsets signalled and it also allows you to signal the time and Date at which the local time offset will change and the value of the next Offset. This is a valuable because if you are transmitting the EIT schedule data, that schedule data is going to go through the daylight saving change. You can actually correctly present the information relating to the local time offset both before and after the daylight saving transition so long as both time offset's are known. In terms of the situation where you have different times zones and you are time shifting material it's self, then the schedule's are genuinely different, in terms of the start times are different and therefore it is different EIT data that you need.
Dick Barton (FACTS)
We need to set up a system of registering network ID's. Peter offered to recognise and Australian agency to allocate those ID's and given them and appropriate block of numbers to use. I think that is something the ABA is in the best position to administer, bearing in mind its responsibility for all broadcasters. Is that something the ABA could consider taking onboard in establishing a network ID registration provision.
Bob Greeney (ABA)
I think it is something, we as an industry, need to look at. To include all the existing broadcasters and any datacasters or new broadcasters that might come to be licensed. As to whether it is a job for the ABA or whether it's a job for us to talk about among industry, which might set up its own registration board, I don't know. It is certainly something we need to look at quickly as we discussed this morning.
Dr Martin Gold (NDS)
In the UK experience it is the independent television commission which is the regulator in the UK responsible for broadcast services, has taken on that responsibility of allocating network ID's.
Bob Greeney (ABA)
This brings another point that was suggested this morning about a reference centre against which to check your equipment. In the UK the independent television association which is the equivalent of FACTS has such a facility not the government.
Dick Barton (FACTS)
And that they charge for service. I can assure you if FACTS had something established like that it would be a fairly healthy charge. I think the element here is, what we actually need is someone who's independent and is entirely within the confidence of all of the participants who wish to use it. I'm not sure that FACTS has the same level of confidence in the non-members of FACTS.
Peter McAvock (DVB)
I can reserve a block of ID's now, if that's appropriate for Australia. What you do with them is largely your own business.
Geoffrey Tomes (GTV-9)
In setting the reservations, it is obviously a much broader spectrum than just the ABC and SBS 7, 9 and 10.we have all the regionals to think about and then some after that. We need to quantify how big a list of registrations we actually need.
Peter McAvock (DVB)
You just get 256 different network ID values.
Don Brooks (Foxtel)
The pay TV operators have been following the CT2C process with interest, we are very pleased that these standards that have been decided are coming very close to the DVB standards that pay TV operators already use. However, there are still a few differences. I would like to put it to the panel, is it usual for there to be some differences of between the different carriage mediums in a country? How do you view how we handle those differences?
Martin Gold (NDS)
In the UK, where there is experience of terrestrial transmissions and digital satellite transmissions, there is an interest in interoperability between the services. They are using different CA systems, different receiver software architectures, but nevertheless there are some possibilities there for achieving interoperability. We have at this stage a fundamental problem in that's one set of receivers has a terrestrial front end and the other set of receivers has a satellite front end. There is more to it than just doing something in the transmission to make it inter-operate. You actually need some hardware in the consumer's homes to achieve the interoperability. The regulator in the UK is interested in seeing simualcrypt implemented in the sense of the Conditional Access services will be available via both CA systems. That is something that is being implemented at the moment. That will achieve some limited interoperability in the context of additional hardware in the home relative to the boxes used for the individual media.
Geoffrey Tomes (GTV-9)
I think in the Australian context there are two major and a few minor differences between the standard DVB implementation of Foxtel, Optus or galaxy. The two major differences are that we are going to transmit high in definition video in the transport stream and we are including a provision for AC-3 audio, which wasn't in the Foxtel implementation. They are the two major differences. The DVB-T specification we are putting forward is in all senses fully interoperable with what Foxtel already have. The new system we are proposing here, for broadcast television, is fully backward compatible with what Foxtel have. If Foxtel have a problem, they have a forward compatibility problem, where their boxes in their current state will not decode high-definition television nor AC-3. That is a commercial problem that Foxtel have to wrestle with. Clearly from now on they would now adopt a process of buying boxes that do decode high-definition television. It has been suggested by some sectors associated with that service, they may even into a situation where they would buy the subscriber the box as an enticement to receiving discounted services. I do reinforce that we are fully interoperable and backwardly compatible with what is available on cable and satellite. That high level decoder and the MPEG audio and the AC-3 decoder will decode anything that the cable and satellite industry throw at it, if the right front end is attached.
There are three minor areas where we are in disagreement, because of early the implementation by the cable industry. One, we have a problem with parental guidance tables. FACTS have an arrangement with the ABA and it is going to be pretty hard for us to take the general public away from that arrangement. We also have some differences where we have to invoke country ID to guard ourselves against the time offset problem. I'm not sure that Foxtel even use country region ID at the moment. They are user tables in there that every country can use for its own purpose, allowed in DVB, and that's what we intend to do. Finally, the last one is content. There may be some minor differences in content genre between the cable industry and us. I believe that will be resolved between us. I don't see the three minor ones being show-stopping issues. Certainly the two major ones are a forward compatibility problem for the cable industry.
Darryl Drake (Optus)
First of all a comment on Geoff's comments. It is not really the cable industry. At the moment the cable systems are in fact analog systems. But there is a satellite, and there are something like 300,000 satellite DVB Compliant boxes in Australia right at the moment. They are DVB Compliant and it is somewhat of a concern to us that Australia has chosen to go with what we still regard as non-DVB Compliant technology using an AC-3 sound system. There may be different places to discuss this, but I am not at all happy with that. Is it the right trend, for what is an internationally open system to suddenly go into a proprietary system? I remember a couple of years ago an argument against DVB specifying a Conditional Access system, where exactly the same arguments were espoused as to why it shouldn't be adopted as a proprietary Conditional Access system. Now it is adopting a proprietary sound system. That was just a comment, it was not my question.
Darryl Drake (Optus)
My question is that there are lots of receiver problems, in fact my impression is that in the DVB satellite system there are lots of receiver problems. This is despite that the receivers in use have been very carefully selected after hundreds of thousands of hours of testing by people such as myself and various colleagues to sort out the problems those receivers used to have. We have got rid all the most of the problems, but the point is someone needs to do this. When you have a free market out there producing receivers, they have to go through some filtering process to make sure they actually work with your transmissions. Otherwise what you are going to find without doubt, is when the customer buys it in the shop it will be producing pictures, but next day or next week the sound unsynchronise with the video, or the video will be flashing on and off, the sound will be going funny. All this magnitude of problems will be going on. It is only by someone sorting out those things in the laboratory, and I am backing the idea of having a laboratory sort out these problems otherwise it really is going to be a bit of a disaster out there.
The second area of this is even when you have got the receivers working perfectly, the best of them from time to time lock up. I don't know of a single brand of receiver that does not do this. They vary from once a week to once a month to a year before they lock up. In other words they suddenly stop receiving pictures and you basically half to turn off the mains and turn it back on again. This is something we are quite familiar with for our computers, but you are not used to it with your TV set. You expect your TV set to continue working. The problem is as these TV sets get closer and closer to computers, they have exotic software in them and get glitches from the mains or whatever happens, sometimes it is something that is transmitted in the signal, and they do lock up. Maybe someone can canvas with a bit of experience how this problem can be overcome in other markets. To us it is a bit of a problem. My other question is, to make sure that your transmissions in fact are not causing such problems, what we are tending to use so far is the three levels of DVB or MPEG compliance. Do you need to comply with all those three levels of testing; do you expect green lights on all of the 50 odd tests from those three levels? I have never seen a box with green lights on everything. A there some more tests that need to be done on a real live basis? We do get unknown problems with the transmission that cause receiver problems but still seem to get through the testing on those three levels of compliance.
Ken McCann (NTL)
We are talking about the 1st, 2nd & 3rd priority compliance tests in ETR290. Those are a perfectly reasonable set of tests to use to give a good indication that there is probably not a problem in the bit stream, they are certainly not comprehensive. It explicitly says in the document that they are not comprehensive. You can certainly create a bit stream which will pass all those tests with flying colours and it will give a blank screen to the receiver. It's not a conformance test, it's a sensible set of tests to be used to indicate that a system that was previously known to be working, is still working. It is to catch common failure modes. It should not be regarded as more than that. The priorities of that are just looking at different layers of complexity going down the bit stream with what the most common failure modes are. In terms of trying to do more thorough conformance testing it's a very thorny issue that's been looked at and not resolved, first in MPEG, DVB and certainly in the UK in DTG. In the case of MPEG, part 4 of the specification, which documents a set of tests, which can be done and doesn't really do much beyond that. In the case of DVB there was ETR290 that went beyond that a bit and specified tests much more precisely and how they should be done. In the case of DTG there is a test bit stream which has been produced that will reasonably exercise all receivers. The really thorny problem that has not been resolved and that everyone would like to have a good solution to is, how can you carry out a test which will guarantee, if it passes this test, it will receive any bit stream successfully. Unfortunately the systems we are talking about are of such complexity that it is just not practicable to produce such a test. A number of times other ways of trying to solve this either by having a third party to mandatorily carry out a test, and then you have to have a stamp form of the regulator to say it has passed this. Therefore it is fit for use. The problem with that has been both one of practicality, in that it would take time for IRDs to go through that, and the whole process of the introduction of digital television has been very time critical in every single country it's been introduced. There has never been enough time to do it. The idea of adding another 3 to 6 months test phase in there has been extremely unpopular. There is also possible legal problems in that if there are problems in the future with half a million set-top boxes that have been passed by your independent test lab, who is responsible for that?
Dick Barton (FACTS)
I think we are getting the message that it is just not feasible to test everything. There was the other question that Darryl asked. Darryl just before I address it to the panel, I am not too clear, because it started of sounding like you have the odd receiver that was locking up, then when you got to the end, it like there is a transport stream error that locked up all the receivers. Now is it both situations or is it one or the other?
Darryl Drake (Optus)
We get instances of both of those. We get some receivers across Australia that randomly lock up at different times. They are probably mains spikes. The other ones are something in our transport stream, we still do not know what, simualtaneously right across Australia, IRDs will lock up.
Martin Gold (NDS)
I don't think on the receive sides that it is a unique problem to digital receivers. Increasingly now when consumer devices have embedded software in them, you will see there is some kind of reset button or there is a line in the instruction that says, if it stops working properly try unplugging it and re-plugging it. I think this is an endemic issue for product implementations that are more dependent on software. Obviously testing of the product is key to getting the reliability as high as possible, but I don't think exactly 100 percent is achieved in practice.
Dick Barton (FACTS)
Martin, I am a litle bit more worried about the possibility of something in the transport stream going out and locking up for the receivers. I can imagine someone turning off all the television in Australia by transmitting an incorrect transport stream. It is not an ideal situation from my point. Is that a worry or is it a feasibility what is likely to be the situation?
Martin Gold (NDS)
I think if the broadcaster transmits something highly misleading to the receiver, then the receiver will obey the instruction to do something highly misleading. There is not a lot you can do about that situation other than the broadcaster taking the trouble in his transmissions to have high reliability of his generation and transmission of data. If it is a case of glitches in the mains or interference in the transmission the receiver implementation that should the robust to those. If it is not, the problem is at the receiver end.
Dick Winston (ABC)
This is the one issue that scares the hell out of me with digital. It is Software. Today the only thing that causes the audience to ring me up and complain is if my transmitter goes off or my link to the transmitter dies. In the future by am going to have software problems added to that, over which I don't have a lot of control. I'm talking about software upgrades and a flexible platform where you want to be able to upgrade functionality and the like. But you've got to do so in a backwardly compatible manner, in the receiver, in the multiplexer, in the encoder. It's all got to work together. I could not support your thing strong enough that we need some reference testing.
John Begini (DVB Aust)
All this in an environment where some people cannot even tune their own TV sets.
John Ward (News)
What we are trying to do here is adopt the DVB standard with the minimum number of Australianisations possible. Of Jeff's major ones, HDTV, which is a government legislative requirement, and there's AC-3 that presumably from a DVB point of view was responding to market requirements. It suddenly occurred to me that I don't know what that the market requirements are, and where they have come from. What research has been done to determine the market requirements or has it just being good Dolby salesmanship? How have we got to AC-3?
Dick Barton (FACTS)
John, I can tell you this matter has been explored at length over the last three months, including a detailed examination by the receiver manufacturers. The result was a careful study by the same group that did a careful study to choose DVB. It was chosen as a package of technology, market aspects and all of the other aspects, which make good business sense for the package that goes with High Definition Television. All of those aspects were taking into account and the recommendation from the broadcasters was they wanted to use AC-3 as the system that would accompany HDTV to make a business success out of HDTV. Recognising that to insure backwards compatibility, with the other services that are there, the decoder should include MPEG 2, as in fact is built into the MPEG standard. That's basically it. If we are talking about compatibility, then the point Jeff is making is, none of those DVB Compliant receivers that Darryl's talking about, are capable of handling HDTV. Nor do I believe any of them are capable of actually receiving Terrestrial Television. I'm not too sure it is easy to upgrade them to do so. We are talking about satellite specific receivers that are basically Standard Definition. We are introducing a new service, we are making sure it has the backwards compatibility to allow it to comply with the other services to the extent it is feasible. We are suffering the position of being the very first to implement HDTV with DVB. That's meant we have had to make changes and I think DVB have been most helpful and most cooperative in upgrading their system to accommodate the needs for transmission of HDTV. That's why we are coming together on something where the differences are those things that really won't have any application outside Australia. The 7 MHz bandwidth shaping that we are doing. The logical channel descriptor is one of the UK found useful, we think it would be useful here. There are very few things like that, which are left in there. What will happen, I believe, by the time we get to June, the number of differences will be able to be put on two pages.
Peter McAvock (DVB)
I'd like to answer the question from a slightly different perspective. I don't wish to comment on the process that went on in Australia prior to and following the decision by the broadcasters to choose AC-3 for their Digital High-Definition Terrestrial Television Broadcasting, however within the DVB Project I would just like to explain that current situation and the previous situation regarding AC-3. Are Dolby good salesman? Yes of course they are. That is why the Dolby AC-3 audio system has been so successful within the DVD environment. That's not an issue, what is an issue is the fact that Dolby two years ago made a request for a private data specifier within the DVB-SI guidelines and codes that we maintain, which was granted. That private data specifier allows them a mechanism to carry AC-3 audio within DVB streams. The request we received from a number of sources, not just Australia, can we document that mechanism for carriage of AC-3 within the DVB specifications in order to make it possible to define a single mechanism for that carriage of AC-3 audio. There are a number of consequences of the work that we are currently doing. One of the consequences is NOT a change in the DVB recommendations for the transmission of HDTV, which currently specifies minimum requirements for the video and the audio. The minimum requirements for the audio are, and DVB still recommend, the use of MPEG Multichannel backwards compatible audio. We have recognised that in some circumstances AC-3 is the preferred option. In that case we suggest that you do the following in order to carry AC-3. So it is very important to understand where the DVB project itself lies. We are not seeking to destabilise the existing DVB specifications, however it would be foolish of us, as a project, to not consider documenting the ways of carrying proprietary systems within DVB which will be used in a number of environments. Australia is one but it is by no means the only one. And we are likely to see similar types of carriage systems being used in Europe, where there could be applications where AC-3 audio could be of use.
Darryl Drake (Optus)
I'd like to follow up on that because it seems to be a pretty emotive issue, this thing about AC-3. As I read the DVB document at the moment basically says that if you comply with DVB, you carry MPEG audio. It specifically says that, now presumably it is going to change so that it says you don't need to do that anymore, you can carry AC-3. Is that correct? If that is correct, then in the future what about the video. I remember when we started transmitting Digital Video on satellites in Australia, about five years ago, it was the GI system. This was before DVB was really in existence. It was quite a good video compression system but it wasn't in DVB. Suddenly you could get the scenario, that in the three years time, you need not transmit MPEG video any longer, you could transmit GI video. You could sort of see what the scenario could lead to. You start to think, what does really DVB mean? When we started we really pushed hard to change from GI based video to DVB based video about five years ago. We thought this is the light to the tunnel, here is a nice standardised open system. Now suddenly someone else is saying it is diverging away from that and we think that this is something that should not be taken lightly.
Ken McCann (NTL)
Just to clarify what the situation is. The AC-3 audio is an option, which may or may not be included in IRDs in the general DVB sense. Every IRD must be capable of decoding MPEG stereo. In terms of Broadcasting, in the general case were you do not know what the population of receivers is out there, then you should always transmit MPEG-1 stereo, even if in addition you may choose also to do AC-3. You may also choose to do MPEG 2 surround sound. In the specific situation where you know that all the receivers for that broadcast have the capability of AC-3, then there seems to be no reason for saying that you have to transmit a MPEG stereo bit stream. For that reason there is an exception made, that if you have knowledge that that is the case, then you are not forced into using simulcast. You would gain nothing by doing so.
Chris Middleton-Williams (Sony)
A question re the possible implementation in Australia of a 6 MHz channel in the amongst the 7 MHz channels. Do you see any potential problems, or do you have any advice as to the implementation of this with receivers moving between a 7 MHz and a 6 MHz channel. Has this occurred elsewhere in the world?
Peter McAvock (DVB)
Do we see a problem? Yes. Has this occurred elsewhere in the world? No.
Dick Barton (FACTS)
We know about the filter problem, but I am not too sure. The labs were going to do some tests on this. Communications LAB may have some later information on this than our European colleagues have got. The answer is we know it needs to be looked at, the labs have a receiver which they can use to see what happens if we can duplicate that operation into a single receiver. Basically the receiver will be probably still 7 MHz wide in terms of reception, how does it react to the foreign signals that get added in. I think you're looking at say channel 27 with two-way radio below it. I think that's probably a bit more specific than any experience that our European colleagues might have had.
Peter McAvock (DVB)
This is an interesting issue. We currently have DVB 6 MHz equipment, and the first implementation of the DVB 6 MHz equipment, is an 8 MHz front-end with the OFDM chipset purely and simply clocked at 6 MHz, with software appropriate to 6 MHz channel spacing. That was the first implementation and of course your immunity to anything that's happening in and around your 6 MHz channel was bananas. But it did work.
Dick Barton (FACTS)
I think what we're hearing is yes there are some potential problems and we better find out what they are and what the solutions are. I think that's what we are asking the laboratory to look at to see how we can get round it. I'm not too sure of what the density of use of the two-way radio immediately below it is, and whether that is going to have a significant impact on it. We need to find the answers out. I suspect if you are trying to talk about something that's squeezed in between two PAL channels at high-level, you might have a real problem. That does make life of bit difficult.
Dick Barton (FACTS)
I'd like to take the opportunity to close the seminar, I hope you've learnt something from today. For those of you that are in charge of people doing the engineering work, I hope you don't think waiting up near the end of the road. I think we are actually getting to the end of the on ramp of a complex system of highways. We have got a lot more work to do. I'd like to thank those who did the work on preparing the draft standard and the drafting group conveners. It is not my effort. It is the effort of a great team of people who have been working their guts out, to look at everything, examine it, and see how it should be applied. We all need to be thankful for the effort they have put in.
E-Mail Information:
Copyright
© Commonwealth of Australia 2000 -
Last update: 29/04/1999
This is the 9617th external access of this page