Snow Leopard / Apple H.264 / RTSP playback problems

Wowza Streaming Engine
1

Taking off from this old thread:

https://www.wowza.com/forums/showthread.php?p=44523

I have found similar problems for Mac OS X 10.6 Snow Leopard clients playing Wowza RTSP streams using Apple/QuickTime H.264 video.

Through Wowza RTSP, Apple H.264 content plays back extremely choppy – basically unwatchable – on Snow Leopard systems in QuickTime X, QuickTime 7, or embedded in Safari. It plays much better in VLC or embedded in Firefox. The same content plays fine in all programs through Darwin or QTSS, or through Wowza using RTMP or HTTP.

All I did was:

  1. Export the Extremists.m4v file as baseline H.264 video in a MP4 container using QuickTime Pro

  2. Set up a new VOD application in Wowza

  3. Play the new file via Wowza RTSP on a Snow Leopard system (QuickTime X, QuickTime 7, or embedded in Safari)

I also see the choppiness in live RTSP H.264 streams from QuickTime Broadcaster (although I know that’s not baseline video).

The original Extremists.m4v demo file streams perfectly everywhere, but I notice its video codec is libx264, while QuickTime-exported MP4 files use the Apple H.264 codec (which is what we use, unfortunately).

I would be happy to do any further troubleshooting for this; if this gets solved, we can probably switch to Wowza exclusively and ditch Darwin/QTSS.

2

I am doing it on Windows.

Charlie

3

I really don’t know. I don’t have any experience on the client side. We are more focused on the server-side.

Charlie

4

Try this new version of the Extremists.m4v sample:

https://www.wowza.com/downloads/content/Extremists.m4v

And try this 400kbs version of bigbuckbunny:

https://www.wowza.com/downloads/content/sample.mp4

Richard

5

Can you provide a sample video that plays well through Darwin and does not play well through Wowza. I would like to take a look at it. If you don’t want to post them on the forums then send a link to support@wowza.com.

Thanks,

Charlie

6

I need the actual source file so I can test it locally. Can you send me a link to the actual file being streamed (support@wowza.com). Be sure to reference this thread so I know what it is in reference to.

Charlie

7

It is odd that the size of the two files are so different. I understand that the hinted version is going to be a bit larger but I would not expect it to be 2 times as large. I suspect that they are different encodes. When I use MP4Box to hint the Extremists2.mp4 rendition, the file size went from 10.9M to 11.9M where the Extremists2hinted.mp4 file is 22.2M.

You may want to go back and re-test using files with the same encode. Also, switch to this patch just so you are running the best RTSP/RTP rendition of our code:

WowzaMediaServer2.1.1-patch1.zip

Charlie

8

The problem seems to be UDP packet loss. If I force the QuickTime player to use RTSP/RTP tunneling (RTSP/RTP over HTTP) then they play the same. Using RTSP/RTP tunneling forces RTP over TCP which eliminates the UDP packet loss issue. Wowza probably needs to do a better job of UDP packet throttling. It is something we may address in the future. It would be interesting to try the patch I sent a few posts back. It might help.

Charlie

9

I’m not sure what to do, or what can be done. It’s true that of all the possible players and devices now, and all the possible encoders and encoding parameters, some encodings don’t work well on some players.

Richard

10

Thanks for the reply. I should have added, I was already using the more recent Extremists.m4v file. The Big Buck Bunny file plays fine too, but it’s also using the “libx264” codec. The problem seems to be Apple H.264 files, as exported by QuickTime Pro.

Here’s a link, where you can stream or download a QuickTime Pro exported version of the Extremists file:

EDIT: link moved to post below

This doesn’t stream well in Snow Leopard Safari (nor does the direct RTSP link work well in QuickTime 7 or X on Snow Leopard).

11

For what it’s worth, when streaming in Safari (or Chrome), the Activity Monitor in Snow Leopard shows an extra “QuickTime Plugin” process, in addition to the browser process and a “vdecoder” process. Firefox (where the video plays correctly) only shows the browser process and the “vdecoder” process. Although QuickTime 7 shows the same as Firefox (itself plus “vdecoder”), and QuickTime X shows “QTKitServer” and “vdecoder” processes in addition to itself. System resources do not appear to be an issue.

Still, it seems odd that Darwin/QTSS can deliver these fine via RTSP, but they are choppy and unwatchable coming from Wowza by the same method using the same players. Oh well.

It looks like I can use this x264Encoder component in QuickTime Pro to produce compatible videos:

http://www003.upp.so-net.ne.jp/mycometg3/

Or ffmpeg, using a command derived from another thread here:

ffmpeg -i source.mov -s 640x480 -y -strict experimental -acodec libfaac -ab 64k -ac 1 -ar 44100 -vcodec libx264 -vpre default -vpre ipod640 -r 15 -g 75 -b 175k -threads 64 -async 1 output.mp4

These methods won’t help with live streaming, obviously, unless I switch encoders (from QuickTime Broadcaster). And it requires re-encoding the finished videos afterward, which is a bit of a pain (previously we could just do a quick “pass through” export to get the videos into a MP4 container and stream them almost immediately after they were done). For now, I will probably just have to maintain separate Wowza and Darwin/QTSS servers.

12

Here’s my demo link again:

http://160.94.17.33/demo/

I’ve got a Darwin stream and a Wowza RTSP stream linked there (and a video download link is on each of those pages). Note that I had to add a streaming hint track to play the MP4 file on the Darwin server, otherwise the two files are the same (the hint track didn’t seem to make a difference to the Wowza server).

And remember, the playback issues only arise on Snow Leopard systems (in Safari, Chrome, QuickTime 7, or QuickTime X). Snow Leopard Firefox seems to work fine, though.

13

Charlie,

There is a Download link on both pages in the above link, which will allow you to download the files. (The Darwin one has a hint track, the Wowza one does not, but otherwise they should be the same.)

14

The hint track was added with QuickTime Pro, and yes, it generally doubles the file size, but it should be the same encode. For what it’s worth, I can play the exact same “hinted” version fine in Wowza as well, for a direct apples-to-apples comparison.

I get the same results using the 854x480 H.264 version of the Big Buck Bunny movie – no re-encoding necessary:

http://160.94.17.33/demo2/

I’m already using the latest Wowza version from the dev build page:

Wowza Media Server 2 Perpetual 2.1.1 build24490

15

I installed the patch, but I get the same results.

How are you forcing it to use tunneling? QuickTime on Snow Leopard has removed that preference.

16

Oh. I haven’t had any playback problems in Windows at all – in the systems and browsers I’ve tested, it’s only been Snow Leopard (and specifically, Safari and QuickTime Player within Snow Leopard) where I have encountered it. Also, I added the RTP jitter buffer to my application, but I don’t see any packet loss in the logs, so I’m guessing it’s not that…?

If there is any advanced RTSP testing that can be done with Wowza and/or Snow Leopard QuickTime/Safari, I would be happy to perform it – I’m just not sure how to proceed. Firefox, Camino, and Opera all play the stream fine in Snow Leopard, and I think they all use the same “QuickTime Plug-in 7.6.6” as Safari (although the behavior in the Activity Monitor would suggest they go about it differently), so I’m not sure what’s going on in Safari/QuickTime.