RE: Meeting Summary - 15 October 2007

Hi,

 

I have a comment regarding the H.264 property. I was the one that proposed
it. I appreciate that the group has taken the time to consider it. Based on
the group's feedback I realize my proposal was badly formulated. 

 

My intention of the proposal was rather to indicate if the device can
playback H.264 for videos. This is regardless if the delivery method is
streaming or download. In this context the property should have been called
"video of H264 Baseline Profile Level 1.0" not "Streaming video of H264
Baseline Profile Level 1.0". I apologize for this bad naming. 

 

Nevertheless the bit rates stipulated are characteristics of a video
conformant with the corresponding profile, but have little to do with the
delivery method of the bits. It is actually the bit rate of the H.264 video.
How the bits got to the device (Streaming, download) I now realize is out
side the scope of the Core Vocabulary. But is the playback capabilities also
outside the scope? I see you have approved gif87 and gif89a for gif images,
so I am curious to know the groups stand on video capabilities? 

 

I am happy to submit a new proposal illustrating this, if it is any chance
of getting it accepted. Based on the emphasis of delivery bitrates
(streaming) I understand that the groups decision to mark it as "Not Core".
However I hope you will reconsider the new proposals below: 

 


Name

Description

Measurement

Justification


Video h264 Baseline  Level 10

Device is capable of playing a video of H264 Baseline Profile (BP) Level
1.0. 

Measured by trying to playback a conformant H264 video at baseline profile
level 1, to the device. Playback should be successful.   

Primarily for lower-cost applications with limited computing resources, this
profile is used widely in videoconferencing and mobile applications.


Video h264 Baseline  Level 1.b

Device is capable of playing a video of H264 Baseline Profile (BP) Level
1.b.

Measured by trying to playback a conformant H264 video at baseline profile
level 1.b, to the device.

Playback should be successful. 

Primarily for lower-cost applications with limited computing resources, this
profile is used widely in videoconferencing and mobile applications.


Video h264 Baseline  Level 1.1

Device is capable of playing a video of H264 Baseline Profile (BP) Level
1.1.

Measured by trying to playback a conformant H264 video at baseline profile
level 1.1, to the device. Playback should be successful.   

Primarily for lower-cost applications with limited computing resources, this
profile is used widely in videoconferencing and mobile applications.


Video h264 Baseline  Level 1.2

Device is capable of playing a video of H264 Baseline Profile (BP) Level
1.2.

Measured by trying to  playback a conformant H264 video at baseline profile
level 1.2, to the device. Playback should be successful.    

Primarily for lower-cost applications with limited computing resources, this
profile is used widely in videoconferencing and mobile applications.

 

 

Regards

 

Runar J. Solberg

 

 

 

-----Original Message-----
From: public-ddwg-request@w3.org [mailto:public-ddwg-request@w3.org] On
Behalf Of Rotan Hanrahan
Sent: Thursday, October 18, 2007 5:55 PM
To: public-ddwg@w3.org
Subject: Meeting Summary - 15 October 2007

 

 

[Meeting Summary - 15 Oct 2007] Vocabulary resolutions, Korea F2F.

 

[Vocab] This week's conference call was energetic and productive. The main
topic on the agenda was to make decisions on the many proposed core
vocabulary properties, taking into account the many responses and other
comments received to date. Over the past week, the group had been voting to
identify those properties that were core, not core and deserving of further
debate. It was assumed that those who had engaged in the voting had strong
opinions to express.

 

The first property discussed related to H.264 (Baseline Profile Level 1.0).
This deals with streaming video rates. It was felt that this property was
outside of the scope of a core vocabulary that was focussed only on the
essential properties for adapting Web content for mobile delivery contexts.
The group intends to respond to the proposal by indicating how domain
specific, custom and advanced vocabularies can be created; and the role of
the UWA ontology in this regard. It was resolved that H.264 is not part of
the core vocabulary.

 

The next property was the DOM Level of the browser. It was felt that the DOM
Level did not have a strong bearing on the adaptation of content. Knowing
the DOM Level might be useful in adapting scripts that access the DOM. In
the same vein, the group considered the XMLHTTPRequest support of the
browser, and again this was felt to be a script-oriented property. Both of
these properties would be considered core to an adaptation process for
mobile Ajax, but not for a simple adaptation process that is dealing with
simple Web content. It was decided that these properties would be
communicated to the OpenAjax Alliance, with a view to encouraging them to
create a vocabulary for adaptation of Ajax, following the example of DDWG.

 

Support for ECMAScript (or JavaScript) was also discussed. It was felt that
knowing that a browser supports scripting is beneficial for more than just
Ajax applications. It was therefore resolved that this property should be in
the core vocabulary, but there would still need to be further discussion on
whether it should represent ECMAScript and/or JavaScript.

 

The proposed property of Characters Per Line was debated. It was suggested
that this property would be useful for pagination. However, it was also seen
as a throwback to the old days of WML content, where fonts were very simple
and the character density was an important property. Today, with variable
fonts and more complex layouts, character density is less precise. In the
absence of exact font information, and approximation based on screen
resolution would probably suffice. To do things like sophisticated line
wrapping, you would need much more detailed information about the fonts,
which the group agreed would go far beyond a simple adaptation. For simple
adaptation, the screen width would be a sufficient means to approximate the
character density and thus the Characters Per Line property was resolved to
be non-core.

 

It was pointed out that no matter what the DDWG decides will be in the core,
there will be people who will say some properties are missing. The best that
the group can achieve is a basic vocabulary that will support simple content
adaptation, and be sufficient to demonstrate the operation of the DDR API.
This needs to be explained in the Vocabulary document.

 

The group then turned its focus on some properties that all agreed were
core: the dimensions of the screen. The width and height were seen by
everyone as essential for content adaptation. While previous proposed
properties were rejected from the core, these two properties were
immediately resolved to be core properties.

 

With this practice on the decision process, the group agreed to take the
discussion to the electronic forum, where the remaining candidate properties
would be debated, and some further resolutions taken. This debate, and the
conclusions, would be visible on the public mailing list and the wiki.

 

[Korea] Finally the group acknowledged an invitation to hold a face-to-face
meeting in Korea in 2008. The group will send a formal response after
polling the members.

 

Attendees:

Matt, Andrea, Pontus, José, Jo, Rotan, Martin, Dimitar, Kevin, Jongpil,
Bryan, Nacho