5 Replies Latest reply on Aug 9, 2010 3:40 PM by Barr4476

    RTMP/SMIL Parsing Question

    ScreenName1710b

      Looking at some SMIL files that I was working with, I noticed an issue with parsing.

       

      For example - take the SMIL file:

      http://mediapm.edgesuite.net/ovp/content/demo/smil/elephants_dream.smil

       

      Which sets (for any particular stream) (example A)

      host = rtmp://cp67126.edgefcs.net/ondemand

      stream = mp4:mediapm/ovp/content/demo/video/elephants_dream/elephants_dream_768x428_24.0fps_408kbp s.mp4

       

      However, not all SMIL files are structured that way some CDNs would set this same content as: (example B)

      host = rtmp://cp67126.edgefcs.net/ondemand/mediapm/ovp/content/demo/video/elephants_dream

      stream = mp4:elephants_dream_768x428_24.0fps_408kbps.mp4

       

      Now if I set these as straight RTMP streams into the standard OSMF Player :

      Only the first example works.

      rtmp://cp67126.edgefcs.net/ondemand/mp4:mediapm/ovp/content/demo/video/elephants_dream/ele phants_dream_768x428_24.0fps_408kbps.mp4

       

      The second example does not:

      rtmp://cp67126.edgefcs.net/ondemand/mediapm/ovp/content/demo/video/elephants_dream/mp4:ele phants_dream_768x428_24.0fps_408kbps.mp4 (OSMF Player comes back Stream Not Found)

       

      However, when I plug these two examples(A/B) directly (as host/stream) into a NetConnection/NetStream/Video group, both of the above examples work. Is this a bug in OSMF? or something that has to be addressed on the CDN level?

      Thanks.

       

      -Will

        • 1. Re: RTMP/SMIL Parsing Question
          ScreenName1710b Level 1

          I tested those examples above and found that they don't work, I apologize to anyone that was trying to look at this.

          However, I believe I've found some assumptions that are going on inside the FMSURL class that may be causing this issue.

           

          First assumption - found in comments

          // If "_definst_" is in the path and in the right place, we'll assume everything after that is the stream

           

          Second assumption is

          if (_streamName.search(/^mp4:/i) > -1)

           

          First, it assumes that _definst_ will always be right infront of the stream name, and that's where it should cut.

          Then it assumes that in the streamName that the "mp4:" will always be in the front. In this particular case; with some CDNs the mp4: might be much further  inside the stream name.

           

          The CDN format that I'm having the issue with (not the examples above) uniformly passes in the smil:

          host: rtmp://some.fms.server.somewhere/myusername/_definst_/mydirectory/directory/directory/

          stream: mp4:thestream.mp4

           

          So when I stitch this together to a standard rtmp - OSMF cuts it off after _definst_ and assumes that is the stream name, and then doesn't find the mp4: in the right place.

          But when I use the SMIL file, it then assumes that the stream name still comes after the "_definst_" (even though it has a seperate stream name) - and then somehow doesn't see the actual stream name at all.

           

          Do I have to write a custom SMIL parser and RTMP parser for this CDN, since it's not standard?

           

          Thanks.

          -Will

          • 2. Re: RTMP/SMIL Parsing Question
            ScreenName1710b Level 1

            I ended up making a modifications to the FMSURL.parsePath() to fix  this issue for this CDN's access:

                      if (_useInstance) {
                           _instanceName = result[INSTANCENAME_START_INDEX];

                      } else {

                           streamStartNdx = INSTANCENAME_START_INDEX + 1;
                      }
                            
                      for (var i:int = streamStartNdx+1; i < result.length; i++) {
                        _streamName += result[i];
                      }

                      // If no  streamName found in the path, check the query string

             

                      if (_streamName == null || _streamName == "") {
                                 _streamName = getParamValue(QUERY_STRING_STREAM);

                      // Else if there is no stream info at All ( Assumption :  This is a probably SMIL Reference)       

                      // Fixes appName for SMIL      

             
                             } else if (_streamName.search(/[.]/) == -1 &&  _streamName.search(/[:]/) == -1){
                                 _streamName = "";
                                 _appName = path;
                             }
                      // If there is still a stream - then search for the MP4  tag, if no MP4 tag

                      // Fixes RTMP issue

                           if (_streamName.search(/^mp4:/i) > -1) {
                                 _fileFormat = MP4_STREAM;
                              } else if (_streamName.search(/mp4:/i) > -1){
                                  _fileFormat = MP4_STREAM;
                                 var  loc:int = _streamName.search(/mp4:/i);
                                 var  tempSN:String = _streamName.slice(loc+4);
                                 var  secSN:String = _streamName.slice(0,loc);
                                  _streamName = "mp4:" + secSN + tempSN;
                             }

             

            Not  sure if this would be considered a hack, but anyway... it works for  the CDN that I'm working with, and all of the previous examples that  were provided by OSMF.  I didn't want to go to the extreme of  modifying the OSMF code, but this was where core issue was, but I didn't  think it could be fixed without modifing this Class/Method.

             

            For my purposes, this is an unsustainable fix - as I will need to be able to use the core OSMF package(AS or swc) that Adobe is supporting. I'm not sure (if someone can give me the recommendaton on how, if it is possible) that I can use a Plug-in to override this one function.

             

            Thanks.

            -Will

            • 3. Re: RTMP/SMIL Parsing Question
              charles_newman-dxEYjs

              I just checked with the FMS team at Adobe and the standard is prefix first, then path, then stream name. The prefix tells FMS which container library to load. So I think the OSMF class is correct. Perhaps a better approach for you is to let your CDN know they are using a non-standard FMS URI format.

              • 4. Re: RTMP/SMIL Parsing Question
                Bob Wohl Level 1

                I'm with Charles on this one about what FMS actually looks for that to know

                what kind of container to shell the media out with be it flv, mp4 or mp3, it

                needs to know otherwise errors are thrown, sometimes not so obvious ones w/o

                looking at the FMS logs. It is a pain with all the different "with or with

                out prefixes - with or without extensions"... Are you sure the CDN you are

                using requires that URL setup? I'm curious on this behavior.

                 

                 

                Bob

                • 5. Re: RTMP/SMIL Parsing Question
                  Barr4476 Level 1

                  I am having a similar issue. In that

                   

                  This url parses incorrectly

                  rtmp://test.com/VOD/vids/MediaCollection/89/791/0/7339/test

                   

                  while this one that doesn't contain an app instance works

                  rtmp://test.com/VOD/MediaCollection/89/791/0/7339/test

                   

                  I would assume that both should work or am I mistaken.

                   

                  Update:

                  After reading a little more I found the way to make it work.

                   

                  testPlayer.source =

                  new VideoElement(new NetLoader, new URLResource(new FMSURL("rtmp://test.com/VOD/vids/MediaCollection/89/791/0/7339/test", true)));

                   

                  Message was edited by: Barr4476