Topics of this blog are related to multimedia communication. In particular, streaming of multimedia content within heterogeneous environments enabling Universal Multimedia Experience (UME).
Thursday, February 10, 2011
MPEG DASH vs. W3C WebTV?
I could not attend this meeting but I followed the Twitter stream #w3ctv which revealed some interesting thoughts from George and Alexander (cf. also screenshots) concerning the adopting of MPEG DASH for W3C WebTV. Alexander, I don't know whether a mug of hot tea helps here...
In general I think that DASH would just work for W3C WebTV and concerning royalties I'd like to quote from the minutes, "it needs to be clear that it is the companies that we have to ask, not the SDOs" - I fully agree [the minutes of the workshop (in usual W3C style) are available here (day #1) and here (day #2)].
In this context it's probably worth reading the following article describing Microsofts approach of "undoing Chrome's AVC (aka H.264) omission". I'm personally wondering what is better, having technology available as open source/royalty free but controlled by a single evil/not evil - whatever you prefer - entity (company) or paying license fees but having clear rules for joining/playing the game of developing and maintaining (corrigenda, amendment) a standard. I'd love to read your comments, feedback, and suggestions ...
Thursday, February 4, 2010
W3C's "The System Information API"
This specification defines an API to provide Web applications with access to various properties of the system which they are running on. Specifically, properties pertaining to the device hardware are addressed. Examples include battery status, current network bandwidth. Additionally, some of those properties offer access to the environment around the device, such as ambient brightness or atmospheric pressure.Remember that's a first working draft which means it's still subject to changes. There's also a nice figure that gives a good overview which APIs one can anticipate in this standard.
In any case, I would appreciate if W3C could define the scope of this specification and what they actually mean by a "system". A proper definition thereof is somewhat missing at the moment but remember, it's a first working draft only...
Finally, defining APIs are now in vogue within SDOs as W3C is doing it for a while, MPEG has some APIs defined and will continue this path, and I wonder whether IETF is also about to join the API club.
Saturday, August 22, 2009
W3C Relaunches Multimodal Interaction Working Group
Very interesting as this WG aims bringing the Emotion Markup Language to Candidate Recommendation. So far the Elements of an EmotionML 1.0 have been identified as a W3C Incubator Group Report. Interestingly, ISO/IEC MPEG also has emotions within the scope of its MPEG-V work item. I wonder whether both groups could benefit from each other, the one way or the other ... let me know what is your opinion.
Friday, July 3, 2009
W3C Launches Device APIs and Policy Working Group
Hmm, they could be interested in the MPEG Extensible Middleware (MXM) which also specifies API that might be exploited by the W3C Device API.
Friday, June 19, 2009
First Draft Published for Ontology for Media Resource 1.0
Thursday, June 4, 2009
Use Cases and Requirements for Ontology and API for Media Object 1.0 Draft Published
This is the second version of this working draft and from the "Purpose of the Ontology and the API" section I've extracted the following:
The ontology will define mappings from properties in formats to a common set of properties. The API then will define methods to access heterogeneous metadata, using such mappings. An example: the property createDate from XMP can be mapped to the property DateCreated from IPTC. The API will then define a method getCreateDate that will return values either from XMP or IPTC metadata.
An important aspect of the above figure is that everything visualized above the API is left to applications. For example.
languages for simple or complex queries
analysis of user preferences (like "preferring movies with actor X and suitable for children")
other mechanisms for accessing metadata
The ontology and the API provide merely a basic, simple means of interoperability for such applications.
Wednesday, May 13, 2009
Guidelines for Writing Device Independent Tests Note Published
Thursday, May 7, 2009
Mobile Web Application Best Practices Draft Published
Interesting that there's also a section about user experience including perceived latency, interaction method, and data consistency. Furthermore, they describe how to handle device capability variation. In other words, adaptation but mainly at the server or client and not within the network. I would appreciate if they could also consider this as a possibility...
Friday, May 1, 2009
W3C: First Draft of Use cases and requirements for Media Fragments
A lot of use cases including on about adapting media resources but some are marked out-of-scope. Why are they still there? Furthermore, "just four requirements" related to temporal, spatial, track, and named fragments have been defined. There's an overlap between named fragments and the rest and it seems they're more seeking for human readability and named fragments is the solution for that requirement. Just take this as a remark.
Tuesday, April 21, 2009
Note Published: W3C Personalization Roadmap: Ubiquitous Web Integration of AccessForAll 1.0
They probably should also include the work of ISO/IEC JTC 1/SC 29/WG 11 (MPEG) on Usage Environment Description (UED) which also provides means to describe user characteristics including accessibility information. UED has been standardized within Part 7 of MPEG-21, entitled Digital Item Adaptation (DIA). The UED Schema can be found here and just search for AuditoryImpairment or VisualImpairment.
Wednesday, April 8, 2009
Efficient XML Interchange Evaluation Draft Published
Sunday, February 22, 2009
Adapting Content
This is an interesting article which provides a solid description on how ‘device independence’ can be achieved by utilizing recent W3C standards. It provides a good introduction, highlights some of the main issues, and gives accurate pointers to the state-of-the-art W3C standards and those under development. There’s one statement in the article that I find very interesting which is:
“DIAL will make it possible to create a Web page whose presentation can be controlled by the properties of a delivery context.”DIAL (Device Independent Authoring Language) and the delivery context – cf. Delivery Context Client Interfaces (DCCI) and Delivery Context Ontology (DCO) – seem to be a competitor of MPEG’s Digital Item Declaration (DID), Multimedia Description Schemes (MDS), and Usage Environment Description (UED). I wonder whether there exists a thorough and, of course, not taking sides comparison of these formats and whether it is possible to harmonize at least parts thereof. For sure that’s a job for academics because these standardization bodies might not be interested in doing this let’s call it academic exercise.
Furthermore, still a big issue is how all these assets are actually communicated over the various networks. The article mentions IETF’s “Transparent Content Negotiation in HTTP” although this RFC2295 is rather old and, more importantly, is ‘experimental’. Additionally, there exist some extensions of HTTP to carry CC/PP-based descriptions defined in RFC2774 identifying the profile or a difference to an existing profile - also ‘experimental’. However, DCO (an all others) may require yet another HTTP extension and, thus, there’s a need to decouple the communication/negotiation of the delivery context and usage environment properties from the actual (transport) protocol.
Finally, CC/PP defines only a ‘container format’, i.e., the language constructs, while UAProf defines the actual ‘terms’, i.e., a vocabulary of actual hardware, software, … characteristics for mobile devices.
Sunday, February 15, 2009
Service Modeling Language, Version 1.1 Proposed Recommendation
From the SML's abstract I read "... used to model complex services and systems, including their structure, constraints, policies, and best practices. SML uses XML Schema and Schematron." It's very interesting to see that SML adopts both XML Schema and Schematron (see related blog posts at O'Reilly). I wonder whether there're any adoptions thereof in the multimedia domain, maybe related to the MPEG-21 Multimedia Framework ...
Wednesday, February 11, 2009
Widgets 1.0: APIs and Events
- access the metadata declared in a widget's configuration document,
- receive events related to changes in the view state of a widget,
- determine the locale under which a widget is currently running,
- be notified of events relating to the widget being updated,
- invoke a widget to open a URL on the system's default browser,
- requests the user's attention in a device independent manner,
- and check if any additional APIs requested via the configuration document's feature element have successfully loaded.
This is somewhat related to MPEG's Rich Media User Interface Framework for which the Call for Proposals is open until April. Requirements for the this Rich Media UI Framework can be found here and some further information about this interesting exploration activity can be found here.
Tuesday, February 10, 2009
W3C Multimodal Standard Brings Web to More People, More Ways
Wow, this development really took a long time but interesting stuff though. The first WD dates back to August 2003 which makes me wonder whether somebody will use/implement that. Nevertheless, it can be used for universal multimedia access w.r.t. multimodal interaction to the content. Other activities of this working group comprise Multimodal Architectures and Interfaces and Ink Markup Language (InkML) both at WD stage. Hope its development does not last forever...
Saturday, December 6, 2008
Cool URIs
The best resource identifiers don't just provide descriptions for people and machines, but are designed with simplicity, stability and manageability in mind, as explained by Tim Berners-Lee in Cool URIs don't change and by the W3C Team in Common HTTP Implementation Problems (sections 1 and 3):
- Simplicity.
- Short, mnemonic URIs will not break as easily when sent in emails and are in general easier to remember, e.g. when debugging your Semantic Web server.
- Stability.
- Once you set up a URI to identify a certain resource, it should remain this way as long as possible. Think about the next ten years. Maybe twenty. Keep implementation-specific bits and pieces such as .php and .asp out of your URIs, you may want to change technologies later.
- Manageability.
- Issue your URIs in a way that you can manage. One good practice is to include the current year in the URI path, so that you can change the URI-schema each year without breaking older URIs. Keeping all 303 URIs on a dedicated subdomain, e.g. http://id.example.com/alice, eases later migration of the URI-handling subsystem.
Monday, December 1, 2008
SMIL 3.0 Advances Standard for Synchronized Multimedia
"The importance of SMIL 3.0 is that it contains a set of user-requested features that provide exciting new functionality, while retaining all the advantages of a declarative (that is, without scripting) approach to building a multimedia presentation," said Dick Bulterman, chair of the Synchronized Multimedia Working Group, which published the specification.
The new features in SMIL (pronounced, "smile") are a direct response to user and industry demand. For instance, the standard allows full-motion, timed captions and labels to be directly inserted in the presentation (called smilText). And SMIL's media pan-zoom control allows people to create "Ken Burns"-style animations easily for photos and visual content. SMIL 3.0 also allows authors to embed timed metadata in presentations, making SMIL a useful descriptive language for the development of Semantic Web resources that evolve over time.
Personal Note: SMIL's Content Control Modules allow for selective/adaptive multimedia presentations through the switch element. SMIL 3.0 Content Control introduces three new attributes: allowReorder, systemBaseProfile, and systemVersion. Additionally, the new module RequiredContentControl has been defined that allows the systemRequired attribute to be specified in profiles that do not otherwise use SMIL content control.
The profile name might one of "Language" | "UnifiedMobile" | "Daisy" | "Tiny" | "smilText" |User-defined-profile-name. User-defined profiles are possible also.

