is it possible to disable hls.js support?

[FrankDaze]

Hi Ron,

happy new year. :)

I still have the problem with mixed content on Android devices. If I have a hls streamed video and then a native mp4 file I have to click play again, because the mp4 video tag hasn't got a click event.

HLS seems to be supported natively on Android and IOS devices, so it is not needed to use the hls.js on this devices (my theory). So, is it possible, if I detect my site is running on an android devices, that I disable the hls.js support and use the plain player?

thanks in advance
Frank

[rafa8626]

This issue is already been solved; please download the latest version that takes care of detecting if browsers supports native HLS and let me know if it works for you

[FrankDaze]

ah ok cool, I will check that.

[FrankDaze]

argh, you changed all css class names, now my own style settings are not working anymore and I see a completely broken player.

:-/

[rafa8626]

Use the classPrefix: 'mejs-' in the configuration and use the mediaelementplayer-legacy.css style sheet. You should be fine with it

[FrankDaze]

ok, I found the class prefix setting. Looks better now. :) Testing now the Android function.

[FrankDaze]

I have still the same problem with the second click on the play button on Android devices.

You can test it here: http://toggo-elex2.beta.eoa.de/videos/eoa/videokategorie-neu-566.htm?v=d37e318da49e2a724b0130a31cd6e7f0&AdDevMode=1

First you see a short video clip "Werbung Anfang" (Start Ad) HLS Video, then the Ad mp4 and then "Werbung Ende" HLS Video.

After the first video clip I have to click on play again to start the mp4 file.

I checked out the version from the 3.x branch, I hope that was the correct branch.

If I check it with the chrome remote debugger, I still see 2 video tags.

[rafa8626]

The 2 tags is expected; we preserve the original node in the event we need to extract other info, like the original URL of the HLS source before it's been converted to BLOB by hls.js. Let me check the issue with the play button, but is the issue stated on this ticket resolved?

[FrankDaze]

no it's not solved, sorry. I asked for nativ hls support on Android to use only 1 video tag on that device, to avoid the 2nd click problem.

On Android you can use the normal video tag with the video URL, the blob tag is not needed.
Then all videos run on the same video tag and you don't have to click on play again.

[rafa8626]

I see. Let me test one more time, because I tested on Safari (another browser that supports native HLS) and I didn't get the second video tag. BTW, which Android device are you using, and what browser are you using? I have a Samsung Galaxy version 4.4.2

[FrankDaze]

I use a Huawei P8 with Android 6, a Nexus 9 with Android 7 and a Kindle Fire HDX 3rd Gen. with Android 4.4.2 -> all with Chrome as Browser.

A good way to test with Android devices is to connect your Galaxy via USB cable and open Chrome on your computer. Then you can do a remote debugging inside Chrome.

[rafa8626]

Perfect I appreciate your help. I'll check this and keep you posted

[rafa8626]

I just tested http://johndyer.github.io/mediaelement/ in my Android device and directly selected the HLS source. I see only a video tag

The website is using the latest version of 3.x-dev. I'm gonna try to use Browserstack to see if I can test your environment, but it shouldn't be different

[rafa8626]

I could test Nexus 9 with Android 5.1 and I see only a video tag

[FrankDaze]

this source looks absolutely different, because it's 1 video tag with a seperate source and track tag.

I have a new pc so I downloaded the ZIP file, after I switched to the 3.x-dev branch. I have now the feeling that the zip file has not the content this branch. Seems to be the content of the master branch, correct?

[rafa8626]

It should you just need to use git checkout 3.x-dev inside the folder to change to that branch

[FrankDaze]

tomorrow, I will check out the branch via git and test again. I had no idea that the zip file is not from the branch.

Thanks for you help so far. Tomorrow I will tell you the new result.

[rafa8626]

Sounds good; keep me posted

[FrankDaze]

ok this morning I made a checkout of the 3.x-dev branch via GIT, but the code of the mediaelement-and-player.js is the same as yesterday. I used Winmerge to compare my files. Must be something other that is different.

I made only updates to the mediaelement-and-player.js file. Do I have to change something for the player initialization ?

[FrankDaze]

the feature list looks fine so far:
cancelFullScreen:()
fullScreenEventName:"webkitfullscreenchange"
hasFirefoxPluginMovingProblem:false
hasMozNativeFullScreen:false
hasMsNativeFullScreen:false
hasMse:true
hasNativeFullscreen:false
hasTouch:true
hasTrueNativeFullScreen:true
hasWebkitNativeFullScreen:true
hasiOSFullScreen:false
isAndroid:true
isChrome:true
isFirefox:false
isFullScreen:()
isIE:false
isSafari:false
isStockAndroid:false
isiOS:false
isiPad:false
isiPhone:false
nativeFullScreenEnabled:true
requestFullScreen:(el)
supportsMediaTag:true
supportsNativeHLS:true
supportsPointerEvents:true
svg:true

[FrankDaze]

oh is it possible, that my config is the problem?

var mediaPlayerConf = {
renderers: ['native_hls', 'flash_hls','html5'],
pluginPath: '../../rtli-video-player/mediaelement/3/',
enablePluginDebug: 0,
showPosterWhenEnded: true,
alwaysShowControls: true,
enableAutosize: true,
features: ['playpause','stop','progress','current','duration','volume','fullscreen'],
loop: false,
hls: {
debug: false,
autoStartLoad: false
},

[FrankDaze]

ok found the problem. The renderers sorting is importing.
With this sort it works: renderers: ['html5','native_hls', 'flash_hls']

[rafa8626]

Glad you found the problem. So can you see the expected output in Android now?

[FrankDaze]

yes, I have only one video tag now under Android. I have to check now all other browsers and iPhone again until I can put it to the live server. But the Android problem seems to be solved now. :-)

[rafa8626]

Sounds good. Let me know when you finish your tests so I can close this issue please

[FrankDaze]

@Ron666 I'm still in test phase, but I found out that the volume slider has a strange behavior now on my website.

Can you see any reason for this?

Same testlink as before: http://toggo-elex2.beta.eoa.de/videos/eoa/videokategorie-neu-566.htm?v=d37e318da49e2a724b0130a31cd6e7f0&AdDevMode=1

[rafa8626]

Which browser are you testing so I can attempt to reproduce the issue?

[FrankDaze]

I found the problem. I had to remove to top value in my css for .mejs-controls .mejs-volume-button .mejs-volume-slider .mejs-volume-handle
and for .mejs-controls .mejs-volume-button .mejs-volume-slider .mejs-volume-current

[rafa8626]

Oh I see what you are saying. So what you are seeing is if you slide up the bar goes down? Or is another behavior?

[rafa8626]

Gotcha. Any other issue?

[FrankDaze]

hehe yes. It was a pilot like volume controller :-)

I think the testing procedure can take time until tuesday next week . I have to check the new version again with all possible browsers and that with Win10 and Win7 and Mac OSX.

[FrankDaze]

After pressing on the play button the videoplayer removes the http:// from my original video source entry. This is causing an error in my VideoPlaza SDK which need URL with http:// or https://

[FrankDaze]

ah ok seems to be no problem in this case. The error come from something other in my Ad Player.

[rafa8626]

Well keep me posted about any other issues and I'll wait for your final feedback

[FrankDaze]

@Ron666 Thanks, you can close the ticket. We double checked the player and it seems to work fine now on all our testsystems & browsers. :-)

[rafa8626]

You are welcome. Glad I could help you