Results 1 to 5 of 5

Thread: Streamschedule.smil Transrate Playback Issue

  1. #1
    Join Date
    Aug 2012

    Default Streamschedule.smil Transrate Playback Issue

    I am using streamschedule.smil to reboardcast recordings thru the Amazon Cloudfront. Wowza transrates the high quality recordings to deliver a multi bit-rate HLS feed. The feed plays fine when played in the player, but when the next video in the playlist from the streamschedule starts, the last frame of the previous video hangs and the audio continues on. If I refresh the player or start and stop, the video will comeback until the next clip starts. If I sandwich the clips (clip A, clip B, clip A) and don't refresh the player on clip B, when the following clip A plays again the video starts up again just fine. All the while the audio plays just fine.

    I am curious if some data from the recorded clips is coming throw the transrate process, or if there is a slight gap when switching files? I have encoded all the recordings the same thinking that might have been the problem but it doesn't seem to have fixed the issue. I have also tried turning the pass metadata thru off and on.

    I have experienced this with the JWplayer and the Videojs player (with a custom flash fallback for HLS). The weird part is if I host the players locally the problem doesn't happen. The remote Videojs player spits this out for what seems like each chunck of the HLS.

    Level 2 Live Playlist parsing finished: reload in 11204 ms
    Loading       385 of [383,385],level 2
    Loaded        385 of [383,385],level 2 m/M PTS:3772621/3784824
    Loaded offset/duration/sliding/discontinuity:22.10/12.20/13.02/false
    Level 2 Live Playlist parsing finished: reload in 11112 ms
    Loading       386 of [384,386],level 2
    Loaded        386 of [384,386],level 2 m/M PTS:3784845/3794808
    Loaded offset/duration/sliding/discontinuity:24.32/9.96/23.02/false
    Level 2 Live Playlist parsing finished: reload in 10488 ms
    Loading       387 of [385,387],level 2
    Loaded        387 of [385,387],level 2 m/M PTS:3794829/3804856
    Loaded offset/duration/sliding/discontinuity:22.21/10.03/35.12/false
    If I play the HLS stream in a native player I don't get the issue.

    I realize this might be more of a player issue, but I wanted to make sure I understood what was happening on the Wowza side of things first.

  2. #2
    Join Date
    Dec 2007


    What you describe is a limitation of players' ability to handle abrupt changes in audio and video encoding midstream. Changes in audio codec can be especially difficult. You have to make each segment as similar as possible.


  3. #3
    Join Date
    Aug 2012


    Figured it was something along those lines.
    Does the keyframe interval on the transrate.xml have to match the video files setting? Also I am guessing <FollowSource> doesn't have anything to do with this.
    The other question would be... Are there better players out there that are know to be more robust? I like video.js cause it's free(obviously).

    When I get a chance to re-encoded the files, I will let you know if that fixes things at all.


  4. #4
    Join Date
    Aug 2012


    So I checked all the files with a bit more scrutiny and did find I had some mono files and stereo files. Can't completely trust batch converters... Anyway now that they all have the same settings, I am still having the same issues.

    I am wondering is there a way to have the Wowza streamschedule broadcast a less segmented stream? Maybe by using the transcoder instead of transrate? If not the other option I am thinking is to join all the files as one. I was trying to avoid that because of large files and the rigidity of that.

    Anyway for the sake of it here is the quicktime info on the codec... Maybe someone has had better experience with other codecs.
    JVT/AVC Coding, 854 x 480
    AAC, 48000 Hz, Stereo (L R)
    From Handbrake using the x264 encoding.

    So using Mediainfo I found some other differences in the video files. Gonna try re-encoding to get them matching perfectly.
    trellis=0 ... vs ... 1
    threads=12 ... vs ... 32
    bframes=3 ... I read these aren't the best for HLS.
    Video Stream BitRate (Nominal)
    Last edited by Surfincolin; 02-24-2014 at 01:38 PM.

  5. #5
    Join Date
    Aug 2012

    Thumbs up

    Well I finally figured it out. I'm kicking myself for not trying this earlier.

    After matching the files as close as possible with my encoders, I was still having video issues when the streamschedule.smil would switch files.
    The cause was that I was using the source in my delivery. Basically Wowza used the source as the HQ out of the 3 bit-rate/sizes that where in my playlist.m3u8. I switched the transrate.xml to not send the source through and instead add a separate high setting that didn't just pass through the source encoding. That fixed it and now the video plays continuously through the changing of clips in the streamschedule.smil.

    The reason I never thought to try that was because using the source during live broadcast that was never an issue. Lesson learned, let Wowza handle every aspect of your feed.

Similar Threads

  1. i need help with streamschedule.smil
    By emile.k in forum General Forum
    Replies: 5
    Last Post: 07-11-2014, 10:21 PM
  2. problem streamschedule.smil
    By tranmy1828 in forum General Forum
    Replies: 6
    Last Post: 03-30-2014, 08:45 PM
  3. Issue in publishing of streamschedule.smil
    By king407 in forum Tutorials Discussion
    Replies: 9
    Last Post: 01-31-2014, 10:46 AM

Posting Permissions

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