Technical Board Monday/Tuesday 30th - 31st July EBU-AMWA FIMS 30 July 2012

FIMS - Intellectual Property Rights Rules "This meeting is being held under the Intellectual Property Rights Policy of the Advanced Media Workflow Association. By signing in and attending this meeting, you have agreed to be bound, and your employer, if a member of the AMWA, is already bound, by that policy. If you are unfamiliar with that policy, please ask the Chair of this meeting, and s/he will provide you with a copy of that Policy. At this time, I would ask that anyone in attendance inform me if they are personally aware of any claims under any patent applications or issued patents that would be likely to be infringed by an implementation of the specification or other work product which is the subject of this meeting. You need not be the inventor of such patent or patent application in order to inform us of its existence, nor will you be held responsible for expressing a belief that turns out to be inaccurate."

EBU, Geneva, July  Monday 30 July: 10 am - 5 pm (approx) CET 1.Introductions 2.Approval of Agenda 3.Document auto-generation for future updates to the specification 4.Implementation Guidelines (FIMS Specification Part 3) - includes time for drafting (Lunch 12.30pm - 2pm) 5. Status of FIMS1.0.7 specification (from 2pm) - AMWA technical review - editUnitNumberType - ListFileLocator - conclusions and updates to documentation (set up drafting groups if required. If necessary, conclude on Tuesday) 6. Repository service - brief update (Loic) 7. Test Harness update (Tony Vasile) 8. Approaches to test tools and possible certification: brainstorming

EBU, Geneva, July  Tuesday 31 July: 9 am - 3 pm CET 9. Finalise FIMS documentation update - review actions / outcome of dicussion from Monday 10. REST: possible standardized set of URIs - re-visit BBC REST issues for specification - other REST issues for Implementation Guidelines 11. IBC EBU Village: demos - EBU Village: presentation - IBC Award - FIMS Sunday meeting during IBC (Lunch 1pm - 2pm) 12. AOB 13. Wrap-up and summary of actions

FIMS 1.0: of the AMWA Technical Review Comments received during review period: 1.Editorial 2.EditUnitNumberType 3.ListFilelocatorType

FIMS 1.0: of the AMWA Technical Review Comments received during review period: 1.Editorial Page 15, first paragraph [Part 1, General Description] doesn’t quite make sense: "In this scenario there is no change in the version of the interface, but the service is replaced with a different implementation where some of the features (e.g., operations) are implemented or fewer features are implemented. In the latter case, the service is backward compatible. In the former case, there is the issue of making the framework aware that the service is not implementing some features." Page : Paragraph 3, ‘For’ missing between 'scope' and 'this '.

FIMS 1.0: of the AMWA Technical Review Comments received during review period: 1.Editorial Page 15, first paragraph [Part 1, General Description]:snake sense. It says: "In this scenario there is no change in the version of the interface, but the service is replaced with a different implementation in which either only some of the features (e.g., operations) are implemented or additional new features are implemented. In the latter case, the service is backward compatible. In the former case, there is the issue of making the framework aware that the service is not implementing some features." ay already have been in use, but are now not available). But perhaps we didn’t understand. Page : Paragraph 3, ‘For’ missing between 'scope' and 'this '. –Fixed in Part 1 v1.0.7.

EditUnitNumberType "A number of edit units as defined in EBU Tech An editUnit is the inverse of the edit rate, or corrected edit rate as the result of editUnit=1/(editRate*(factorNumerator/factorDenominator)). See EBU Tech 3293 for more information. " - "confusingly different..." - "numerous small errors related to media position and length calculations are avoided by using a rational representation rather than a real number." - "conversion from two-integer representation to three-integer representation" Encodings: 1. FIMS EditUnitNumberType: three integer values to represent a rate as a rational number. 2. SMPTE ST rational number rates: two integer values 3. AAF/MXF object model: two integers, matches SMPTE ST The AAF xml schema: string encoding of integer or rational number.

EditUnitNumberType "A number of edit units as defined in EBU Tech An editUnit is the inverse of the edit rate, or corrected edit rate as the result of editUnit=1/(editRate*(factorNumerator/factorDenominator)). See EBU Tech 3293 for more information. " Proposed solution: 1. editRate: shall be selected to be closest integer to actual rate 2. When performing calculations, a rational representation of the rate should be should be used rather than a real number, and this should be obtained by multiplying editRate by factorNumerator. 3. Provide tables to cross-reference to existing representations 4. Specification or EBUCore (Tech. 3293) to provide constraints?

EditUnitNumberType  Table 1: Relationship between combinations of editRate, factorNumerator, factorDenominator and rational and rounded representations (case: Actual rate same as Nominal rate)

EditUnitNumberType  Table 2: Relationship between combinations of editRate, factorNumerator, factorDenominator and rational and rounded representations (case: 59.94i Pull Down)

EditUnitNumberType  Table 3: Relationship between combinations of editRate, factorNumerator, factorDenominator and rational and rounded representations (case: 59.94i Pull Down)

EditUnitNumberType  Table 4: Relationship between combinations of editRate, factorNumerator, factorDenominator and rational and rounded representations (case: 50i Pull Down)

EditUnitNumberType  Table 5: Relationship between combinations of editRate, factorNumerator, factorDenominator and rational and rounded representations (case: 50i Pull Down)

ListFileLocatorType Problem: The current schema cannot describe multiple AV files with different bit rates in ListFileLocator - as only one “bitRate” can be described as VideoFormat.

bmEssenceLocator and bitRate The current schema cannot describe multiple AV files with different bit rates in ListFileLocator. However, the "bitRate" parameter in VideoFormat is optional. It could be possible to describe multiple AV files with different bit rates when the "bitRate" parameter is omitted. The current schema cannot describe multiple AV files with different bit rates in ListFileLocator. However, the "bitRate" parameter in VideoFormat is optional. It could be possible to describe multiple AV files with different bit rates when the "bitRate" parameter is omitted.

ListFileLocatorType Possible solutions: 1. Delete ListFileLocatorType 2. Deprecate ListFileLocatorType, move to new solution (?) 3. State that multiple AV files must all have the same rate as described by “bitRate” 4. State that files with multiple bit rates are permitted when “bitRate” (which is optional) is not used. One piece of content. 5. Provide usage scenarios for every Locator Type in the Implementation Guidelines (together with some usage constraint in specification)