Video glitches on Quest 2 after updating to Oculus OS v53

[Gurwar]

Problem description:

When playing 8k 360 video inside the quest, there are noticable glitches and artifacts within the video stream. The glitches also occur with 5K video but not as much.

Device (which devices are you having the issue with - model, OS version number):

Quest 2

Media (tell us about your videos - number of videos, resolution, codec, frame-rate, example URLs):

Multiple Videos, 8K/5K Resolution,

System Information:

AVPro Video: v2.6.6 (plugin v2.6.3f1-ultra) Target Platform: Android Unity: v2021.3.16f1 WindowsEditor OS: Desktop - B550M DS3H AC (Gigabyte Technology Co., Ltd.) - Windows 11 (10.0.22621) 64bit - English CPU: AMD Ryzen 5 5600X 6-Core Processor - 12 threads - 32691KB GPU: NVIDIA GeForce RTX 3080 - NVIDIA - Direct3D 11.0 [level 11.1] - 10067KB - 16384

[Chris-RH]

Hi, can you make sure you're using the latest version of AVPro Video please.

You don't say what the specs of your videos are. Have you checked these guidelines: https://creator.oculus.com/getting-started/media-production-specifications-for-delivery-to-meta-quest-2-headsets/

[Gurwar]

I have updated to the latest AVPro. I am still getting glitches on a video with the following settings.

General Complete name : F:\bmadDownloads\drk_cap_samples-oct-21\downloadable\drk_cap_003a_v036_7-2k_tpz-downloadable.mp4 Format : MPEG-4 Format profile : Base Media Codec ID : isom (isom/iso2/avc1/mp41) File size : 49.0 MiB Duration : 9 s 867 ms Overall bit rate : 41.6 Mb/s Writing application : Lavf59.24.100 Comment : drk_cap_003a_v036_8k_tpz.000001.png

Video ID : 1 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L6 Format settings : CABAC / 4 Ref Frames Format settings, CABAC : Yes Format settings, Reference : 4 frames Codec ID : avc1 Codec ID/Info : Advanced Video Coding Duration : 9 s 867 ms Bit rate : 41.6 Mb/s Maximum bit rate : 140 Mb/s Width : 7 200 pixels Height : 3 600 pixels Display aspect ratio : 2.000 Frame rate mode : Constant Frame rate : 30.000 FPS Color space : YUV Chroma subsampling : 4:2:0 Bit depth : 8 bits Scan type : Progressive Bits/(Pixel*Frame) : 0.054 Stream size : 48.9 MiB (100%) Writing library : x264 core 164 r3094 bfc87b7 Encoding settings : cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=36 / lookahead_threads=6 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=18.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / vbv_maxrate=140000 / vbv_bufsize=22500 / crf_max=0.0 / nal_hrd=none / filler=0 / ip_ratio=1.40 / aq=1:1.00 Codec configuration box : avcC

[RealMoonSt]

Hi, I am also experiencing this same visual artifact problem with avpro ultra in our Quest 2 Unity app build. This seems to be occurring across a range of different video file resolution and HEVC/h265 encodings (mainly using 7440x3720p video, 8bit and 10bit etc). This started when Oculus OS updated to v53, and is also affecting other apps such as SkyboxVR and Virtual Desktop (which uses h264 and h265 streams - a lot of chatter in the VD discord server about it - the developer says Meta has to fix). I've also heard it affects Oculus Link. The description of the problem is white/sometimes colored sparkle like artifacts that occur most prominiently on high contrast imagery and appears magnified with head movement.

I have been trying to get to the bottom of it. I have not tried updating to the latest version of AVPro yet... however Gurwar above indicates that did not work, and this seems to be more of a oculus system problem. The only clue I have found is that DeoVR player appears unaffected with all the same video clips...and I have spoken to the developer last year where he confirmed he is using exoplayer just like AVPro for Quest 2. The next thing I am trying is a VP9 encoding, which AVPro is also suppose to support, to see if it is just HEVC that is affected by this.

[RealMoonSt]

I should also mention our VR videos were working perfectly on Quest 2 with AVPro Ultra until the headset updated to v53, thanks

[Chris-RH]

That's very interesting, thanks @RealMoonSt. Have you tried updating to Oculus OS v54 to see if there is any improvement?

@Gurwar, do you know which version of Oculus OS you are using?

Are you able to provide a minimal test project to unitysupport@renderheads.com please?

[RealMoonSt]

Thanks for the quick reply Chris, I have been trying to update my Quest 2 to v54 but I can't seem to force it to happen (and I'm apparently not on the PTC, even though I'm in developer mode). The v54 rollout seems to occur in stages for some. I have an Unity app developer who is working on this project with us and I will ask him about a minimal test project... however he is also working on two other projects that have been broken by the recent Oculus OS update that are not even related to this problem (!)... something to do with a poor quality and regression testing at Meta as they have gone from Android 10 to 12 with no rollback possible.

I did manage to test alternate video encoding yesterday... VP9 and different flavours of h265 encoding (color range, 8/10 bit, lowering Res etc), but this did not improve the problem. My test today will be to encode (using ffmpeg) with a lower Max bitrate and Max Buffer.... previously this was set at 85M and 160M respectively, and as mentioned we had those working perfecty with AVPro before the update. Thanks again for looking at this problem - we were actually only days away from submitting to App Lab before the update.

[Gurwar]

Our tester commented that after upgrading to v54 the glitches I mentioned earlier have been solved.

[RealMoonSt]

I just updated to v54 by activating the PTC on the Oculus phone app, but unfortunately it has not solved the glitching for me.

[RealMoonSt]

I will also ask my developer to update AVPro to the latest version in our build (we implemented it in September 2022) and see if that works with v54

[RealMoonSt]

Hi just a quick update - we upgraded to AVPro Ultra to the lastest 2.8.0, as well as the latest Oculus XR plugin 3.2.3, and updated the headset to Oculus OS v54 (and v55 PTC). Unfortunately the Sparkling pixel artifacts remain with our vr180 video, no matter what flavour of encoding settings we use (bitrate, resolution, color bit depth etc), or in App settings such as renderscale and CPU/GPU level and refresh rate. However this seems to be an Oculus system level problem as many people in Meta forums are describing the exact same problem (with photos) with virtual desktop and Oculus link HEVC streaming (describing it as white/rainbow sparkles)... so we are kind of at a loss to fix this :(

All I can say is the playback was working beautifully until Oculus updated to v53.

Thanks again.. any insight into what may be causing this might mean we can alter the encoding options to get around it for us.

[Chris-RH]

I think, unfortunately, if its an Oculus-wide problem then it is up to Meta to fix it. There do seem to be quite a lot of people reporting it, so hopefully that'll encourage them to sort it out ASAP.

[RealMoonSt]

Thanks Chris - I would say that some other 360/180 players on Quest 2 like SkyboxVR and DeoVR seem unaffected... so maybe there's some tweak that can be made?

Currently we have tried every possible encoding/file format/App rendering settings with small test files we can think of, nothing seems to fix it. The only clue is that it always occurs in the same scenes or moments in the video... where there is a high level of complexity to the frame with both bright and dark elements - but its got nothing to do with bitrate or resolution (we have tried low constant bitrate and lower res video file and low in-App renderscale).

I would be really interested to know if you can play a H265/h264/vp9 180 3D 7K/8K video file on Quest 2 with AVPro without this problem. Unfortunately, with no telling when Meta might fix this, we will have to start trying other Unity based immersive video players :(

[Chris-RH]

That's interesting. Do SkyboxVR and DeoVr both use Unity?

[Ste-RH]

I believe both SkyboxVR and DeoVr use AVPro Video under the hood (or at least I have had support correspondence with both companies in the past).

Edit: A glance at logcat will likely reveal if they do

[RealMoonSt]

My research so far has indicated that Skybox actually uses libVLC for Quest (at least that's what everyone seems to refer to in the Skybox VR forums - one person put forward that Skybox is not forthcoming about it as is may be unlicensed), and in FB groups the DeoVR founder indicates that they are using a customized Exoplayer.

DeoVR also have what they call an "android overlay" beta mode, which bypasses the Unity sphere projection mesh and renders directly to the display for improved performance and quality - something John Carmack also once posted about on meta blog when he was into VR Video in the early days of quest

[RealMoonSt]

Just as an update to the problem, I went back down from OS PTC v55 to v54 (which also forced a factory reset) and now the video plays back as normal SO LONG as the headset never goes to sleep and wakes... as which point the flashing pixels will return, and the only way to get rid of them is to reboot the device. I can even do this during AVPro (with exoplayer) playback... pressing the sleep and wake button twice fairly quickly, and after a quick blank screen the flashing pixels return - this happens everytime without fail. I have logged all this in the Meta PTC v55 forum thread as have others, in the hopes the meta engineers will see.

The Virutal Desktop developer is saying still its a render issue with the OS, and the sleep wake mechanism seems to indicate this either directly or indirectly with whatever that is doing. I only wish I knew what DeoVR or Skybox are doing to defeat this... as Chris has identified it could be a Unity based problem which those players may not even be using anymore

[Gurwar]

Me and my team have decided to try a custom implementation of exoplayer with Unity to see if that fixes the problem. The oculus update only reduced the problem, it didn’t completely fix it.

Get Outlook for iOShttps://aka.ms/o0ukef

---

From: RealMoonSt @.> Sent: Monday, June 19, 2023 2:17:36 PM To: RenderHeads/UnityPlugin-AVProVideo @.> Cc: Gurwar @.>; Mention @.> Subject: Re: [RenderHeads/UnityPlugin-AVProVideo] Video glitches on Quest 2 after updating to Oculus OS v53 (Issue #1549)

Just as an update to the problem, I went back down from OS PTC v55 to v54 (which also forced a factory reset) and now the video plays back as normal SO LONG as the headset never goes to sleep and wakes... as which point the flashing pixels will return, and the only way to get rid of them is to reboot the device. I can even do this during AVPro (with exoplayer) playback... pressing the sleep and wake button twice fairly quickly, and after a quick blank screen the flashing pixels return - this happens everytime without fail. I have logged all this in the Meta PTC v55 forum thread as have others, in the hopes the meta engineers will see.

The Virutal Desktop developer is saying still its a render issue with the OS, and the sleep wake mechanism seems to indicate this either directly or indirectly with whatever that is doing. I only wish I knew what DeoVR or Skybox are doing to defeat this... as Chris has identified it could be a Unity based problem which those players may not even be using anymore

— Reply to this email directly, view it on GitHubhttps://github.com/RenderHeads/UnityPlugin-AVProVideo/issues/1549#issuecomment-1597575194, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AKIJTZBRGK57HNTCNQWHKQTXMCJUBANCNFSM6AAAAAAY3AKRRA. You are receiving this because you were mentioned.Message ID: @.***>

[Ste-RH]

If you are not using ExoPlayer specific features, you could try switching to using the MediPlayer API path in AVPro Video

[RealMoonSt]

If you are not using ExoPlayer specific features, you could try switching to using the MediPlayer API path in AVPro Video

Thanks for the suggestion, but we tried that and unfortunately it made the problem worse! In general we have found exoplayer to be much better

[Chris-RH]

Have you managed to update to offical release of v55 yet? I'd be interested to know if the issue has been fixed with the latest update. Also, are you using Windows 10 or 11?

(From my browsing, people have been seeing the issue in rec room, virtual desktop, vrchat, skybox and a bunch of vr games)

[RealMoonSt]

I have been trying to update to the official v55 (from v54) but no luck yet... I check everyday. I'm using Windows 10 to build the apk in Unity. It's kind of unbelievable how many people and how many apps have been affected by this since v53... yet Meta still hasn't fixed despite acknowledging the issue in the forums. There seems to be a number of other things broken by the recent updates also that they acknowledge. My developer's best guess is that there was a mandate to make the new GPU and CPU boost updates go live by a certain date (inorder to make news in the media to counter the Apple's news, in addition to quest 3), and proper quality and regression testing was not done prior to the OS release (which also included a jump from android 10 to 12).

[Chris-RH]

I'm really hoping that this update fixes it. Just keep us up to date with developments please :)

[RealMoonSt]

Just got this from Ryanality the Community Manager in the Meta VR Forums in response to my question of a fix soon:

"Just checked in with the team and there should be a partial fix with some improvements coming to PTC soon. The team is also working on a larger fix for the artifacts which I think will take a little longer. I'll let you know when I hear more that I can share."

[Chris-RH]

Ahh, so we're looking for v56 PTC hopefully. Thanks for the update.

[Chris-RH]

Any luck with the v56 PTC?

@RealMoonSt

[RealMoonSt]

@Chris-RH I've updated to PTC v56, but there has been no change in the issue. The community manager asked to put the issue in a separate thread which I did the other day for PTC v56, and he made a reply that he'd spoken to the engineering team and they were still working on a fix from the before, but previously in the PTC Megathread he said it was on of their list of next things to fix - I think the update also made Airlink unusable for some users so that was first priority for them.

You can find my thread here if you wanted to add to it, but people are also still posting in the v55 and PTC v56 Megathreads about it:

https://communityforums.atmeta.com/t5/Get-Help/PTC-v56-Flashing-white-colored-pixel-artifact-problem-introduced/m-p/1065710

[RealMoonSt]

@Chris-RH and @Ste-RH Just a quick update to this issue with my thoughts, after speaking to the Meta Support members extensively on the Meta forums, it would appear that the Meta engineering team have been able to reproduce this issue for sometime... but have not been able to provide a fix yet (it is always "in the works" according to the Community Manager). Furthermore a number of people have also chimed in about the Headjack app (which also uses exoplayer in Unity) having the same issue - it would appear the issue is more acute on immersive video ( especially high contrast scenes) as opposed to regular video game rendering where it occurs more rarely (with the exception of Virtual Desktop which uses streaming h.265 or H.264 video compression).

I am starting to consider, as my app developer has suggested, that too many of the senior Meta devs have left and there is no longer the knowledge base and experience at Meta to properly solve these kind of problems (with the Junior Devs now running the Asylum). It does seem to me like this issue is equivalent to the perpetual "can being kicked down the street" , as it was first reported with v53 and now we are on v56. I was wondering if Renderheads would consider attempting to implement another one of the Unity media player plugin options (not including the native Unity Mediaplayer) that might provide a long term fix ... similar to how the Skybox app reportedly uses libVLC and for which they don't seem to be getting any of this artifacting... simillairly DeoVR has found some sort of workaround also. It may be worth also communicating with the Headjack team, as they have stated on their blog that they licence AVPro for a number of VR platform implementations.

I'm asking this because I feel that this may never be resolved if the Meta Engineering team decide to focus more now on Quest 3, which may not even suffer this problem due to its new CPU/GPU architecture, leaving the existing user base out in the cold

[RealMoonSt]

Also I have a strong belief that DeoVR is using Exoplayer in Unity for their Non-Android Overlay mode (Android Overlay mode is their term for bypassing the Unity Projection Mesh/skybox and rendering directly to the Android display layer, an option in their Playback Settings) and I can confirm that there is no artifacting on DeoVR with "like for like" settings and using the same H.265 video file as with the AVPro-built app (renderscale resolution, refresh rate etc)... so it looks like DeoVR have found some way to solve the problem in their app build with Exoplayer. Perhaps they could be reached out to, to see if they would be willing to share their solution with Exoplayer - they may be more amenable to this with someone from Renderheads, rather than a standard user such as myself.

[RealMoonSt]

Just as a final quick update for @Chris-RH ans @Ste-RH , I had a brief chat with Sandi from DeoVR's discord who works with their Unity team, and he confirmed that they use AVPro with a customized version of Exoplayer for Quest DeoVR.

I can confirm that on a "like for like" settings the DeoVR exoplayer does not exhibit any of the pixel artifacting (with the exact same video file), and as such they may have inadvertently found a fix through their customization of Exoplayer. Sandi said he will speak to their Main developer... but since DeoVR is seemingly a customer of Renderheads then it seems possible, if both parties are amenable, that this might be a way forward to help to find a solution for all AVPro customers affected, who are currently unable to implement VR Video Apps for Quest. Even in the DeoVR Discord there were other people asking the question of why DeoVR Quest Player was unaffected by this bug, when their own Unity based video players were getting the Pixel artifacting on immersive video, so this seems to be a such a widespread problem.

[Chris-RH]

I'd certainly be interested to know what they have changed that means that they are not experiencing this issue.

[RealMoonSt]

I'd certainly be interested to know what they have changed that means that they are not experiencing this issue.

Yes, I can confirm that the DeoVR app is not experiencing any of the pixel flashing artifacts... I tried it over a dozen times to be sure, and even tried to make it happen artificially by boosting the rendering resolution and refresh rate to higher than normal levels via Sidequest ADB commands(refresh rate 120hz, Render Scale 2+ so Eyebuffer Res greater than 3000 width and height etc), but the artifacting never occurred.

My concern which I believe is rational, is that with the Quest 3 launch approaching in just a few months, that Meta will refocus all their engineering team resources on supporting that device, and this issue will never get resolved - those that continue to complain will be advised to upgrade to the Quest 3. There are about ten different reddit posts now about this issue, in addition to the many complaints in the Meta forums (plus other app specific forums like this one) and yet this has gone on for about 3 months now... even though the Meta team were apparently aware of the issue almost from the outset. Then there is the worrying fact that this issue made it past the quality and regression testing in the first place. It does not look promising that Meta will be focused on finding a fix at this stage, when according to the Community Manager they have not even narrowed it down to a root cause yet.

Obviously this is preventing me from moving forward on my custom Quest 2 Video app, which I really really need to get going for my business, but it also must be affecting Renderhead's other customers that can't easily switch away from Meta Quest (to Pico for example), since AVPro is now seemingly no longer an implementable solution for Quest 2. I have tried every variation on file formats, sizes, device settings etc. There are a number of people in Meta forums referring to Headjack as being impacted too, which I understand also uses AVPro. It would appear that the DeoVR team have inadvertently found a more robust solution to this issue, so I implore you guys to reach out to them directly or follow along on their discord server... as my technical knowledge on how exoplayer or AVPro is set up is limited (I'm not a coder or a dev, just a VR videographer), and I'm not sure that I will be able to get from them or understand the necessary details myself to work out what they have changed in the AVPro setup (exoplayer versions, memory buffer setups etc). This is a potential solution in sight... as opposed to a Meta fix that may never come:

https://discord.com/invite/vHYbDHHVEq

[ForemanDev]

I can confirm that I am experiencing this issue also - I recently switched my Meta Quest 2 based video player app from Unity's built-in video player to AVPro Exoplayer, and after I did that, I am now seeing the same glitches and artifacts described in this issue. I came here to see if it had already been reported and found this issue.

I mirror @RealMoonSt 's comment that this issue is currently affecting all of AVPro's customers that use AVPro for the Meta Quest and a fix should be prioritized if at all possible. It would be great if Renderheads could get in touch with the DeoVR team about a fix if they have managed to solve the issue. Looks like their Discord has been linked above if communication with them still needs to be established. Thanks!

[ForemanDev]

@RealMoonSt The DeoVR team said that they didn't do anything in particular to fix the issue in their implementation of Exoplayer. Are you positive that DeoVR and the other AVPro-based apps you tried out don't actually have this issue (even after putting the headset to sleep and waking it up)?

[ForemanDev]

@Chris-RH Does the AVPro team have a Meta Quest 2 or a Meta Quest Pro to test with? If so, could a workaround for this issue be developed? I realize that this is likely an issue with Meta's OS, however it is unlikely that Meta will fix the problem in a timely manner and this affects AVPro's customers that use AVPro for immersive content on Meta's VR devices. If a workaround can't be created, I will likely be forced to abandon AVPro and revert back to Unity's less-efficient built in video player. ☹️

[Chris-RH]

Yes, we do have a Quest 2 for testing. We are trying to get a conversation going with the DeoVR devs to see what they are doing differently.

On Thu, 27 Jul 2023 at 19:14, Matt Foreman @.***> wrote:

@Chris-RH https://github.com/Chris-RH Does the AVPro team have a Meta Quest 2 or a Meta Quest Pro to test with? If so, could a workaround for this issue be developed? I realize that this is likely an issue with Meta's OS, however it is unlikely that they will fix it in a timely manner and this affects AVPro's customers that use AVPro for immersive content on Meta's VR devices. If a workaround can't be created, I will likely need to abandon AVPro and revert back to Unity's built-in video player. ☹️

— Reply to this email directly, view it on GitHub https://github.com/RenderHeads/UnityPlugin-AVProVideo/issues/1549#issuecomment-1654154474, or unsubscribe https://github.com/notifications/unsubscribe-auth/AYRROUIH2HGWWXO4YQDARMTXSKVXNANCNFSM6AAAAAAY3AKRRA . You are receiving this because you were mentioned.Message ID: @.***>

[ForemanDev]

Thank you! 🙏

[RealMoonSt]

@RealMoonSt The DeoVR team said that they didn't do anything in particular to fix the issue in their implementation of Exoplayer. Are you positive that DeoVR and the other AVPro-based apps you tried out don't actually have this issue (even after putting the headset to sleep and waking it up)?

@ForemanDesigns Hi Matt, thanks for checking in with the DeoVR discord. I have tested my "best settings" video files in DeoVR (10bit colour, 8K, 80Mbps, full range, 30fps) and their player works perfectly on this file, even after putting to sleep (which that trick doesnt work for me anymore on PTC v56). I have also used ADB commands to boost the rendering quality and and refresh rate of their app with the same files, and still no Artifacts. I recommend you try your own files in DeoVR and see if it works for you too without the artifacts.

@Chris-RH Thanks for checking with DeoVR, I spoke to the Headjack guys and they are experiencing this problem too and are looking for a fix - but they said they are only getting it in Quest Pro, not with Quest 2. I tested this with their cloud build last night, and I can confirm that their Quest 2 app played back my "safe settings' video file (8bit, limited range, 3500p etc) with about 90% reduced artifacts - not completely gone but massvely reduced and tolerable. My Best settings 10bit etc file however still produced the Artifacts. I will be downloading their Headjack SDK today to a Unity project to try to see what they are using. I believe that its likely going to be some combination of Exoplayer version (or fork) , Oculus XR plugin version and/or Unity version that is resulting in the circumvention of this bug.

I just added to the DeoVR discord about this clue of the above from HJ, and the DeoVR Dev just now said they are using 2020.3.42f1 Unity and will check with the team on Monday for more info.

@Chris-RH I believe Ivan Varko is the founder of DeoVR... I have spoken to him a few time on FB groups if you have trouble getting in touch with him. Again I'm grateful to both you and now Matt for helping with this, and also the Headjack guys who want to help too

[RealMoonSt]

I should also mention that the Quest 2 PTC issue thread I started on the official Meta forums is by far the most viewed PTC issue thread on the site, with currently 1500 views... double the next most viewed issue, and about 5 times more than most other active Quest 2 Issue threads - it is currently listed as one of the top 5 trending topics on the Meta community main page. So this is very widespread, well beyond just immersive video ofcourse, so Meta Engineers must absolutely be aware of it at this point. It seems to me that a solution/workaround is insight for immersive video at least if we keep working on it.

[RealMoonSt]

This from Sandi at DeoVR in their discord today:

"sandiDeoVR — Today at 3:20 AM So we use https://www.renderheads.com/content/docs/AVProVideo/versions/2.7.3.html And use exoplayer from this version of AVPro."

I will see if we can try that version of AVPro in our app, unfortunately I believe this is what we tried before... I have asked also for the Oculus XR plugin version they are using. Furthermore it may be something else in the setup of of their Unity Project (android) settings that is giving them the artifact-free result.

[Chris-RH]

If you're testing using a clean project with just one of our demo scenes, are there any particular test streams URLs that do or don't work?

[Chris-RH]

I am keeping an eye on the Meta thread. It looks like they are working on another partial fix. I'm really hoping that this will improve things for you.

[Gurwar]

I have been trying to make a custom exoplayer build using Android Studio but so far have gotten stuck on making it work with Unity. The problem occurs when exoplayer related functions are called using .aar file.

I have tried to include the exoplayer library modules with the apk build and also changed dependencies using a custom manifest but nothing seems to work.

What would be the ETA on a new AVPro update?

[Chris-RH]

I don't have a Quest 2 to test with. Could I have a link to video to build into our demo scene which is regularly causing this glitch to occur?

[Gurwar]

public static void initializePlayer(Activity unityPlayer) { ExoPlayer player = new ExoPlayer.Builder(unityPlayer).build(); }

Is what I use to initialize the player in Android Studio.

Here is my Unity side.

AndroidJNIHelper.debug = true; var playerClass = new AndroidJavaClass("com.unity3d.player.UnityPlayer"); AndroidJavaObject activity = playerClass.GetStatic("currentActivity"); Debug.Log("Got activity"); var plugin = new AndroidJavaClass("com.bmad.exolib.Exo"); Debug.Log("Found Plugin"); plugin.CallStatic("test"); Debug.Log("Found Test"); plugin.CallStatic("initializePlayer"); Debug.Log("Found Function");

public static void initializePlayer(Activity unityPlayer) { ExoPlayer player = new ExoPlayer.Builder(unityPlayer).build(); } Here is the Unity side.

AndroidJNIHelper.debug = true;
var playerClass = new AndroidJavaClass("com.unity3d.player.UnityPlayer");
AndroidJavaObject activity = playerClass.GetStatic<AndroidJavaObject>("currentActivity");
Debug.Log("Got activity");
var plugin = new AndroidJavaClass("com.bmad.exolib.Exo");
Debug.Log("Found Plugin");
plugin.CallStatic("test");
Debug.Log("Found Test");
plugin.CallStatic("initializePlayer");
Debug.Log("Found Function");

Unfortunately I hit an error when trying to use the unityPlayer as the context for building the player. Error Unity AndroidJavaException: java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/media3/exoplayer/ExoPlayer$Builder;

Any guidance would be appreciated.

[RealMoonSt]

Here are the complete settings I was able to get from DeoVR:

**Unity version is 2020.3.42f1

AVPro 2.7.3 and the coresponding version of Exoplayer included with that

Oculus XR Plugin Name = "com.unity.xr.oculus", Version = "2.2.0-preview.1"**

I'm not sure if there is anything else that would be needed. Unfortunately my Dev is on vacation and I do not have the Unity experience to test these in a new project (I couldn't get the AVPro demo scene to play properly) and I couldn't import our current project into this older version of Unity without significant compiling errors that I can't fix.

I can confirm that even on the latest v56 PTC, the DeoVR app still players back my video files flawlessly... so they are doing something to beat this. Hopefully someone with more experience than me will be able to test the above versions on their files.

I could also provide a video clip in the VR180 format to Chris if that will help, not sure if that's what you meant before.

@Chris-RH @ForemanDesigns

[Chris-RH]

If someone could send me a simple repro project using our trial version please, that would be great. unitysupport@renderheads.com

[Chris-RH]

Note: It looks like there is a bit of improvement in the latest PTC release.

[Ste-RH]

public static void initializePlayer(Activity unityPlayer) { ExoPlayer player = new ExoPlayer.Builder(unityPlayer).build(); }

Is what I use to initialize the player in Android Studio.

Here is my Unity side.

AndroidJNIHelper.debug = true; var playerClass = new AndroidJavaClass("com.unity3d.player.UnityPlayer"); AndroidJavaObject activity = playerClass.GetStatic("currentActivity"); Debug.Log("Got activity"); var plugin = new AndroidJavaClass("com.bmad.exolib.Exo"); Debug.Log("Found Plugin"); plugin.CallStatic("test"); Debug.Log("Found Test"); plugin.CallStatic("initializePlayer"); Debug.Log("Found Function");

public static void initializePlayer(Activity unityPlayer) { ExoPlayer player = new ExoPlayer.Builder(unityPlayer).build(); } Here is the Unity side.

AndroidJNIHelper.debug = true;
var playerClass = new AndroidJavaClass("com.unity3d.player.UnityPlayer");
AndroidJavaObject activity = playerClass.GetStatic<AndroidJavaObject>("currentActivity");
Debug.Log("Got activity");
var plugin = new AndroidJavaClass("com.bmad.exolib.Exo");
Debug.Log("Found Plugin");
plugin.CallStatic("test");
Debug.Log("Found Test");
plugin.CallStatic("initializePlayer");
Debug.Log("Found Function");

Unfortunately I hit an error when trying to use the unityPlayer as the context for building the player. Error Unity AndroidJavaException: java.lang.NoClassDefFoundError: Failed resolution of: Landroidx/media3/exoplayer/ExoPlayer$Builder;

Any guidance would be appreciated.

This does not look like AVPro related code. It looks like you should be posting this to the ExoPlayer github issues board.

[Chris-RH]

Any improvement since updating to PTC v57?

[RealMoonSt]

Hi Chris, I haven't been able to get my headset to update to PTC v57 yet... but will be trying to force it today. However Ryanality the community manager from Meta Support did not indicate that there was any fix to be expected in the update to PTC v57. Also the previous "improvement update" within ptc v56 did not provide any improvement to the artifact problem with our Unity/AVPro app, and some of the other users in the forum thread said it didn't work for them while others said it did help.

Just for clarification my Meta forum name is Dave200S, and I'm the one that started the long standing thread (with now over 8000 views) on this issue: [https://communityforums.atmeta.com/t5/Get-Help/PTC-v56-57-Flashing-white-colored-pixel-artifact-problem/td-p/1065710/page/18] Ryanality was also able to change the name of the thread to now include v57, yet still keep all the previous links working that direct to the thread from outside forums

Finally my app developer just got back from vacation this week and last night we were able to test the DeoVR Unity versions and plugins on our app from before (and we tested the current DeoVR player app also which still works without artifacts):

Unity version is 2020.3.42f1

AVPro 2.7.3 and the coresponding version of Exoplayer included with that

Oculus XR Plugin Name = "com.unity.xr.oculus", Version = "2.2.0-preview.1"_

While we did initially get an improvement on launching the app the first, on subsequent launches the issue returned - we cannot explain this. Also inorder to rollback to AVPro Video we had to download the 2.7.2 trial version from your github and install it from that package.... but we did not know how to activate the trial version to Android Core or Ultra, so had to continue in Trial mode with watermarks etc. I do not know if you allow such rollbacks... we could only activate our license with package manager for the latest 2.8.4.

Finally earlier in the week Headjack contacted me to say they have maybe identified the root cause and are testing a possible fix. If this works I hope it can be applied to all Unity/AVPro Video projects (which they currently use of course).