[Bug] [Media Element] Sliding the position bar causes the MediaFailure event

[rodhemphill]

Description

Xamarin Forms MediaElement on Android: Sliding the position bar on an Android tablet past the buffering progress causes the MediaFailure event to be triggered. Sliding up to the buggering position is fine, sliding on iOS is fine.

This is extremely frustrating as these are instructional videos for field staff. The reason they scrub forward is they need to see particular sections of the video (e.g. switch setting in an electrical sub-station setup). The work around is to reset the video to the start removing the buffering and causing the problem again. When it fails once I know they are going to do it again - they need that information towards the end of the video. We do not have great internet coverage in rural Australia and unfortunately I can't affect that.

Steps to Reproduce

1. Implement the standard Media Element repo.
2. Deploy to a Android tablet (mine is a Lenovo TB-X340L (API 25)
3. Slide the position bar past the buffing position

Expected Behaviour

Same as iOS: play wait until buffering catches up.

Actual Behaviour

The MediaFailed event is triggered. If you don't catch the event then MediaElements throws the display "Can't play this video." If you subsequently press "OK" to this prompt the video hangs - totally unresponsive. None of the controls work and the frame is frozen.

Basic Information

• Version with issue: Forms 4.6.0.847
• Last known good version: None
• Platform Target Frameworks:
  • Android: 9.0 (Pie)
• Android Support Library Version: v7.MediaRouter (28.0.0.3)

Reproduction Link

https://docs.microsoft.com/en-us/xamarin/xamarin-forms/user-interface/mediaelement

Workaround

(This is an unacceptable work around from a user perspective): I trap the MediaFailed event, display a message "Video has failed to play", replace the media source with a promotional video.

[hartez]

@rodhemphill The videos are remote, not locally stored or embedded? Are you loading them by setting the Source property of the MediaElement?

[rodhemphill]

Correct @hartez, they are URLs created using Azure Media transcoding being streamed from Azure and set using the Source property or MediaElement.

[hartez]

@rodhemphill Any chance these are publicly available, so we can reproduce/verify/test the problem with them? I can't reproduce the problem simply by loading MP4s remotely, so I'm guessing the issue has something to do with how MediaElement is handling the streaming format.

If they aren't available, can you tell us what streaming protocols you're using?

[rodhemphill]

Hi @hartez , easy to give you videos to test against, below. If you need a repo then with a bit of work I can create you a less client confidential one and give you private access with a temporary login. Let me know if you need that.

https://melbappdevstorage.blob.core.windows.net/techflix-dev/8d777b64-0f10-43d8-88a3-40914f55_1280x720_AACAudio_3456.mp4 8:31 https://melbappdevstorage.blob.core.windows.net/techflix-dev/b8c529a6-292a-435b-be4c-8c5eb2ab_646x360_AACAudio_466.mp4

[rodhemphill]

If you need a repo I'll send you access details on your gmail address.

[hartez]

@rodhemphill We'll get someone to test these out this week, and if we can't reproduce the problems with the links you provided, we'll figure out how to handle the repo access.

[hartez]

@rodhemphill Okay, when I tried one of the videos you linked above, I can absolutely reproduce the issue. But if I just use this Channel 9 video, I can't get the error to happen.

So this is probably an issue with how the MediaElement is handling the attempt to scrub forward.

Another interesting detail: If I open that Channel 9 video in a browser window (Chrome) and use the thumb on the slider to scrub forward to a spot past the end of the loading indicator, the video simply jumps forward to that spot. But if I open the videos linked above and do the same thing, the the thumb snaps back to the original spot rather than jumping forward.

I don't know a lot about streaming video formats, but maybe we're just dealing with a format which doesn't allow that kind of jumping around, and the MediaElement needs to behave accordinginly?

[rodhemphill]

@hartez We produced that video using Azure Media Services transcoding process and it is quite possible the Channel 9 video was also produced by azure media services.

Media Services works like this: We call a service that takes in (effectively) the raw video stream and a "Transform", which is essentially the rules to be applied to transcode a raw video into different resolutions. There are 10 encoder presets (listed below) for this transform - we use "AdaptiveStreaming" which we guessed would be best for us, but we have no idea really.

I see the choices as:

1. Get the problem fixed in MediaElement, or
2. Use a preset that by-passes the problem.

Either way, it would be very helpful to find out what preset Channel 9 used. Do you have any contact in the production team of Channel 9 that can tell us?

Thanks, Rod

Values are: EncoderNamedPreset.AdaptiveStreaming EncoderNamedPreset.AACGoodQualityAudio; EncoderNamedPreset.ContentAwareEncoding; EncoderNamedPreset.ContentAwareEncodingExperimental; EncoderNamedPreset.H264MultipleBitrate1080p; EncoderNamedPreset.H264MultipleBitrate720p; EncoderNamedPreset.H264MultipleBitrateSD; EncoderNamedPreset.H264SingleBitrate1080p; EncoderNamedPreset.H264SingleBitrate720p; EncoderNamedPreset.H264SingleBitrateSD;

[hartez]

@rodhemphill Changing your encoding might be a workaround until we get MediaElement fixed, but we definitely need to fix the control so it behaves appropriately in that situation.

@jamesmontemagno Do you happen to know how Channel 9 encodes its videos?