Video issue in preview

Bug Reports
1

Fuse version 0.34.0 (build 10613)

OSX 10.12.3

iOS 10.2.1

When showing Apple’s example HLS video in preview it crashes on OSX and only plays the sound on iOS. For the latter that also goes for other videostreams I have tested (none-public, so I can’t disclose those).

<App Background="Black">
    <Video ux:Name="video" Dock="Top" Url="https://devimages.apple.com.edgekey.net/streaming/examples/bipbop_4x3/bipbop_4x3_variant.m3u8" IsLooping="false" StretchMode="Uniform" AutoPlay="true" />
</App>

The crash happens around a second into playing the video, so the first bit works fine.

Crashlog from Fuse Monitor:

LOG: System.ArgumentException: start_index + length > array length
    Parameter name: length
      at (wrapper managed-to-native) System.Runtime.InteropServices.Marshal:copy_from_unmanaged (intptr,int,System.Array,int)
      at System.Runtime.InteropServices.Marshal.Copy (IntPtr source, System.Byte[] destination, Int32 startIndex, Int32 length) <0x152b6248 + 0x00027> in <filename unknown>:0 
      at Fuse.Video.Mono.PixelBuffer.UpdateTexture (Int32 textureName, Fuse.Video.Mono.VideoHandle handle) <0x152b5ca0 + 0x000e3> in <filename unknown>:0 
      at Fuse.Video.Mono.VideoImpl.UpdateTexture (Fuse.Video.Mono.VideoHandle handle, Int32 textureHandle) <0x152b55d8 + 0x00143> in <filename unknown>:0 
      at Fuse.Video.Mono.MonoImpl.UpdateTexture (Int32 textureHandle) <0x152b55a8 + 0x0001b> in <filename unknown>:0 
      at Fuse.Video.Graphics.CIL.VideoImpl.UpdateTexture (Fuse.Video.Graphics.CIL.VideoHandle handle, Int32 textureHandle) <0x152b5580 + 0x00021> in <filename unknown>:0 
      at Fuse.Controls.VideoImpl.CIL.VideoPlayer.Update () <0x152b4a70 + 0x001af> in <filename unknown>:0 
      at Fuse.Controls.VideoImpl.GraphicsVideoService.Fuse.Controls.VideoImpl.IVideoService.Update () <0x141fb658 + 0x0002c> in <filename unknown>:0 
      at Fuse.Controls.VideoImpl.VideoVisual.OnUpdate () <0x141fb5d8 + 0x0001c> in <filename unknown>:0 
      at Fuse.UpdateListener.Invoke () <0xfc343d0 + 0x00053> in <filename unknown>:0 
      at Fuse.UpdateManager.ProcessListeners (Fuse.Stage stage, System.Collections.Generic.List`1& _exceptions) <0xfc34210 + 0x00057> in <filename unknown>:0
2

Thanks for a detailed report. I’ve filed an internal ticket to look into this.

3

It seems like HLS is not supported at all on iOS. The audio plays fine, but nothing is ever displayed. MP4 videos works fine on iOS.

(I have tested with various HLS sources, but here’s one you need to watch anyway :smiley:
https://video.scenesat.com:8082/rerun/ds2017-part6/playlist_dvr.m3u8)

4

I’ve found the issue of why there is only audio on iOS. This is because of these two methods in VideoImpl.mm:

int getWidth(void * videoState)
{
	VideoState * vs = (VideoState*)videoState;
	return [vs->Asset naturalSize].width;
}

int getHeight(void * videoState)
{
	VideoState * vs = (VideoState*)videoState;
	return [vs->Asset naturalSize].height;
}

naturalSize will not contain the correct size if the video is a HTTP Live Stream, as it has not been properly initialised at that point. I guess this is also why naturalSize is deprecated, as the documentation suggests reading the size-values from the video track in the stream.

I hope a fix for this can find its way into 0.36.0 :slight_smile:

5

Thanks for digging further. I took a quick stab at trying to deal with your findings, but unfortunately it’s a bit more complicated than that; switching to [AVAssetTrack naturalSize] (like the documentation suggest) doesn’t help, because there’s no AVAssetTracks with media-type AVMediaTypeVideo either at that point. Which seems a bit bizarre to me, as the asset is reported as loaded at that time.

6

No problem, I was the one needing it :slight_smile:

Yeah. I think I also tried to check in updateTexture() if there were indeed any tracks with video at any point, to no avail.

A workaround could be to use the Width and Height parameters from the tag if the naturalSize is unavailable? Or perhaps the size reported by the actual pixelbuffer in updateTexture(), as that one is accurate.

7

I suspect consulting the pixel-buffer will be the correct fix, but unfortunately this is a bigger change, as the higher level abstraction assumes it can query the size once the video is reported as loaded.

I unfortunately don’t really think we have a realistic chance of getting a fix for this into 0.36.0, because the person maintaining this code is currently on vacation. So unless I can find a minimal fix, video stream support will probably have to wait a bit.

8

Fair enough - I will continue with my own hack (fixed Video-size) for the time being and look forward to 0.37.0 :smiley:

Thanks for helping!