MPEG (was Re: [emergency] usage scenarios)

[Art Botterell <acb@incident.com>]

While it's probably true that jumbo payloads can break some transport  
or receipt systems, that's equally true for PowerPoint (ask the  
Navy!) or any number of other formats.  I don't think we should build  
implementation-based limits into the spec that could hobble future,  
more capable implementations.

We could, of course, add a note reminding implementers that embedding  
excessively large content objects can have negative and even fatal  
effects on networks and recipients' systems.  Beyond that, I think  
experience will remind folks of the practical limits of their current  
technology if they lose track of them.

(Also, I don't think the issue here is MPEG, per se... obviously the  
size of a particular MPEG clip relates its duration, resolution,  
frame rate, image motion and other factors, and some clips might be  
relatively small.  The concern would be the same for large binaries  
of any type... and we can only speculate as to what the tolerable  
file size might be in any particular environment and at any point in  
time.)

As for supporting multiple access methods, I think the current  
version of the spec provides that capability... using the "absolute  
for network, relative for local" approach in <uri>.  But, for the  
record, I'll add both that and the content size concern to the Issues  
List.

- Art


On Aug 18, 2005, at 8/18/05 12:05 PM, 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