[FFmpeg-user] Playback issues with HLS on Android
Henk D. Schoneveld
belcampo at zonnet.nl
Tue May 14 18:43:34 CEST 2013
On May 13, 2013, at 11:02 AM, Andrew Sinclair <ajsinclair at gmail.com> wrote:
> Hi All,
> Sorry to pipe in late but after spending a lot of time recently on Android
> I can tell you there is no simple answer for HLS to work consistently
> across all devices. The underlying issue is that every hardware variation
> has a different video decoder chip and by nature this means that they all
> have slightly different video players compiled which are then called via
> JNI from the Android application layer.
> Now while many of these players are deriviatives of ffmpeg/ffplay they are
> often from way old versions.
> Best bet is to only go with a single bitrate if you want it to work
> reasonably well as multi bitrate will vary massively from device to device.
> If you really want good Android support you need to go with a custom media
> player and you can launch these via a webpage using an intent or just embed
> them in an app.
> For maximum compatibility I have also found that some Android devices don't
> like a lot of variation between what they get in the playlists and what
> they see in the segments so you should force keyframes so that the segment
> doesn't have chop on where the next I frame comes. I have been using a
> wrapper around ffmpeg to generate the keyframe string
> https://gist.github.com/sinkers/5567058 though should time permit I would
> like to get this into the ffmpeg codebase.
Suggestions to improve encoding speed and lowering bitrate by use of the crf function and anamorphic instead of a PAR of 1:1
By dividing build.sh in 5 pieces, 1 for each resolution, for example 1.sh - 5.sh.
Remove the 2 pass solution to 1 pass
In stead of -s 960x540 use 604x540 and for -s 1280x720 use 896x720
Run in parallel with
time ./5.sh 2>/dev/null & time ./4.sh 2>/dev/null & time ./3.sh 2>/dev/null & time ./2.sh 2>/dev/null & time ./1.sh 2>/dev/null &
On my 4-core machine encoding drops from
Total size of all encoded files drops from
30M tsorig ; original build.sh
19M ts ; crf 22 instead of bitrate and anamorphic vs PAR 1:1
I don't know of anamorphic works on Android on Apple iPod Touch TV iPad all works perfect
> However if anyone was to map which variations of HLS work and don't work on
> the many many devices it would be quite useful!
> On 13 May 2013 15:14, Fing Cmo <fingcmo at gmail.com> wrote:
>> Just to correct and add to the test list.
>> I tested your HLS test page on the following devices on their Chrome
>> Latest official OS/Firmware versions as of today.
>> Galaxy Note 2 -------------------- 1st AND 4th video play (No Flash).
>> Google Nexus 4 (Phone) ----- 1st AND 4th video play (No Flash).
>> Google Nexus 7 (Tablet) ----- 1st AND 4th video play (No Flash).
>> iPhone 4 --------------------------- All 4 HTML5 videos play (No Flash).
>> iPhone 5 --------------------------- All 4 HTML5 videos play (No Flash).
>> Google TV (Vizio VAP430) - ALL 5 videos play including the flash one.
>> Note that for Google TV, it plays in spite of your disclaimer:
>> "*Note:* AddType application/vnd.apple.mpegurl m3u8 #Does not work on
>> So apparently it works on that Android :)
>> On Sat, May 11, 2013 at 12:14 AM, Walter Ebert <lists at walterebert.com
>>>> If you don't mind, can you provide the ffmpeg commands you used to
>>>> generate the video segments?
>>> The commands are on Bitbucket:
>>>> Do the exact segments play on iDevices as well?
>>>> I guess I can test those later on iPhone :)
>>> The segments play on iOS devices. Although there is a problem on older
>>> devices with a resolution of 480x360 pixels (and iOS 4.2):
>>> - The first video can be started, but actually does not play because it
>>> contains higher resolution streams.
>>> - The 2nd and 3rd video cannot be started.
>>> - The 4th video with the 480x270.m3u8 stream play just fine.
>>> I would have expected that the device would automatically select the
>>> highest resolution it can play.
>>> On iPad the videos play without any problems. iPad 1 cannot play full HD
>>> (1920x1080) or higher. That is why the highest resolution on test page
>>> is 1280x720 pixels.
>>>>> I looked at your test page and found that your 3rd example has a typo
>>>>> the mime type: appplication/vnd.apple.mpegURL
>>>>> It should be application/vnd.apple.mpegURL
>>>>> (Note your mistaken triple "p")
>>> Thanks Timothy for catching that. I corrected the MIME type.
>>> ffmpeg-user mailing list
>>> ffmpeg-user at ffmpeg.org
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
More information about the ffmpeg-user