An odd issue we’ve had crop up here, that seems to trace back to something with the Wowza server-side recording functionality (as accessed through a custom HTTPProvider module we built, based on the ModuleLiveStreamRecord package).
Streams are all H.264/AAC, packaged as mp4.
Live streams always play fine, on all three of our test targets:
Flash via RTMPe
iOS (iPad) via Cupertino
VLC via RTSP
Our encoder sends the encoded streams to Wowza via RTMP, and records the same encoded output to a local mp4 file.
Because we can easily start & stop the archive recording on the Wowza server (much easier than on our live encoder), our primary means of generating files for VOD streaming is by server-side recording.
If a stream has B-frames enabled, the server-side recorded file plays fine on Flash/RTMP, but when played on iPad via Cupertino or VLC via RTSP, has an odd playback, it looks almost as though the frames are interlaced out of order, sort of a 2 frames forward, 1 frame back thing. (Our streams are deinterlaced at the encoder level and encoded progressive).
Taking the local recording of the same stream, made by the encoder, and uploading it to the server, results in perfect playback on all three targets.
Setting B-frames to zero results in perfect playback, but causes live streams on the iPad to stop playing after only a couple seconds.
B-frame settings tried were:
2 B, GOP length 90 (exhibits the problem)
1 B, GOP length 90 (exhibits the problem)
0 B, GOP length 90 (plays fine)
0 B, GOP length 45 (plays fine)
At one point, with a 0 B-frame setting, I saw a problem where the ipad would end playback of a live stream after just a couple seconds of material, but I can’t reliably reproduce that.
Are there any known issues around this, or any solutions? Let me know if any other testing, samples, etc, would be helpful for you to test this.
Many thanks ~