![]() RTMP is still probably the best option for flash based players or alternatively HDS which is a protocol similar to HLS but is designed around flash. ![]() It is public demand and the fact that iOS devices do not support flash that has made HLS so popular. I wouldn’t go as far as saying that rtmp is a heavier protocol than HLS. Once the stream is running, rtmp will push out the stream data at roughly the video bitrate so that the player buffer remains full. Again, the closer the bandwidth is to the bitrate, the longer this will take. The default rtmp buffer setting on JW player is 3 seconds and Wowza will send out a complete buffer duration of video as fast as the network connection will allow so it will normally fill in less time. In contrast, rtmp playback will start and seek a lot quicker because the player only needs to fill the playback buffer in order to start initially or after a seek request. If you are close on your bandwidth then you will have to wait longer for the first chunk to be delivered. īecause of the size of the chunks and the fact that the player needs to request them on demand, the delay that you are seeing is the time taken for this request. You can set the chunk duration target to a different value by setting the following property in the HTTPStreamer / Properties in your Application.xml or in Application > Properties > Custom Properties in the Wowza Streaming Engine Manager. For the best results, you should use a key frame interval that will multiply evenly to the chunk duration target. Chunks are created at key frame boundaries so will be as close to the chunk duration target as the key frames will allow. The size of the chunks is determined by the cupertinoChunkDurationTarget property setting (default 10 seconds) and the key frame interval. HLS delivers the videos in separate chunks or segments that are requested by the player as it needs them. The main reason for the differences are in how each of the different methods deliver the video. Any ideas how to correct that? We have wowza configured to pull the videos off of a network share and I’m wondering if that plays into this. ![]() Once one video has been watched though, any subsequent attempts to watch any video has a much reduced start time. If a video hasn’t been watched for 15 or 20 minutes, it takes 15 - 30 seconds to start a video. Also notice that in firefox the HLS gets pixelated and blocky sometimes when you seek.Īlso, one more thing. First, notice Notice how much faster the RTMP seeks. The second one is RTMP, followed by HLS, with download fallback. The first video is HLS with download fallback. Perhaps I’m not embedding the player correctly. Originally, I wanted to stay away from RTMP if possible because it’s a heavier protocol. I realize this might be a question for the folks over at JWPlayer, but I thought I’d ask you guys too. RTMP seeks way faster than HLS and it never gets pixelated or blocky. So then I configured it to use RTMP as the primary, then HLS as secondary, and download fallback. Happens sometimes when you seek or when the video changes key frames. What is the best way to embed JWPlayer 6 so it works on the desktop, iOS, and android? We have videos in mp4 format and I originally configured the player to use HLS with download fallback, but I ran into a bunch of issues:ĭelayed start time, and a few second delay every time you seekįirefox and IE sometimes shows very pixelated and blocky video.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |