This one’s been quite elusive, and I hope its common enough I just missed something. I’ve got choppy VOD (not choppy as in poor performance, but choppy like something is wrong) from HLS using iPhone 4, iPad1, and Safari 4 on 10.7. Its like a constant stuttering but only with specifically compressed files. Files also play fine through Quicktime directly and through RTMP/Flash, but through Wowza and HLS stutters.
It sounds related to this:
I also verified this (on v2 and v3 of Wowza)
90 key frames @30fps = 3000ms for the cupertinoChunkDurationTarget.
I’ve got the issue down to one difference being Main level 3.0 being OK and level 3.1+ has the issue (creating out of Compressor or Squeeze). Even when the above chunking is different I don’t have the problem on level 3.0 and down.
I’ll stop there hoping there’s a quick fix for this. iPhone 4S handles High now, so jumping at that would be cool to play with. What did I miss?
It might be encoding problem. Do you see anything in Flash playback? In Cupertino you should see smooth video for at least as long as the chunk size, then possibly buffering if bandwidth is the issue.
Do you have a m3u8 URL we can try? Post here or send to support@wowza.com with a link to this thread for reference
Trying to use HLS for on-demand streaming and users are complaining a ton about coppiness… using adaptive bitrate streaming. Hoping to find a setting that would help this. Using jwplayer to play the stream.
A typical user complaint is as follows:
"The videos are skipping a lot. The video just jumps to a random spot.
This is happening very often. It is becoming hard to watch the videos. I have a really good internet
connection because I can watch videos from other sites without a problem."
I would be suspect that it’s the users connection but it’s happening quite a lot across the board. Could it be an encoding issue of the videos? I’ve checked all aspects of the streaming path and I’m hoping a config change will help users with this type of issue.
I did see that article and it specifically talked about live HLS(iOS) which is different from my case. I can surely try the settings mentioned there if they will also be applicable to on demand HLS.
It looks like the default GOP is set to 250 for h264 video with ffmpeg. (https://sites.google.com/site/linuxencoding/x264-ffmpeg-mapping) So for a 30 fps video we’d be looking at a keyframe every 8.3 seconds… which isn’t optimal to be sure. I’ll see about lowing that to see if I can get more bang for my buck. Sadly I’m not able to repro this issue… go figure!
The information provided here helped me a lot for sure.
I was able to identify the problem with the pts stamps not lining up but also one of the streams had a different keyframe interval which would mess up things when switching streams. I ended up using a slightly modified ffmpeg command for conversions. I have noted it on the page for multibitrate encoding but for the sake of the thread I’ll include it here as well:
So switching to different sizes is easy by changing the scale value. It will automatically calculate the height based on the width passed in. Of course a -b could be added to set the bitrate.
Just to be sure, these properties are being added in the XML to Root/LiveStreamPacketizer/Properties correct? Not Root/Streams/LiveStreamPacketizer/Properties?
Oh, and there’s a naming difference in the article. In the post the names are “cupertinoXXX” but in the comments they omit “cupertino”. For version 3 which is it?
Yes I know, I quoted it in the first thread. There’s a naming difference in that article though. In the post the names are “cupertinoXXX” but in the comments they omit “cupertino”. For version 3 which is it? And just to be sure because its unclear in the article, these properties are being added in the XML to Root/LiveStreamPacketizer/Properties correct? Not Root/Streams/LiveStreamPacketizer/Properties? Otherwise the packet changes are not changing the glitchy video.
Thanks! Yep, these properties have no effect on the VOD stream, and don’t change how the video stutters. Its doing it about 6-7 times a second, though audio plays smooth. I have to wonder if its something else?
Ahhh! Alright, that seems to make the load time change. Still no go on the stutter. Tried several multiples. It seems like if it were a chunking problem, then every 3 seconds (since I’m in 90key @30fps), or a multiple of, there would be some sort of skip. Is that what it looks like if the chunking isn’t a multiple?
Assuming you haven’t messed with the packet sizes in the app config… The “jumps to random spots” might suggest each quality level doesn’t have keyframe/full frame/iframe in the same spot since when a rate change only happens on a keyframe. Uncheck any auto or best kind of setting in the compression app and enter one in that’s a multiple of the video’s frame rate, the same on each vid. That’s my take… unless Richard’s got his usual ninja-awesome trick I don’t know about or knows some other weird HLS thing.
I don’t know offhand what the default ffmpeg keyframe (GOP size, as if this didn’t have enough nicknames) would be if it wasn’t specified, and seems like Google isn’t super clear, so try setting it for sure. This is also helpful for setting up Wowza.