Reusing ExoPlayer with Rtmp streams is crashing the app about librtmp-client-for-android

[lumyus]

It actually works with the newest version of Exoplayer. Thanks anyway

[mekya]

I think the problem may be about closing the rtmp connection, if you want
to open another connection without closing the previous one, it may throw
an exception. So let me ask you, are you sure you close the previous rtmp
connection while switching?

On Sun, Feb 21, 2016 at 7:26 PM, Bikrant Tripathi [email protected]
wrote:

I have an ExoPlayer with Surface view on my MainActivity and I'm trying to
switch between multiple Rtmp Stream directly from the MainActivity.

The initial Rtmp Stream works as expected but whenever I try to switch to
a new Rtmp Stream it crashes on me.

This is the code used for both playing the first stream/video & switching
to different stream/video.

public void preparePlayer(Context context, Uri uri, VideoStreamingType videoStreamingType) {
if (mRendererBuildingState == RENDERER_BUILDING_STATE_BUILT) {
stopVideo();
}
mPlayerNeedsPrepare = true;
mVideoUri = uri;
mRendererBuilder = getRenderer(context, uri, videoStreamingType);
if (mPlayerNeedsPrepare) {
prepare();
mPlayerNeedsPrepare = false;
}
mExoPlayer.setPlayWhenReady(true);
}

public void prepare() {
mVideoFormat = null;
mVideoRenderer = null;
mRendererBuildingState = RENDERER_BUILDING_STATE_BUILDING;
maybeReportPlayerState();
mRendererBuilder.buildRenderers(this, mMediaCodecAudioVideoTrackRendererEventListener);
}

public void stopVideo() {
mRendererBuilder.cancel();
mExoPlayer.stop();
mExoPlayer.seekTo(0L);
}

getRenderer() provides me ExtractorRendererBuilder class that you
modified on the integration of this Library and ExoPlayer
https://github.com/ButterflyTV/ExoPlayer-with-RTMP-and-FLV-seek/blob/master/demo/src/main/java/com/google/android/exoplayer/demo/player/ExtractorRendererBuilder.java
if I'm passing in a link for rtmp stream.

I tested switching between normal videos (mp4, webM, mkv) and hls stream
videos they work as expected no crashes so far.

Could you help me find a solution for this issue ?

—
Reply to this email directly or view it on GitHub
#2.

[bikranttripathi]

@mekya Thanks for replying back.

I thought closing the rtmp connection was supposed to be ExoPlayer's task, meaning when I call mExoPlayer.stop() .

Although, as you said because I was not closing the previous rtmp connection myself assuming that ExoPlayer would do that for me lead to the instant crash when trying to switch to another video.

I made one change on the ExtractorRendererBuilder cancel() method and it did fixed the instant crash but whenever I tried to touch any thing in the UI it crashes because of this change.

I'm calling the Renderer's cancel() method from the stopVideo() method of the player as you can see on the first comment.

    @Override
    public void cancel() {
        if (mDataSource instanceof RtmpDataSource) {
            try {
                mDataSource.close();
            } catch (IOException e) {
                e.printStackTrace();
           }
       }
    }

[mekya]

Could you please send the logcat output and paste your code?

On Mon, Feb 22, 2016 at 5:14 PM, Bikrant Tripathi [email protected]
wrote:

Thanks for replying back.

I thought closing the rtmp connection was supposed to be ExoPlayer's task,
meaning when I call mExoPlayer.stop() .

Although, as you said because I was not closing the previous rtmp
connection myself assuming that ExoPlayer would do that for me lead to the
instantly crash when trying to switch to another video.

I made one change on the ExtractorRendererBuilder cancel() method and it
did fixed the instant crash but whenever I tried to touch any thing in the
UI it crashes because of this change.

I'm calling the Renderer's cancel() method from the stopVideo() method of
the player as you can see on the first comment.

@Override
public void cancel() {
    if (mDataSource instanceof RtmpDataSource) {
        try {
            mDataSource.close();
        } catch (IOException e) {
            e.printStackTrace();
       }
   }
}

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[shroge]

I've come across this problem with read error that seems to happen all the time with rtmp:
(int net.butterflytv.rtmp_client.RtmpClient.read(byte[], int, int)+172)

Full logs below:

02-22 20:05:52.979 17056-17672/com.exoplayer.videoplayer A/libc: Fatal signal 11 (SIGSEGV), code 1, fault addr 0x0 in tid 17672 (Loader:Extracto)
02-22 20:05:53.086 509-509/? A/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
02-22 20:05:53.086 509-509/? A/DEBUG: Build fingerprint: 'google/angler/angler:6.0.1/MMB29Q/2480792:user/release-keys'
02-22 20:05:53.087 509-509/? A/DEBUG: Revision: '0'
02-22 20:05:53.087 509-509/? A/DEBUG: ABI: 'arm64'
02-22 20:05:53.088 509-509/? A/DEBUG: pid: 17056, tid: 17672, name: Loader:Extracto >>> com.exoplayer.videoplayer <<<
02-22 20:05:53.088 509-509/? A/DEBUG: signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 0x0
02-22 20:05:53.111 509-509/? A/DEBUG: x0 0000007f6f42fa70 x1 0000000000000000 x2 0000000000000001 x3 0000000000000000
02-22 20:05:53.111 509-509/? A/DEBUG: x4 0000000000000000 x5 0000000000000000 x6 0000007f6f42fa70 x7 ff646c606d2c6efe
02-22 20:05:53.112 509-509/? A/DEBUG: x8 00000000000000cf x9 ff0972241f397224 x10 7f7f7f7f7f7f7f7f x11 0101010101010101
02-22 20:05:53.112 509-509/? A/DEBUG: x12 0000000000000038 x13 0000000000000016 x14 0000000000000002 x15 0000000000000002
02-22 20:05:53.112 509-509/? A/DEBUG: x16 0000007f6fb79e88 x17 0000007f8a316148 x18 0000000000000016 x19 0000007f85848000
02-22 20:05:53.112 509-509/? A/DEBUG: x20 0000000000000001 x21 0000007f85848110 x22 0000000000000001 x23 0000000000000001
02-22 20:05:53.112 509-509/? A/DEBUG: x24 0000007f6fb64848 x25 0000007f6f42fa70 x26 0000007f8584c000 x27 0000000000000001
02-22 20:05:53.112 509-509/? A/DEBUG: x28 0000007f80f5b640 x29 000000006fc500e0 x30 0000007f6fb5dc98
02-22 20:05:53.112 509-509/? A/DEBUG: sp 0000007f6f42f9c0 pc 0000007f8a3161d4 pstate 0000000080000000
02-22 20:05:53.123 509-509/? A/DEBUG: #00 pc 000000000001c1d4 /system/lib64/libc.so (memcpy+140)
02-22 20:05:53.123 509-509/? A/DEBUG: #1 pc 0000000000007c94 /data/app/com.exoplayer.videoplayer-1/lib/arm64/librtmp-jni.so
02-22 20:05:53.123 509-509/? A/DEBUG: #2 pc 0000000000008094 /data/app/com.exoplayer.videoplayer-1/lib/arm64/librtmp-jni.so (RTMP_ReadPacket+112)
02-22 20:05:53.123 509-509/? A/DEBUG: #3 pc 000000000000a404 /data/app/com.exoplayer.videoplayer-1/lib/arm64/librtmp-jni.so (RTMP_GetNextMediaPacket+40)
02-22 20:05:53.123 509-509/? A/DEBUG: #4 pc 000000000000a508 /data/app/com.exoplayer.videoplayer-1/lib/arm64/librtmp-jni.so
02-22 20:05:53.124 509-509/? A/DEBUG: #5 pc 000000000000ae64 /data/app/com.exoplayer.videoplayer-1/lib/arm64/librtmp-jni.so (RTMP_Read+400)
02-22 20:05:53.124 509-509/? A/DEBUG: #6 pc 0000000000003d44 /data/app/com.exoplayer.videoplayer-1/lib/arm64/librtmp-jni.so (Java_net_butterflytv_rtmp_1client_RtmpClient_read+68)
02-22 20:05:53.124 509-509/? A/DEBUG: #7 pc 00000000005ff0d8 /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (int net.butterflytv.rtmp_client.RtmpClient.read(byte[], int, int)+172)
02-22 20:05:53.124 509-509/? A/DEBUG: #8 pc 000000000081a91c /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (int com.exoplayer.videoplayer.player.datasource.RtmpDataSource.read(byte[], int, int)+96)
02-22 20:05:53.124 509-509/? A/DEBUG: #9 pc 0000000000767320 /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (int com.google.android.exoplayer.extractor.DefaultExtractorInput.readFromDataSource(byte[], int, int, int, boolean)+308)
02-22 20:05:53.124 509-509/? A/DEBUG: #10 pc 00000000007681d0 /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (boolean com.google.android.exoplayer.extractor.DefaultExtractorInput.readFully(byte[], int, int, boolean)+260)
02-22 20:05:53.124 509-509/? A/DEBUG: #11 pc 0000000000771354 /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (boolean com.google.android.exoplayer.extractor.flv.FlvExtractor.readTagHeader(com.google.android.exoplayer.extractor.ExtractorInput)+136)
02-22 20:05:53.125 509-509/? A/DEBUG: #12 pc 000000000077198c /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (int com.google.android.exoplayer.extractor.flv.FlvExtractor.read(com.google.android.exoplayer.extractor.ExtractorInput, com.google.android.exoplayer.extractor.PositionHolder)+352)
02-22 20:05:53.125 509-509/? A/DEBUG: #13 pc 000000000076a898 /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (void com.google.android.exoplayer.extractor.ExtractorSampleSource$ExtractingLoadable.load()+828)
02-22 20:05:53.125 509-509/? A/DEBUG: #14 pc 00000000005e0cc0 /data/app/com.exoplayer.videoplayer-1/oat/arm64/base.odex (offset 0x3ae000) (void com.google.android.exoplayer.upstream.Loader$LoadTask.run()+692)
02-22 20:05:53.125 509-509/? A/DEBUG: #15 pc 000000007231a3d0 /data/dalvik-cache/arm64/system@[email protected] (offset 0x1ed8000)

[shroge]

So the error from above happens when switching video streams. I found that the RtmpClient takes too long to close down (and seems to be doing so asynchronously) when the ExoPlayer releases. I have to put in a multiple-second delay between releasing the ExoPlayer (and closing the RtmpClient) and re-launching the ExoPlayer. Otherwise, it seems that the RtmpClient is "corrupted" some how on the ExoPlayer re-initialization and the read errors from above show up reliably to kill the app.

[mekya]

Hi,

I take a look at the logcat output and read your last comments. It seems
that rtmp client can handle one connection at a time. Opening a new
connection without closing the previous one causes this error. I think we
can fix it. Do you need this feature urgently? or I can tell how to do that
if you want to make it with your ownself.

On Tue, Feb 23, 2016 at 5:43 PM, Shaun Gerner [email protected]
wrote:

So the error from above happens when switching video streams. I found that
the RtmpClient takes too long to close down (and seems to be doing so
asynchronously) when the ExoPlayer releases. I have to put in a
multiple-second delay between releasing the ExoPlayer (and closing the
RtmpClient) and re-launching the ExoPlayer. Otherwise, it seems that the
RtmpClient is "corrupted" some how on the ExoPlayer re-initialization and
the read errors from above show up reliably to kill the app.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[shroge]

Hi Mekya,
Thank you for replying! I was hoping to get it working by the middle of next week at the latest, so it is not too urgent. The sample app I have does release the ExoPlayer and close the RtmpClient before it attempts to open the next stream. However, I get those intermittent crash errors popping up, which leads me to believe there is something not getting cleaned up, I'm not sure though. I will get you access so you can check it out. If you didn't get the github invite, please let me know.
By the way, I had to modify the rtmp-client build.gradle file as follows to allow lower end devices to not crash since I need to support down to API 16.
android {
compileSdkVersion = 19
buildToolsVersion = "19.1"

    defaultConfig.with {
       // applicationId = "net.butterflytv.rtmp_client"
        minSdkVersion.apiLevel = 16
        targetSdkVersion.apiLevel = 19
        versionCode = 1
        versionName = "0.1.1"
    }
}

That problem and solution (back down to API 19) is explained here:
http://stackoverflow.com/questions/28504875/android-ndk-cannot-load-libc-shared-so-gets-cannot-locate-symbol-rand-refe

[mekya]

I got the github invite. thank you.

yeah you are right about the rtmp-client build.gradle. Yesterday, one guy
told me this issue and we have fixed that by making compileSdkVersion 16.
https://github.com/ButterflyTV/LibRtmp-Client-for-Android/blob/master/rtmp-client/build.gradle

new version is 0.2.1

compile 'net.butterflytv.utils:rtmp-client:0.2.1'

On Wed, Feb 24, 2016 at 4:46 PM, Shaun Gerner [email protected]
wrote:

Hi Mekya,
Thank you for replying! I was hoping to get it working by the middle of
next week at the latest, so it is not too urgent. The sample app I have
does release the ExoPlayer and close the RtmpClient before it attempts to
open the next stream. However, I get those intermittent crash errors
popping up, which leads me to believe there is something not getting
cleaned up, I'm not sure though. I will get you access so you can check it
out. If you didn't get the github invite, please let me know.
By the way, I had to modify the rtmp-client build.gradle file as follows
to allow lower end devices to not crash since I need to support down to API
16.
android {
compileSdkVersion = 19
buildToolsVersion = "19.1"

defaultConfig.with {
   // applicationId = "net.butterflytv.rtmp_client"
    minSdkVersion.apiLevel = 16
    targetSdkVersion.apiLevel = 19
    versionCode = 1
    versionName = "0.1.1"
}

}

That problem and solution (back down to API 19) is explained here:

http://stackoverflow.com/questions/28504875/android-ndk-cannot-load-libc-shared-so-gets-cannot-locate-symbol-rand-refe

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[mekya]

I am closing this issue.

Native library is compiled with sdk level16 with 0.2.1 version

[lumyus]

I have come across the exact same problem. I am using Toro Library. Whenever I put a few seconds delay between the initialising and the playing it works, however very unstable. The error from logcat is the same as the one from @shroge . Toro: 3.1.0 ExoPlayer 2.5.1
Any idea on resolving this issue?
Thanks

[mekya]

Is it possible to share some source code for me in order to create the test environment quickly?

[mekya]

Yeah we have fixed a bug about this issue and afaik exoplayer uses that version in the new release.