0

Currently I am developing a streaming application for android using rtp/rtsp. The android device should be the server. So, I compiled Live555 (Version 01.04.2015) using Android NDK 10 an everthing works fine. However, when I try to start the stream, the app crashs and the following output appears in the logcat:

01-06 14:40:46.750: D/LiveCam(1167): Entering play()
01-06 14:40:46.750: A/libc(1167): Fatal signal 11 (SIGSEGV) at 0x00000034 (code=1), thread 1194 (Thread-95)

Here's my source code (based on the example of live555):

void play() {
    logDebug("Entering play()");
    // Open the input file as a 'byte-stream file source':
    ByteStreamFileSource* videoFileSource = ByteStreamFileSource::createNew(*uenv,    videoFile);
    if (videoFileSource == NULL) {
        logError("Unable to open video file"); // no output in logcat
        return;
    }
    logDebug("play() - video file opened"); // no output in logcat
    ...
}

So, I guess the error appears in ByteStreamFileSource, but I don't know why.

Any help would be appreciated!

Thank you.

EDIT //

The native code is based on the "testH264VideoStreamer" sample provided by live555. So, my jni code looks like this:

JNIEXPORT void JNICALL Java_de_douglasmedia_LiveCam_streaming_LiveStreamer_stream(
    JNIEnv *env, jobject obj, jstring ipAddress, jobject videoFD) {
    const char* c_ipaddress = env->GetStringUTFChars(ipAddress, false);

    jclass streamClazz = env->GetObjectClass(obj);
    jclass exceptionClazz = env->FindClass("java/lang/RuntimeException");

    if (streamClazz == NULL || exceptionClazz == NULL)
        return;

    videoFile = openFileFromFileDescriptor(env, videoFD);
    if (videoFile == NULL) {
        env->ThrowNew(exceptionClazz,
            "Unable to open the video pipe as a file");
        return;
    }
    logDebug("Video pipe opened as a file");

    logDebug("Starting to stream");

    // setting up the usage environment
    TaskScheduler *scheduler = BasicTaskScheduler::createNew();
    uenv = BasicUsageEnvironment::createNew(*scheduler);
    logDebug("Done setting up usage environment ...");
    ...
    // Start the streaming:
    play();
    uenv->taskScheduler().doEventLoop(); // does not return
}

This is the java wrapper for the native code (which is called in a new thread from MainActivity):

public class LiveStreamer implements Runnable {
    private static final String LOG_TAG = LiveStreamer.class.getSimpleName();
    private final MediaStream video;
    private Context context;

    public LiveStreamer(Context context, MediaStream video) {
        this.context = context;
        this.video = video;
    }

    @Override
    public void run() {
        try {
            Log.d(LOG_TAG, "Start streaming ...");
            String ipAddress = NetworkUtilities.getWifiIpAddress(context);
            if (video != null) {
                stream(ipAddress, video.getFD());
            }
            Log.d(LOG_TAG, "Stopp streaming ...");
            video.close();
        } catch (IOException e) {
            e.printStackTrace();
        } // start event loop here
    }

    private native void stream(String ipAdress, FileDescriptor videoFD);
}

My idea was to record the video into a file and stream this file with live555.

mpromonet
  • 11,326
  • 43
  • 62
  • 91
Robin
  • 709
  • 2
  • 8
  • 20
  • the call does not appear to be structured right for jni/android. you have cpp type code with pointers appearing in android/java. instead you need java/android -> jni native wrapper -> cpp version of play that provides the stream to the player on a proper encoding ... https://github.com/audioBoom/audioboo-android/blob/master/src/fm/audioboo/jni/FLACStreamDecoder.java – Robert Rowntree Jan 06 '15 at 17:31
  • Oh, I forgot to say, that the play()-Method is of course written in cpp and no java code... Or what do you mean? – Robin Jan 06 '15 at 22:18
  • Where is the jni linkage calling in to 'play' from java jni side – Robert Rowntree Jan 06 '15 at 23:48
  • I met segfaults with strange backtraces after header files modifications without full rebuild and update of all affected libraries. Sample sequence: modification of AwesomePlayer.h, rebuild and update on target device of the libmediaplayerservice.so only, restart of the mediaserver. Libstagefright.so and other libraries work with old AwesomePlayer interface and if I try to play anything that will cause segfault with strange backtrace. Are your player header files left intact? – Vladimir Kunschikov Jan 07 '15 at 17:55
  • I think it is not the problem, because the headerfiles did not changed frequently. Furthermore, I've done a full rebuild (clean & build all), everytime I changed the native code. – Robin Jan 07 '15 at 21:04
  • Make sure your java env can get your jclass in your native code. – xry Jan 08 '15 at 08:02
  • Yes, the java env can get the jclass correcly (otherwise it would return earlier) – Robin Jan 08 '15 at 19:39
  • your logcat hopefully contains more information. Check what is logged with DEBUG tag. You can try the `ndk-stack` tool that comes with Android NDK (see a somewhat outdated _[document](https://code.google.com/p/android-ndk-stacktrace-analyzer/wiki/Usage))_ or use addr2line (see _[example](http://www.codexperiments.com/android/2010/08/tips-tricks-debugging-android-ndk-stack-traces/)_) – Alex Cohn Jan 17 '15 at 19:27

0 Answers0