Re: [emergency] usage scenarios

[Rex Brooks <rexb@starbourne.com>]

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.

Regards,
Rex

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).
>
>Cheers
>Kon


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