Server-side recording + B-frames, for iOS/RTSP playback

Wowza Streaming Engine
1

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 ~

-Joshua

2

Joshua,

The solution is to avoid b-frames if there is any issue using them, which they are frequently and we don’t have a solution in that case at present.

Richard

3

We would like to track the issue. What encoder are you using, what settings, and how is Wowza configured? (StreamType “live” and LiveStreamRecord module?)

Richard

4

Joshua,

Thanks for the info.

Richard

5

Thanks, Richard. I’ve shut off the B-frames on the encoder, and it seems that all is as expected now.

The live Wowza application is StreamType “live”, with the LiveStreamRecord module installed. I’ve written a custom HTTPProvider based on the included one to control the stopping/starting and add a couple features, but no changes to the core of the module itself.

The on-demand Wowza application that plays back the recorded files is StreamType “default”.

Our encoder is an Elemental Live server, publishing via RTMP; we’re currently pushing three streams per event:

1: 400x224, 256k H.264 + 128k AAC, 0 B-frames, GOP size 45, CABAC off.

2: 640x360, 512k H.264 + 128k AAC, 0 B-frames, GOP size 90, CABAC off.

3: 848x480, 1200k H.264 + 128k AAC, 0 B-frames, GOP size 90, CABAC on.

I can send additional information if needed, just let me know what you need. Thanks ~

-Joshua