Results 1 to 5 of 5

Thread: SMIL file causing long startup time

  1. #1
    Join Date
    Sep 2013
    Posts
    3

    Default SMIL file causing long startup time

    I'm having a problem where fetching an f4m file is taking a very long time--often 5-10 seconds--and subsequent requests happen quickly as though the data has been cached.

    We have a rather elaborate install for doing HDS (San Jose) streaming. Behind ELB, we have instances of Wowza. All of our video content has smil files, that look something like:

    <smil>
    <head>
    </head>
    <body>
    <switch>
    <video src="mp4:0-75k.mp4" system-bitrate="75000"/>
    <video src="mp4:0-150k.mp4" system-bitrate="150000"/>
    </switch>
    </body>
    </smil>
    once we request the .f4m from wowza, it returns something like:

    <manifest xmlns="http://ns.adobe.com/f4m/1.0">
    <id>9/positions/29/29/0.smil</id>
    <width>320</width>
    <height>240</height>
    <duration>14.022</duration>
    <mimeType>video/mp4</mimeType>
    <streamType>recorded</streamType>
    <deliveryType>streaming</deliveryType>
    <bootstrapInfo profile="named" id="bootstrap1">
    AAAAzmFic3QBAAAAAAAAAQAAAAPoAAAAAAAANsYAAAAAAAAAAAABAAEAAAABAAAAGmFzcnQBAAAAAQAAAAABAAAAAQAAAAcBAAAAhmFmcnQBAAAAAAAD6AEAAAAABwAAAAEAAAAAAAAAAAAAB9AAAAACAAAAAAAAB9AAAAfQAAAAAwAAAAAAAA+gAAAH0AAAAAQAAAAAAAAXcAAAB9AAAAAFAAAAAAAAH0AAAAfQAAAABgAAAAAAACcQAAAH0AAAAAcAAAAAAAAu4AAAB+Y=
    </bootstrapInfo>
    <media streamId="1" bootstrapInfoId="bootstrap1" width="160" height="120" bitrate="73" url="media_b75000_w659349691_qYXV0aD1Zekk1TnpkaE5URXRZakV5TnkwMFptVXlMV0ZoTlRVdE16QmlNbVZrWXpoaVl6Um1PbUl4WTJKa056QTRMVGN4TURNdE5HRmxNeTFoTkRBNExXSmhZekk0TnpsbE56YzFaam94TXpnd016RTNOVFV5T2pZMU5qWTRaV0ptWkRneU56TmlNak5sTnpOak5ETmxPREV4T1dSa09UUTROek00TURBNU1EYzZiVzlpYVd4bFgyUnBjbVZqZEElM0QlM0Q=.abst/">
    <metadata>
    AgAKb25NZXRhRGF0YQgAAAAAAAl0cmFja2luZm8KAAAAAgMACGxhbmd1YWdlAgADdW5kAAl0aW1lc2NhbGUAQDgAAAAAAAAABmxlbmd0aABAdPAAAAAAAAARc2FtcGxlZGVzY3JpcHRpb24KAAAAAQMACnNhbXBsZXR5cGUCAARhdmMxAAAJAAAJAwAIbGFuZ3VhZ2UCAAN1bmQACXRpbWVzY2FsZQBA1YiAAAAAAAAGbGVuZ3RoAEES3wAAAAAAABFzYW1wbGVkZXNjcmlwdGlvbgoAAAABAwAKc2FtcGxldHlwZQIABG1wNGEAAAkAAAkADWF1ZGlvY2hhbm5lbHMAQAAAAAAAAAAAD2F1ZGlvc2FtcGxlcmF0ZQBA1YiAAAAAAAAOdmlkZW9mcmFtZXJhdGUAQDgAAAAAAAAABmFhY2FvdABAAAAAAAAAAAAIYXZjbGV2ZWwAQCYAAAAAAAAACmF2Y3Byb2ZpbGUAQFkAAAAAAAAADGF1ZGlvY29kZWNpZAIABG1wNGEADHZpZGVvY29kZWNpZAIABGF2YzEABXdpZHRoAEBkAAAAAAAAAAZoZWlnaHQAQF4AAAAAAAAACmZyYW1lV2lkdGgAQGQAAAAAAAAAC2ZyYW1lSGVpZ2h0AEBeAAAAAAAAAAxkaXNwbGF5V2lkdGgAQGQAAAAAAAAADWRpc3BsYXlIZWlnaHQAQF4AAAAAAAAACWZyYW1lcmF0ZQBAOAAAAAAAAAAMbW9vdnBvc2l0aW9uAEEAh0AAAAAAAAhkdXJhdGlvbgBALAs9C5Y1uwAACQ==
    </metadata>
    </media>
    <media streamId="2" bootstrapInfoId="bootstrap1" width="320" height="240" bitrate="146" url="media_b150000_w659349691_qYXV0aD1Zekk1TnpkaE5URXRZakV5TnkwMFptVXlMV0ZoTlRVdE16QmlNbVZrWXpoaVl6Um1PbUl4WTJKa056QTRMVGN4TURNdE5HRmxNeTFoTkRBNExXSmhZekk0TnpsbE56YzFaam94TXpnd016RTNOVFV5T2pZMU5qWTRaV0ptWkRneU56TmlNak5sTnpOak5ETmxPREV4T1dSa09UUTROek00TURBNU1EYzZiVzlpYVd4bFgyUnBjbVZqZEElM0QlM0Q=.abst/">
    <metadata>
    AgAKb25NZXRhRGF0YQgAAAAAAAl0cmFja2luZm8KAAAAAgMACGxhbmd1YWdlAgADdW5kAAl0aW1lc2NhbGUAQDgAAAAAAAAABmxlbmd0aABAdPAAAAAAAAARc2FtcGxlZGVzY3JpcHRpb24KAAAAAQMACnNhbXBsZXR5cGUCAARhdmMxAAAJAAAJAwAIbGFuZ3VhZ2UCAAN1bmQACXRpbWVzY2FsZQBA1YiAAAAAAAAGbGVuZ3RoAEES3wAAAAAAABFzYW1wbGVkZXNjcmlwdGlvbgoAAAABAwAKc2FtcGxldHlwZQIABG1wNGEAAAkAAAkADWF1ZGlvY2hhbm5lbHMAQAAAAAAAAAAAD2F1ZGlvc2FtcGxlcmF0ZQBA1YiAAAAAAAAOdmlkZW9mcmFtZXJhdGUAQDgAAAAAAAAABmFhY2FvdABAAAAAAAAAAAAIYXZjbGV2ZWwAQCoAAAAAAAAACmF2Y3Byb2ZpbGUAQFkAAAAAAAAADGF1ZGlvY29kZWNpZAIABG1wNGEADHZpZGVvY29kZWNpZAIABGF2YzEABXdpZHRoAEB0AAAAAAAAAAZoZWlnaHQAQG4AAAAAAAAACmZyYW1lV2lkdGgAQHQAAAAAAAAAC2ZyYW1lSGVpZ2h0AEBuAAAAAAAAAAxkaXNwbGF5V2lkdGgAQHQAAAAAAAAADWRpc3BsYXlIZWlnaHQAQG4AAAAAAAAACWZyYW1lcmF0ZQBAOAAAAAAAAAAMbW9vdnBvc2l0aW9uAEEOFJgAAAAAAAhkdXJhdGlvbgBALAs9C5Y1uwAACQ==
    </metadata>
    </media>
    </manifest>
    So the first thing that catches my eye here is in my original smil file, I did not specify width/height--this implies that Wowza is actually fetching the content to populate the manifest file, and I believe this is the cause of slowness in our system. All of our video content relies in S3 and geographically stuff can get a little weird (large, distributed system), so I'd like to avoid having wowza hit s3 to pull the video data to generate the f4m manifest. Is there any way to do this?

  2. #2
    Join Date
    Sep 2013
    Posts
    3

    Default

    Realizing this is probably the wrong forum; any advice on where to repost this?

  3. #3
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    I doubt that the width and height info is the cause of this problem. I would take ELB out of the loop to test, that's where I would suspect the problem is.

    Richard

  4. #4
    Join Date
    Sep 2013
    Posts
    3

    Default

    Quote Originally Posted by rrlanham View Post
    I doubt that the width and height info is the cause of this problem. I would take ELB out of the loop to test, that's where I would suspect the problem is.

    Richard
    Maybe I wasn't clear--I don't believe "width and height info is the cause of this problem." Notice the smil file contains no width/height info, while the resulting f4m file does contain that info--that means wowza fetched the actual video data from s3 to generate the f4m. I don't think ELB has anything to do with the problem because all of that would be behind ELB.

    I've also noticed that even if I put width and height info in my smil file, it is overwritten entirely when wowza generates the f4m file. Same goes for duration and other properties. Basically I'd like to supply all the info necessary in the smil file, and not have wowza go out to s3 to generate the f4m. Is that possible?

    (edit: as an aside, I've noticed HLS does not suffer from this problem--you can lie through your teeth in the smil file--e.g. set width and height to 5000--and that's what gets served out if you request the m3u8; so one option I've pondered is swapping my flash player over to use the HLS url, although that's not exactly a trivial change to make OSMF jump through those hoops)
    Last edited by jnoring; 09-30-2013 at 11:13 AM.

  5. #5
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    The problem may be fragmented mp4 files. For comparison, take a look at the vod article and download the files in the ABR section article to use for testing.

    Richard

Similar Threads

  1. Long delay when playing live stream on iOS devices using SMIL file
    By mishak in forum Live Streaming and Encoder Discussion
    Replies: 4
    Last Post: 07-02-2014, 08:46 PM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •