From bill.mandel unistudios.com Fri Apr 20 12:50:47 2001 From: bill.mandel unistudios.com (Mandel, Bill) Date: Wed Jul 30 14:06:32 2003 Subject: [M4IF Technotes] FW: [M4IF Infolist] MPEG-4 and MHP and SMIL? Message-ID: (moved over) This has been an interesting thread. Are we seeing a divergence of specs with similar user experience goals? I'd like to hear some comments comparing how user experiences/apps are developed in addition to how the various formats overlap. Technology Implementation/Authoring Timeframe MHP Java or (Bean Tool?) Today? MPEG4 Scripting (BIFS Tool?) <1 year SMIL2.0 Handcoding or Tool Ongoing Flash Authoring Tool Ongoing DHTML/ActiveX Handcoding? Ongoing Are there comparison(s) to be made between BIFS and SMIL? Regards, Bill Mandel From ayerkes gmvnetwork.com Sat Apr 28 03:15:18 2001 From: ayerkes gmvnetwork.com (Art Yerkes) Date: Wed Jul 30 14:06:32 2003 Subject: [M4IF Technotes] DMIF and uuData Message-ID: <200104280215.f3S2FIN07956@mail.genxnet.com> Hello all, We have implemented a DMIF instance (apart from any comittee sources) that we believe is commercially viable. It's a C API that uses an XML configuration. The DMIF specification makes it possible to write such an API enabling applications to stream MPEG-4 without knowing about transports or protocols. It has gone well. We have written some sample code with it, and it fully complies with DMIF. The development of DMIF represents significant change in the design of media infrstructure when it becomes mainstream, because it allows a beautiful sharing of code between applications. I am confident that, IP issues aside, DMIF will become the preeminent API for writing streaming apps, because it provides an amicable divorce between code that implements transport and code that implements the 'value', presentation, player, IPMP, and other code. However, I noticed one thing that makes DMIF more complicated to adhere to if you don't know what application your DMIF instance will be communicating with. In our case, our DMIF is meant to be sold as a component. Perhaps no-one else plans to do this, but we wanted to mention our problem in hopes that someone else may benefit from sharing experience about this matter. I propose a problem and one possible solution. I am interested in hearing comments both about our view of this problem and our intended solution. The problem as I see it is that uuData in it's many forms throughout the specification of the DMIF Application interface is only opaque data. Even though this data is meant for interpretation by the application and not by DMIF, conforming applications eventually need to settle on a form for this data both to prevent misinterpretation by incompatible DMIF applications which implement the same protocol, and to facilitate good communication between DMIF applications that are meant to be compatible. I have several reasons for thinking this: 1) A vendor may wish to implement a DMIF service layer (part of a "peer application," running on the same computer that reads a certain filetype and delivers data to the DAI layer of the calling application. The generaic service provider needs a way to interface with potentially many Originating DMIF peer applications. 2) In 14496-6.10.4.1, it is specified that the DMIF user 'might' provide additional information such as client credentials in uuData. A media-unaware transport agent (such as a firewall tunnel or similar) may need to check credentials before admission to the firewalled environment. This necessitates an application independent method at least for credentials signalling. In HTTP and RTSP, this is handled with a WWW-Authenticate response-header, which allows any HTTP-enabled application to interact in a seamless manner with different authentication systems of which it is aware. This does not limit application freedom very much. Vendors still have the opportunity to use any available authentication mechanism (nothing is specified about what mechanism to use), it simply allows the mechanism and it's associated data to be clearly identified. 3) In 14496-6.10.4.5, the uuDataIn field provides information about the channels requested. This information is important when individual elementary streams contain different parts of a presentation. An example of this would be a presentation containing several JFIF images connected by hyperlinks, such as the menu system for a kiosk. Although this information is "opaque to the delivery layer", it is not opaque to the remote DMIF application. Again, an identification of what data has been sent should also be sent in a standard form, probably a MIME type preceeding the data. Again, This is not too much to ask, and provides the benefit of letting the peer DMIF application know what to expect. Even better would be the specification of a requested ES_ID form and position. This would allow (for example) a disk DMIF instance to correctly identify a requested elementary stream in a uniform way. It would also allow two DMIF peers made by different companies to dicuss a specific elementary stream, even if they were not 'born' compatible. 4) In 14496-6.10.4.6, the specification states that the ES_ID may be present in the return uuData. It's presence and form (2 bytes, network byte order?) should be specified, as well as where it can be found in the uuData should be specified. This makes it possible for an application to silently ignore most of the opaque data that it doesn't understand, but still retrieve the ES_ID. 5) In 14496-6.10.4.9, as with the other uuData fields, this one carries no indication of it's contents. The problem here is that both a local DMIF scenario, and a remote instance have need of the information contained therein. This field has been implemented as four-byte little endian integers and as text strings. It would be nice to get an indication of the control scheme in use. An 'integer' scheme would not be pleased to get the string 'PLAY\0' and likewise, a DMIF peer implemented to expect null terminated strings would be imperiled by the reception of '\010TEARDOWN' (a string with the length information in front). While one might envision several solutions, I would propose that uuData objects follow HTTP style rules: At least a 'Content-Type: ...' header must be present before any data, but any number of response headers are allowed. Response headers are terminated by a blank line. Any data, binary, ASCII, opaque or otherwise may follow. The Content-Length header is never needed in this scenario because the length of the object is specified in the DMIF primitive itself. The payload part of the Content-Type header should be a textural MIME type. I also propose that the HTTP style WWW-Authenticate scheme be used in the ServiceAttach and ServiceDetach (when attachment is denied). I further propose that ES_ID, when present, shall be sent among the headers as mpeg4-esid, or mpeg4-esids if there are multiples (as sugguested in the draft-singer-mpeg4-ip-02 IETF draft. I wanted to gather comments and see if anyone else is like minded. Perhaps, this type of discussion can be the basis for either a formal or informal rule with regard to those pesky opaque bytes. References Title: A Framework for the delivery of MPEG-4 over IP-based Protocols Authors: D. Singer, Y Lim URL: http://www.ietf.cnri.reston.va.us/internet-drafts/draft-singer-mpeg4-ip-02.txt Title: Real Time Streaming Protocol Authors: H. Schulzrinne URL: http://www.freesoft.org/CIE/RFC/Orig/rfc2326.txt Title: Hypertext Transfer Protocol Authors: R. Fielding, J. Gettys, J Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee URL: http://www.freesoft.org/CIE/RFC/Orig/rfc2616.txt Art Yerkes Chief Software Architect GMV Network -- HTTP_TRACE( "RTSPSession has died of snarfage.\n" ) -- Anonymous C source file #define SS_USR 6 /* The user is broken */ -- Anonymous Header File From manish.kulkarni uisdl.com Mon Apr 30 12:04:25 2001 From: manish.kulkarni uisdl.com (Manish Kulkarni) Date: Wed Jul 30 14:07:54 2003 Subject: [M4IF Technotes] Help Message-ID: <3AECF961.71F9A9C7@uisdl.com> Hi, I recently purchased a license for ISO14496-5 which is the reference software from ISO... I tried running the IM1player as per the systems\systems.doc file. In that document it is given that the command line to run the above project is given in[3] i.e ISO/IEC JTC1/SC29/WG11 M4372, Version notes on IM1 Core code and Tools release 2.0, Contribution for Seoul, South Korea, March 1999 But this document is not avaliable anywhere and i have searched for it on the ISO Web site. What is the problem?..it surely cannot be obsolete files as the Reference was recently ordered. If any of you have come across this problem let me know at the above e-mail address. Thank u in advance, Manish