The video codecs allowed for the “videoFile” element are not specified. There are many propietary and non-portable codecs which would break portability of a document.
Define a set of patent-free, portable video codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)
5.1.3.6 te
3296(3303)
Proposed Disposition of DIS 29500 Comment CO-0221 (Modified: 2008-01-04) Agreed; just as there is a content type available for files included within the document package (using the content type item defined in Part 2), there should be a way to specify a content type when using the video element to link to external video content. As well, the list of video codecs provided in Part 1 should be referenced from this location. The following changes will be made to the specification: Part 4, §5.1.3.6, page 3,296, line 26, a new attribute will be added: Attributes Description contentType (Content Type of Linked Video File) Specifies the content type for the external file that is referenced by this element. Content types define a media type, a subtype, and an optional set of parameters, as defined in Part 2, §8.1.2. If a rendering application cannot process external content of the content type specified, then the specified content can be ignored. [Note: A list of suggested video types is provided in Part 1, §15.2.16. end note] If this attribute is omitted, application should attempt to determine the content type by reading the contents of the relationship’s target. The possible values for this attribute are defined by the XML Schema string datatype. Part 4, §5.1.3.6, page 3,297, after line 6: The following XML Schema fragment defines the contents of this element: <complexType name="CT_VideoFile"> <sequence> <element name="extLst" type="CT_OfficeArtExtensionList" minOccurs="0" maxOccurs="1"/> </sequence> <attribute ref="r:link" use="required"/> <attribute name="contentType" type="xsd:string" use="optional"/> </complexType>
Fluff
Video codec of embedded video file should be independant of document format.
it isn’t really fluff, there is a point they are trying to make. I think it is more of a feature request.
It would be kind of ridiculous if the ODF standard had a free codec range to embed into it but the OOXML format would require extending to allow cerain codecs in. Also weird is that ISO has even standardized propriety video codecs like mpeg2 that would not qualify as being patent free.
To suggest that even ISO codecs should not be in a format unless it is extended is just over the top.
I do agree with you in general, but we are not marking the validity of the comments, just picking out the ones worth talking about and classifying them. This is clearly a request for a feature. Whether or not it would be a good feature is debatable, I tend to agree with you on this one.
I think comments like AU-1 where there is no specific point being made as fluff. This comment is specific, and about the format.
just to clarify a bit, we certainly can discuss and debate the validity of the comments here, I just don’t plan to tag them as valid or not valid.
Please do not ever include a codec as an attachment to a file. This is a serious breach of security. We all know that if such a thing happen the next virus to propagate will be called “New Britney Video”