4
votes

I'm a new iOS developer, I'm working on a video player app for a video sharing site, where sometimes a recording consists of two video streams (one showing the presenter, the other showing the recording of his screen). I'm trying to play this second video with AVFoundation, creating an AVPlayer. With some videos it works very well, but with some others it runs out of memory. After lot of investigating I figured that it tries to buffer the whole video into the memory.

I've spent hours googling it, but couldn't find anything.

I created a small project just to demonstrate this: github project. It sets up two AVPlayer's, for two different video streams, and updates the UI to show the loadedTimeRanges of the players' AVPlayerItem. For the first video it only buffers ~60 seconds, which is nice, but for the second video it keeps buffering.

self.player1 = [AVPlayer playerWithURL:url1];
self.player2 = [AVPlayer playerWithURL:url2];

and the two text labels:

self.data1.text = [NSString stringWithFormat:@"Player 1 loadedTimeRanges: %@",
                      self.player1.currentItem.loadedTimeRanges];
self.data2.text = [NSString stringWithFormat:@"Player 2 loadedTimeRanges: %@",
                      self.player2.currentItem.loadedTimeRanges];

Maybe this could be important: The over-buffering video does not have an audio track, just a video.

UPDATE: I reproduced the problem with using MPMoviePlayerController instead of AVPlayer, and checking the playableDuration property. With the first movie it stops around 60 seconds, with the second movie it keeps going and then it runs out of memory.

UPDATE2: I got the actual video files and put them up to Dropbox, and tried to stream those: then I don't have the problem! It buffers the whole movie, but it does not run out of memory. It only runs out of memory if I stream them from the original site (our video sharing site). The URLs are there in the github project.

I'm really looking forward to any hints what could cause this.

Thank you!

1
As suggested by Apple's Guidelines, do not use progressive download for bigger files but proper HTTP-streaming instead.Till
Hi @Till! Thank you for the comment! I'm not sure I understand, if I should change the app to use streaming, or the server side is not OK? The URL I have problem with is this: http://stream.videotorium.hu:1935/vtorium/_definst_/mp4:705/3705/3705_3571_content_hq.mp4/playlist.m3u8?sessionid=cp8dl757mvqukp0bsoflhd79s0_3705, if I curl it, I get an m3u which contains one other URL, if I curl that, I get an m3u with hundreds of URLs like media_1.ts?wowzasessionid=530673462&sessionid=cp8dl757mvqukp0bsoflhd79s0_3705. Does that mean that the server side is sending the proper stream?zsombornagy

1 Answers

1
votes

This problem is indeed caused by the lack of an audio track for video streams sent from Wowza media server. (I have inferred from your stream URLs that you're using Wowza media server to stream your videos).

To verify this issue, I created a 5 minute video file with no audio track.

mplayer -nolirc -vo null -ao null -frames 0 -identify test_60.mp4
...
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm: ffmpeg (FFmpeg H.264)
==========================================================================
ID_VIDEO_CODEC=ffh264
Audio: no sound
Starting playback...
...

Then I added a mp3 track to that video file using mp4box.

MP4Box -new -add test_60.mp4 -add test_music.mp3 test_60_music.mp4

And verified that there was indeed an audio track.

mplayer -nolirc -vo null -ao null -frames 0 -identify /tmp/test_60_music.mp4
...
AUDIO: 44100 Hz, 2 ch, floatle, 320.0 kbit/11.34% (ratio: 40000->352800)
ID_AUDIO_BITRATE=320000
ID_AUDIO_RATE=44100
ID_AUDIO_NCH=2
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
==========================================================================
AO: [null] 44100Hz 2ch floatle (4 bytes per sample)
ID_AUDIO_CODEC=ffmp3float
Starting playback...
...

Then, I put both the test_60.mp4 and test_60_music.mp4 in the Wowza content directory, and tested them. I actually wrote a small test app similar to yours to examine the loadedTimeRanges, but just loading the videos via safari from the device should be sufficient to see the difference.

I opened wowza_server:1935/vod/mp4:test_60.mp4/playlist.m3u8 and pressed pause as soon as it started playing. The buffer indicator kept increasing until the full 5 minute video was loaded.

Then, I opened wowza_server:1935/vod/mp4:test_60_music.mp4/playlist.m3u8 and did the same, but only the first 1/5th (roughly 1 minute) was loaded.

So it seems like a problem with the Wowza server's packetization - note this problem does not happen for me on adobe (flash) media server 5.0. Only 60 seconds is buffered regardless of whether the video contains an audio track.

Hope that's helpful. I've asked for input from Wowza folks at the Wowza forums