RTSP stream crashing Quest 2 / Android

[tangentlab]

Describe the issue
Using a test pattern stream from http://rtsp.stream I'm getting the feed coming into our Meta Rift app but when I try to bring that stream into the Quest 2 version the app crashes with a "Fatal Exception". I've tried other rtsp streams that will playback in Quest / Android but the test pattern has a hard crash.

Taking a look at other issues posted I'm wondering if the problem is related to the streamkey, but I'm looking for feedback on that. Also looking for advice on testing RTSP streams, but it seems like it's hard to come by dependable tests.

Your Setup (please complete the following information):

• Unity version: 2020.3.36
• AVPro Video version (number and edition (trial/core/ultra/enterprise)): 2.7.3
• Operating system version: Android
• Device model: Quest 2
• Video specs (resolution, frame-rate, codec, file size):

To Reproduce
Using a test pattern

1. rtsp://zephyr.rtsp.stream/pattern?streamKey=648874c20d52b13c27b3606cef9a8bb7

Logs

[Chris-RH]

Hi,

Yeah I don't believe we support RTSP with streamkey on android.
AVPro Video doesn't have strong support for real-time streaming as it is not the focus of this plugin and most operating systems do not have good native support for them. Its also quite difficult to find good test streams (as you've mentioned).

[Docteh]

as far as RTSP clients go, streamkey is just a part of the URL to get handed to the server. Query Parameters in HTTP parlance. In the case of MediaMTX (rtsp-simple-server renamed fairly recently) the key is considered as a replacement to other authentication methods.

I suspect it's an issue with either the resolution or the encoding. I just tested the pattern stream from that rtsp.stream site and I got a 320x240 30FPS H.264 stream. Meanwhile in I suppose a docker image I found necrodome/rtsp-on-flyio is doing 1024x768.

I've tested streaming from OBS at 720x480 30fps into VRChat with good results.

VRCDN has a test stream
rtsp://stream.vrcdn.live/live/vrcdn is 1280x720 30fps, 48khz AAC audio.

You could try something like rtsp://stream.vrcdn.live/live/vrcdn?streamkey=ImSorryJon to see if URL parameters are causing trouble specifically.

[tangentlab]

It seems like it may be hard to confidently know what will actually work. Any suggestions at least on where I might be able to catch the crash? So I can at least smooth out bad links?

[Docteh]

Reading the actual trace, problem is with audio.

https://github.com/google/ExoPlayer/blob/0106f02a25a71321f9948f5aa6fefeb3008e21ca/library/rtsp/src/main/java/com/google/android/exoplayer2/source/rtsp/RtspMediaTrack.java#L309

Is the test stream a guaranteed crash? Like five out of five attempt crash?

I don't know what would be easier for you, either test exoplayer demo on a phone, maybe compile with URL.

Or maybe try to reproduce in VRChat. Private instance of https://vrchat.com/home/world/wrld_25bf4795-501c-4d05-b874-8dc4e78ad83d "black gold lounge". Dj booth has different URL for PC and quest, so you can like paste VRCDN stream for pc, and the test stream to Quest.

If you posted your correct streamkey to these comments you might need new key.

I figure maybe VRChat catches AVPro error, and doesn't die, or maybe the demo application catches the error.

I know very little of android stuff, from what I can understand exoplayer is either angrily crashing when it shouldn't, or AVPro isn't handling this error, when it should.

[tangentlab]

Thanks!

I noticed this line in logcat and I'm wondering if it's a hint ... I'm not familiar with any of this really but I'm grasping at straws.
Debug CCodecConfig config failed => CORRUPTED

I have a fully logcat output that I could potentially share here if that's useful.

Is the test stream a guaranteed crash? Like five out of five attempt crash?

Ya it seemed like it was 100% though I could have done some more passes to be totally confident. I've seen the fatal crash enough that there is an obvious problem with the stream.

I know very little of android stuff, from what I can understand exoplayer is either angrily crashing when it shouldn't, or AVPro isn't handling this error, when it should.

Agree that this should be handled more gracefully in either of these places ^

[tangentlab]

Just thought I would throw this here. ExoPlayer dev thinks maybe related to audio metadata androidx/media#302

[tangentlab]

It looks like ExoPlayer may have an update that solves the issue.
androidx/media#302