Patent ID: 12200318

DETAILED DESCRIPTION OF THE INVENTION

FIG.1aillustrates modules of an exemplary device implementing this invention. It is to be noted that the invention may be implemented in any kind of computing device able to manipulate video files and is not limited to the device herein described. This device may be a recording device like a camera. It may have communication capabilities, for example a network camera with wired or wifi connection. It may be used as a media server using this communication module. For example, the device105is configured for encapsulating a video stream with annotated regions according to the invention. As illustrated, device105records a video source through a camera100, producing sequences of images that can be compressed by an encoding module105. An object recognition module110may be used to identify and locate one or several objects that can be tracked through a sequence of images to define regions of interest. These objects can be determined by image analysis after encoding or prior to encoding (as suggested with dotted line). The detected objects may move in the images over time and thus, potentially overlap at some point in time, appear or disappear. It is to be noted that the object recognition or detection step can be carried out offline, before the transmission of the video through a communication network, or online during encoding of the images issued by the video source and transmission of the encoded images. The detection may be handled by an external device, the device105then communicating with this external device in charge of content analysis for object recognition through the communication module. The recognized or detected objects onto the recorded images may be associated with a whole image or to partitions within an image (e.g. NAL units, slices, tiles, subpictures . . . ). As illustrated, the encoded images are encapsulated into a media file or into media segments in encapsulation module115before being possibly transmitted using a communication module120. The transmission may occur when a client requests the device server105to download the media file, or requests the device server for adaptive streaming of the file.

FIG.1bis an example of objects detected onto an image150. Each object may be described with a textual annotation, for example: a flower, a star, a person . . . .

FIG.1cis an example of detected objects onto an image155with corresponding picture partitioning (for example slices, tiles or subpicture represented by the dashed lines). For some detected objects, a corresponding image or sequence of images may be available as a media track (155-1,155-2or155-3). Images in this media track are composed of one or several portions of the complete image sequence.

FIG.1dis an example of a moving region of interest (165-1,165-5and165-10) into a sequence of images160(for example: a recognized face). On this exampleFIG.1d, the picture partitioning170is also depicted. The moving region is composed of the image portions overlapping with the object. The image portion composing the moving region of interest and their number may vary over time to follow the object in the image.

FIG.2illustrates a high-level view of the invention for associating annotations with a region of an image or of an image sequence. An annotated region210is linked to an entity200. An entity here is for example an image item that describes an image. This entity may also be another kind of item, a group of items, a track or samples within a track or even subsamples within samples of a track. The link between the annotated region and the entity may be, depending on the entity and according to various embodiments an item reference, an item property, a track reference, a sample description or a sub-sample description.

An annotated region210may be defined by a geometry220, for example as an anchor point and a shape. Several kinds of geometry can be defined: a point, a rectangle, a circle, a polygon, a binary mask. . . . Other geometries may also be used, such as a 3D box projected onto the image plane. The geometry may change along time: the anchor point or the shape or both.

An annotated region210may also contain or may be linked to one or more annotations230,231, and232. These annotations are used to store information describing or corresponding to the region210of the entity200. An annotation can be for example the focus location of the picture, a face detected in an image, an object detected in the image, a GPS location corresponding to an object in the image, a description for a part of the image, the text contained in a region of the image. . . . It may be user generated or machine generated, preferably as one or more null terminated character strings. A textual annotation is defined as an annotation comprising one or more character strings. It may be human readable. One of the character string may define the language of the text in the other, or others, character string. As for geometry, a given region may have annotations varying along time depending on the media content. For example a textual annotation may be described using the item property for user description ‘udes’ defined in HEIF.

FIG.3illustrates a first embodiment where an annotated region is described as an item (region item320) associated with a track. The encapsulation module while encapsulating a picture track or a video track310when receiving or extracting object information may create a ‘meta’ box in the file to declare a region item320in an ItemInfoEntry box. The track310may be a picture track (e.g. identified by a ‘pict’ handler type, like HEIF image sequence track) or a video track (e.g. identified by a ‘vide’ handler type, like an HEVC or VVC track stored in ISOBMFF or an ISOBMFF-based specification like HEIF, MIAF or any application format). The region item320has a specific item type and an item_ID not conflicting with other item or track or any other entity in the media file's ID. The region item320is associated with the track using an item reference box. The item reference type may be the generic ‘cdsc’ item reference type indicating that the region item provides some description of the track310. Alternatively, the item reference type may be of a more specific type, for example ‘rgan’ to indicate that the region item provides annotated region information. Using a more specific item reference type, provides more precise indication of the relationship between the track and the region item. This is an indication to parsers or media players on how to process an item. The region item may be associated with one or more item properties340as can be any HEIF item (e.g. using the ‘ipma’ box345). For example, an item property may provide the anchor point. Another property may provide the geometry of the region. A single item property may provide both location and shape. Alternatively, the anchor point or geometry are in the data part of the region item, in the data part of the file (e.g. ‘mdat’ or ‘idat’ box) and indexed by an ItemLocationBox. Another item property, representing a textual annotation, may be a ‘udes’ item property providing title or description or tags for the region. Optionally, metadata items350may provide further description of the region item320. For example, XMP metadata or MPEG-7 descriptors or vendor-specific metadata (e.g. in a ‘uuid’ box) may provide more detailed information on the region. This detailed information may not be human readable. The format for these additional metadata may depend on the format generated by the object recognition module110. This is indicated by the dashed arrow355. As well, when video or image content is available for the region item320, this item may contain an item reference335to this video or image item, called ROI image item330, providing a representation of the region. For this, an item reference of type ‘eroi’ (for “encoded region of interest”) may be used. It is to be noted that330may be a single image item, for example a picture of a detected person onto the video track. It may also be a set of alternative image items (different pictures of this detected person, grouping into an ‘altr’ entity to group). It may also be an image sequence track or video track, showing the person's face along the sequence in track310. The ROI image item330and the track310may have some relationship (not represented) indicated in the media file.

For this embodiment, the item reference315and the optional item reference335require the “to_item_ID” field of the ItemReferenceBox to reference, in addition to items, track or group of tracks (for example a set of alternative tracks). The semantics of the to_item_ID becomes: to_item_ID contains the item_ID or the group_id of an entity to group or the track_ID or the track group_id of respectively the item, entity group, track or track group referred to. This is relevant in media file mixing items and tracks and using unique IDs (as may be indicated by the ‘unif’ brand in the ftyp box of the file). This may be a simple way to associate item properties to a track. Extending semantics of ItemReferenceBox allow any item in the ‘meta’ box of a media file to be associated to a track in the ‘moov’ part of a media file.

In a variant, offering even more direct association of an item property to a track, the ‘ipma’ box may be extended to allow referencing, in addition to item ID or entity ID also track IDs. This may be useful for media files containing picture or video track and image items: some properties associated to image items may be associated with this mechanism to all samples of a video or picture track. The so-extended ‘ipma’ box may be indicated by a new version of the box or a flags value or when using a specific brand, for example the ‘unif’ brand. While describing annotated region as an item allows simple annotated region of an image sequence or video track, it is limited to “static annotated region”. A static annotated region is an annotated region that does not change (e.g. that is invariant) along the whole track310. The next embodiments allow dynamic annotated region.

FIG.4illustrates a first variant of a second embodiment where region annotations are stored in a different track than the media track (describing the video or sequence of images). In this embodiment, a first video or image sequence track410containing samples is described. A second track420, a timed metadata track420is dedicated to the storage of annotated regions for this video track as sample420x. The timed metadata track is associated with the video track with a track reference type set to ‘cdsc’ (415, for content description). As an example of timed metadata track, the ‘2dcc’ track from MPEG-B Part-10 may be used. A sample of a ‘2dcc’ track provides the anchor point and the sizes of a rectangular region of interest in the corresponding sample (e.g. with same decoding time) of the first track410. Optionally, the timed metadata track may also be associated with another video or image sequence track providing representation of the region of interest described in this timed metadata track. This may be indicated by the ‘eroi’ track reference type, as defined in MPEG-B Part-10. To distinguish a timed metadata track as defined in MPEG-B Part-10 from a timed metadata track according to this embodiment, a specific track reference may be used between the timed metadata track with annotations420and the media track410. For example, instead of the generic ‘cdsc’ one, a track reference type set to ‘rgan’ for “region annotation” can be set between a timed metadata track420and the video track from which the region has been identified or extracted.

It is to be noted that the timed metadata track420may not contain as many samples as the video track410it describes. For example, when the region of interest's position and size remain stable along time (as depicted on some time interval onFIG.1d) or when the position or size may be interpolated, there may be no sample420xcorresponding to a video sample. In this embodiment, the timed metadata track420is extended with a new sample group providing annotations (421-1,421-2. . . ) for the regions described in the samples420x. In a first variant, a new grouping_type ‘udes’421is proposed to associate group of samples with either a title, a description or a tag. A specific UserDescriptionSampleGroupEntry is defined as inheriting from SampleGroupDescriptionEntry (for example from TextSampleGroupEntry) to allow the indication of the following parameters:abstract class UserDescriptionSampleGroupEntry ( ) extends TextSampleGroupEntry (‘udes’)

{utf8string lang;utf8string name;utf8string description;utf8string tags;}with the following semantics:lang is a character string containing an RFC 5646 compliant language tag string, such as “en-US”, “fr-FR”, or “zh-CN”, representing the language of the text contained in name, description and tags. When lang is empty, the language is unknown/undefined.name is a null-terminated UTF-8 character string containing human readable name for the item or group of entities. If not present (an empty string is supplied) no name is provided.description is a null-terminated UTF-8 character string containing human readable description of the item or group of entities. If not present (an empty string is supplied) no description is provided.tags is a null-terminated UTF-8 character string containing comma-separated user-defined tags related to the item(s). If not present (an empty string is supplied) no tags is provided.

It is to be noted that in this variant, since the user description sample group entry provides the same parameter as the ‘udes’ item property from HEIF, the same 4 cc is used for the grouping type. This allows players to reuse the same parsing code for sample group or item property with this type. In an alternative, a different 4 cc may be used, especially if only a single text parameter is preferred to describe an annotated region (‘rdes’), for example as follows:abstract class RegionDescriptionSampleGroupEntry ( ) extends TextSampleGroupEntry (‘rdes’)

{utf8string lang;utf8string description;}with the same semantics as in previous variant.

For these variants, the new sample group entry for region annotation (‘rdes’ or ‘udes’ or any other dedicated 4 cc) permits the association of group of samples with a user-defined name (e.g. title, name, description, or tags); there may be multiple such properties, which shall have different language codes (different values for their lang parameter). When several instances of the new sample group entry for region annotation (‘rdes’ or ‘udes’ or any other dedicated 4 cc) are associated with the same group of samples, they represent alternatives possibly expressed in different languages and a reader should choose the most appropriate. These alternatives may be distinguished by the grouping_type_parameter, for example set to a value ‘lang’ or ‘reusing the ‘mela’ four character code for “Media language”, as for the differentiating attribute in the track selection box. At most one the new sample group entry for region annotation (‘rdes’ or ‘udes’ or any other dedicated 4 cc) with the same lang value should apply to the same group of samples.

This embodiment may apply even for static region by defining the ‘udes’ or ‘rdes’ sample group as being static.

In a variant for this embodiment where the region annotations are stored in the track providing the location and size of the regions, the annotations (420-1,420-2. . . ), instead of being declared as a sample grouping may be stored in a new definition of the samples420x. For example, a new sample entry type ‘2dca’ may be defined as follows:

The 2D Cartesian coordinates with annotation ‘2dca’ sample entry provides spatial information related to the referenced track expressed in a two-dimension Cartesian coordinate system, optionally with a textual description (human-readable) of the region. Such sample indicates region geometry and optionally annotations, for example as an additional string parameter that may be an empty string. The length of the string is determined by the sample size indicated in the appropriate ISOBMFF box: The 2D Cartesian coordinates sample may be defined as follows:

aligned(8) class 2DCartesianCoordinatesSample {unsigned int(16) top_left_x;unsigned int(16) top_left_y;unsigned int(16) width;unsigned int(16) height;unsigned int(1) interpolate;unsigned int(7) reserved;utf8string  annotation;}top_left_x and top_left_y give respectively the horizontal and vertical coordinate of the top-left corner of the rectangle region associated with the media sample of the referenced track.width and height give respectively the width and height of the rectangular region associated with the media sample of the referenced track.interpolate indicates the continuity in time of the successive samples. When true, the application may linearly interpolate values of the ROI coordinates between the previous sample and the current sample. When false, there shall not be any interpolation of values between the previous and the current samples and where annotation is a null-terminated UTF-8 character string containing human readable description of the ROI. If not present (an empty string is supplied) no description is provided. When the interpolate flag is set, it is expected that the interpolated samples match the presentation time of the samples in the referenced track. For instance, for each video sample of a video track, one interpolated 2D Cartesian coordinate sample is calculated. For the annotation, the same annotation repeats in interpolated samples.

FIG.5illustrates a second embodiment of the invention. In this embodiment, region annotations are in a different (metadata) track distinct than the media track. A first video or image sequence track510contain samples. These samples may be NAL unit based samples. A second track520, a timed metadata track is dedicated to the storage of regions positions and sizes for this video track510as samples520x. The timed metadata track is associated with the video track with a track reference type set to ‘cdsc’ (515, for content description). This second track520may be associated with an ‘eroi’ track reference type to another media track (not represented) providing encoded version of the region of interest. A third track530is created by the encapsulation module to provide the region annotations as samples535x. This track530is associated with the second track520providing region position and sizes with a new track reference type dedicated to the indication of region annotations ‘rgan’545. When parsing the track reference345, a parser or media player is informed that the third track530provides annotation for the regions defined in the second track520.

The new track reference type respectively allows encapsulation module and parsers to describe and identify this track as one track dedicated to the storage of annotations for regions.

The handler type for such third track530may be set to ‘text’ to indicate that samples contain textual annotations and that the associated decoder will process only text data. The textual annotations may be user-generated or machine generated. It describes a region identified in or extracted from a video or image sequence track. The textual annotation in the sample of such track may be accompanied with a parameter indicated the language for this textual description. As an alternative, the language is indicated in the media header box (language field). The former is preferred when textual description in alternative languages are provided for a region. Samples for textual description may or may not be aligned with samples of the second track or of the first (media) track. When not aligned, the textual description applies until a new sample providing a new textual description is defined in the third track. The sample duration are set accordingly to indicate these durations. For fragmented files, it is recommended to provide a textual description sample for the first sample of the fragment. The payload of the sample is a null terminated string (when language is not present) or consist in two null-terminated strings (when language is provided within the sample). The sample size in the appropriate ISOBMFF box (e.g. ‘stsz’ or ‘stz2’) provides the lengths of these strings.

According to this embodiment, a media file may contain (or reference through the data reference box ‘dref’) multiple “third tracks” providing annotations for the regions described in the second track. Each of these third track has a track reference of type ‘rgan’ indicating that each provides annotations for the regions described in the referred second track. The set of third tracks may be declared as a group of alternate tracks. In this case, only one should selected and used to render the region annotation on a media player interface. This could be the case, for example, when third tracks provide alternate language for the region annotations. This may be further indicated in a track selection box with a differentiating attribute set to Media language ‘mela’. There may be cases where the set of third tracks that provides annotations for the regions described in the second track are rather complementary than alternate. For example, there may be a first third track providing user annotations like a title, a second third track providing machine generated tags, a third track providing even more detailed information like for example a WebVTT track (providing annotation but also rendering instructions) or an MPEG-7 track. Some of the third tracks (e.g. containing structured data) may then have a handler-type set to ‘meta’ rather than ‘text’. In this case, the parser or media player may select and render on a client interface the different annotations. The client may provide in a GUI means for the user to adapt or select the level of annotation he or she would like to see. In a variant, the specific track reference type between the track defining the region position and size and the track providing the annotations may be from track520to track530. This is relevant for parsers because if they decide not to process the track describing the region position and size they may not be interested in the annotation track either. At the reverse, when processing the track520, following the specific track reference545, it will get the track or group of tracks providing the annotations. Having the track reference545in this direction is of interest when there are multiple alternative or complementary “third” tracks, the track reference directly referencing the alternate group of tracks in the track_IDs parameter.

FIG.6illustrates a third embodiment where annotated regions are stored in the ‘meta’ part of a media file601while track description is within the ‘moov’ part of the media file600. In this embodiment, the media file is augmented with regions annotations that are stored within the file-level ‘meta’ box601.

In this embodiment, the position and sizes of the regions are stored in a timed metadata track600-2. Optionally, a video or picture track600-3provides encoded representation of some regions.

In a first variant, region annotations are declared as item properties of type ‘udes’ (for example in the ‘ipco’ box), and the track600-2providing the region position and size (e.g. the geometry of the region), contains a sample grouping640providing SampleToMetadataltemEntry (from ISOBMFF specification). In other words, group of 2dcc samples from the track600-2may be associated with one or more item property of type ‘udes’, as illustrated by the arrows620or630. The item_ID in the SampleToMetadataltemEntry is set to the implicit ID of the property in the ‘ipco’ container box. Indeed, ‘ipco’ box implicitly defines an identifier that corresponds to the position of an item property in the ‘ipco’ box. Several groups of samples may be linked to a same item property providing annotated region. Some item property providing annotations or user descriptions may not be referenced by samples from the timed metadata track600-2(for example, because they are used for other image items also declared in the media file). The sample grouping640may be a default grouping when all the samples describing the position and size of a region have the same annotation.

In a second variant, to explicitly indicate that the IDs used in the sample group entries640correspond to identifiers of item property, a new grouping type is defined to indicate that samples are actually associated not to items but explicitly to item properties. The syntax of this new grouping type may be as follows (the 4 cc and the name of the sample group entry is here as an example):

class SampleToPropertyltemEntry( )extends SampleGroupDescriptionEntry('stpi') {unsigned int(32) property_type;unsigned int(32) num_items;for(i = 0; i < num_items; i++) {unsigned int(32) property_index[i];}}

The property_type is an optional parameter indicating the 4 cc corresponding to the type of property to which samples are associated. When present, the property_index may count only properties of the specified type. When not present (or by default), the property_index is the 1-based index (counting all boxes, including FreeSpace boxes) of the associated property box in the ItemPropertyContainerBox contained in the same ItemPropertiesBox. The value 0 may be reserved, because it would indicate no association to any property. This can be signalled by not mapping samples or NAL units to a property.

According to a fourth embodiment, the video or picture track itself contains or references the annotated regions.

In a first variant, depicted onFIG.7, the media file has a ‘moov’ part describing a video or picture track701and a ‘meta’ part710providing region annotation description, for example as item properties (711-1or711-4) declared in the ‘ipco’ box711. The media track701contains NALU-based samples, each representing an image (or a partition of an image, for example a slice, a tile or a subpicture). This track may be fragmented along time. The video track701contains two sample groups702and703in the sample table box. The first sample group702provides the position and size of regions of interests identified or extracted by the object recognition module110. For example, the sample group description entry702-1provides a description of a region identified within the group of samples701-1. For this purpose, the encapsulation module may use the existing ‘trif’ sample group or any sample group providing location and shape of an image region. The second sample group703provides annotations for the regions described by the first sample group702. As an example, the sample group description entry703-1provides a reference (720) to an annotation for the group of samples701-1. The grouping type may be the ‘stmi’ or ‘stpi’ sample grouping as described in the previous embodiment. onto the video or picture samples. The second sample group associates samples or group of samples of the video or picture track to one or more item properties in the ‘meta’ box. As an example, the second sample, group703associates the first group of samples701-1to the item property of type ‘udes’711-1and the second sample group703also associates the group of samples701-3to the item property711-4. It is to be noted that for region annotation, groups of samples are mapped to ‘udes’ item properties, but the same would apply when mapping samples of a media track to any kind of item property. NAL units (with the NALU mapping mechanism), samples or group of samples of a media track may be mapped to item properties through a ‘stmi’ or ‘stpi’ sample group like703. In such case, the first sample group702becomes optional, because dedicated to regions. Moreover, with default sample grouping, this could be an easy way to associate item properties to all the samples of a track. This could be an alternative to the embodiment ofFIG.3or to the extensions of the ItemReferenceBox to also reference tracks. The two group of samples between702and703may be aligned or may be not aligned. When aligned, this means that each region described in the first sample group is associated to an annotation property. When not aligned, this means that one annotation property may apply to different regions described in the first sample group or that one region in the first sample group may have several annotations. Both sample groups may use the properties of sample group like default, static or virtual sample grouping when the grouping_type allows it. The first and second sample groups may also be used for samples but also for NAL units through the NALU mapping mechanism.

In a variant, the video track contains a sample group to associate groups of samples to region item (like320). This means that both geometry and annotation of detected or extracted regions from the media track701are described in the meta part of the media file710. This would avoid the declaration of the first sample group702providing the position and size of these detected or extracted regions of interest.

In another variant, depicted onFIG.8, the media file800has only a ‘moov’ part. The media track is self-contained or self-described, meaning that it is not related to item properties or to additional tracks. In this variant, the media track800has a sample group mechanism to describe the region annotations.FIG.8depicts an example of two distinct sample groups802and803but there could be a single one merging the properties from the two sample group description entries of802and803. Such merging may be interesting when the group of samples in802and803are aligned, thus saving description bytes for one SampleToGroupBox and one SampleToGroupDescriptionBox. This is the case where a same group of samples has the same region annotation and a same region description (e.g. location, size . . . ) for the duration of this group of samples. Back toFIG.8, the media track801contains a combination of a first sample group of a grouping type providing a position and size of a region (e.g. ‘trif’ sample group802) and a second sample group803of a grouping_type providing textual description for group of samples (like the ‘udes’ or ‘rdes’ from previous embodiment). As an example, the group of samples801-1may be associated to a first sample group description entry802-1and to a second sample group description entry803-1. While the figure illustrates same group of samples mapped to two different sample group description entries, the group of samples mapped to802-1and803-1may be different. This keeps the annotated region simple because all information is stored in a single track, especially for media streaming use cases, thus avoiding transmission delays and synchronization issues in the reception of the data for the different tracks. A limitation is that the roi or region position may not move on a sample basis, but only on a fragment basis, when a new sgpd of type trif (or type for the position and size of a region) may be defined. This embodiment also allows annotations on a subsample basis (e.g. range of NAL units, slice, tile or subpicture) when a first sample to group box first maps samples to NAL unit patterns, through a NALU MapEntry, and this NALU Map entry maps NAL units to a sample group description box containing a new sample group entry (e.g. the ‘rdes’ or ‘udes’ from previous embodiment or any other dedicated 4 cc). In variants where annotations relate to full image, the first sample group802describing the regions becomes optional, only the second sample group803may be present in the file. As well, when used with a NALU mapping mechanism, and when annotations correspond to partitions in the sample or image (e.g. slices, tiles or subpictures) and that these partitions correspond to one or more NAL units, the first sample group may be optional. If the media track801contains samples corresponding to partition of an image (e.g. HEVC tile track or VVC subpicture track), annotation may be associated to sample or groups of samples of such track via the second sample group803, making the first sample group802optional.

FIG.9is a schematic block diagram of a computing device900for implementation of one or more embodiments of the invention. The computing device900may be a device such as a micro-computer, a workstation or a light portable device. The computing device900comprises a communication bus connected to:a central processing unit901, such as a microprocessor, denoted CPU;a random access memory902, denoted RAM, for storing the executable code of the method of embodiments of the invention as well as the registers adapted to record variables and parameters necessary for implementing the method according to embodiments of the invention, the memory capacity thereof can be expanded by an optional RAM connected to an expansion port for example;a read only memory903, denoted ROM, for storing computer programs for implementing embodiments of the invention;a network interface904is typically connected to a communication network over which digital data to be processed are transmitted or received. The network interface904can be a single network interface, or composed of a set of different network interfaces (for instance wired and wireless interfaces, or different kinds of wired or wireless interfaces). Data packets are written to the network interface for transmission or are read from the network interface for reception under the control of the software application running in the CPU901;a user interface905may be used for receiving inputs from a user or to display information to a user;a hard disk906denoted HD may be provided as a mass storage device;an I/O module907may be used for receiving/sending data from/to external devices such as a video source or display.

The executable code may be stored either in read only memory903, on the hard disk906or on a removable digital medium such as for example a disk. According to a variant, the executable code of the programs can be received by means of a communication network, via the network interface904, in order to be stored in one of the storage means of the communication device900, such as the hard disk906, before being executed.

The central processing unit901is adapted to control and direct the execution of the instructions or portions of software code of the program or programs according to embodiments of the invention, which instructions are stored in one of the aforementioned storage means. After powering on, the CPU901is capable of executing instructions from main RAM memory902relating to a software application after those instructions have been loaded from the program ROM903or the hard-disc (HD)906for example. Such a software application, when executed by the CPU701, causes the steps of the flowcharts of the invention to be performed.

Any step of the algorithms of the invention may be implemented in software by execution of a set of instructions or program by a programmable computing machine, such as a PC (“Personal Computer”), a DSP (“Digital Signal Processor”) or a microcontroller; or else implemented in hardware by a machine or a dedicated component, such as an FPGA (“Field-Programmable Gate Array”) or an ASIC (“Application-Specific Integrated Circuit”).

Although the present invention has been described hereinabove with reference to specific embodiments, the present invention is not limited to the specific embodiments, and modifications will be apparent to a skilled person in the art which lie within the scope of the present invention.

Many further modifications and variations will suggest themselves to those versed in the art upon making reference to the foregoing illustrative embodiments, which are given by way of example only and which are not intended to limit the scope of the invention, that being determined solely by the appended claims. In particular the different features from different embodiments may be interchanged, where appropriate.

Each of the embodiments of the invention described above can be implemented solely or as a combination of a plurality of the embodiments. Also, features from different embodiments can be combined where necessary or where the combination of elements or features from individual embodiments in a single embodiment is beneficial.

In the claims, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. The mere fact that different features are recited in mutually different dependent claims does not indicate that a combination of these features cannot be advantageously used.