A short list of suggestions for SVG support in TV

Open for comments and/or suggestions.
Thank you for your consideration.


-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org]
Sent: Friday, July 23, 2004 3:09 PM
To: James Bentley
Cc: 'www-svg@w3.org'
Subject: Re: The 'hanlder' element



On Friday, July 23, 2004, 7:49:44 PM, James wrote:


JB> You are correct, I am confusing externalResourcesRequired with
JB> requiredFeatures.
JB> However, this statement:
JB> "Only feature strings defined in the Feature String appendix are
allowed."

requiredFeatures describes features listed in the spec.
requiredExtensions is for things not in the spec so is open ended.

JB> may be a bit too restrictive. and requiredExtensions has this verbiage:
JB> "The requiredExtensions attribute defines a list of required language
JB> extensions."

JB> I'm wondering if this is sufficient to indicate whether or not JPEG,
MPEG,
JB> DVR, VOD, DOCSIS, TCP and other "resources" are available. I understand
JB> that "resources" is an overloaded term. I suppose my confusion is a
JB> combination
JB> of "resources" overloaded meaning

Resources has the same meaning as in the Architecture of the World Wide
Web document. (Strictly, resource representations).

Availability of codecs etc would not be 'resources' in this sense.

JB> I was assuming that this was the proper place to indicate "resources"
that
JB> are required for
JB> "proper rendering", such as JPEG decoder.

No. Its to indicate that, say, a particular JPEG image is needed for
proper rendering, proper in the sense that the content creator would
rather nothing was displayed at all than that the SVG was displayed
without it.

JB>  I can also, falsely, assume that
JB> this may extend to
JB> presence of RTSP or DSM-CC for streamable media control (albeit this is
JB> introducing
JB> implementation detail - but it will be required to account for differing
VOD
JB> implementations).

Availability of particular transports is not currently addressed in the
SVG specification. I can see that you would want to test for it. On the
other hand, its not a language extension - the SVG language itself is
not extended, as the scheme part of a URI is not constrained by the SVG
spec.

JB> At least for RTSP, it can be part of the URI (I'm assuming again).

Yes, it can. See http://www.ietf.org/rfc/rfc2326.txt

JB> But I'm not sure on DSMCC

I don't know what DSM-CC is, can you give me a pointer?

JB> and this has no bearing on digital-video-recording (DVR). Perhaps a
JB> 'metadata'
JB> or 'foreignObject' element could describe the requirements - then
JB> 'requiredExtensions'
JB> can simply reference the object (I'm including 'metadata' because it
does
JB> not require a
JB> bounding box).  Is this the intent of the spec? A bounding box (viewBox,
JB> viewPort,
JB> etc.) would be necessary for images, and may be helpful for streamed
media.

Streamed media would use video (if visual and requiring a viewbox) or
audio (if not).

JB> We use an image that is similar to a bitmap, with much less header
JB> information. It is compressed in a proprietary manner.
JB> Unfortunately, this image has been in use for years - as we advance
JB> to using new technologies, we must be willing to accept this format
JB> to support backward compatibility. I suppose we could call it a
JB> bitmap, but that would ceratinly confuse people - being that its
JB> proprietary, I don't know that we would release the compression
JB> scheme and format, even though the image may be short lived (approx.
JB> 5years). Any suggestions? Is 'foreignObject' a good place for this
JB> extension?

The fact that it is proprietary is irrelevant, and you do not have to
release the schema to get it a MIME type. In fact, for a proprietary
vendor media type you can get one registered in a couple of days.

You would use the image or video elements as appropriate. No extension
of SVG language is needed for that. A switch that has an image with a
URI for your image format (and a test) and another image as a fallback
(eg a JPEG or PNG) would be a good way forward.


JB> -----Original Message-----
JB> From: Chris Lilley [mailto:chris@w3.org]
JB> Sent: Friday, July 23, 2004 10:34 AM
JB> To: James Bentley
JB> Cc: 'www-svg@w3.org'
JB> Subject: Re: The 'hanlder' element



JB> On Thursday, July 22, 2004, 8:44:40 PM, James wrote:

JB>> Converting JPEG to MPEG is not straigth
JB>> forward.

JB> I was just wondering out loud.

JB>> Cable standards do not mandate support for PNG
JB>> nor JPEG. OCAP does allow it.

JB> I was thinking of MHEG5

JB>> I was under the impression that eRR could be
JB>> used in a switch statement to identify system
JB>> capabilities.

JB> I think you are confusing it with requiredFeatures and
JB> requiredExtensions.
JB> http://www.w3.org/TR/SVG11/struct.html#ConditionalProcessing


JB>> Putting test attributes in the image element
JB>> would be a great idea.

JB> Okay.

JB>> foreignObject may still be required since
JB>> some proprietary image formats do not
JB>> have a mime-typed and are not general
JB>> purpose.

JB> Yeah, lack of mime types is a problem. Which image formats are you
JB> thinking of?

JB>>  These must also be able to
JB>> identify system capabilities. Is this 
JB>> possible in the image element?

JB>> -----Original Message-----
JB>> From: Chris Lilley [mailto:chris@w3.org]
JB>> Sent: Thursday, July 22, 2004 10:24 AM
JB>> To: James Bentley
JB>> Cc: 'Robin Berjon'; 'www-svg@w3.org'
JB>> Subject: Re: The 'hanlder' element


JB>> On Wednesday, July 21, 2004, 5:39:12 PM, James wrote:


JB>>> A list is being compiled. If you are referring to Image formats,
JB>>> JPEG and PNG may be problematic in low-end set top boxes.
JB>>> However, MPEG I or P Frames are possible (in some).

JB>> Is it possible to convert the JPEG or have it displayed using the MPEG
JB>> decoder? (just wondering aloud). I know some STB already have PNG
JB>> (sometimes in hardware) and some TV standards require it.

JB>>> One suggestion
JB>>> would be to allow the 'image' element to reference a 'switch' element
JB>>> that must resolve to an element capable of inheriting image
attributes.
JB>>> This would allow the 'externalResourcesRequired' attribute to be used
JB>>> to identify JPEG and/or PNG rendering capability,

JB>> (eRR does not do that. It tells the viewer to wait until all resources
JB>> are loaded before displaying anything).

JB>>> as well as MPEG rendering capability.

JB>> we are considering adding a media type test attribute to the image
JB>> element for 1.2, which we already have on the video and audio elements.
JB>> We are also adding switch to a lot more places. Test attributes can
JB>> already be used outside of switch, though.

JB>>> Since many proprietary image formats exist, it may also be necessary
to
JB>>> use 'foreignObject' for additional image rendering.

JB>> That is not needed (its not the same as the HTML object element) you
can
JB>> use the image element for that.

JB>>> So, to answer your question, the requirement is problematic, and we
JB> need
JB>> a
JB>>> way to specify additional image formats.

JB>> You can specify additional image formats already.

JB>>> This also shows that some media (i.e. MPEG) can be treated as either
an
JB>>> image or a stream - in consideration of 1.2's media extensions.

JB>>> One more item. Has there been any thoughts into Copy protection -
JB>> especially
JB>>> for streamed media?

JB>> Thoughts, yes. A DRM solution for an open format is problematic, and
JB>> a 'bozo bit' is seen as adding little value. Copyright information can
JB>> certainly be included, ,of course, in the metadata element.

JB>>> I'll see what I can do to rush the assessment along. Thanks.

JB>>> -----Original Message-----
JB>>> From: Chris Lilley [mailto:chris@w3.org]
JB>>> Sent: Wednesday, July 21, 2004 9:28 AM
JB>>> To: James Bentley
JB>>> Cc: 'Robin Berjon'; 'www-svg@w3.org'
JB>>> Subject: Re: The 'hanlder' element



JB>>> On Wednesday, July 21, 2004, 4:38:56 PM, James wrote:


JB>>>> We are considering SVG Tiny 1.2 as part of our assessment, and yes it
JB>>>> does solve many issues that were raised when we implemented to 1.1
JB>> Tiny.
JB>>>> Some issues still remain.

JB>>> It would be helpful to have a list of them, would that be possible?

JB>>>> Many of these issues center around interactivity,
JB>>>> image formats, conditional processing and external reference . We
JB> would
JB>>> also
JB>>>> like some restrictions relaxed and impose others.

JB>>> Is it the requirement to support two particular formats that you find
JB>>> problematic, or the lack of other formats with mandated support?

JB>>>> Thank you for the information on MicroDOM. I am very curious to
JB>> discover
JB>>>> how well this matches up to what we have implemented. As always, we
JB>>> would
JB>>>> seek to match up with standards wherever possible.

JB>>>> Also, thank you for the consideration. I am confident that the
JB> problems
JB>>> will
JB>>>> be solved, but I am concerned that we will travel too far down a
JB>>> development
JB>>>> path that diverges from the specification.

JB>>> In that case I encourage you to track SVG Tiny 1.2 as it moves through
JB>>> Last Call. Tell us how it meets your needs and how it doesn't.

JB>>> We would also be very interested in MicroDOM implementation
experience.















-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group