mobile ?

[AdrianDroid]

It don't seem to work on any mobile devices

[Wedmer]

As most of mobile devices have native support for hls you can make conditional video tag.

[AdrianDroid]

Unfortunately, HLS support on Android is far from perfect, it is broken / buggy across different brands of phones. With those old devices around, I will need a alternative solution.
Strangely, this lib don't seem to be work on ANY of my testing devices. I am still pinpointing why.
Even the The Galaxy Note 4, With run on Android 4.4 and latest chrome, have failed me.

I have done a few test case, AJAX with type BLOB (with mp4/webm) works fine. But once it load to ArrayBuffer/ convert from ArrayBuffer to BOLB, the video failed to work.

[RReverser]

Unfortunately, I don't have any of these devices to play with (and emulators don't show the full picture).

In any case, I think using native support wherever possible is the correct approach, as this library does repackaging in background thread, which requires more CPU resources than native libs, and so will consume battery pretty fast, which is important limitation of mobile devices.

[AdrianDroid]

Perfectly understand that. There are limitation that we must use HTML / WebView :<

anyhow, any idea how would ArrayBuffer to BOLB fail in ALL mobile device but not desktop ?

[RReverser]

Nope, no idea why. That's why I need at least some logs from device.

[DaKaZ]

I am a little late to the conversation, but as I am dealing with the fact that HLS is completely broken on Android 4.4.3 and 4.4.4 (which is all Galaxy S5s on Verizon!) I am looking for alternatives as well. I have a theory that I think could work with this library and I'll be happy to experiment with it if you can just give me your opinion quickly.

Basically, my theory is this. Our app is in appcelerator titanium, so I basically have a V8 javascript core to work from. I was planning on having my app pre-load the first X chunks of each video and store in a local .mp4 file. When a user goes to play that file, the app would then proceed to fetch the rest of the chunks and append to the existing MP4 file.

My question is this: is this even possible to append to the MP4 while playing it? I know MPEG2-TS quite well but not MP4. Doesn't the MOOV box have to be updated as new GOPs are added to the file? Would the native mobile player (android or iOS) even be able to handle that? I know MP4 supports progressive download so maybe I need to know what my file will look like when its all done and then append it? Although this would completely break if we have rate adaptive HLS files (which we do since we are mobile).

I am open to any and all suggestions, but my basic psuedo code would look like this:

1. Pre-fetch first 5 chunks of HLS video, convert to base MP4
2. When video starts playing, stream in remaining chunks, convert to MP4, append to base file

Note: we don't allow scrubbing so need to support ff/rew. Only pause.

Please let me know your thoughts.

Thanks

[RReverser]

@DaKaZ Nope, unfortunately, you need to have entire generated file information (i.e. information collected from all the original chunks in the stream) in order to provide even progressive download. That's why MP4 isn't suitable for streaming unless it's used for small separate chunks in Adaptive Streaming protocol like Apple HLS.

[Gagaro]

Hi,

I've tested the demo on Firefox OS (2.1). It seems to kinda works. Video is very small, it cuts sometimes (change of chunk ?), audio works fine. Does anyone have some experience using this library on this OS ?

Thanks

[RReverser]

Yeah, for some reason recently FF started reducing size of it (on desktop too), need to play with it to figure out why. I also have FF OS device, but actually didn't try there yet.

[Gagaro]

Thanks for the quick answer. I'll probably try some things on FF OS with this library later this week. I'll tell you if I figure out anything.

[Gagaro]

It works fine with FF 35 on windows.

[RReverser]

But not in Developer Edition 37.0a2.

[modest]

@DaKaZ @RReverser I think you guys are missing a key part of MP4.

Traditional MP4 files needed a complete index at the beginning of the file (in the "moov" atom).

MP4-based streaming formats (like MPEG-DASH) take advantage of a feature of the MP4 format called fragments. With a fragmented MP4, you do not need a complete sample table to write the MP4 headers. In this format, the file contains:

• a description of the tracks, with no sample table (moov)
• 1 or more fragments, each with:
  • a sample table (moof)
  • 2-10 seconds of media data (mdat), followed by another header

This is the right way to implement streaming MP4 and avoid playback gaps. If this project were updated to use fragmented MP4 with the Media Source Extensions API, it could achieve flawless HLS playback.

[RReverser]

Um, no, we are not missing it and this is reflected in other issues.