UnityPlugin-AVProVideo
UnityPlugin-AVProVideo copied to clipboard
Player loop won´t end opening streaming media
Describe the issue A clear and concise description of what the issue is.
Your Setup (please complete the following information):
- Unity version: Unity 2020.3.25f1
- AVPro Video version: 2.5.7f1-ultra Ultra edition
- Operating system version: Windows 11
- Device model: Asus TUF F15
- Video specs: Encrypted HLS audio files. Only happens with audio files, if the source is a video it works fine
To Reproduce
- Open with path or URL this media:
https://s3.us-west-2.amazonaws.com/streaming-dev.sandbox.game/streaming/08591d3a-f610-4b17-a271-4072c90d3878/3213db3883d7a3924d51fc83bb2d5d7a1a4994b9bf2dde10ef28f548a3c871de/c651c791-740f-4a37-8b50-c1ac5575ac1f/c651c791-740f-4a37-8b50-c1ac5575ac1f.m3u8
. - Set the decryption key to:
cfDacd6dC2f697FB
. - Use VideoAPI WinRT to be able to support encrypted sources.
- If the player is set to
Loop=false
it will work as expected, but if the player is set toLoop=true
then the audio will never start.
Logs The player doesn´t log anything in Unity. It seems it never passes the opening state.
Can you double check the details for the stream you provided? We have tried to play it back here according to your steps, but cannot get the stream to play.
Hi Ste, without the loop being set you still weren´t able to make it play?
This is the opening method I'm using to test it. The token is cfDacd6dC2f697FB
and the URL https://s3.us-west-2.amazonaws.com/streaming-dev.sandbox.game/streaming/08591d3a-f610-4b17-a271-4072c90d3878/3213db3883d7a3924d51fc83bb2d5d7a1a4994b9bf2dde10ef28f548a3c871de/c651c791-740f-4a37-8b50-c1ac5575ac1f/c651c791-740f-4a37-8b50-c1ac5575ac1f.m3u8
public void PrepareVideo(MediaPathType type, string path, string token, bool loop)
{
byte[] decryptionKey = System.Text.Encoding.UTF8.GetBytes(token);
#if UNITY_STANDALONE_OSX || UNITY_EDITOR_OSX
videoPlayer.PlatformOptionsMacOSX.keyAuth.overrideDecryptionKey = decryptionKey;
#else
videoPlayer.PlatformOptionsWindows.videoApi = Windows.VideoApi.WinRT;
videoPlayer.PlatformOptionsWindows.keyAuth.overrideDecryptionKey = decryptionKey;
#endif
videoPlayer.Loop = loop;
videoPlayer.Events.AddListener(OnMediaPlayerEvent);
if (!videoPlayer.OpenMedia(type, path, true))
{
status = AudioStatus.Failed;
}
}
That implementation would play with loop set to false
, but will not start with loop set to true
.
Ok, yeah, that works now. I was setting the key in the MediaPlayer component and was not getting playback...so I think there might be an issue there as well.
Not sure why looping affects at this stage. We will investigate.
Thanks Ste!
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Hi guys, we you have any update on this issue?
Hi @emmarojasfredini, Apologies for the lack of an update, the team has been (and mostly still are) on holiday. I'll check where we are with this and give you an update.
Can you confirm the test stream is still alive @emmarojasfredini ?
Hi @Ste-RH ! Yes, the source should be alive, I still have it on our backend.
Hi guys, do you have an update on this issue?
Sorry to be this insistent, but do you have any updates on this issue?
No update yet I'm afraid. When I have a free dev I will get them to look into it.
Guys, I'm really sorry to be so bothersome. But have you got any updates?
Hi @emmarojasfredini,
We've been looking into this issue but unfortunately can't offer a fix as of yet. What we can tell you:
- We've located a script issue linked to the key override on the player component being overwritten before use and will look into this separately, but as you suggest can workaround by directly setting in code
- Our native code for WinRT is relatively lightweight and directly wraps a lot of WinRT functionality (WinRT is more of a black box). We can reproduce your issue, by passing in your URL and swapping between setting looping/non-looping flags directly into WinRT.
- There is already some workaround code in place to do with a separate low-level bug within WinRT (and Media Foundation) linked to seeking, whilst looping is enabled, with certain media
The above leads us to believe this may be a lower-level issue than we can fix but will continue looking, albeit our workload is very high so don't think there will be a quick resolution - in the meantime are you maybe able to encode a blank video track alongside your audio as a workaround?
Cheers,