ipad: troubles with long clips and/or playlists

[GoogleCodeExporter]

See:
http://flowplayer.blacktrash.org/test/ipad-long.html

Plays through on html5 mp4 capable desktop browsers and iPod - but not on iPad.
API available on html5 mp4 capable desktop browsers (Safari, Chrome): 
$f().seek(3000) and $f().play(2) work - trouble on iPad.

I don't have an iPad, so iPad owners to the front!

Triggered by:
http://flowplayer.org/forum/support.html?id=100966

Original issue reported on code.google.com by blacktrashproduct on 14 Jun 2012 at 8:24

[GoogleCodeExporter]

Is there a way to get a test with a raw tag. need to test playback and seeking 
with that. In my tests so far it will randomly drop frames after seeking 
outside the buffer, then stops downloading and playbacks stops. This is a 
quicktime player it uses after all, ie the quicktime logo appears. Perhaps its 
an issue with the ipad plugin ..

Original comment by electrot...@gmail.com on 14 Jun 2012 at 9:16

[GoogleCodeExporter]

http://www.blacktrash.org/test/videotag.html - no playlist obviously, but a 
long clip.

Original comment by blacktrashproduct on 14 Jun 2012 at 9:29

[GoogleCodeExporter]

thanks very much still does it. drops frames audio still plays, after i dropped 
the scrubber, takes ages to catch up, pauses but can come out of pause mode. 
possibly an issue with the default controls. will have to test via scripting 
with a few seek commands. just plain awful experience, I dont really watch 
videos in the ipad. 

yes ive done it quite a few times and there is a buffer marker where its 
stopped downloading, if i try and seek past this it will go back and then 
pause. perhaps this is whats happening with the playlists also. 

i'm going to have to say bug with IOS. perhaps have to set autoPlay to false 
for playlists, to let it buffer a little bit and what not. 

Original comment by electrot...@gmail.com on 14 Jun 2012 at 9:40

[GoogleCodeExporter]

It could also be cloudfront handling the headers too. Is there another place to 
get the files from ? 

Original comment by electrot...@gmail.com on 14 Jun 2012 at 9:42

[GoogleCodeExporter]

I've now added the detailed codec info in the source type attributes.

wrt cloudfront: that's the whole point of using cloudfront, isn't it? Shouldn't 
other devices/browsers then exhibit the problem? Will upload one video to my 
server temporarily though and update the demo.

Original comment by blacktrashproduct on 14 Jun 2012 at 9:57

[GoogleCodeExporter]

http://www.blacktrash.org/test/videotag.html updated with 2nd sample, mp4 only, 
mp4 delivered from blacktrash.org.

Original comment by blacktrashproduct on 14 Jun 2012 at 10:41

[GoogleCodeExporter]

Same deal, here is my opinion, apart from what I found , longer the mp4 larger 
the moov atom to download, the worse the progressive download experience. Very 
large flv progressive download in flash for instance starts right away however 
because its header is tiny, taking into account latency etc. 

I'll spend some time to setup a HLS alternative or give me a file I can use to 
split it up. I bet it will work best, I only ever setup HLS for people. I'm not 
sure what else to say so far, I know just as much as you do. 

Original comment by electrot...@gmail.com on 14 Jun 2012 at 11:44

[GoogleCodeExporter]

and HLS is built by apple and designed especially for streaming properly on 
these devices where the user experience is consistant, if apple suggest to use 
it, that is a eye opener in regards to their stance on h264, I just don't think 
they care much with h264.  

Again we should test HLS and probably a smaller sized mp4 to try and crash that 
because I think people have been complaining about HLS also which may suggest 
the default controlbar is dodgy somehow, we might need to setup some seek 
scripted commands to verify that. Not very easy to figure when the internals 
are closed source / no logs. 

Original comment by electrot...@gmail.com on 14 Jun 2012 at 11:50

[GoogleCodeExporter]

For the fun of it I've added JWPlayer with the same playlist at
http://flowplayer.blacktrash.org/test/ipad-long.html

If it doesn't exhibit the problem, we know we have to do something about the 
ipad plugin.

A real pity, because in all other circumstances html5 is very convincing with 
long videos: instant seeking to anywhere etc.

The small iOS devices probably avoid the problem by taking longer to load the 
entire moov atom.

Perhaps the ipad plugin should check explictly for video.loadeddata

Original comment by blacktrashproduct on 14 Jun 2012 at 9:06

[GoogleCodeExporter]

Oh, and desktop browsers seem to handle http 1.1 headers just fine, the video 
does NOT have to be downloaded progressively.

Original comment by blacktrashproduct on 14 Jun 2012 at 9:10

[GoogleCodeExporter]

According to the customer there was no problem with the one single long vidoe 
deployed via VideoJS at http://flowplayer.blacktrash.org/graceful.html - which 
would point to a problem with the ipad plugin.

Will also try to segment those videos - when I find the time.

Original comment by blacktrashproduct on 15 Jun 2012 at 6:27

[GoogleCodeExporter]

No im suffering instability issues with just one video as explained above with 
just the html5 tag. OK so they are using a scripted controlbar I will have to 
test that in a moment. Thats what I mean by testing seeking with scripts. It 
does take ages to load the atom and sits there and hangs while its doing it. 
ALL mp4 streams have to download the atom first . 

Original comment by electrot...@gmail.com on 15 Jun 2012 at 9:31

[GoogleCodeExporter]

It does take a long time on iOS, but not in a html5 capable desktop browser. 
You can seek immediately. Try it with an empty cache. I think that's because of 
the byte-range headers.

Original comment by blacktrashproduct on 15 Jun 2012 at 9:51

[GoogleCodeExporter]

Im sorry im testing it this way but i feel its related upon changing streams, 

In safari the default html5 controls is ok on this one apart from the awful 
startup times because of the moov atoms like its that long it would perceive to 
be frozen. the jwplayer wont even let me seek at all and the dragger goes back 
to the start. videojs skipped back also and has the same startup time troubles. 
downloads moov atoms then shows frame then buffers then plays could take up to 
10-20seconds to do all this on a 100MB cable connection. startup time on 
videojs on safari is worse i think. flash starts up quicker. 

not seeing this crazy lockup though as im seeing on ipad. 

will test ipad. 

Original comment by electrot...@gmail.com on 15 Jun 2012 at 10:56

[GoogleCodeExporter]

same deal on ipad with those tests , what ive just discovered as with the vimeo 
html5 player, it gets replaced with the default controls, ipad completely takes 
it all over with their own play button / player as ive noticed before. Perhaps 
its something to do with the controlbar which could be confirmed with seek 
scripting. But definitely drops frames sound keeps playing while trying to 
seek, this instability along with the startup time issue could be causing the 
transition problem. In my view I would be setting up multiple tags and arming 
the next before just before the other one ends perhaps for ipad, usual work 
arounds because of apple !  Confirm this with HLS I guess, I've never seen 
issues with HLS and tested it's bitrate switching also and works fine. 

Original comment by electrot...@gmail.com on 15 Jun 2012 at 11:08

[GoogleCodeExporter]

I really don't see such big problems in desktop browsers, there's about 1 or 2 
seconds loading of the moov atom for the 1 hour 50 min video, but I sometimes 
get this kind of loading time in rtmp as well (even for short clips).

Be that as it may, everything seems broken on iPad, even the playlist with 
shorter clips, so I will segment these streams - will take some time though.

Original comment by blacktrashproduct on 15 Jun 2012 at 4:27

[GoogleCodeExporter]

Nah the loading times in html5 on desktop is the same, flash loaded in less 
time, ipad was worse. I think its just the html5 implementation on the ipad. If 
there is an encoding.com account it can be done as a job easily with the 
iphone_stream profile. I do think this is partially the problem when changing 
streams, the moov atom start times, and this random pausing when it messes up. 

Original comment by electrot...@gmail.com on 15 Jun 2012 at 4:35

[GoogleCodeExporter]

quote customer from support:
i originally discovered this bug while using 2 vids from the akamai hd network, 
using the akamai provider, in m3u8 format

(!!)

I will work on m3u8 segmentation, but at least in theory I don't understand how 
reading a long m3u8 playlist file should take less time than reading a large 
moov atom.

Original comment by blacktrashproduct on 15 Jun 2012 at 10:43

[GoogleCodeExporter]

Before I switched to cloudfront, I also tested hddn because they offer m3u8 
playlists. One of the reasons - besides pricing - I choose cloudfront was that 
loading m3u8 took at least as long as loading the mp4 (moov atom).

From my perspective this leaves the iPad as only problem case.

Original comment by blacktrashproduct on 15 Jun 2012 at 11:18

[GoogleCodeExporter]

It's using much smaller files to buffer, and byte appending techniques to 
locate to portions of the file no byte range seeking, smaller file headers, its 
mpegts also not h264 (mpegts is old and being depreciated  i believe !). I just 
think apple are a rouge organisation and if something isn't theirs they won't 
care much about it and try and use their influence to try and kill it but in 
the process create a nightmare in terms of standards, I think their stance 
against h264 is obvious, especially with these inconsistant encoding limits and 
complaining that it's intensive as an excuse for making bad hardware ;) 
Unfortunately there is no real way to get lower level logs of whats going on 
inside if I do find out i'll let you know. 

I would test a normal set of segments, if you give me some files I can run jobs 
through encoding.com. hls via wowza incurs the overhead of transcoding through 
wowza although convenient. 

Original comment by electrot...@gmail.com on 16 Jun 2012 at 8:21

[GoogleCodeExporter]

??? the video _codec_ is still h.264 or avc if you like in the small .ts files 
delivered by an m3u8 playlist. And for a large video still a large m3u8 file 
must be read first which will take at least as much time as reading a large 
moov atom.

hls is primarily for Live streaming, otherwise I don't see the advantage - at 
least in theory.

You can play around with http://media.blacktrash.org/ccc.mp4 if you want.

Original comment by blacktrashproduct on 17 Jun 2012 at 8:46

[GoogleCodeExporter]

thanks i'll download. it's not just for live streaming, its in byte append mode 
therefore streaming not downloading. you are right it is a container format 
with h264, but there is no moov atom in the chunks to deal with i believe. 

I came across videos on my local news site, it didn't seem to have the issues 
im experiencing, but locality wise the files are probably on a lower latency 
connection, would have to debug that. 

Original comment by electrot...@gmail.com on 18 Jun 2012 at 1:24

[GoogleCodeExporter]

well that failed miserably, I have people using encoding.com but I met nothing 
but brick walls and flaws with the signup of their system that they arrogantly 
ignored my suggestions to fix, and the job failed after an hour because the 
file + the encodes was over a gig which is the limit on the free account and 
even though I explained myself they want me to pay. I may not direct people 
there anymore ! Will try somewhere else but I may end up having to use the 
command line ;)

Original comment by electrot...@gmail.com on 19 Jun 2012 at 1:57

[GoogleCodeExporter]

Here: http://flowplayer.blacktrash.org/test/videotag-ios.html segmented by 
yours truly, i.e. ffmpeg.

Again: works ok with iOS 3.1.3 - but it will NOT work with desktop browsers! 
Seems to load slightly faster in my ipod, but not that much faster.

If indeed this is more reliable, then one for html5 one has to have 4(!) 
versions of a video available.

Will try to make this work with fp playlists, but already those m3u8 files do 
not end properly (yes I have #EXT-X-ENDLIST at the endo of the m3u8). But at 
least now I long video can be tested.

btw, the file(s) are somewhat over 500Mb, not 1GB, not sure what encoding.com 
does.

Original comment by blacktrashproduct on 19 Jun 2012 at 10:09

[GoogleCodeExporter]

ok: here's the playlist with long clips:
http://flowplayer.blacktrash.org/test/ipad-long.html#player2
On my ipod with iOS 3.1.3 the result bad:
1) no play through, hangs at end of first clip
2) no (apple or QT) playlist controls
Does not happen with mp4 files:
http://flowplayer.blacktrash.org/test/ipad-long.html#player1

Looks like the iPad just can't handle long videos, or just one at a time, sort 
of ...

Original comment by blacktrashproduct on 19 Jun 2012 at 2:11

[GoogleCodeExporter]

just chill until i get something working with zencoder i might have to reduce 
the duration of this file first. it needs to use the filesegmenter tool and its 
only available to ios developers. having a look at the mp4 in safari gives me 
exactly the same playback experience as ios. the m3u8 is not seekable so 
something is up there but it start immediately. 

Original comment by electrot...@gmail.com on 19 Jun 2012 at 4:49

[GoogleCodeExporter]

It's seekable on the ipod.

The filesegmenter tool will basically do the same thing what I did, but you're 
welcome to try.

http://media.blacktrash.org/stsp.mp4 is shorter. But don't make it too short, 
after all this is about long videos.

Original comment by blacktrashproduct on 19 Jun 2012 at 5:07

[GoogleCodeExporter]

http://www.wowza.com/?lb=demo the wowza demo, plays fine and starts up fine, is 
seekable although still a bit of an awful experience, the dragger doesnt work, 
the track has to be clicked in safari anyway. On ipad with latency in mind its 
smooth as expected. 

And regarding multiple formats and versions times bitrates for html5, welcome 
to the world of html5. i told my client this and he freaked as he runs a 
showreel video platform for film professionals and its growing fast, he's 
sticking to HLS + flash for now ;)

Its highly unlikely any of these arrogant vendors will figure out what to 
standardise, if ice cream sandwich is supporting HLS you would think chrome 
would, hopefully DASH produces a standardised streaming platform. 

Original comment by electrot...@gmail.com on 19 Jun 2012 at 5:43

[GoogleCodeExporter]

http://flowplayer.blacktrash.org/test/ipad-long.html#player1

going to have to say the mp4 + HLS start the same, but seeking the mp4 doesnt 
have the frame issues i was experiencing with the other videos and starts 
quicker than the HLS for some reason. loading the second playlist item however 
produced the same startup time results, took about 40 seconds, 30 seconds to 
start, then 10 displays play button then begins playback. seeking on the hour 
long video is unstable. 

HLS when going to next playlist item, it started immediately but displayed the 
playbutton for 5 seconds while it was buffering. i tried to get close to the 
end to get to the next playlist item, it seeked to the duration then hanged 
with some operation cannot be completed dialog window. im now seeking it paused 
on startup after i have played the files a few times. 

Maybe there is some code issues as the jwplayer im not seeing it pause on 
startup, it also uses the default controls and scrubbing made the entire player 
hang and the browser refreshed itself or something like that. 

im now not experiencing the dropped frames issues on the 1 hour mp4 in jwplayer 
? the videos don't take that long to startup either ? need to pick out what the 
differences are I suppose. 

Original comment by electrot...@gmail.com on 19 Jun 2012 at 6:11

[GoogleCodeExporter]

Btw zencoder were a little more willing to extend the encode on this job but 
the interface is awful and requires time to figure it out because it's only api 
request based. is there any place out there that have done it right, and no 
need to muck around :) 

Original comment by electrot...@gmail.com on 19 Jun 2012 at 6:18

[GoogleCodeExporter]

Even some official Apple clip does not work on my iPod - same problem at the 
end (this one stops, unable to get out, deadly for a playlist - others just 
replay):
http://flowplayer.blacktrash.org/test/videotag-ios.html

Original comment by blacktrashproduct on 20 Jun 2012 at 10:28

[GoogleCodeExporter]

http://flowplayer.blacktrash.org/test/ipad-long.html#player2 now also delivers 
original Apple m3u8 long videos (not in Flash) - and on my iPod I cannot play 
through the list, plus I have no playlist controls (which I do have with mp4 
files).

Original comment by blacktrashproduct on 20 Jun 2012 at 10:54

[GoogleCodeExporter]

yeah its possibly some coding issue as jwplayer seems to refresh the files ok, 
but its still not smooth, it's clearly displaying some flashes of changing the 
file and the quicktime logo pops up. So its  doing something to completely 
remove the tag first before changing videos ? This is as far as I can go for 
testing i'm afraid, but I assure you HLS works better on IOS. 

But keen to start testing out DASH, it's picking up pace now with wowza backing 
it, it's also going to provide encryption methods / drm so I think it will 
eventually provide a standardised solution assuming all browsers uptake it, or 
back to the same problems of inconsistancies :(

http://informitv.com/news/2012/04/12/wowzajoinsdash/

Original comment by electrot...@gmail.com on 21 Jun 2012 at 9:07

[GoogleCodeExporter]

hls is working better on the iPad you are running. It's definitely worse on my 
iPod, and I don't even get playlist controls - just the ability to seek back 30 
secs on click.

And recent Apple desktop Safaris might play m3u8, not older ones - and Chrome 
doesn't either.

m3u8 LIVE streams are fine. m3u8 on demand - not convincing at all.

Original comment by blacktrashproduct on 21 Jun 2012 at 9:50

[GoogleCodeExporter]

http://dashpromotersgroup.com/
http://blogs.adobe.com/ktowes/2012/02/adobe-announces-support-for-mpeg-dash-stre
aming-standard.html

this is picking up pace !

Original comment by electrot...@gmail.com on 21 Jun 2012 at 12:23

[GoogleCodeExporter]

can we stay in the present, please, annoying as it might be?

Original comment by blacktrashproduct on 21 Jun 2012 at 12:27

[GoogleCodeExporter]

if you have a way to put some streams on hddn, test its hls implementation in a 
playlist perhaps, i dont have time to figure out zencoder and playback is 
smooth with wowza, i was unable to play your files back properly. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 12:33

[GoogleCodeExporter]

errmh, as I wrote, both demos now deliver an official Apple video from 
http://qthttp.apple.com.edgesuite.net/ - if that doesn't work on the iPad ...

What you will always miss out on with hls on the small iOS devices is the 
playlist controls, you cannot jump from one playlist item to another. 
Regardless of the delivery, imho this more or less a showstopper.

Original comment by blacktrashproduct on 21 Jun 2012 at 1:08

[GoogleCodeExporter]

sorry mate had a look, they use the segementer obviouslly, and there is many 
options i believe with it. it starts right away on the ipad, seeking is smooth 
no bugs whatsoever compared to mp4 playback. totally crap in safari osx, 
playback is fine but the seek start ups aren't fast enough. 

Original comment by electrot...@gmail.com on 21 Jun 2012 at 1:15

[GoogleCodeExporter]

http://flowplayer.blacktrash.org/test/ipad-long.html#player2 actuall did not 
work AT ALL playlist-wise with the official apple demo: it just stayed on the 
first version. To make it more obvious I've put 
http://184.72.239.149/vod/smil:bigbuckbunnyiphone.smil/chunklist-b400000.m3u8 
in between, and it just does not play through - it either hangs at the end of 
the first clip, or repeats the first clip.

From my perspective: unusable for playlists.

The segmentation thing is nothing magic, I'm now able to create exact 10 second 
chunks no problem. The problem is always at the end of the clip: either repeat 
or hang - exactly the same as with the apple demo.

I also tried with a more recent iPhone: again no problem with the mp4 files.

Original comment by blacktrashproduct on 26 Jun 2012 at 6:22

[GoogleCodeExporter]

Similar report: http://flowplayer.org/forum/support.html?id=101538

Everything works on iPhone, but not on iPad.

Original comment by blacktrashproduct on 28 Jun 2012 at 12:55

[GoogleCodeExporter]

I seem to make progress. This playlist plays through:
http://flowplayer.blacktrash.org/test/ipad-m3u8.html

Under one condition: the internet connection must allow high throughput! For 
instance huge concurrent uploads break the playlist item transitions - so on 
the iPod it feels still less stable than an mp4 file.

Original comment by blacktrashproduct on 28 Jun 2012 at 11:17