Page 1 of 1

HLS Live Streaming Performance

Posted: 13 Jan 2014 16:00
by Ltty
Hi,

we're actually trying to use LibVLC on Android for HLS live streaming of the GoPro preview, which is actually a H264 encoded stream. Compiling the project for Android and streaming any MP4 file works well. However, live preview from a m3u8 playlist does not play smoothly. Android reports that there are errors in the segment numbers and the video is stuttering and has a delay up to 5 seconds on a HTC One with native OMX decoding.

Is there a way to somehow improve HLS livestreaming to get rid of the delay, respectively reduce it to somewhat reasonable? From the official GoPro app, I know that smooth video streaming is possible with a delay of about 0.5 seconds. However, they don't process audio but I don't think that that's the reason for the bad performance of the decoder. Also, I am assuming that VLC is more experienced in video decoding than they are. So I was wondering what I can possibly do in order to improve the performance for HLS decoding in order to provide a smoother user experience without stuttering and less delay.

If required, I could upload a sample of the *.m3u8 file. Any ideas appreciated!

Best regards

Re: HLS Live Streaming Performance

Posted: 13 Jan 2014 21:40
by edwardw
What are you encoding on and where are you decoding it?

Re: HLS Live Streaming Performance

Posted: 14 Jan 2014 13:04
by Ltty
This is the information I get from the m3u8 file:

Duration: 00:00:00.02, start: 1248.215467, bitrate: 131 kb/s
Stream #0:0: Video: h264 (High) (HDMV / 0x564D4448), yuvj420p, 432x240 [SAR 1:1 DAR 9:5], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1: Audio: aac ([15][0][0][0] / 0x000F), 48000 Hz, stereo, s16, 131 kb/s

Basically, encoding is done on the camera, I cannot influence the encoding process. All I get is the m3u8 file containing the streaming information. Regarding LibVLC, for a first trial I just added the *.m3u8 to the playlist, activated iomx, deactivated the audio sync, enabled frameskip. That's it. I did not enforce a color profile or deblocking, as YUV just gives me a black screen. Deblocking mode is set to auto. I'm rendering to a Android SurfaceView by the way. So actually, I did not change anything specific regarding the decoding process, just tried to forward the m3u8 file to LibVLC. The file comes via http://10.5.5.9:8080/live/amba.m3u8

Re: HLS Live Streaming Performance

Posted: 15 Jan 2014 12:08
by edwardw
Can you play it back from VLC for Desktop?

Re: HLS Live Streaming Performance

Posted: 15 Jan 2014 12:36
by Ltty
Yes, I can without any issues or stuttering. It also works on Android, however the performance is not good. Getting these huge delays as previously mentioned, even on high-end devices.

Re: HLS Live Streaming Performance

Posted: 16 Jan 2014 01:19
by edwardw
Try to produce a debug/messages log: http://wiki.videolan.org/Android_Report ... ssages_log

Re: HLS Live Streaming Performance

Posted: 17 Jan 2014 11:03
by Ltty
Hi,

I produced a log file for a few seconds of video playback. Device was an HTC One with Android 4.3.
You can download the log from here as it is too large to post it directly in here: https://dl.dropboxusercontent.com/u/126 ... id_log.txt

I figured out that it also starts to stutter and stalls on VLC for Windows after some time.

Does VLC on Android come with Neon support, what about stagefright?

Any ideas how to approach a possible solution? I really need to get a better performance than that and I know that it is possible.

Re: HLS Live Streaming Performance

Posted: 17 Jan 2014 12:54
by edwardw
Does VLC on Android come with Neon support
Yes, take the ARMv7 build.
what about stagefright?
Not directly, but we do support Android MediaCodec (and iomx on older platforms).

Re: HLS Live Streaming Performance

Posted: 17 Jan 2014 13:03
by Ltty
Okay, I am using the ARMv7 build so that shouldn't be the problem.

I'm starting to think that the provided ts files are maybe corrupted because I don't experience this issue for different m3u8. Is the decoder waiting at some point if sequence numbers are corrupted or if any specific information is missing or wrong? I'm starting to believe that GoPro themselves just try to bruteforce decode the frames they get and play them as fast as possible regardless synchronization. Also they strip the whole audio part.

However, I know that they make use of stagefright in combination i iomx but I don't think that this would boost the performance that much. Maybe you can have a look at the log file. Perhaps you find something useful. Otherwise I could also provide one or multiple of the ts files.