[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [emergency] Groups - Draft Meeting Notes 8-19-2005.doc uploaded
I'm disappointed to see that we are essentially allowing enormous video chunks to be inserted into the EDXL payload (if I understand the minutes correctly). For streaming video, the bitrate should be included instead of the size, this way a parser can determine if it is on a high enough bandwidth link to access the streaming video. 3 relevant variables to streaming video which should be in the DE are: 1. What format is it and how to access it (an SDP file usually describes this) i.e. what method of access (video codecs, etc.) does it use (HTTP, Multicast, UDP, ..). This metadata file should either be included as derefuri or referenced by uri. 2. The bitrate of the video (in kbits/sec) 3. The availability of the video (times during the day) (2) and (3) are contained in SDP files but not in many other streaming metadata descriptor formats. I'd suggest that SDP be used for the URI/DrerefURI fields whenever streaming video is used: http://www.faqs.org/rfcs/rfc2327.html I'd also like to point out that it is *impossible* for the DE to contain streaming video. The size of the video inside the DE will always be known because it has to be a finite size when it is base64 encoded. If the video is streaming and is recorded to be encoded, the sender can approximate the size of the video by using the recording time and bitrates of the system, video, and audio components and offsetting them by the encoding parameters if the stream if it is variable bitrate. Inserting the size of the video chunk in the message only helps if the system transmitting the EDXL data can analyze each message and inform/split messages before transmission to recipients. Essentially anyone who cannot handle the message has to create an intelligent gateway because the messages cannot be routed. I am curious to know what type of network David's video sits on and what the rationale is for including it in the payload vs. moving it across the network by other means. Cheers Kon On Sat, 2005-08-20 at 09:00 +0000, ejones@warningsystems.com wrote: > Please review the draft meeting notes for the 8/19/05 telecon. Any > corrections should be emailed to Julia and copied to Elysa as soon as > possible or be prepared with comments for the 8/23/05 meeting.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]