International organisation for standardisation

3.2Output documents related to MPEG-7 Visual

No.	Title	TBP	Available
11085	Study Text of ISO/IEC 15938-3/FPDAM 4 Video Signature Tools	N	10/02/05
11086	MPEG-7 Visual XM 38	N	10/02/05
11087	Description of Core Experiments in Video Signature Description development	N	10/01/22
11088	Disposition of Comments on ISO/IEC 15938-7/FPDAM 5	N	10/01/22
11089	Text of ISO/IEC 15938-7/FDAM 5 Conformance Testing for Image Signature Tools	N	10/02/05
11090	Disposition of Comments on ISO/IEC 23000-3/FPDAM 2	N	10/01/22
11091	Text of ISO/IEC 23000-3/FDAM 2 Conformance Testing for Photo Player MAF	N	10/02/05

4Reconfigurable Video Coding (RVC)

4.1General status of work

The main part of RVC work during the week in Kyoto was devoted to improving understanding and text of the ongoing Amd.1 (software and conformance). A better understanding about the meaning of conformance testing was achieved, in particular

• 
  Conformance testing specification is necessary for algorithmic FUs (Functional Units), in particular describing the normative input/output dataflow behaviour and related test patterns with the necessary precision. This also relates to the parser.
  
• 
  Some behaviour of management (control) FUs could be implementation-specific – as long as it does not concern the invoking of FU networks. It is still under discussion whether and which conformance will be needed, or if it is implicit that by defining codec-level conformance sufficient evidence is given that the management FUs also work properly.
  

• 
  Conformance at the codec level is necessary for combinations of FUs that have defined by MPEG coding standards. In the current first phase of RVC (re-implementing existing standards' profiles/levels), this implicitly exists.
  

Therefore, a solution without a specification for conformance testing at the control FU level may work for the moment, but for an operational (and particularly extensible) RVC framework it will not be sufficient, and a much better scheme is needed – in which management/control parts need to be normative.
About RVC Simulation Model (RSM): It was discussed that besides the available tools that derive an RVC implementation directly from the CAL description, other implementations of RVC (e.g. written in C/C++) would be possible, with advantages mentioned to potentially give better support in relevant operating environments (e.g. for parallel processing). Further, C/C++ could be easier to debug in available professional testing environments. To get better understanding about potential benefits of having multiple reference software implementations, the proposed C/C++ HOPES framework (see M17309 and M17344) will be investigated in a Core Experiment to be added to RSM – provided that the framework is fully compliant to RVC including the support of FND (FNL) and FU implementation.
Adding a second branch of (non-normative) software implementation would have

• 
  PROs: Being able to check the RVC concepts on an broader basis, and giving users alternative help in implementation,
  
• 
  CONs: No interoperability (probably) between the different software frameworks particularly at FU level, larger effort of maintenance.
  

The new RVC Work Plan (N11093) is as follows:

• 
  Development of not-yet-operational FU conformance elements, such that FDAM1 can be finalized in April 2010; a new Study document is issued on the parts that have become available in the meantime;
  
• 
  PDAM2 (AVC High Profile) is now expected for April 2010 – the biggest challenge is still the CABAC implementation, which was to be expected.
  

An AHG was appointed (N11117, as recorded in N11076) to further the work until the 92nd meeting.