FR2972321A1 - Method for aggregation and formatting of video on e.g. telephone, involves publishing generated document scene, and adapting step of generation chain of scene document to satisfy constraint associated to output format of generation chain - Google Patents

Abstract

The method involves formatting a metadata extracted starting from a set of heterogeneous structured data sources (21) i.e. XML document. A scene template (31) i.e. dynamic structure document, is filled with formatted metadata in order to generate a scene document (4). The generated document scene is published, and a step of generation chain of the scene document is adapted to satisfy a constraint associated to output format of the generation chain of the scene document. The template of scene is overlapped with another template of scene. Independent claims are also included for the following: (1) a system for aggregation and formatting of multi-media contents for multimedia terminals (2) a computer program product implemented on a memory medium, comprising a set of instructions for implementing a method for aggregation and formatting of multi-media contents for multimedia terminals.

Description

The invention relates to the technical field of aggregation and formatting of multimedia contents on multimedia terminals. Hereinafter, "multimedia content" denotes any digital representation comprising at least one multimedia scene which is generally described by a scene document specifying the arrangement, in space and time, of multimedia objects which find there. More specifically, a multimedia scene consists of an initial scene that can integrate a plurality of discrete multimedia objects (text, basic graphic elements, animations for example) or continuous (audio content, video content for example) as well as possibly scene transformation elements to make it evolve from one state to another either in time or by an interactive action. Moreover, here "multimedia terminal" means any user equipment (mobile or fixed) able to receive and display a multimedia scene such as a mobile communication terminal (a telephone, a smartphone, a PDA for example), a computer, a television, or more generally a means of displaying multimedia information (news, transport schedules). The technological advances of the means of communication aim, in particular, at developing the capabilities of multimedia terminals to support a multimedia service of ever better quality. The visualization of a multimedia scene on the screen of a user terminal constantly arouses the need for an increasingly fluid and rapid availability of multimedia content. This need is particularly felt in the multimedia market on low-speed networks, such as 3G wireless networks, for low-resource terminals such as smartphones or personal digital assistants (PDAs). "Reduced resources" means the capacity of connectivity (3G, Wifi, cable for example), codecs, V007 B001 FR / TQD

terminal memory, and the power, for example, of the multimedia terminal. As a result, the emergence of low-resource multimedia terminals has brought up the limits of current multimedia content delivery techniques. The provision of multimedia content includes, in particular, the generation of scene documents: in this phase, an abstraction of the scenes is made using various descriptive methods such as BIFS (Blnary Format for Scene), XHTML (eXtensible HyperText Markup Language), SVG (Scalable Vector Graphics), Flash, SMIL (Synchronized Multimedia Integration Language). This phase furthermore comprises the adaptation of the generated content to the constraints related to the multimedia terminals; - the publication of the generated scene documents: the publication is done in a specific format according to a particular mode (in broadcast, or on IP for example) up to the device of reading and / or visualization (browser, Flash reader, BIFS, for example) to be displayed in a multimedia scene; and - the management of the modifications or updates of the displayed multimedia scenes related to the user interaction or to the temporal actions. There are a large number of prior methods for aggregating and merging data into a single document, as well as for publishing or transforming the produced scene document.

As far as aggregation is concerned, the document produced is usually static and formatting aspects are sometimes proposed within the processing chain. This aggregation step can take place at the level of the client itself (the multimedia terminal) using script (AJAX for example); or - from a remote server to the recovery of the document (PHP, JPS for example) by the client. V007 B001 FR / TQD

In the latter two cases, the design and formatting are done in a single process. In a third category of system, the aggregation is done on the server and the produced pages are static although they can be generated (and thus different) with each new request of a client (system CSS + MODEL + DATA for example) . For the generation of a multimedia scene, there are also a multitude of processes and systems such as Flash generators and Web toolkits to generate dynamic presentations (Gmail® web pages for example).

In terms of transformation, there may be mentioned, for example, methods based on the XSLT (eXtensible Stylesheet Language Transformations) language. This language makes it possible to transform an Extensible Markup Language (XML) document into another document (often XML too). The produced document is then static and does not evolve in time. The known processes and systems are imperfect, in particular because: - most existing processes only produce static documents (which do not evolve over time). The user is then forced to request the page again if he wishes to obtain the modified page; most known systems are designed to process only one type of format. Their generation chains are built entirely around the output format. So you need as many generation chains as formats that you want to address. Some channels only produce proprietary formats (Flash for example); some solutions do not include a post-injection formatting step of the raw data. It is therefore necessary to format the data before injecting them into a model - which poses problems when one does not necessarily know the final design of the document; - for some solutions where the raw data are formatted at the level of multimedia content generation (jsp, php, AJAX by V007 B001 FR / TQD

example), formatting is often done when the customer requests a document. It is then necessary to redo the entire formatting layer as soon as the design is modified; - the existing processes are not specifically oriented for broadcast broadcasting; - Existing processes must generally be terminated when modifying data entry sources, or service models or the processing workflow; the costs of implementation, evolution and maintenance of the known systems are generally very high; - each client can not have an optimal version corresponding to its configuration; - The routing of complex multimedia content described using existing description templates is still a difficult task. An object of the present invention is to overcome the disadvantages of the methods and devices of the prior art. Another object of the present invention is to make multimedia content available as automatically, quickly and generically as possible. Another object of the present invention is to propose an abstraction method for the description of a multimedia scene. Another object of the present invention is to propose a method for adapting multimedia contents to multimedia terminals.

Another object of the present invention is to define a multimedia framework covering the multimedia content supply chain. Another object of the present invention is to provide a model for describing rich multimedia scenes (which can be composed of text, 2D / 3D graphics, video, images and audio). V007 B001 FR / TQD

Another object of the invention is to provide users with dynamic multimedia content, generated automatically in different formats. Another object of the present invention is to provide a visual, interactive and dynamic content generation engine, independently of the output format, the transport mode, and the multimedia terminals. Yet another object of the present invention is to adapt the multimedia content to various constraints related to the context of use (or consumption) of the multimedia content.

It is proposed, according to a first aspect, a method of aggregating and formatting multimedia contents intended for multimedia terminals, this method comprising: a step of formatting metadata extracted from a plurality of structured source data heterogeneous; a filling step, with at least one formatted metadata, of at least one scene template in order to generate a scene document; a step of publishing the generated scene document; a step of adapting at least one step of the generation chain of the scene document to satisfy at least one constraint. This method may further include a step of nesting scene templates. According to a second aspect, there is provided a system for aggregating and formatting multimedia contents intended for multimedia terminals, this system comprising: a formatter arranged to format a plurality of extracted metadata from a plurality of data heterogeneous structured sources; V007 B001 FR / TQD

a scene manager arranged to register the nesting of scene templates filled by the formatted metadata in order to generate a scene document; a publication module responsible for relaying the generated scene document; a controller configured to retroact on the generation chain of the scene document to satisfy at least one constraint. Other characteristics and advantages of the invention will appear more clearly and concretely on reading the following description of preferred embodiments, which is made with reference to the appended drawings in which: FIG. 1 schematically illustrates a representation functional of an embodiment; Figures 2 to 7 schematically illustrate functional modules, taken alone or in interaction, according to different embodiments. In Figure 1 is illustrated a generator 1 of scene documents 4 from heterogeneous structured source data 21. The purpose of the generator 1 is to aggregate, for example from web sites and / or databases 2, source data to provide in real time multi-format scene documents 4 independent of heterogeneous structured input source data. It should be noted that here we mean by "dynamic structured document" a representation defining a set of nodes connected together forming a tree (or a scene tree). In accordance with the general notion of tree, it consists of nodes each of which has an arbitrary number (possibly zero) of children (or leaf nodes) and exactly one parent. The scene document template 4, used hereinafter, extends the previous tree definition by adding a differentiation of the nodes into two categories: document nodes, generally leaf nodes, describing the static internal structure of the document (with grouping node tree) and the content itself of the document; V007 B001 FR / TQD

command nodes describing commands for updating the structure of the document. These commands are inserted in the document itself and their triggering events depend on the language associated with the model (time event, user action, reaction to a modification of the document for example). Thus, a dynamic structured document contains, in the same tree, an initial description of a static document and a set of commands applicable thereto, thus attributing the dynamic dimension. A change made to a multimedia scene can therefore be seen as an insertion, deletion or replacement of nodes or sheets, equivalent to an update operation of the tree. The scene document generator 4 comprises: a formatter 11 arranged to format extracted metadata from the structured source data 21 (an XML document for example). The extracted metadata consists of the attributes and contents of the elements of the document 21, hereinafter referred to as keys. The formatter 11 comprises a plurality of unitary formatting modules arranged in a chain and whose outputs can relate to the temporal, spatial, or interactive aspect of a scene; a scene manager 12 provided with a scene template database 31 (that is to say models) and configured to register the nesting of scene templates 31 filled with the keys in order to obtain a document 4. A scene template 31 is a dynamically structured document declaring nodes for receiving the keys 122, and anchor points 123 for supporting the nesting of other scene templates 31. The scene manager 12 thus has an instantaneous view on the tree structure of the scene templates 31 relating to the structured document 21. A publication module 13, located at the output of the scene document generator 1, and responsible for relaying the scene document 4 established by the scene manager 12 or to request, from the latter, the instantaneous state of a scene. V007 B001 FR / TQD

The data injected into the input of the generator 1 comes from various uncorrelated data sources 2 not having knowledge of the models - obtained by nesting the scene templates 31 - to be completed. This data can not be inserted as is in document templates. For this, the formatter 11 is configured to allow the formatting and enrichment of the input raw data before insertion into the models. With reference to FIG. 2, the formatter 11 is preferably composed of a plurality of unitary formers 111-114 connected to each other.

Advantageously, unitary instructors 111-114 make it possible, by combination, to obtain "formatting blocks" carrying out complex functions while maximizing the reuse perspectives of each unitary trainer 111-114 (or each elementary block). The instructor 11 declares input keys on which he performs one or more elementary operations using the unit instructors 111-114 to produce output keys. Thus, one or more outputs that can be predicted from corresponding input values can be produced by the instructor 11. It should be noted that a unitary trainer 111-114 may not have an input key (respectively, a key of exit). For example, a unitary formatter 113 may generate output values without the need to collect input data (e.g., a unitary formatter giving the current time). The trainer 11 also manages the updating of the keys, either at the input of the module (data injected into the generator 1 via the dedicated interface) or at the output of the unit trainers 111-114. The consideration of key updates works on an event mechanism. The updating of a key at any point of the formatting chain 110 causes the changes to be propagated step by step through the various unitary instructors 111-114 according to an algorithm ensuring the execution of the formatting graph in preventing the appearance of infinite loops. V007 B001 FR / TQD

With reference to FIG. 3, the keys 122 available at the output of the formatting chain 110 are connected to the modules 121 of scenes obtained by nesting scene templates 31 loaded in the scene manager 12. The nesting of the scene templates 31 is done using anchor points 123. Updating an input data of the formatting string 110 results in an update of one or more keys 12 scene manager input. This scene manager 12 then applies the corresponding modification to the module 121 of scenes and generates an event (a command) corresponding to the update performed. The role of the scene manager 12 is mainly to register and manage the links between the scene templates 31 loaded therein from the database 3. Indeed, the creation of rich scene documents 4 from simple documents is carried out by nesting scene templates 31 previously loaded into the database 3. Having at all times a knowledge of the links between the various scene templates 31 (arrows, in FIG. 3, linking the anchoring points 123 of a scene template 31 to another scene template 31 within the scene module 121), the scene manager 12 is able to perform on demand a scene document reconstruction corresponding to any sub-part of its scene tree. . Given an entry point (root scene), it suffices to traverse the tree in a descending way by recursively proceeding to the nesting of the child scenes on the anchor node of their parent.

In one embodiment, the scene manager 12 is a container of a "cloud of scenes" connected to each other, and each scene of which evolves within this container independently of the others, and generates differential events to signal its setting. day. In addition, the creation and deletion of links between the different scenes also trigger events (corresponding to a node insertion in the case of a connection creation, or to a node deletion for a break). These events are exposed at the end of the module, so other modules can be listened to

V007 B001 FR / TQD

of these events to make an interpretation: this is the case of the module 13 of publication. Therefore, the output interface of the scene manager 12 can provide a plurality of functions, mainly: the relaying of differential events (commands) and the construction (on request) of documents by nesting scenes (that is, templates). stage) connected to each other. The publication module 13 is at the output of the scene document generation chain 4. Its role is to perform the export of a scene tree. For this purpose, the publication module declares to the scene manager 12 as being in tune with a given scene, and will relay events for this scene and all its scenes children. The publication module 13 may, in addition, at any time request the scene manager 12 to provide it with the current state of this scene, it then obtains an aggregated document from the declared root scene. Depending on the mode of use of these two features provided by the scene manager 12, three distinct categories of publication emerge: a static publication: the publication module 13 does not interpret the events emitted by the scene manager 12. It retrieves the aggregated document (periodically or not), then exports it in a suitable format; a dynamic publication: the publication module 13 carries out a relay of events to a third party application, optionally performing a prior transformation of these events to satisfy target language constraints. The publication module 13 is not concerned with the overall state of the scene; a mixed publication: simultaneous use of the two modes of operation described above. The publication module 13 makes it possible, in fact, to recover the current state of the scene to interpret / transform the events it receives. It should be noted that all the modules of the scene document generator 1 (ie, the trainer 11, the scene manager 12, and the

V007 B001 EN / TQD n

publication module 13) are controllable via control interfaces 14-16. These control interfaces 14-16 give the possibility to one or more external operator (s) (human or not) to configure in real time the entire generation chain.

Indeed, the control interface 14 makes it possible: to configure the trainer 11: creation / deletion and the linking of the unit trainers 111-114, control of the unit trainers 111-114 (if they offer the possibility), management of the trainer graph (links between the unit trainers 111-114). Thus, it is possible, by simply building a formatting chain by association of unitary trainers 111-114, to obtain at the output of the trainer 11 a collection of keys 122 (ie formatted metadata) used. shaped for insertion into the scene modules 121, including scene templates 31 and supported by the scene manager 12; to configure the scene manager 12: connection of the keys 122 of the scene modules 121 to the output keys of the formatter 11 (ie the metadata formatted by the formatter 11), creation / deletion of connections between the different models of scenes included in the scene manager 12 (making / unmounting scene templates 31 by using the scene manager 12. The scene manager 12 thus makes it possible, as a cloud container of interconnected scenes, to perform, on request from the control interface 14, the reconstruction of all or part of a tree of scenes); to configure the publication module 13 according to the function performed by this module: parameterize the publication mechanisms of the aggregated data. Furthermore, the scene template injection interface 16 represents the entry point of the scene templates 31 into the scene manager 12. In one embodiment, a scene template 31 includes an XML document declaring a set of keys 122 and anchors 123. The V007 B001 FR / TQD

generator 1 is able to extract these meta-information from the scene template 31 thanks to the use of a namespace reserved for this purpose. The data injection interface 15 makes it possible to supply the formatter 11 with heterogeneous structured data (an XML document for example). The data intended to fill the document templates is integrated into the generator 1 as an XML data stream. When injecting an XML feed into the string, a key collection is generated by following a fixed BOM: the root element of the document is designated by its name (XML tag name) the kth child element with the same name elementName is designated by elementName [k-1] attribute attributeName of an element is designated by #nameAttribute the textual content of an element is not designated by a particular name, but, if there is no no specified attribute name, it can be implicitly designated; key names can be generated recursively by separating the different components by a special character such as the "." (period) character.

The control interfaces 14-16 perform two distinct functions: the injection interfaces 15-16 allow insertion into the generator of the document templates (injection interface 16 of scene templates 31) and filling data of these models (injection interface 15 associated data); the control interface 14 offers the possibility of controlling the various modules of the generator 1 (formatting, scene management, publication). The generator 1, when injecting a scene template 31 (or a scene model 31), scans the document in search of these specific attributes and generates the corresponding keys and anchors that are assigned to the scene module 121. corresponding. The generator 1 thus makes it possible to create a module 121 of scenes for the template (s) 31 (or model (s) 31) by exposing its anchors and keys.

V007 B001 FR / TQD

If a document injected into the generation chain has internal commands, then the model 31 inserted into the generator 1 comprises at least one temporal scene: the document is decomposed into temporally ordered commands and which executes internally of the module 121 of scenes . The generator 1 automatically generates a key 122 for each element / attribute / text of the XML document 21 injected. Thus, having knowledge of this nomenclature, the set of unitary trainers 111-114 of the formatting string 110 can connect to any key 122 of an input XML stream. In addition, the generator 1 remains connected to this data stream and detects any change in value of one or more values. If necessary, it propagates the update throughout the chain (execution of the formatting graph 110, update of the modules 121 of scenes, generation of events to the module 13 of publication). The publication module 13 makes it possible to produce a final multimedia content while satisfying at least two types of constraints: constraints imposed by the configuration of the steps / modules of the scene document generation chain 4 (via the control interfaces 14 and injection 15-16 models and associated data), generally related to the data format and service architecture; constraints associated with the output format of the generation chain (ie of the generator 1) of scene documents 4 such as flow or language constraints for example. For this, a fine configuration of the different modules of the generator 1 in knowledge of the characteristics of the output format is adopted. Indeed, the various components and constraints of the system can vary greatly over time the source data injected into the formatting brick can vary in number and characteristics (weight, quality for example); V007 B001 FR / TQD

anchoring or deleting a global service scene can change the "weight" of the data to be published; the publishing configuration may change, in particular, the bit rate allocated to the transport of the service.

Hence the advantage of an adaptable configuration of the generator 1. An optimal configuration at a given time may be inadequate following the various modifications mentioned above. In order to preserve the optimality of the generator 1, the publication module 13 is responsible for controlling the servocontrol of the generation chain by applying a new configuration to each atomic modification it detects. The publication module 13 makes it possible to "feedback" on all the modules of the generator 1. With reference to FIG. 4, the publication module 13 therefore produces a multimedia service data stream 18 on the one hand, and on the other hand a control flow 17 for the different generation modules (including the publication module itself). Thus, the current state of the publication module 13 is reinjected as configuration data of the various modules 11-13. This slaving of the generator 1 to the output constraints adds to the system a capacity for optimization and automatic adaptation in real time to the variations of these constraints. Advantageously, the information returned by the publication module 13 helps the different modules of the generator 1 to decide on the form and the optimal nature of the adaptations to be added to the current processes.

For this purpose, it is introduced, as shown in FIG. 5, in the formatter 12 a plurality of control parameters among the feedback data 17 looped back from the output of the publication module 13. Thus, the formatting module 11 is enslaved to the control flow produced at the output of the generator 1 and thus realizes a real-time adaptation of the service data under the constraints imposed by the publication module 13. V007 B001 FR / TQD

In one embodiment, the adaptation is made by selection under stress co, ..., cm. This embodiment is based on having several data do, ..., dN different (in format, type, size, quality, for example) that can be substituted for each other within the global service. The adaptation is performed by selecting one of these data as a function of control parameter (s) allowing decision-making. In another embodiment, the formatter 11, taking as input a set of alternative data as well as a control data, comprises a selection function making it possible to take a decision on the data item to be activated at the output of the formatter 11. implementation of the selection function can be done according to several different models: external decision: the decision making does not take place within the trainer 11. The latter simply offers the possibility of selecting by direct referral the input to be redirected to the output of the trainer 11; internal decision: the trainer 11 takes as input a set of constraints co, ..., cm and internally implements a function F (co, ..., cm, do, ..., dN) of decision making the selection of the data to be output.

FIG. 5 illustrates a trainer with a decision function F (co,..., Cm, do, dN) capable of selecting, for example, one of a set of images of sizes, formats and weights (do, .. ., dN) different. In another embodiment, the adaptation is performed by a transformation under constraints. This embodiment proposes to perform an adaptation on a single data by acting by transforming it to satisfy a set of constraints (co, ..., cm). For example, a trainer, taking a high resolution image data input allows to produce at its output a degraded image that best meets the constraints of bit rate, format or available space at the service level. Moreover, the adaptation can be obtained by feedback on the scene manager 12. Indeed, in a modular service architecture offering several alternative service format that can be V007 B001 FR / TQD

substituted for each other to satisfy a set of output constraints, one or more scene modules 121 (or scene containers 121) may be connected to a number of alternative sub-scenes as shown in FIG.

The control data 17 (obtained by feedback) act as control commands of the scene manager 12 performing the creation and breaking of links between the container 121 and the scene i chosen to perform the adaptation. Each output constraint modification of the publication module 13 results in feedback on the scene manager 12 defining a new configuration of the service architecture that best meets these constraints. FIG. 7 illustrates an exemplary rate constrained service adaptation scenario: three alternative scenes are defined therein, each being calibrated to satisfy a particular bit rate range: a scene containing a video and thus requiring a large bit rate. a scene with an image and a descriptive text adapted to an "average" transmission rate. a descriptive text alone adapted for a low transmission rate. Figure 7 illustrates a case where the variation of the available data transmission bit results in a change in the content of the service (video, image + text or text only). The control data 17 generated by the publication module 13 can also be used by it to adapt its publication strategy to the variations of constraints. Here we take the example of a broadcast stream generation system (MPEG-2 TS type). The publication module 13 comprises: a multiplexer operating on a broadcast architecture that can be viewed as a set of streams carrying data in the form of packets. The role of the multiplexer is to create a single transport stream by selecting packets on all of its input streams according to a routing algorithm. Each input stream V007 B001 FR / TQD

has its own configuration (target bit rate, data repetition period for example) which are as many constraints to be solved for the routing algorithm in order to produce a multiplexed stream that best meets all these constraints; an encoder: each input stream of the multiplexer has an encoder to allow the transport of data on the multiplexed stream. The data can be of different types (audio, video, vector drawing for example), which explains that each stream to be multiplexed has its own encoder, with a specific configuration (including the target bit rate). The routing algorithm of the multiplexer takes into account these constraints during the production of the multiplexed stream. an organizer: the data to be published, from the scene manager 12, are injected into a brick called "organizer". Its role is to break down the multimedia service on the various flows of the broadcast architecture. It must do this to project the service produced by the scene manager, as well as service update events, on the various input streams of the multiplexer; a controller: the three bricks described above form a "connected" sequential processing chain at the output of the scene manager 12. As a general rule in the case of a broadcast channel, the flow produced by the multiplexer is subject to strict rate constraints imposed either by the broadcast standard or by the entity responsible for broadcasting the transport stream. These constraints are therefore imposed on the multiplexer which is the last link in the generation chain. The controller keeps informed at all times of the state of the multiplexer and can feedback on the entire generation chain: o the trainer 11 / the scene manager 12: the controller can retroact on these modules to adapt to the better the service, whether in its structure (feedback on the scene manager 12) or in its content (feedback on the trainer 11 associated data), broadcast constraints. This can, for example, make it possible, in the event of a reduction in available throughput, to reduce the weight of data

V007 B001 FR / TQD

images or to propose alternative scenes less "greedy" in flow; o Organizer: Feedback on the organizer provides the ability to edit the service data projection strategy for broadcast streams in real time. For example, if the output is too large, the organizer can perform stream sharing by redirecting multiple outputs to the same broadcast stream (for example, grouping the scene and update data on the same stream. broadcast stream); o encoders: if the various encoders (audio, video, scene for example) have degrees of freedom on the quality of their encoding, it is possible to make a feedback on these processing bricks to modify for example the flow rates of encoding audio or video streams in response to rate variations available at the output of the generation chain; o the multiplexer: it is possible to carry out a direct return on the multiplexing module itself. Indeed, the latter can adapt its referral strategy to best distribute the available bit rate on all the streams to be multiplexed. As a result, advantageously, the media content obtained is adapted to the constraints of the consumption context, such as the capabilities of the terminal, the user's preferences, and the network's capabilities. The process just described has a number of advantages.

It enables the development of the multimedia market on low-speed networks such as wireless networks and by terminals with limited resources such as mobile phones and smartphones. It should be noted that the term "module" here covers any physical box integrating a processor programmed to perform one or more predetermined functions, or any software application (program or subroutine, plugin) implemented on a processor, independently or in combination. with other software applications. V007 B001 EN / TQD 10 15 20

Claims (15)

REVENDICATIONS1. A method of aggregating and formatting multimedia content for multimedia terminals, the method comprising: - a step of formatting metadata extracted from a plurality of heterogeneous structured source data (21); a filling step, with at least one formatted metadata, of at least one scene template (31) in order to generate a scene document (4); a step of publishing the generated scene document (4); a step of adapting at least one step of the generation chain of the scene document (4) to satisfy at least one constraint. 2. Method according to claim 1 characterized in that it further comprises a step of nesting templates (31) scenes. 3. Method according to any one of claims 1 or 2, characterized in that the structured source data (21) is an XML document. A method according to any one of the preceding claims, characterized in that the scene template (31) is a dynamically structured document declaring nodes for receiving formatted metadata, and anchor points (123) for supporting interleaving other scene templates (31). 5. Method according to any one of the preceding claims, characterized in that the constraint is a constraint associated with the output format of the generation line of the scene document (4). 6. Method according to any one of the preceding claims, characterized in that the constraint is a constraint imposed by the configuration of at least one module of the generation line of the scene document (4). V007 B001 FR / TQD A system for aggregating and formatting multimedia content for multimedia terminals, the system comprising: a formatter (11) arranged to format a plurality of metadata extracted from a plurality of structured source data (21). heterogeneous; a scene manager (12) arranged to register the nesting of scene templates (31) filled by the formatted metadata in order to generate a scene document (4); a publication module (13) responsible for relaying the generated scene document (4); a controller configured to feedback on the generation chain of the scene document (4) to satisfy at least one constraint. 8. System according to the preceding claim, characterized in that it further comprises a database (3) templates (31) scene. 9. System according to any one of claims 7 or 8, characterized in that the module (13) of publication is arranged to require, from the manager (12) scene, the instantaneous state of a scene document ( 4). 10. System according to any one of claims 7 to 9, characterized in that the formator (11) comprises a plurality of unitary formers (111-114). System according to any one of claims 7 to 10, characterized in that the scene template (31) is a dynamic structure document declaring nodes for receiving formatted metadata, and anchor points (123) for support the nesting of other scene templates (31). 12. System according to any one of claims 7 to 11, characterized in that it further comprises - a control interface (14) arranged to configure the formatter (11), the scene manager (12) and the module (13) publication; V007 B001 FR / TQD - an injection interface (16) of scene templates (31) for inserting scene templates (31) into the scene manager (12); a data injection interface (15) for feeding the formatter (11) with heterogeneous structured data (21). 13. System according to any one of claims 7 to 12, characterized in that the constraint is a constraint imposed by the configuration of at least one module of the generation line of the scene document (4). 14. System according to any one of claims 7 to 13, characterized in that the constraint is a constraint associated with the output format of the generation line of the scene document (4). 15. Computer program product implemented on a memory medium, capable of being implemented within a computer processing unit and comprising instructions for the implementation of a method according to one of claims 1 to 6. V007 B001 EN / TQD