OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency] usage scenarios

It could be changed to an image taken from the video clip if that 
fits better and doesn't run into the issues discussed here. I didn't 
intend this to be a big payload, and in fact, the image makes more 
sense, except that it requires more preprocessing than a clip of a 
couple of seconds, which doesn't need to be converted from an mpeg 
frame to jpeg or png--just long enough to be recognizable and give 
the viewer an immediate picture of the situation.

However, Kon's considerations are valid, so since what we need is 
non-xml content, an image, regardless of how it is obtained or where 
it comes from is all we need.


At 12:05 PM -0700 8/18/05, Kon Wilms wrote:
>"Separate automatic notifications of both the car crash and the HAZMAT
>carrier are sent using the Vehicular Emergency Data Set (VEDS),
>contained in the Distribution Element, and in addition, a video clip
>taken from a live transmission is transmitted as a properly mimeTyped
>non-xml mpeg file for a time-stamped reference."
>It concerns me that the EDXL framework is being used in this example as
>a transport mechanism to deliver MPEG video - something it clearly is
>not. I've brought this up a few times and it has largely gone ignored.
>Base64 encoding adds quite a lot of overhead to data, and embedding this
>type of content can easily lead to situations where a decoder is
>hammered because it cannot deal with the size of the payload, or the
>message is rendered useless because it cannot be delivered in a timely
>fashion over bandwidth-starved and/or error-prone transmission links. If
>the transmission link is unicast, you can quite easily cap out the
>bandwidth on the link if multiple recipients are retrieving the content
>at the same time (in which case the EDXL delivery system is for all
>intent purposes rendered useless).
>Content of this nature should be delivered to recipients via out-of-band
>delivery on the same base transport mechanism (be that HTTP or
>whatever). That way you can receive the message immediately and parse
>the video content when it arrives. Server operators can also then apply
>QoS settings to the traffic to prioritize delivery of EDXL messages.
>In these situations it may also be advantageous to support multiple
>content URI references, i.e. a reference to a download URI for the
>content, a local disk reference if another mechanism handles delivery of
>assets, and alternate methods for access such as streaming (in which
>case the streaming metadata file (SDP, etc.) is inserted into the
>content as a derefuri chunk).

Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-849-2309

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]