Skip to main content
Participant
May 17, 2006
Answered

Pausing a NetStream while publishing to allow buffer to empty

  • May 17, 2006
  • 3 replies
  • 482 views
I am having trouble with dialup users who are publishing webcam video using NetStream.publish(streamname, "record"). The video doesn't completely upload because there's a backlog of data in the buffer that gets tossed when they hit the Stop button in my app and the stream gets closed.

I figured a workaround would be to pause the uploading stream and wait for the bufferLength to reach zero before closing the stream, but I can't figure out how to pause a publishing stream. NetStream.pause() doesn't seem to work.

I'd appreciate any help. Thanks.
    This topic is closed to new replies. Start a new post to keep the conversation going.
    Correct answer fromsir12
    I was wrestling with the same problem. Here is the solution I used and it sounds like it might solve your problem.

    When the user hits Stop, use the code:

    function stopRecording() {
    recordStatus.text = "Paused";
    stopRecordingVid = true;
    record_ns.attachVideo(null);
    record_ns.attachAudio(null);

    delete user_mic;
    delete user_cam;
    }

    Then for the NetStream's onStatus event:

    record_ns.onStatus = function(infoObject bject) {

    if(infoObject.code == "NetStream.Unpublish.Success"){
    playback();
    }

    if(infoObject.code == "NetStream.Buffer.Empty"){
    if(stopRecordingVid == true){
    record_ns.publish(false);
    record_ns.close();
    delete record_nc;
    }
    }

    Whatever you set the buffer to .... when it empties out, the onStatus event will be called and by catching this along with the boolean set by the Stop button ... the stream will stop taking data, the buffer(remaining data) will be sent with the stream, and when the buffer empties out, have the onStatus event catch it and close the stream.

    Hope this helps!
    Brian



    }

    3 replies

    pilahakaAuthor
    Participant
    May 17, 2006
    I came up with another workaround, that's not very elegant and certainly not foolproof, but it works... mostly. I'd still appreciate any other ideas. So, for posterity, here' what I did.

    When the user clicks the Stop button, I calculate a kbps using the buffer and the stream time, in an effort to figure out a time in the future when all the video up to the point where they clicked stop should be uploaded:

    stopTime = ns.time + ((ns.bufferLength / ((ns.time - ns.bufferLength) / ns.time)) * 1.20); // 20% margin for error

    Since, I can't seem to pause the stream, I let it go and wait until NetStream.time = stopTime. In my tests it seems to work pretty well, but if the user's upload speed varies by too much, video will get cut off. It also runs the risk of recording too much and capturing embarassing moments. All in all, not good, but the best I could do.

    I'd still appreciate some help.
    fromsir12Correct answer
    Participant
    May 31, 2006
    I was wrestling with the same problem. Here is the solution I used and it sounds like it might solve your problem.

    When the user hits Stop, use the code:

    function stopRecording() {
    recordStatus.text = "Paused";
    stopRecordingVid = true;
    record_ns.attachVideo(null);
    record_ns.attachAudio(null);

    delete user_mic;
    delete user_cam;
    }

    Then for the NetStream's onStatus event:

    record_ns.onStatus = function(infoObject bject) {

    if(infoObject.code == "NetStream.Unpublish.Success"){
    playback();
    }

    if(infoObject.code == "NetStream.Buffer.Empty"){
    if(stopRecordingVid == true){
    record_ns.publish(false);
    record_ns.close();
    delete record_nc;
    }
    }

    Whatever you set the buffer to .... when it empties out, the onStatus event will be called and by catching this along with the boolean set by the Stop button ... the stream will stop taking data, the buffer(remaining data) will be sent with the stream, and when the buffer empties out, have the onStatus event catch it and close the stream.

    Hope this helps!
    Brian



    }
    pilahakaAuthor
    Participant
    September 4, 2006
    Thanks. Works like a charm.