AMS не получает команду отмены публикации ИНОГДА через rtmpt

Question

Это заставило меня уехать на неделю как минимум. Я пытаюсь записать видео файл в AMS. Он прекрасно работает почти все время, за исключением примерно 1 из 10 или 15 сеансов записи. Я никогда не получаю NetStream.Unpublish.Success на свой netstream от AMS при закрытии потока. Я подключаюсь к AMS, используя rtmpt, когда это происходит, кажется, что он отлично работает над rtmp. Кроме того, похоже, что это происходит только в сафари на Mac, но так как это так непостоянно, я не очень доверяю этому. Вот мой основной поток:

// just a way to use promises with netStatusEvents
private function netListener(code:String, netObject:*):Promise {
    var deferred:Deferred = new Deferred();

    var netStatusHandler:Function = function (event:NetStatusEvent):void {
        if (event.info.level == 'error') {
            deferred.reject(event);
        } else if (event.info.code == code) {
            deferred.resolve(netObject);
            // we want this to be a one time listener since the connection can swap between record/playback
            netObject.removeEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);
        }

    };

    netObject.addEventListener(NetStatusEvent.NET_STATUS, netStatusHandler);

    return deferred.promise;
}

// set up for recording
private function initRecord():void {

    Settings.recordFile = Settings.uniquePrefix + (new Date()).getTime();

    // detach any existing NetStream from the video
    _view.video.attachNetStream(null);

    // dispose of existing NetStream
    if (_videoStream) {
        _videoStream.dispose();
        _videoStream = null;
    }

    // disconnect before connecting anew
    (_nc.connected ? netListener('NetConnection.Connect.Closed', _nc) : Promise.when(_nc))
    .then(function (nc:NetConnection):void {

        netListener('NetConnection.Connect.Success', _nc)
        .then(function (nc:NetConnection):void {

            _view.video.attachCamera(_webcam);
            // get new NetStream
            _videoStream = getNetStream(_nc);

            ExternalInterface.call("CTplayer." + Settings.instanceName + ".onRecordReady", true);

        }, function(error:NetStatusEvent):void {
            ExternalInterface.call("CTplayer." + Settings.instanceName + ".onError", error.info);
        });

        _nc.connect(Settings.recordServer);

    }); // end ncClose

    if (_nc.connected) _nc.close();

}

// stop recording
private function stop():void {

    netListener('NetStream.Unpublish.Success', _videoStream)
    .then(function (ns:NetStream):void {        
        ExternalInterface.call("CTplayer." + Settings.instanceName + ".onRecordStop", Settings.recordFile);
    });

    _videoStream.attachCamera(null);
    _videoStream.attachAudio(null);
    _videoStream.close();
}

// start recording
private function record():void {

    netListener('NetStream.Publish.Start', _videoStream)
    .then(function (ns:NetStream):void {
        ExternalInterface.call("CTplayer." + Settings.instanceName + ".onRecording");
    });

    _videoStream.attachCamera(_webcam);
    _videoStream.attachAudio(_microphone);
    _videoStream.publish(Settings.recordFile, "record"); // fires NetStream.Publish.Success

}

Обновление Я сейчас использую новый NetConnection для каждой попытки подключения, а также не форсирую порт 80 (см. Мой ответ ниже). Это не решило моих проблем с подключением, только сделало случаи более редкими. Теперь, как и каждую неделю или около того, у меня все еще есть случайный сбой АМС или вспышки. Совсем недавно кто-то сделал запись, а затем флэш-плеер не смог загрузить видео для воспроизведения. Журналы ams показывают попытку подключения, а затем ничего. По крайней мере, должно быть зарегистрировано событие воспроизведения, когда я загружаю метаданные. Это довольно сложно и невозможно отладить.

Answer 1

Я бы попробовал 2 разных объекта NetConnection, один для записи и один для воспроизведения. Это избавит вас от сложностей, связанных с логикой добавления / удаления и подключения / повторного подключения / отключения слушателей, и IMO станет чище. NETConnections дешевы, и я всегда использовал один для каждой задачи под рукой. Другим преимуществом является то, что вы можете подключить оба при запуске, так что подключение воспроизведения готово мгновенно.

Я не видел здесь ранее Обещания, но я не компетентен комментировать, может ли это вызвать проблему или нет.

Answer 2

Я думаю, что моя проблема была связана с портом 80. Первоначально я думал, что должен был использовать порт 80 с rtmpt, поэтому я установил свой Settings.recordServer переменная к rtmpt://myamsserver.net:80/app, Сейчас я использую подход с использованием дробовика, где я пробую сразу несколько комбинаций портов и протоколов и выбираю первый для подключения. Он почти всегда выбирает порт 443 вместо rtmpt, который кажется намного быстрее и стабильнее всего около 80, и с тех пор у меня не было этой проблемы. Это также может быть связано с тем, что не использовать повторно NetConnection объект, как предложил Стефан, трудно сказать.