Television receivers are being developed to host resident interactive services, transmitted for example through a bidirectional retum channel or simply broadcast over the same channel as the video signal. In this context, ATVEF (Advanced TeleVision Enhancement Forum) specifies the use of a number of protocols such as IP multicast (Internet Protocol multicast) for transporting data for interactive television program enhancement services over a number of transmission media.
According to the ATVEF specification, when a service provider wishes to transmit an interactive service, he first has to transmit a message called an announcement, containing information describing the interactive service. This announcement is transmitted to a specific IP multicast address and to a specific port, known to all receivers (IP address 126.96.36.199 and UDP Port 2670).
Receivers compatible with the ATVEF specification continuously monitor this address/port couple. Their resident software modules retrieve the announcement, which contains a pair of IP addresses, one for the transmission of the interactive service (called the ‘content’), another one of the transmission of triggers. Triggers are messages for triggering a certain behavior of interactive services at predetermined moments.
Software modules resident in the receivers may require updates. For flexibility reasons, it should be possible to make such an update in remote fashion, i.e. to transmit the updated software modules to the receivers in situ. Such a transmission should obviously use some of the already available transmission media, such as the return channel (be it through the PSTN or the cable network, or another type of bi-directional communication means) or the television broadcast medium.
The ATVEF protocol stack (see FIG. la) carmot be used directly to transmit the update—or other types of binary data—, because the software in charge of retrieving the interactive service (e.g. a browser) is not able to interpret the content data which represents the resident software module update. This update is typically binary data, instead of the UHTTP data expected by the browser. This could result in unpredictable behavior at the receiver level. Modifying the browser to detect and process binary data would be impractical. In addition, transporting binary data using UHTTP is cumbersome, since this protocol has not been developed for such a purpose.
Nevertheless, it is desired to respect as much a possible the ATVEF protocol, to remain within the constraints defined by the broadcast tools.
The object of the invention is a method for transmitting binary data in a video transmission system comprising the steps of:
providing ATVEF announcements on a first predefined IP
providing ATVEF trigger and/or content transmission on a
first range of IP multicast addresses;
providing non-ATVEF announcements on a second pre
defined multicast address different from said first address;
providing non-ATVEF data transmission on a second
range of IP multicast addresses, exclusive of the first range.
According to an embodiment of the invention, said system comprises an emitter comprising a data inserter for inserting ATVEF and non-ATVEF information into a transmission signal, said method further comprising the steps of:
providing ATVEF announcements and non-ATVEF
announcements to the data inserter,
dynamic insertion of IP multicast addresses by the data
inserter into the amrouncements, in accordance with the first and second ranges.
According to an embodiment of the invention, the method further comprises the step of splitting each of the first and/or the second range of IP multicast addresses into a third and a fourth range, where the third range is reserved for automatic address detennination by the data inserter, and the fourth range is reserved for addresses which are predefined in the announcements provided to the data inserter.
According to an embodiment of the invention, ranges are distinguished by different IP address ranges, different port ranges or both.
According to an embodiment of the invention, at the level of a receiver, the method further comprises the steps of:
receiving a non-ATVEF announcement amrouncing trans
mission of receiver software update data, said announcement containing an IP multicast address on which signaling data describing the update data transmission is to be sent;
lister1ing to the address specified in the announcement;
retrieving the signaling data and storing it in a memory
which is not erased during download of the update data; launching of a loader program;
having the loader program retrieve the stored signaling
proceeding with the download of the update data based on
the stored signaling data.
Another object of the invention is an emitter device for broadcasting announcements in a transmission system compatible with ATVEF transmissions, characterized in that it comprises means for transmitting ATVEF announcements on a first predefined IP multicast address, ATVEF trigger and/or content data on a first range of IP multicast addresses, binary data announcements on a second predefined IP multicast address different from the first predefined address and binary data on a second range of IP multicast addresses, wherein the first and second address ranges are exclusive of each other.
According to an embodiment of the invention, the emitter comprises means for receiving an amrouncement, for determining whether the announcement comprises a predetermined IP multicast address in a first range, and in the negative, for selecting an IP multicast address in a second range, distinct from the first range, and for inserting the selected IP multicast address into the amrouncement.