实时音视频

实时音视频

iOS 基于实时音视频 SDK 实现屏幕共享功能——2

WebRTCadmin 发表了文章 • 0 个评论 • 371 次浏览 • 2020-12-03 18:26 • 来自相关话题

iOS 基于实时音视频 SDK 实现屏幕共享功能——1iOS 基于实时音视频 SDK 实现屏幕共享功能——2iOS 基于实时音视频 SDK 实现屏幕共享功能——3iOS 基于实时音视频 SDK 实现屏幕共享功能——4这里的核心思想是拿到屏幕共享的数据之后,先进... ...查看全部

微信截图_20201203182500.png


iOS 基于实时音视频 SDK 实现屏幕共享功能——1

iOS 基于实时音视频 SDK 实现屏幕共享功能——2

iOS 基于实时音视频 SDK 实现屏幕共享功能——3

iOS 基于实时音视频 SDK 实现屏幕共享功能——4



这里的核心思想是拿到屏幕共享的数据之后,先进行压缩,当压缩完成后会通过回调上报给当前类。既而通过 clientSend 方法,发给主 App。发给主 App 的数据中自定义了一个头部,头部添加了一个前缀和一个每次发送字节的长度,当接收端收到数据包后解析即可。

- (void)clientSend:(NSData *)data {
    //data length
    NSUInteger dataLength = data.length;
    // data header struct
    DataHeader dataH;
    memset((void *)&dataH, 0, sizeof(dataH));
    // pre
    PreHeader preH;
    memset((void *)&preH, 0, sizeof(preH));
    preH.pre[0] = '&';
    preH.dataLength = dataLength;
    dataH.preH = preH;
    // buffer
    int headerlength = sizeof(dataH);
    int totalLength = dataLength + headerlength;
    // srcbuffer
    Byte *src = (Byte *)[data bytes];
    // send buffer
    char *buffer = (char *)malloc(totalLength * sizeof(char));
    memcpy(buffer, &dataH, headerlength);
    memcpy(buffer + headerlength, src, dataLength);
    // to send
    [self sendBytes:buffer length:totalLength];
    free(buffer);
}

1.4 接收屏幕共享数据

//
//  RongRTCServerSocket.m
//  SealRTC
//
//  Created by Sun on 2020/5/7.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "RongRTCServerSocket.h"
#import <arpa/inet.h>
#import <netdb.h>
#import <sys/types.h>
#import <sys/socket.h>
#import <ifaddrs.h>
#import <UIKit/UIKit.h>
#import "RongRTCThread.h"
#import "RongRTCSocketHeader.h"
#import "RongRTCVideoDecoder.h"
@interface RongRTCServerSocket() <RongRTCCodecProtocol>
{
    pthread_mutex_t lock;
    int _frameTime;
    CMTime _lastPresentationTime;
    Float64 _currentMediaTime;
    Float64 _currentVideoTime;
    dispatch_queue_t _frameQueue;
}
@property (nonatomic, assign) int acceptSocket;
/**
 data length
 */
@property (nonatomic, assign) NSUInteger dataLength;
/**
 timeData
 */
@property (nonatomic, strong) NSData *timeData;
/**
 decoder queue
 */
@property (nonatomic, strong) dispatch_queue_t decoderQueue;
/**
 decoder
 */
@property (nonatomic, strong) RongRTCVideoDecoder *decoder;
@end
@implementation RongRTCServerSocket
- (BOOL)createServerSocket {
    if ([self createSocket] == -1) {
        return NO;
    }
    [self setReceiveBuffer];
    [self setReceiveTimeout];
    BOOL isB = [self bind];
    BOOL isL = [self listen];
    if (isB && isL) {
        _decoderQueue = dispatch_queue_create("cn.rongcloud.decoderQueue", NULL);
        _frameTime = 0;
        [self createDecoder];
        [self receive];
        return YES;
    } else {
        return NO;
    }
}
- (void)createDecoder {
    self.decoder = [[RongRTCVideoDecoder alloc] init];
    self.decoder.delegate = self;
    RongRTCVideoEncoderSettings *settings = [[RongRTCVideoEncoderSettings alloc] init];
    settings.width = 720;
    settings.height = 1280;
    settings.startBitrate = 300;
    settings.maxFramerate = 30;
    settings.minBitrate = 1000;
    [self.decoder configWithSettings:settings onQueue:_decoderQueue];
}
- (void)receiveData {
    struct sockaddr_in rest;
    socklen_t rest_size = sizeof(struct sockaddr_in);
    self.acceptSocket = accept(self.socket, (struct sockaddr *) &rest, &rest_size);
    while (self.acceptSocket != -1) {
        DataHeader dataH;
        memset(&dataH, 0, sizeof(dataH));
        if (![self receiveData:(char *)&dataH length:sizeof(dataH)]) {
            continue;
        }
        PreHeader preH = dataH.preH;
        char pre = preH.pre[0];
        if (pre == '&') {
            // rongcloud socket
            NSUInteger dataLenght = preH.dataLength;
            char *buff = (char *)malloc(sizeof(char) * dataLenght);
            if ([self receiveData:(char *)buff length:dataLenght]) {
                NSData *data = [NSData dataWithBytes:buff length:dataLenght];
                [self.decoder decode:data];
                free(buff);
            }
        } else {
            NSLog(@"pre is not &");
            return;
        }
    }
}
- (BOOL)receiveData:(char *)data length:(NSUInteger)length {
    LOCK(lock);
    int receiveLength = 0;
    while (receiveLength < length) {
        ssize_t res = recv(self.acceptSocket, data, length - receiveLength, 0);
        if (res == -1 || res == 0) {
            UNLOCK(lock);
            NSLog(@"receive data error");
            break;
        }
        receiveLength += res;
        data += res;
    }
    UNLOCK(lock);
    return YES;
}
- (void)didGetDecodeBuffer:(CVPixelBufferRef)pixelBuffer {
    _frameTime += 1000;
    CMTime pts = CMTimeMake(_frameTime, 1000);
    CMSampleBufferRef sampleBuffer = [RongRTCBufferUtil sampleBufferFromPixbuffer:pixelBuffer time:pts];
    // Check to see if there is a problem with the decoded data. If the image appears, you are right.
    UIImage *image = [RongRTCBufferUtil imageFromBuffer:sampleBuffer];
    [self.delegate didProcessSampleBuffer:sampleBuffer];
    CFRelease(sampleBuffer);
}
- (void)close {
    int res = close(self.acceptSocket);
    self.acceptSocket = -1;
    NSLog(@"shut down server: %d", res);
    [super close];
}
- (void)dealloc {
    NSLog(@"dealoc server socket");
}
@end

主 App 通过 Socket 会持续收到数据包,再将数据包进行解码,将解码后的数据通过代理 didGetDecodeBuffer 代理方法回调给 App 层。App 层就可以通过融云 RongRTCLib 的发送自定义流方法将视频数据发送到对端。



iOS 基于实时音视频 SDK 实现屏幕共享功能——1

WebRTCadmin 发表了文章 • 0 个评论 • 381 次浏览 • 2020-12-03 18:21 • 来自相关话题

iOS 基于实时音视频 SDK 实现屏幕共享功能——1iOS 基于实时音视频 SDK 实现屏幕共享功能——2iOS 基于实时音视频 SDK 实现屏幕共享功能——3iOS 基于实时音视频 SDK 实现屏幕共享功能——4Replaykit 介绍在之前的 iOS 版... ...查看全部

微信截图_20201203181458.png

iOS 基于实时音视频 SDK 实现屏幕共享功能——1

iOS 基于实时音视频 SDK 实现屏幕共享功能——2

iOS 基于实时音视频 SDK 实现屏幕共享功能——3

iOS 基于实时音视频 SDK 实现屏幕共享功能——4

Replaykit 介绍

在之前的 iOS 版本中,iOS 开发者只能拿到编码后的数据,拿不到原始的 PCM 和 YUV,到 iOS 10 之后,开发者可以拿到原始数据,但是只能录制 App 内的内容,如果切到后台,将停止录制,直到 iOS 11,苹果对屏幕共享进行了升级并开放了权限,既可以拿到原始数据,又可以录制整个系统,以下我们重点来说 iOS 11 之后的屏幕共享功能。

系统屏幕共享

- (void)initMode_1 {
    self.systemBroadcastPickerView = [[RPSystemBroadcastPickerView alloc] initWithFrame:CGRectMake(0, 64, ScreenWidth, 80)];
    self.systemBroadcastPickerView.preferredExtension = @"cn.rongcloud.replaytest.Recoder";
    self.systemBroadcastPickerView.backgroundColor = [UIColor colorWithRed:53.0/255.0 green:129.0/255.0 blue:242.0/255.0 alpha:1.0];
    self.systemBroadcastPickerView.showsMicrophoneButton = NO;
    [self.view addSubview:self.systemBroadcastPickerView];
}

在 iOS 11 创建一个 Extension 之后,调用上面的代码就可以开启屏幕共享了,然后系统会为我们生成一个 SampleHandler 的类,在这个方法中,苹果会根据 RPSampleBufferType 上报不同类型的数据。

- (void)processSampleBuffer:(CMSampleBufferRef)sampleBuffer withType:(RPSampleBufferType)sampleBufferType

那怎么通过融云的 RongRTCLib 将屏幕共享数据发送出去呢?

1. 基于 Socket 的逼格玩法

1.1. Replaykit 框架启动和创建 Socket

//
//  ViewController.m
//  Socket_Replykit
//
//  Created by Sun on 2020/5/19.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "ViewController.h"
#import <ReplayKit/ReplayKit.h>
#import "RongRTCServerSocket.h"
@interface ViewController ()<RongRTCServerSocketProtocol>
@property (nonatomic, strong) RPSystemBroadcastPickerView *systemBroadcastPickerView;
/**
 server socket
 */
@property(nonatomic , strong)RongRTCServerSocket *serverSocket;
@end
@implementation ViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    self.view.backgroundColor = [UIColor whiteColor];
    // Do any additional setup after loading the view.
    [self.serverSocket createServerSocket];
    self.systemBroadcastPickerView = [[RPSystemBroadcastPickerView alloc] initWithFrame:CGRectMake(0, 64, [UIScreen mainScreen].bounds.size.width, 80)];
    self.systemBroadcastPickerView.preferredExtension = @"cn.rongcloud.sealrtc.RongRTCRP";
    self.systemBroadcastPickerView.backgroundColor = [UIColor colorWithRed:53.0/255.0 green:129.0/255.0 blue:242.0/255.0 alpha:1.0];
    self.systemBroadcastPickerView.showsMicrophoneButton = NO;
    [self.view addSubview:self.systemBroadcastPickerView];
}
- (RongRTCServerSocket *)serverSocket {
    if (!_serverSocket) {
        RongRTCServerSocket *socket = [[RongRTCServerSocket alloc] init];
        socket.delegate = self;
        _serverSocket = socket;
    }
    return _serverSocket;
}
- (void)didProcessSampleBuffer:(CMSampleBufferRef)sampleBuffer {
    // 这里拿到了最终的数据,比如最后可以使用融云的音视频SDK RTCLib 进行传输就可以了
}
@end

其中,包括了创建 Server Socket 的步骤,我们把主 App 当做 Server,然后屏幕共享 Extension 当做 Client ,通过 Socket 向我们的主 APP 发送数据。

在 Extension 里面,我们拿到 ReplayKit 框架上报的屏幕视频数据后:

//
//  SampleHandler.m
//  SocketReply
//
//  Created by Sun on 2020/5/19.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "SampleHandler.h"
#import "RongRTCClientSocket.h"
@interface SampleHandler()
/**
 Client Socket
 */
@property (nonatomic, strong) RongRTCClientSocket *clientSocket;
@end
@implementation SampleHandler
- (void)broadcastStartedWithSetupInf(NSDictionary<NSString *,NSObject *> *)setupInfo {
    // User has requested to start the broadcast. Setup info from the UI extension can be supplied but optional.
    self.clientSocket = [[RongRTCClientSocket alloc] init];
    [self.clientSocket createCliectSocket];
}
- (void)processSampleBuffer:(CMSampleBufferRef)sampleBuffer withType:(RPSampleBufferType)sampleBufferType {
    switch (sampleBufferType) {
        case RPSampleBufferTypeVide
            // Handle video sample buffer
            [self sendData:sampleBuffer];
            break;
        case RPSampleBufferTypeAudioApp:
            // Handle audio sample buffer for app audio
            break;
        case RPSampleBufferTypeAudioMic:
            // Handle audio sample buffer for mic audio
            break;
        default:
            break;
    }
}
- (void)sendData:(CMSampleBufferRef)sampleBuffer {
    [self.clientSocket encodeBuffer:sampleBuffer];
}
@end

可见 ,这里我们创建了一个 Client Socket,然后拿到屏幕共享的视频 sampleBuffer 之后,通过 Socket 发给我们的主 App,这就是屏幕共享的流程。

1.2 Local Socket 的使用

//
//  RongRTCSocket.m
//  SealRTC
//
//  Created by Sun on 2020/5/7.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "RongRTCSocket.h"
#import <arpa/inet.h>
#import <netdb.h>
#import <sys/types.h>
#import <sys/socket.h>
#import <ifaddrs.h>
#import "RongRTCThread.h"
@interface RongRTCSocket()
/**
 receive thread
 */
@property (nonatomic, strong) RongRTCThread *receiveThread;
@end
@implementation RongRTCSocket
- (int)createSocket {
    int socket = socket(AF_INET, SOCK_STREAM, 0);
    self.socket = socket;
    if (self.socket == -1) {
        close(self.socket);
        NSLog(@"socket error : %d", self.socket);
    }
    self.receiveThread = [[RongRTCThread alloc] init];
    [self.receiveThread run];
    return socket;
}
- (void)setSendBuffer {
    int optVal = 1024 * 1024 * 2;
    int optLen = sizeof(int);
    int res = setsockopt(self.socket, SOL_SOCKET, SO_SNDBUF, (char *)&optVal,optLen);
    NSLog(@"set send buffer:%d", res);
}
- (void)setReceiveBuffer {
    int optVal = 1024 * 1024 * 2;
    int optLen = sizeof(int);
    int res = setsockopt(self.socket, SOL_SOCKET, SO_RCVBUF, (char*)&optVal,optLen );
    NSLog(@"set send buffer:%d",res);
}
- (void)setSendingTimeout {
    struct timeval timeout = {10,0};
    int res = setsockopt(self.socket, SOL_SOCKET, SO_SNDTIMEO, (char *)&timeout, sizeof(int));
    NSLog(@"set send timeout:%d", res);
}
- (void)setReceiveTimeout {
    struct timeval timeout = {10, 0};
    int  res = setsockopt(self.socket, SOL_SOCKET, SO_RCVTIMEO, (char *)&timeout, sizeof(int));
    NSLog(@"set send timeout:%d", res);
}
- (BOOL)connect {
    NSString *serverHost = [self ip];
    struct hostent *server = gethostbyname([serverHost UTF8String]);
    if (server == NULL) {
        close(self.socket);
        NSLog(@"get host error");
        return NO;
    }
    struct in_addr *remoteAddr = (struct in_addr *)server->h_addr_list[0];
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_addr = *remoteAddr;
    addr.sin_port = htons(CONNECTPORT);
    int res = connect(self.socket, (struct sockaddr *) &addr, sizeof(addr));
    if (res == -1) {
        close(self.socket);
        NSLog(@"connect error");
        return NO;
    }
    NSLog(@"socket connect to server success");
    return YES;
}
- (BOOL)bind {
    struct sockaddr_in client;
    client.sin_family = AF_INET;
    NSString *ipStr = [self ip];
    if (ipStr.length <= 0) {
        return NO;
    }
    const char *ip = [ipStr cStringUsingEncoding:NSASCIIStringEncoding];
    client.sin_addr.s_addr = inet_addr(ip);
    client.sin_port = htons(CONNECTPORT);
    int bd = bind(self.socket, (struct sockaddr *) &client, sizeof(client));
    if (bd == -1) {
        close(self.socket);
        NSLog(@"bind error: %d", bd);
        return NO;
    }
    return YES;
}
- (BOOL)listen {
    int ls = listen(self.socket, 128);
    if (ls == -1) {
        close(self.socket);
        NSLog(@"listen error: %d", ls);
        return NO;
    }
     return YES;
}
- (void)receive {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [self receiveData];
    });
}
- (NSString *)ip {
    NSString *ip = nil;
    struct ifaddrs *addrs = NULL;
    struct ifaddrs *tmpAddrs = NULL;
    BOOL res = getifaddrs(&addrs);
    if (res == 0) {
        tmpAddrs = addrs;
        while (tmpAddrs != NULL) {
            if (tmpAddrs->ifa_addr->sa_family == AF_INET) {
                // Check if interface is en0 which is the wifi connection on the iPhone
                NSLog(@"%@", [NSString stringWithUTF8String:inet_ntoa(((struct sockaddr_in *)tmpAddrs->ifa_addr)->sin_addr)]);
                if ([[NSString stringWithUTF8String:tmpAddrs->ifa_name] isEqualToString:@"en0"]) {
                    // Get NSString from C String
                    ip = [NSString stringWithUTF8String:inet_ntoa(((struct sockaddr_in *)tmpAddrs->ifa_addr)->sin_addr)];
                }
            }
            tmpAddrs = tmpAddrs->ifa_next;
        }
    }
    // Free memory
    freeifaddrs(addrs);
    NSLog(@"%@",ip);
    return ip;
}
- (void)close {
    int res = close(self.socket);
    NSLog(@"shut down: %d", res);
}
- (void)receiveData {
}
- (void)dealloc {
    [self.receiveThread stop];
}

@end

首先创建了一个 Socket 的父类,然后用 Server Socket 和 Client Socket 分别继承类来实现链接、绑定等操作。可以看到有些数据可以设置,有些则不用,这里不是核心,核心是怎样收发数据。

1.3 发送屏幕共享数据

//
//  RongRTCClientSocket.m
//  SealRTC
//
//  Created by Sun on 2020/5/7.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "RongRTCClientSocket.h"
#import <arpa/inet.h>
#import <netdb.h>
#import <sys/types.h>
#import <sys/socket.h>
#import <ifaddrs.h>
#import "RongRTCThread.h"
#import "RongRTCSocketHeader.h"
#import "RongRTCVideoEncoder.h"
@interface RongRTCClientSocket() <RongRTCCodecProtocol> {
    pthread_mutex_t lock;
}
/**
 video encoder
 */
@property (nonatomic, strong) RongRTCVideoEncoder *encoder;
/**
 encode queue
 */
@property (nonatomic, strong) dispatch_queue_t encodeQueue;
@end
@implementation RongRTCClientSocket
- (BOOL)createClientSocket {
    if ([self createSocket] == -1) {
        return NO;
    }
    BOOL isC = [self connect];
    [self setSendBuffer];
    [self setSendingTimeout];
    if (isC) {
        _encodeQueue = dispatch_queue_create("cn.rongcloud.encodequeue", NULL);
        [self createVideoEncoder];
        return YES;
    } else {
        return NO;
    }
}
- (void)createVideoEncoder {
    self.encoder = [[RongRTCVideoEncoder alloc] init];
    self.encoder.delegate = self;
    RongRTCVideoEncoderSettings *settings = [[RongRTCVideoEncoderSettings alloc] init];
    settings.width = 720;
    settings.height = 1280;
    settings.startBitrate = 300;
    settings.maxFramerate = 30;
    settings.minBitrate = 1000;
    [self.encoder configWithSettings:settings onQueue:_encodeQueue];
}
- (void)clientSend:(NSData *)data {
    //data length
    NSUInteger dataLength = data.length;
    // data header struct
    DataHeader dataH;
    memset((void *)&dataH, 0, sizeof(dataH));
    // pre
    PreHeader preH;
    memset((void *)&preH, 0, sizeof(preH));
    preH.pre[0] = '&';
    preH.dataLength = dataLength;
    dataH.preH = preH;
    // buffer
    int headerlength = sizeof(dataH);
    int totalLength = dataLength + headerlength;
    // srcbuffer
    Byte *src = (Byte *)[data bytes];
    // send buffer
    char *buffer = (char *)malloc(totalLength * sizeof(char));
    memcpy(buffer, &dataH, headerlength);
    memcpy(buffer + headerlength, src, dataLength);
    // tosend
    [self sendBytes:buffer length:totalLength];
    free(buffer);
}
- (void)encodeBuffer:(CMSampleBufferRef)sampleBuffer {
    [self.encoder encode:sampleBuffer];
}
- (void)sendBytes:(char *)bytes length:(int)length {
    LOCK(self->lock);
    int hasSendLength = 0;
    while (hasSendLength < length) {
        // connect socket success
        if (self.socket > 0) {
            // send
            int sendRes = send(self.socket, bytes, length - hasSendLength, 0);
            if (sendRes == -1 || sendRes == 0) {
                UNLOCK(self->lock);
                NSLog(@"send buffer error");
                [self close];
                break;
            }
            hasSendLength += sendRes;
            bytes += sendRes;
        } else {
            NSLog(@"client socket connect error");
            UNLOCK(self->lock);
        }
    }
    UNLOCK(self->lock); 
}
- (void)spsData:(NSData *)sps ppsData:(NSData *)pps {
    [self clientSend:sps];
    [self clientSend:pps];
}
- (void)naluData:(NSData *)naluData {
    [self clientSend:naluData];
}
- (void)deallo c{
    NSLog(@"dealoc cliect socket");
}
@end


30万+App都在用的服务商,有什么特别之处?

科技创新融云那些事 发表了文章 • 0 个评论 • 125 次浏览 • 2020-08-03 16:57 • 来自相关话题

两个月前,一款名为 Clubhouse 的 App 开始流行于美国 VC、名人圈层,并且一直热度不减。尽管它的用户只有几千人,但其估值却已超过 1 亿美元。Clubhouse 是一款语音社交软件,被誉为是“音频 Twitter”。打开 Clubhouse,选一... ...查看全部

两个月前,一款名为 Clubhouse 的 App 开始流行于美国 VC、名人圈层,并且一直热度不减。尽管它的用户只有几千人,但其估值却已超过 1 亿美元。

Clubhouse 是一款语音社交软件,被誉为是“音频 Twitter”。

讯飞1.webp.jpg

打开 Clubhouse,选一个房间进入,人们可以查看房间里都有哪些参与者,并可以听到他们的谈话,再决定是否继续听或直接加入群聊。

如果要说它最大的规则是什么,那就是:只用语音,没有文字

近年来,移动互联网飞速发展,语音功能已开始成为 App 的标配,各种属性的音频类 App 尤其是声音社交类 App 也在悄然壮大。

红杉中国发布的《创造未来——红杉 00 后泛娱乐消费研究报告》显示,社交性、潮流性和个性化是“00 后”用户最看重的三大产品特征。因此,比图片和文字有温度,比视频更含蓄的声音社交方式,开始在他们之中风靡。

而根据艾瑞咨询的数据,2019 年中国网络音频行业市场规模为 175.8 亿元,同比增长 55.1%,预计 2020 年中国网络音频行业市场规模达 272.4 亿元。越来越多的资本和资源看到了声音背后蕴藏的更多可能性。

讯飞2.png

随着 5G 网络的逐渐普及,网络速度变得更快,以音频、视频为主要交互方式的互联网产品或将大行其道。

今年年初的疫情期间,我们已经看到各种音视频软件在在线教育、在线办公中发挥着巨大的作用。但有一个不得不面对的事实是,它们都曾因短时期内使用人数过多而崩溃。

对于音视频类互联网产品来说,保证用户使用过程中不会出现卡顿、声音效果差等问题十分重要,这就需要技术上的强力支持与保证,在这一方面能够提供“实时音视频”技术的服务商做的相当专业。

目前,在我国从事“实时音视频”技术底层搭建的服务商主要分为两大阵营。其一,是只专注“实时音视频”技术的单一产业服务商;其二,是 IM 领域已经耕耘多年,现将 IM 即时通讯及实时音视频两大业务版块交融聚合的服务商。例如,已多年稳居 IM 市场占有率第一的融云。

讯飞3.webp.jpg

北京云中融信网络科技有限公司(简称融云),是一家安全、可靠的全球互联网通信云服务商,向开发者和企业提供即时通讯和实时音视频通信云服务。虽成立时间不长,但发展迅速,成立不久就获得了 1 亿元人民币 B 轮融资。

截止目前,已有中原地产、汽车之家、融创地产、丽兹行、寺库、哈啰出行、核桃编程、易车网、编程猫以及 Castbox、Opera 等超过 30 万款海内外 App 通过融云实现了全球化的互联网通信能力。

融云现已在科大讯飞旗下人工智能全产业链综合服务平台——讯飞 AI 服务市场入驻,来一起看看,它的哪些技术能让如此之多的 App “钟情”于它?

融云IM即时通讯

许多 85 后甚至 90 后的大学记忆中都有一款即时通讯工具,飞信。在那个短信 1 毛钱一条,流量 5 块钱只有 30M 的年代,飞信免流量、免费发短信的功能,很有吸引力。作为当初中国移动即时通讯的扛鼎之作,飞信注册用户最高时达到了 5 亿,高峰时拥有高达 9000 万的活跃用户,其技术水平自不必多说。

融云的技术团队源自飞信技术团队,在即时通讯领域有着丰富的经验和强大的核心技术实力。

融云即时通讯支持多聊天模式、多消息类型、自定义界面等功能,同时支持聊天记录漫游、消息回执与召回、消息内容全文搜索、消息内容审核等功能。用户可以根据自己的需求调用相关接口,大大节约在通信能力上的研发时间和成本。

讯飞7.png

基于融云私有通信协议,可以保障消息不丢不重不乱,支持无上限用户数的群组和聊天室互动,公有云平台 150 亿条日均消息量2218 亿条日消息量峰值。融云建立了全球多数据中心,服务覆盖全球所有国家及地区(共 233 个),实时监控全球网络,基于融云分布在全球的数据中心与节点建设,向客户提供链路接入方案,持续的海外链路优化让消息发送稳定可靠,畅通无阻。

讯飞8.webp.jpg

无论是私密社交、兴趣社交还是商业沟通、系统消息等场景,融云都可以轻松应对,它也是业内唯一承诺消息可靠性 100% 的厂商。

融云RTC实时音视频

为了适应移动互联网发展和市场需求,融云在即时通讯之外还发展了实时音视频业务。融云实时音视频主要包括音视频通话、低延迟直播、音视频会议、云端录制等功能。用户可以根据自己的需求调用相关接口,大大节约在通信能力上的研发时间。

讯飞9.png

融云实时音视频具备低延迟、低成本、高流畅、高品质、部署简单、扩展灵活等技术优势。在整体网络架构上,全球分布式架构的部署让扩容时间大幅缩短,能轻松应对海量流量的激增。弱网优化策略方面,增强了抗丢包及抗网络抖动能力,音频能对抗 80% 丢包,视频能对抗 40% 丢包,延时最低可达 66ms,以保证低成本输出高性能的实时音视频能力(可以提供最高 1080P 的高清画质和最高 48KHz 的音频采样率) 。经过海量客户业务验证,融云实时音视频业务在稳定性、连通性、并发/负载等方面服务可用性达到 99.9%

融云在疫情期间还免费开放了在线医疗、在线教育及协同办公场景的通信能力,并开发了 VR 看房等新的业务场景。

最新活动推荐:

 融云年中大促活动海报.png


芥末堆专访:线上教学交付能力背后,在线音视频通信技术成刚需

科技创新融云那些事 发表了文章 • 0 个评论 • 186 次浏览 • 2020-08-03 16:43 • 来自相关话题

2020 年过半,疫情加速在线教育发展已成事实。疫情防控常态化使得线下教育场景面临着长期挑战,线上教学交付能力俨然成为教培机构的标配。伴随着线下机构转型线上探索教育 OMO,线上教学背后的技术能力开始受到重视。相比线下场景天然的临场感和及时的互动性,线上化教学... ...查看全部

2020 年过半,疫情加速在线教育发展已成事实。疫情防控常态化使得线下教育场景面临着长期挑战,线上教学交付能力俨然成为教培机构的标配。

伴随着线下机构转型线上探索教育 OMO,线上教学背后的技术能力开始受到重视。相比线下场景天然的临场感和及时的互动性,线上化教学不是仅仅利用音视频工具就足够。线下场景中的信息传递是基于面对面的沟通,如何在线上场景“重现”甚至“超越”面对面沟通的信息传递方式是关键问题。

 芥末堆1_副本.jpg

无论教学形式或场景怎样变化,教育始终是效果为王。“全民网课”的时代,教学效果的保证离不开高质量的音视频信息传递、全方位的及时互动和多维度的数据分析。然而这些对于教培机构,尤其是以教学见长的线下机构,都并不熟悉。

全球通信云服务商融云 CPO 任杰表示:“在互联网时代,教育创业者应该聚焦自己的核心业务逻辑,而不是去关心通用型能力的实现。”

为此,融云专注于互联网云通信领域,为包括在线教育在内的互联网行业提供“IM 即时通讯+实时音视频+推送”的一体化解决方案,凭借技术积累实现安全、可靠、实时的即时通讯及音视频服务,满足各类教育场景的通用型和定制化的信息交互需求。

“IM 即时通讯+实时音视频+推送”,在线教育一体化解决方案

据任杰介绍,融云最初选择互联网云通信领域,就是看到互联网发展的趋势和通信需求的刚性。时至今日,伴随着移动互联网的发展,云通信已经成为标配能力。融云也从最初的“IM 即时通讯”业务,发展到“用一套 SDK,解决所有通信场景”,涵盖“IM 即时通讯+实时音视频+推送”的一体化解决方案。

任杰告诉芥末堆,融云整体的服务形式是以客户端 SDK 的方式体现,App 只要通过简单的几行代码就可以完成通信 SDK 集成,实现通信和社交能力。此外,融云还提供实时音视频相关功能和整体解决方案。

芥末堆2_副本.jpg 

去年 11 月 30 日,融云正式宣布已完成数亿元 C 轮融资

技术的发展背后是需求的演变。从图文时代到音视频时代,信息传播的媒介和方式都在发生着巨大变化。与之相应的是互联网企业对音视频通信技术的更高要求。任杰表示,如何打造一流的实时音视频服务,赋能开发者追赶音视频领域的技术红利,是融云始终关注的。

而作为互联网通信的主要应用场景之一,在线教育的内容以视频直播为主要形式。相比娱乐内容,教育内容的严肃性和互动性使得低延迟的高质量音视频传输成为刚需。任杰告诉芥末堆,以 PC 或平板为设备载体的在线教育对画质的要求,要远远高于移动端。

 芥末堆3_副本.jpg

如果将内容看作在线教育的产品核心,那么音视频质量可以看作在线教育的技术核心。相比其他内容行业,同样面对卡顿或延迟,在线教育用户的容忍度更低。任杰介绍,融云在今年 5 月份对融云实时音视频业务进行全面升级,针对开发者最关心的音视频通话质量,融云使用的是 WebRTC 技术,完全可以满足在线教育等场景中低延迟、强互动的需求。

据了解,在视频方面,融云目前能够提供最高 1080P 的分辨率,画面纤毫毕现,尤其适合特殊高清场景,如在线教育领域中的双师课堂场景的大屏直播。同时,融云还提供各种高中低分辨率供不同业务场景调用,实现画面和流量平衡,帧率最高支持 30FPS,可以匹配不同设备端的教学需求。

在音频方面,融云采用最高音频采样率 48KHz,可真实还原对端声音,高清音质。任杰介绍,融云目前可以提供高清音乐模式,针对乐器的高频音段和弱音音阶进行优化处理,高度还原音乐细节,带给用户更贴近线下场景的体验。在音频方面,融云完全可以满足素质教育领域的音乐培训的需求。

云通信能力之后,融云要延伸到更多在线教育场景

在沟通中,任杰始终强调融云在做的是底层技术能力的支持。但在介绍在线教育场景的应用时,芥末堆发现针对不同角色、不同班型、不同细分赛道的差异化需求,融云在技术上都有设计并满足。

提到融云通信云能力的特点,任杰总结到:性能稳定、全平台覆盖、全方位互动和全球部署。

 芥末堆4_副本.jpg

性能稳定是融云的核心优势。依托技术优势,融云可以为大型直播课程提供无用户上限和消息量限制的聊天室服务,亿级消息并发即时到达,互动稳定流畅、延迟低。任杰表示,在弱网优化策略上,融云的核心策略是能够迅速预估宽带,并采用降低码率来确保以声音与流畅优先的原则,保证用户最优体验。

在覆盖平台方面,融云实时音视频 SDK 可覆盖全平台,包括 iOS、Android、Web、Windows、macOS、Linux、Electron 等,并全面适配市场主流的各类终端设备,包括在智能手表、智能音箱、智能门禁等多种智能硬件设备中实现平台间通信,全面保障融云实时音视频在各类终端上的良好应用。

在全方位互动方面,任杰介绍,融云支持 1080P 高清视频,视频窗口放大缩小可切换不同分辨率;具备互动白板功能,支持上传常见办公文档,实时进行课堂演示;一对一、小班课、大班课、双师课等不同班型的实时直播、举手答疑和视频回看都能实现。他特意强调,为保障在线课程可 100% 回看,融云是采用两条线路双向录制的。

在全球部署方面,融云拥有覆盖全球的通信加速网络,全球多个数据中心,数千个加速点,触达全世界 233 个国家和地区,能够帮助教育企业实现全球范围内的高质量教学。

提到融云在在线教育领域的探索,任杰表示,教育的未来趋势一定是线上,但这离不开技术的发展和应用。融云后续将继续利用技术优势,持续在降低高质量音视频网络流量占用的方向上发力。

此外,将技术应用延伸到教育的各个场景也是融云的发力点之一。除了今年爆发的在线 K12 领域外,素质教育、在线考试等领域也亟待技术的重构。任杰以音乐教育为例,融云为管乐培训机构大雅乐盟做了针对性的音频通信改善,给出管乐培训的线上教育解决方案。而后续,钢琴、舞蹈等线上教学领域也是融云将会深化去探索的场景。

最新活动推荐:

融云年中大促活动海报.png

实时音视频选型 开发者应该避开哪些坑?

IM即时通讯融云那些事 发表了文章 • 0 个评论 • 141 次浏览 • 2020-07-24 15:19 • 来自相关话题

实时音视频技术的专业度和复杂度都很高,通过 PaaS 服务商来集成实时音视频,快速开发 App,是时下开发者的优先选择。所选 RTC 是否好用易用、契合所需场景,将直接影响项目开发进度和后期运维成本。开发者需要... ...查看全部

实时音视频技术的专业度和复杂度都很高,通过 PaaS 服务商来集成实时音视频,快速开发 App,是时下开发者的优先选择。所选 RTC 是否好用易用、契合所需场景,将直接影响项目开发进度和后期运维成本。

开发者需要了解实时音视频技术选型中要避开的坑点,以便提高开发集成效率。具体来说,以下四个方面要综合考虑。

一、实时音视频与 IM 能力不宜分散

几乎 100% 的实时音视频在线应用都有文字/语音消息、文件传输、图片显示等 IM 需求。

目前市场上 PaaS 服务商这两方面能力强弱不一:有的大厂虽然两方面能力都提供,但不能确保两种能力同样高质量;有的专业 RTC 厂商,只能提供 RTC 能力,IM 能力还得由第三方专业服务商提供。

这样,便迫使开发者在集成过程中不得不分别选择服务商。当实时音视频与 IM 质量不稳定时,需要逐一协调各个服务商,逐一排查问题,无形中增加了后期的运营成本。其实,IM 和音视频在很多场景下有耦合,建议开发者在选型一开始就要考虑具有 RTC+IM 双重高保障能力的通信云厂商,尽量“用一套 SDK,解决所有通信场景”。

任杰总2.png

对开发者来说两项功能同时开发,开发包相对比较小;如果前期只用到了 IM,没有用到 RTC,那么只需要学习 IM 方面的开发文档就可以了,一旦有了 RTC 需求,再去学习 RTC文档,开发者只需接入相关接口,快速与 IM 能力做对接和匹配,即可完成两类功能在 App 生命周期里的全覆盖。

除了开发上的易快速上手外,选择“IM+RTC+推送”整合的解决方案,开发者还可以享受一致的网络架构,提高传输的效率和质量,获得一致的服务保障。例如,融云近期升级了实时音视频能力,RTC的通信信令是复用 IM 信令通道,可以确保消息 100% 的连通率和到达率,使底层的通信优势发挥到最大。

二、延时、卡顿、抖动的质量问题要解决好

通过调研发现,用户最不能接受实时音视频的三个质量问题是延时、卡顿、抖动。

低延时要靠两个方面解决,一个是传输协议,一个是优化整体传输环节。实时音视频的主流传输协议有 RTMP 和 UDP 两种,一种支持 CDN 技术,一种支持 WebRTC 技术,相对来说,CDN 技术延时性在 3-5 秒,WebRTC 可以在几百毫秒以内,现在很多厂商可以同时支持这两种技术,分别适用于不同的场景。

整体传输环节中,采集/渲染、编解码/网络往返都会有一定的延时,有些是硬件的物理延迟,需要靠 5G 这样底层网络技术的提升,或者布更多的数据中心、边缘结点,便于就近接入;有些要针对实际场景,在具体形态上做一些权衡,比如在处理粒度上粗细的考虑,越细的粒度传输的数据包相对较大,延迟也会更高。

当音视频出现卡顿时,有一个视频流畅优先的原则。我们通过降低一些码率和帧率,即使画面模糊一点,也要让用户视觉上是流畅不卡顿的。这样在选型时候,要考虑几个方面:一个是优化低码率下的视频清晰度;二是要有带宽估算能力,当预判到这个带宽没法承受高清晰视频传输时,自动转化成低码率并通过优化算法,使低码率视频清晰度能媲美高清视频。

音视频弱网优势_副本.png


另外,数据包通常会以错误的顺序到达,从而产生抖动相关问题,或者直接丢失,造成音视频空白。谷歌一份资料显示,视频聊天应用 Duo 99% 的通话都有数据包丢失、过度抖动或网络延迟情况。20% 的通话丢失了超过 3% 的音频,10% 的通话丢包率超过 8%,也就是说每次通话都有很多音频需要替换。

处理上述问题,很多厂商会采用抗丢包及抗网络抖动能力的 NACK(丢包重传)、FEC(前向纠错)、自适应带宽调整(动态调整码)、接收端 Jitter Buffer(媒体流平稳)等各种机制,有些是组合使用,有些是单独使用,开发者在选型前一定要做到深入了解。

  • 拥有全球通信和场景化能力

    刚才谈到低延时、抗丢包的解决策略,有些是与网络接入路径长短直接相关的。比如中美两地的音视频连接,没有全球通信网络支持、数据中心和节点布局的厂商是提供不了服务的。开发者选型开发前,就要考虑到自己业务的所属范围。   

    选择全球化服务的云厂商,除了看数据中心和节点分布外,还要仔细考察全球网络布局的品质,简单说,有的厂商提供了全球网络优化能力,中美之间的音视频连接在未优化前要经过 100 多跳,而优化后仅 6 跳就能完成连通。这是由于,这些厂商拥有自有的路径最优算法,通过智能路由就近接入,即使在异国/地网络环境较差的情况下,仍然能够及时切换到更好的线路上去。比如融云拥有全球优化加速网络,实时音视频通话可做到全球端到端延时小于 400ms,最低延时 66ms,保障端到端之间延迟无感知的实时互动。

在场景化能力上,实际上相比 IM,实时音视频更加通道化,在各个场景中复用的程度也相对较高,能力也更基础。优秀的 PaaS 厂商会按场景提供不同的 Demo,音视频技术的升级也针对解决更多的应用场景去优化,便于开发者拿来即用,这种方式对入门级的开发者都十分友好。各种 API 接口相对独立,开发者只需关注和使用所需要的 SDK,就可以实现想要的场景,大大降低集成开发的难度。

四、开发者服务足够完善

在一些社区中,我们常常会看到一些技术文档下,开发者提出问题而没有回复。开发者为提高开发效率,越来越倾向于自助完成工作,因此,开发文档是否易懂,Demo 是否易用,都显得十分重要。

另外,工单回复的速度,微信群、社区的值守和响应程度等都能反映 PaaS 厂商服务意识的强弱。通常来说,7×24 小时技术支持服务,1 小时工单快速回复、快速远程接入、快速恢复的故障应急响应机制,这些都是对开发者很完善的服务支持。

有些厂商还会提供特色的质量监控服务,比如融云“北极星”的质量问题排查平台,通过可视化图表,快速定位卡顿位置,实时统计丢包率,使开发者可以自助排查每一次音视频通话过程中的丢包率、网络带宽等通信技术参数。可以直接定位用户问题,提高排查效率,提升用户体验。

点击阅读原文

最新活动推荐:

融云年中大促活动海报.png


LiveVideoStackCon 深圳站:融云解析 WebRTC 低延迟直播技术

WebRTC融云那些事 发表了文章 • 0 个评论 • 242 次浏览 • 2020-06-16 18:36 • 来自相关话题

“基于 WebRTC 的低延迟直播将会是未来直播行业的主流解决方案!”这是融云联合创始人兼CTO 杨攀在 8 月 LiveVideoStackCon 2019 音视频技术大会北京站上对于未来行业趋势的判断。仅仅 4 个月之后,当大会首次落户有“中国硅谷”之称的... ...查看全部

“基于 WebRTC 的低延迟直播将会是未来直播行业的主流解决方案!”这是融云联合创始人兼CTO 杨攀在 8 月 LiveVideoStackCon 2019 音视频技术大会北京站上对于未来行业趋势的判断。仅仅 4 个月之后,当大会首次落户有“中国硅谷”之称的深圳时,融云的另一位技术专家,首席架构师李淼就“基于 WebRTC 的低延迟直播方案”进行了深入的技术分享。

12 月 13-14 日,LiveVideoStackCon 音视频技术大会在深圳举办,大会聚焦音视频、图像、AI 等技术的最新探索与应用实践,覆盖社交、游戏、直播、智能设备等行业领域,面向开发者分享技术创新与最佳实践。本次大会,聚集了数十名海内外技术专家和上千名开发者围绕前沿技术发展进行探讨。


融云首席架构师李淼
随着我国 5G 正式走向商用,直播行业在获得更多发展机遇的同时,也对直播技术提出了新的挑战。传统直播解决方案如果无法解决技术层面导致的延时问题,那么这一弊病将在 5G 的高速网络环境下被无限放大,这也进一步促使了低延迟音视频直播技术方案的演化。对此,李淼结合 WebRTC 的低延迟特性,在现场展示了融云 WebRTC 直播场景的构建全过程及服务架构设计,并向开发者们分享了技术实践细节,希望通过新技术的应用来解决视频直播的延时问题。

为什么要选用 WebRTC 来做直播?李淼表示,相较于传统的直播解决方案,WebRTC 拥有着不可比拟的三大优势。首先是低延时,让直播用户可以享受低延时的观看体验。目前直播行业中绝大多数产品是基于 RTMP、HLS、HDL 方式构建的,即使在不考虑网络链路的情况下,也会产生秒级的延迟,而 WebRTC 则天生具备低延迟的优势,使用 WebRTC 直播可有效将延迟降低至 200ms 以下。

其次是流量消耗小。基于 UDP 传输的 WebRTC 相比基于 TCP 传输的 RTMP 等协议,由于 UDP 协议内容较 TCP 小,且数据包是基于 NACK 进行传输等特点,对于流量的使用也有明显的降低。对于开发者和直播企业而言,流量消耗大幅削减,成本也因此可以得到有效的控制。

而最重要的优势在于 WebRTC 技术方案可以使主播端与观众端保持一致。当主播端使用  WebRTC 进行推流时,主播端与观众端保持一致,可以减少开发的编码量,对于团队人员的占用和后期对于代码的维护,都能保证最低的资源消耗。

在 LiveVideoStackCon 现场,李淼向开发者讲解了如何通过 WebRTC 完成直播场景构建的全过程,并对于 WebRTC 直播的技术细节一一进行了详细解读。李淼表示,使用 WebRTC 直播方案,MCU 服务器的设计至关重要。一方面 MCU 可以按需进行编解码,另一方面需要以房间号进行聚合,记录每台MCU的状态并按最小资源分配新房间,通过这种设计来减少 WebRTC 直播方案的资源消耗。


WebRTC 直播发布订阅流程
当然,对于很多开发者而言,实际的生产环境中仍面临着如何做到秒开视频、降低 MCU 带宽压力以及避免流量风暴等难题,李淼从 GOP 缓存结构和 GOP 控制策略两个层面进行了分析。以解决首帧卡顿延迟为例,直播数据在客户端与 Media Sever 进行交互之后,通常会对 SPS 和 I 帧进行正常下发,但是在随后的 P 帧或 B 帧的下发阶段,融云会采用 1.2 倍速下发的方式进行,直至所有数据包与 MCU 端推包进程同步,这就将直播延迟降至了最低。

此外,李淼还指出,客户端的设计必须考虑就近接入,且支持多链路选择,数据中心间同源音视频只有一路级联;同时还可以利用 IaaS 层的能力,进行中心间级联链路的优化。遵循这些直播网络设计原则都可以有效地降低直播延迟。

在分享的最后,李淼表示在 5G 时代,直播、短视频等内容传播形态将迎来新一轮技术升级,用户体验将成为行业洗牌的关键,此次将 WebRTC 低延迟直播的设计理念和技术要点与开发者和行业人士们一同分享,希望能够给业界带来一些启发和思考。作为互联网通信云行业的技术领导者,融云也将持续优化实时音视频技术和场景化解决方案,助力音视频直播行业在 5G 时代的创新发展。

融云助力嘉和海森 以通信云技术服务在线医疗“战疫”到底

科技创新融云那些事 发表了文章 • 0 个评论 • 52 次浏览 • 2020-06-16 18:30 • 来自相关话题

这些天,新型冠状病毒肺炎疫情一直牵动着全国人民的心,与疫情相关的健康咨询需求也明显呈现激增趋势。然而,扎堆去发热门诊咨询问诊,在增加线下门诊压力的同时也极有可能会引发交叉感染。为平衡医疗资源,疏导人民群众进行针对性就医,提升问诊效率,安全便捷的线上咨询成为近期... ...查看全部

这些天,新型冠状病毒肺炎疫情一直牵动着全国人民的心,与疫情相关的健康咨询需求也明显呈现激增趋势。然而,扎堆去发热门诊咨询问诊,在增加线下门诊压力的同时也极有可能会引发交叉感染。为平衡医疗资源,疏导人民群众进行针对性就医,提升问诊效率,安全便捷的线上咨询成为近期就医形式的首选。

在这个全民抗疫的时刻,医疗软件行业知名企业嘉和海森与互联网通信云服务商融云联合多家医疗机构开展了网上免费健康咨询服务,包括北京朝阳医院、通辽市医院等全国各地的众多医疗机构纷纷通过嘉和海森互联网医疗软件开展网上咨询。所有在线咨询的患者,可通过文字、图片、音频和视频进行网络咨询,与医生进行实时互动,在线获取医生的健康指导,实现足不出户在线问医。


融云助力在线医疗App
以朝阳医院上线的朝阳健康云APP为例。在当患者进行健康咨询时,通常问的都是一些偏基础性的问题,医患之间可以通过图文、语音消息的方式进行互动。而在网络问诊中,考虑到需要对患者进行更详尽的检查,医患之间需要通过音频+视频的形式进行实时互动,同时通过图片+文字进行补充沟通。除了医患之间的在线问诊,App还可以让身处不同地区的医疗工作者,能够在同一群组中通过图文+语音的形式远程对患者的病情进行实时讨论,合理地平衡和调用各地医疗资源。


医生通过音视频在线问诊
毋庸置疑,在线问诊最需要的就是稳定可靠的互联网通信能力。无论是医疗行业的高精专属性还是考虑到病患问诊时紧张心理,医疗类App对于问诊时音视频画面和声音的稳定流畅性、图文交互的即时性都有着极高的要求。据了解,在嘉和海森医疗App中,所有医生与问诊者之间的图文、语音、视频的交互,都是通过融云互联网通信云实现的。

作为一家以技术立命的互联网科技公司,融云致力于为开发者和企业提供 IM即时通讯和实时音视频通信云服务。融云提供的 PaaS 层服务,可以通过 SDK 的形式集成到应用中,开发者可以根据自身业务的需要调用不同功能,自由组合下载。同时融云还针对在线医疗等不同行业属性,针对性地推出场景化解决方案,让开发者拿来即用,降低集成难度和开发时间。

在医疗资源紧张的当下,融云坚信“科技向善”,以安全稳定的即时通讯和实时音视频技术驰援互联网医疗。“足不出户,网络问医”这一模式不仅能有效分流患者,缓解门诊压力,同时通过在线问诊,医师可通过症状初步判断其发热原因,减少非新型肺炎患者前往医院就诊的交叉感染机率。

在此,融云也承诺从即日起至疫情结束,针对在线医疗场景不收取任何费用,向各在线健康咨询平台、政府疫情防控平台、互联网医院等平台免费开放即时通讯和实时音视频通信云服务。此外,融云也面向企业、机构免费开放在线教育以及协同办公场景下的实时音视频服务。

目前,融云已经开通了 7*24 小时咨询热线 13161856839,欢迎有需求的政府部门、医疗机构、企业机关与我们联系,待沟通确认符合相关场景需求后,我们将以最快的速度进行技术对接,助力政府和医疗机构应对此次疫情,为这场“战疫”献出一份绵薄之力。

疫情期间远程协同办公成刚需 融云助力拓维打造视频会议系

科技创新融云那些事 发表了文章 • 0 个评论 • 41 次浏览 • 2020-06-16 18:29 • 来自相关话题

一场新型冠状病毒疫情的突袭,严重影响了社会各领域的正常运行,也使得春节后的企业正常复工成为难题。为了减少人员流动和聚集,防止交叉感染,大量企业响应国家的号召,选择通过远程协同办公的形式来维持企业正常运营。如果说此前远程协同办公只是企业办公的一项补充条件,那么在... ...查看全部

一场新型冠状病毒疫情的突袭,严重影响了社会各领域的正常运行,也使得春节后的企业正常复工成为难题。

为了减少人员流动和聚集,防止交叉感染,大量企业响应国家的号召,选择通过远程协同办公的形式来维持企业正常运营。如果说此前远程协同办公只是企业办公的一项补充条件,那么在疫情期间显然已经成为一种用户刚需。据媒体报道,仅在 2 月 3 日当天,全国就有上千万企业、近 2 亿人开启远程办公模式。

为了帮助更多企业实现稳定高效的远程协同办公,拓维信息积极响应国家号召,免费向企业提供1个月的远程视频会议服务,同时对于原有客户免费增加用户许可,保证企业全员远程办公的需求,直到疫情结束。在这段视频会议流量大规模爆发的时期,拓维无纸化会议系统稳定可靠地支持了众多企业远程会议同时进行,有效地为企业在疫情期间正常运行提供了保障。


拓维无纸化会议系统
据了解,拓维无纸化会议系统可满足远程资料共享、远程视频通话、会议资料安全等会议需求,且支持多个会议同时召开,单个会议场景可支持数百人同时在线。而拓维无纸化会议系统之所以在用户量激增的情况下仍能保持平台的持续稳定运行,与其底层通信能力服务商融云多年来在实时音视频领域的技术积累和稳定服务密不可分。

作为国内领先的互联网通信云服务商,融云致力于为开发者和企业提供 IM 即时通讯和实时音视频通信云服务。融云 CPO 任杰介绍称,融云在实时音视频领域拥有多年研发经验,各项技术指标保持市场领先水平,支持流畅稳定的一对一、多对多音视频通话、服务端录像,同时通过分层编码、大小流设计、带宽估计以及多服务器优化等方面来实现对更多路的支撑。目前融云在视频会议方面可以做到同时支持 14 路,纯音频则能做到同时支持 25 路,优于市场上一般软件的能力表现。此外融云还在不断强化技术支持能力,让开发者 30 分钟即可快速集成音视频能力,加速产品的上线效率。

同时,在这次疫情期间,视频会议系统很容易出现在线人数激增、海量消息并发的峰值情况,往往因难以准确预估流量,错误部署服务器导致系统崩溃,非常考验系统架构稳定性。融云通过“锦囊”服务可以在前期以最佳实践经验安排专家团队协助客户进行服务器部署,当遇大规模流量涌入的峰值期时,运维人员和技术人员通过实时监控,可以动态调整服务器部署,针对可能的并发问题量身定制相应的保障方案,确保在疫情期间企业协同办公的正常运行。

在此,融云也向社会承诺,从即日起至疫情结束,免费向企业、机构提供协同办公场景下的实时音视频服务,同时免费开放在线医疗场景下的 IM 及实时音视频服务和在线教育场景下的实时音视频服务。目前,融云已经开通了 7*24 小时咨询热线 13161856839,欢迎有需求的企业、机构与我们联系,待沟通确认符合相关场景需求后,我们将以最快的速度进行技术对接,帮助更多企业解决疫情期间的协同办公难题,实现办公方式的迭代升级,为坚决打赢这场疫情防控阻击战提供更多助力。

科技向善 共克时艰:融云在疫情期间免费开放三大场景通信云服务

科技创新融云那些事 发表了文章 • 0 个评论 • 62 次浏览 • 2020-06-16 18:27 • 来自相关话题

一场突如其来的疫情打乱了所有人的生活。然而,这个史上最没有存在感且令人压抑的春节也已经结束了。除了在抗疫一线奋战的医护人员外,我们大多数普通民众也纷纷迎来了返工和在线复学的日子。实际上,在这个特殊的春节假期,很多人一直处于家庭在线办公模式。而为了最大程度地规避... ...查看全部

一场突如其来的疫情打乱了所有人的生活。

然而,这个史上最没有存在感且令人压抑的春节也已经结束了。除了在抗疫一线奋战的医护人员外,我们大多数普通民众也纷纷迎来了返工和在线复学的日子。

实际上,在这个特殊的春节假期,很多人一直处于家庭在线办公模式。而为了最大程度地规避出行和返岗带来的交叉感染可能性,不少人的家庭在线办公模式可能还需要持续一段时日。同时,学生群体作为最脆弱和亟需保护的人群之一,多地政府早已下达文件通知各类学校开学时间不得早于3月份,使得在线教育亦成为眼下疫情期间的巨大市场刚需。此外,尤其值得注意的是,在我们的出行不那么方便的这段时间,人们对于在线医疗尤其是有关疫情的相关健康咨询也呈现骤增态势。

针对这样的市场需求,中国cPaaS领域的通信云领军企业融云近日宣布,从即日起至疫情结束,向企业、机构免费提供在线医疗场景下的IM及实时音视频服务,同时免费开放在线教育以及协同办公场景下的实时音视频服务。

“作为一家互联网通信云公司,我们决定免费开放这三大场景下的通信能力,是希望能够在国家遭遇这样的疫情期间,尽我们所能为社会提供一些帮助。通过我们技术人员的协助,最短2-3天时间,有这方面需求的单位和机构就能够快速用上我们的服务。”融云CPO任杰在近日接受C114采访时表示。

共同抗疫:在线医疗让我们更有安全感

随着感染者和就诊者数量的不断增多,疫区很多医院的发热门诊已不负重堪,对于大多数问诊者而言,专家建议可以在线问诊,通过线上IM及实时音视频交流,医生可以直观地了解和检查问诊者的真实情况,为问诊者提供医疗帮助,以减轻线下医院发热门诊的超负荷运转,同时也可以降低线下就医交叉感染的风险。

任杰介绍道,“通过我们的IM即时通讯和实时音视频能力,在线医疗可以帮助对端的医生跟患者之间实现线上沟通,从而帮助患者进行一些初步的诊断,使患者实现足不出户便可网络问医。”他指出,在线医疗除了可以实现医生对患者的初步诊断外,另一方面在疫情期间还能帮助患者渡过心理层面上的难关。


图:融云助力在线医疗 App
毋庸置疑,在线问诊最需要的就是稳定可靠的互联网通信能力。无论是医疗行业的高精专属性,还是考虑到病患问诊时的紧张心理,医疗类App对于问诊时音视频画面和声音的稳定流畅性、图文交互的即时性都有着极高的要求。而融云此前在在线医疗方面已经积累了不少经验。

例如,医疗软件行业知名企业嘉和海森已与融云联合多家医疗机构开展了网上免费健康咨询服务,包括北京朝阳医院、通辽市医院等全国众多医疗机构都已通过嘉和海森互联网医疗软件开展网上咨询。

共克时艰:协同办公提高社会运转效率

除了在线医疗外,在线协同办公亦是此次融云免费开放实时音视频服务的重要场景之一。与阿里钉钉、企业微信等SaaS层服务不同,融云更加专注于向不同规模企业提供协同办公的底层PaaS能力,然后企业可根据自身需求来实际进行部署和采用。

具体来说,融云提供的是IM即时通讯和实时音视频通信云服务等PaaS层服务,这些服务可以通过SDK的形式集成到应用中,开发者可以根据自身业务的需要调用不同功能,自由组合下载。同时融云还根据不同行业属性,针对性地推出了场景化解决方案,包括上述在线医疗和协同办公等诸多场景,让开发者可以拿来即用,大幅地降低了集成难度和开发时间。

“我们协同办公能力最主要的特点是,我们的服务一般都是企业采用私有部署模式,可以支持高达几十万人这样的超大企业规模,这是其他办公软件所不具备的。其他软件往往仅支持几千到上万人的规模上限,而我们达到几十万量级上,依然可以稳定运行。”任杰强调到。

他谈到,融云的协同办公能力中组件非常完整,包括企业通讯录、视频会议、电子白板、屏幕共享以及企业隐私权限的控制,同时包括网盘、文件、存储、传输等相关的非常完整的功能。融云的合作伙伴可以直接调用这些能力来做私有化部署产品或者SaaS产品。

在任杰看来,疫情期间,在线协同办公是保持社会机器逐步恢复正常运转的有效手段之一,对于减弱疫情对整个社会经济的冲击影响非常重要。

共渡疫情 :在线教育让学生停课不停学

与2月开始陆续复工的企业不同,全国各地几乎都已宣布各类学校需在3月以后才能开学。由此也使得不少老师和学生开始了“网课”生涯。这也正是融云此次在疫情期间免费开放能力的另一重要场景。

与上述在线医疗和协同办公场景一样,融云在在线教育方面主要提供的也是底层IM+实时音视频能力,但与现在不少学生使用的企业微信等非标准在线教育软件不同,融云除了提供基础的通信能力外,还可以实现整个授课过程中的控场能力,老师作为一个主持人身份可以对麦克风等权限进行管理,从而有效防止课堂秩序的混乱。


图:融云在线教育服务场景
同时,任杰向我们介绍,融云的在线教育服务在提供屏幕共享和电子白板等标准功能的同时,还支持将外部的音视频等文件导入进行播放,这使老师不仅可以轻松实现PPT共享和白板讲义等基础教学操作,还可以进行更多的外部资源分享和延伸。

事实上,尽管融云提供的是PaaS层服务,其本身并不涉及SaaS层软件的直接提供。但眼下有需求的单位和企业若想快速用上服务,可以直接将融云提供的不同场景的Demo作为源码来进行改写,然后与自身业务进行对接整合,从而实现服务快速上线。

例如,融云在办公场景中的产品名为安信,它与企业微信和钉钉类似,核心用的是融云的底层能力;而在教育场景中,融云也有一个名为SealClass的Demo——这是一个小班课场景,里面有各种基础功能和控制功能。

科技向善:最快2-3天让所需单位用上服务

在采访中,任杰对于融云在疫情期间应对各种场景下的高并发流量表现得十分有信心。而他的底气则源于该公司在IM领域的长久积累,从2014年融云创立至今,该公司通过良好的基础架构设计和普惠千行百业的发展理念,早已具备亿级并发处理能力。

“例如,IM在企业协同办公领域最重要的核心就是通讯录,我们针对几十万人的企业通讯录做了专门的优化,包括围绕通讯录的拉取方式、加载方式、组织方式和权限管理等,我们都做了海量并发的一系列的优化。这是其他很多企业办公软件所不具备的。”任杰说到。“在音视频方面,我们在支持多路方面也有很多经验和技巧,比如通过分层编码、大小流设计来实现对更多路的支撑;当然还有带宽估计、多服务器等方面的优化。”他表示,目前融云在视频会议方面可以做到同时支持14路左右,纯音频则能做到同时支持22-25路,优于市场上一般软件的能力表现。

任杰表示,在线医疗、在线教育和协同办公这三类企业,眼下只要提供相关企业证明,就可以使用融云的免费服务。“我们面对在线医疗的所有服务都是免费的——即IM和实时音视频两大产品线全部都是免费的,而在线办公和在线教育是实时音视频产品全部免费,因为这些场景主要用到的也是音视频能力。”他详细介绍道。

目前,针对这些企业,融云专门开通了一个绿色通道。“融云会在第一时间去处理这些申请,之后会有专门的服务支撑人员去协助快速地完成集成。在疫情期间,最快我们可以做到将此前需要7-10天的部署上线时间缩短到2-3天,当然,这也要取决于对方的时间和实际需求情况。”

科技向善,此次疫情期间,涌现出许许多多像融云这样无偿贡献自身服务和能力的企业。一个企业的力量可能比较微弱,但我们相信,通过这一股股善意的汇聚和支撑,这一次的全民“战疫”一定会更快取得胜利,我们的社会也将更快恢复正常运转。

期待春暖花开到来的那一天。

疫情之下单日消息量破千亿 融云以通信云技术助力全行业战疫

科技创新融云那些事 发表了文章 • 0 个评论 • 45 次浏览 • 2020-06-16 18:25 • 来自相关话题

通过协同办公软件实现远程视频会议、通过在线教育平台让学生“停课不停学”、进入电商App直播间与主播互动并购买各类商品,疫情之下的我们无论是主动拥抱还是被动接受,曾经所构想的云上生活都已经在疫情期间成为了现实。 根据 Questmobile 最新公布的数据显示,... ...查看全部

通过协同办公软件实现远程视频会议、通过在线教育平台让学生“停课不停学”、进入电商App直播间与主播互动并购买各类商品,疫情之下的我们无论是主动拥抱还是被动接受,曾经所构想的云上生活都已经在疫情期间成为了现实。


根据 Questmobile 最新公布的数据显示,2020 年春节假期过后,日均活跃用户增量 Top10的行业中,办公和教育类占据了半壁江山,视频、社交和电商也成功入围。

远程办公、在线教育等行业的井喷也引发了互联网通信云业务量的急剧增长。各类 SaaS 通信产品正在全面占据我们的工作生活,PaaS 云服务商也在持续地为各行业的 App 们提供底层通信能力。作为互联网通信云行业的领航企业,融云 IM即时通讯和实时音视频云服务在疫情期间正在呈现出几何倍数的增长态势。

疫情期间,融云平台单日消息量破千亿

据融云平台统计数据显示,2019 年依托融云通信云平台实现通信能力的 App 超过 30 万款,日均消息量达 150 亿条。而进入 2020 年后,受疫情影响大部分交流均通过网络远程进行,日均消息量明显激增,每日的消息量相较于 2019 年提升了 3 倍以上,单日峰值消息量更是突破千亿条。

与此同时,视频会议、直播课堂等也带动了融云平台上实时音视频流量的倍数增长,2020年 2 月,融云平台实时音视频单月使用分钟数较 2019 年平均值增长了 4 倍以上。


融云通信云服务在教育、医疗、协同办公中的应用
根据行业分析来看,最典型的就是这次疫情期间涌现出的线上“四大天王”:在线医疗、在线教育、协同办公以及线上泛娱乐行业,这些客户占据了融云消息分发量的 7 成以上。在线教育和协同办公在春节假期结束后便进入了消息的爆发期,日均消息量增长6倍,而在线医疗在经历了疫情初期的爆发后开始趋于平缓,但消息量仍实现了翻倍增长。至于社交、直播等泛娱乐行业,无论是活跃人数还是日消息量均持续保持高发态势。

与此同时,面临着复工难题的线下行业也在寻求新的发展机遇,在线视频招聘、VR看房、直播卖车等等一系列线上服务在疫情之下成为了新的流行趋势。在高端房地产服务平台丽兹行上,通过VR直播看房的形式,让客户无需亲临实地也能体验房间的面宽和进深,同时经纪人可以在直播间里与客户即时交流,针对性地解答客户问题,让客户更好地掌握房子的各项细节;在北京某4S店内,销售们借助直播平台,摇身一变成为了汽车主播,对着直播镜头介绍不同车型和相关配置,而在屏幕的另一端,数千名同时在线的网友提出了一个个促销优惠、车辆保养、直播抽奖等问题与其互动。


通信云服务实现VR看房实时互动
上述的这些场景正不断地在网络上一次次上演,每一套房屋的成交、每一辆汽车的售卖、每一次人才的成功招聘……这都离不开互联网通信云为其构建的交流平台。疫情之下,正在有越来越多的行业企业借助融云互联网通信云平台稳定可靠的服务,来拓展新机遇。

技术致胜,稳定支撑海量消息的秘钥

一切皆远程,一切在云上,巨大流量带来的不仅是机会更是挑战。

对于很多企业机构而言,突然到来的大规模、高并发流量把风口变成了风暴,微博热搜时常被软件崩溃占据,话题下有许多网友诉说着平台崩溃对办公、学习带来的不便,保证平台稳定的重要性已经不言而喻。

作为国内领先的互联网通信云服务商,融云为了更好地应对高并发压力,通过构建数据存取模型、优化缓存策略以及采用异步化请求处理等方式,不断提升平台的承载能力,并针对群聊、聊天室等不同场景进行具体分析和应对,通过最佳实践方案来解决高并发问题。

在群聊场景中,融云在系统中使用消息分发控制策略,在群消息分发中引进快、中、慢三个队列,通过消息直推与通知拉取相结合的方式,进行快速处理,同时融云还通过“引用分发”机制来降低消息缓存的存储,可极大地减轻系统承载压力。

而针对于直播聊天室场景的高并发消息服务请求,融云部署了环形队列的内存缓存,滚动保存最近的50条消息。在终端完全改用通知拉取的方式,用户收到通知后,可从服务端的缓存中批量获取消息,这极大的提高了消息下发效率,提升了聊天室系统的吞吐量。同时融云根据多年服务客户的经验以及自身的技术模型,制定了一套按消息类型进行消息处理机制。根据消息属性和优先级进行叠加或抛弃,确保在消息并发量极大的情况下,能起到很好的限流左右,保证用户端可以享受流畅的直播互动体验。

在实时音视频通信云服务方面,融云支持流畅稳定的一对一、多对多音视频通话、服务端录像,同时通过分层编码、大小流设计、带宽估计以及多服务器优化等方面来实现对更多路的支撑。同时,通过不断地技术更迭,融云音频抗丢包可达到 80%,视频可对抗 40% 丢包,保障音视频的高流畅性。

此外,融云技术服务团队也梳理了技术系统可能存在的风险,以防在流量爆发性增长时确保不出故障,除了采用链路切换、数据中心灾备等常规手段外,融云也做好了故障迁移工作,在出现问题的情况下可以将之前的业务全部迁移,确保在客户业务即使面临大规模的流量冲击依然能够正常运行。

结语:

疫情之下,众多行业从火热的旺季突然冰封至零度以下,如何在疫情期间寻找新的发展机遇,企业自救的同时更需要全社会的帮助。作为一家有社会责任感的企业,融云坚信科技向善,愿以互联网通信云服务助这些行业一臂之力,目前融云已开通了 7*24 小时咨询热线 13161856839,欢迎有需求的企业、机构与我们联系。融云将竭尽全力来帮助企业快速构建通信能力,助力复工复产,打赢这场疫情防控阻击战。

LiveVideoStackCon 深圳站:融云解析 WebRTC 低延迟直播技术

WebRTC融云那些事 发表了文章 • 0 个评论 • 242 次浏览 • 2020-06-16 18:36 • 来自相关话题

“基于 WebRTC 的低延迟直播将会是未来直播行业的主流解决方案!”这是融云联合创始人兼CTO 杨攀在 8 月 LiveVideoStackCon 2019 音视频技术大会北京站上对于未来行业趋势的判断。仅仅 4 个月之后,当大会首次落户有“中国硅谷”之称的... ...查看全部

“基于 WebRTC 的低延迟直播将会是未来直播行业的主流解决方案!”这是融云联合创始人兼CTO 杨攀在 8 月 LiveVideoStackCon 2019 音视频技术大会北京站上对于未来行业趋势的判断。仅仅 4 个月之后,当大会首次落户有“中国硅谷”之称的深圳时,融云的另一位技术专家,首席架构师李淼就“基于 WebRTC 的低延迟直播方案”进行了深入的技术分享。

12 月 13-14 日,LiveVideoStackCon 音视频技术大会在深圳举办,大会聚焦音视频、图像、AI 等技术的最新探索与应用实践,覆盖社交、游戏、直播、智能设备等行业领域,面向开发者分享技术创新与最佳实践。本次大会,聚集了数十名海内外技术专家和上千名开发者围绕前沿技术发展进行探讨。


融云首席架构师李淼
随着我国 5G 正式走向商用,直播行业在获得更多发展机遇的同时,也对直播技术提出了新的挑战。传统直播解决方案如果无法解决技术层面导致的延时问题,那么这一弊病将在 5G 的高速网络环境下被无限放大,这也进一步促使了低延迟音视频直播技术方案的演化。对此,李淼结合 WebRTC 的低延迟特性,在现场展示了融云 WebRTC 直播场景的构建全过程及服务架构设计,并向开发者们分享了技术实践细节,希望通过新技术的应用来解决视频直播的延时问题。

为什么要选用 WebRTC 来做直播?李淼表示,相较于传统的直播解决方案,WebRTC 拥有着不可比拟的三大优势。首先是低延时,让直播用户可以享受低延时的观看体验。目前直播行业中绝大多数产品是基于 RTMP、HLS、HDL 方式构建的,即使在不考虑网络链路的情况下,也会产生秒级的延迟,而 WebRTC 则天生具备低延迟的优势,使用 WebRTC 直播可有效将延迟降低至 200ms 以下。

其次是流量消耗小。基于 UDP 传输的 WebRTC 相比基于 TCP 传输的 RTMP 等协议,由于 UDP 协议内容较 TCP 小,且数据包是基于 NACK 进行传输等特点,对于流量的使用也有明显的降低。对于开发者和直播企业而言,流量消耗大幅削减,成本也因此可以得到有效的控制。

而最重要的优势在于 WebRTC 技术方案可以使主播端与观众端保持一致。当主播端使用  WebRTC 进行推流时,主播端与观众端保持一致,可以减少开发的编码量,对于团队人员的占用和后期对于代码的维护,都能保证最低的资源消耗。

在 LiveVideoStackCon 现场,李淼向开发者讲解了如何通过 WebRTC 完成直播场景构建的全过程,并对于 WebRTC 直播的技术细节一一进行了详细解读。李淼表示,使用 WebRTC 直播方案,MCU 服务器的设计至关重要。一方面 MCU 可以按需进行编解码,另一方面需要以房间号进行聚合,记录每台MCU的状态并按最小资源分配新房间,通过这种设计来减少 WebRTC 直播方案的资源消耗。


WebRTC 直播发布订阅流程
当然,对于很多开发者而言,实际的生产环境中仍面临着如何做到秒开视频、降低 MCU 带宽压力以及避免流量风暴等难题,李淼从 GOP 缓存结构和 GOP 控制策略两个层面进行了分析。以解决首帧卡顿延迟为例,直播数据在客户端与 Media Sever 进行交互之后,通常会对 SPS 和 I 帧进行正常下发,但是在随后的 P 帧或 B 帧的下发阶段,融云会采用 1.2 倍速下发的方式进行,直至所有数据包与 MCU 端推包进程同步,这就将直播延迟降至了最低。

此外,李淼还指出,客户端的设计必须考虑就近接入,且支持多链路选择,数据中心间同源音视频只有一路级联;同时还可以利用 IaaS 层的能力,进行中心间级联链路的优化。遵循这些直播网络设计原则都可以有效地降低直播延迟。

在分享的最后,李淼表示在 5G 时代,直播、短视频等内容传播形态将迎来新一轮技术升级,用户体验将成为行业洗牌的关键,此次将 WebRTC 低延迟直播的设计理念和技术要点与开发者和行业人士们一同分享,希望能够给业界带来一些启发和思考。作为互联网通信云行业的技术领导者,融云也将持续优化实时音视频技术和场景化解决方案,助力音视频直播行业在 5G 时代的创新发展。

iOS 基于实时音视频 SDK 实现屏幕共享功能——2

WebRTCadmin 发表了文章 • 0 个评论 • 371 次浏览 • 2020-12-03 18:26 • 来自相关话题

iOS 基于实时音视频 SDK 实现屏幕共享功能——1iOS 基于实时音视频 SDK 实现屏幕共享功能——2iOS 基于实时音视频 SDK 实现屏幕共享功能——3iOS 基于实时音视频 SDK 实现屏幕共享功能——4这里的核心思想是拿到屏幕共享的数据之后,先进... ...查看全部

微信截图_20201203182500.png


iOS 基于实时音视频 SDK 实现屏幕共享功能——1

iOS 基于实时音视频 SDK 实现屏幕共享功能——2

iOS 基于实时音视频 SDK 实现屏幕共享功能——3

iOS 基于实时音视频 SDK 实现屏幕共享功能——4



这里的核心思想是拿到屏幕共享的数据之后,先进行压缩,当压缩完成后会通过回调上报给当前类。既而通过 clientSend 方法,发给主 App。发给主 App 的数据中自定义了一个头部,头部添加了一个前缀和一个每次发送字节的长度,当接收端收到数据包后解析即可。

- (void)clientSend:(NSData *)data {
    //data length
    NSUInteger dataLength = data.length;
    // data header struct
    DataHeader dataH;
    memset((void *)&dataH, 0, sizeof(dataH));
    // pre
    PreHeader preH;
    memset((void *)&preH, 0, sizeof(preH));
    preH.pre[0] = '&';
    preH.dataLength = dataLength;
    dataH.preH = preH;
    // buffer
    int headerlength = sizeof(dataH);
    int totalLength = dataLength + headerlength;
    // srcbuffer
    Byte *src = (Byte *)[data bytes];
    // send buffer
    char *buffer = (char *)malloc(totalLength * sizeof(char));
    memcpy(buffer, &dataH, headerlength);
    memcpy(buffer + headerlength, src, dataLength);
    // to send
    [self sendBytes:buffer length:totalLength];
    free(buffer);
}

1.4 接收屏幕共享数据

//
//  RongRTCServerSocket.m
//  SealRTC
//
//  Created by Sun on 2020/5/7.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "RongRTCServerSocket.h"
#import <arpa/inet.h>
#import <netdb.h>
#import <sys/types.h>
#import <sys/socket.h>
#import <ifaddrs.h>
#import <UIKit/UIKit.h>
#import "RongRTCThread.h"
#import "RongRTCSocketHeader.h"
#import "RongRTCVideoDecoder.h"
@interface RongRTCServerSocket() <RongRTCCodecProtocol>
{
    pthread_mutex_t lock;
    int _frameTime;
    CMTime _lastPresentationTime;
    Float64 _currentMediaTime;
    Float64 _currentVideoTime;
    dispatch_queue_t _frameQueue;
}
@property (nonatomic, assign) int acceptSocket;
/**
 data length
 */
@property (nonatomic, assign) NSUInteger dataLength;
/**
 timeData
 */
@property (nonatomic, strong) NSData *timeData;
/**
 decoder queue
 */
@property (nonatomic, strong) dispatch_queue_t decoderQueue;
/**
 decoder
 */
@property (nonatomic, strong) RongRTCVideoDecoder *decoder;
@end
@implementation RongRTCServerSocket
- (BOOL)createServerSocket {
    if ([self createSocket] == -1) {
        return NO;
    }
    [self setReceiveBuffer];
    [self setReceiveTimeout];
    BOOL isB = [self bind];
    BOOL isL = [self listen];
    if (isB && isL) {
        _decoderQueue = dispatch_queue_create("cn.rongcloud.decoderQueue", NULL);
        _frameTime = 0;
        [self createDecoder];
        [self receive];
        return YES;
    } else {
        return NO;
    }
}
- (void)createDecoder {
    self.decoder = [[RongRTCVideoDecoder alloc] init];
    self.decoder.delegate = self;
    RongRTCVideoEncoderSettings *settings = [[RongRTCVideoEncoderSettings alloc] init];
    settings.width = 720;
    settings.height = 1280;
    settings.startBitrate = 300;
    settings.maxFramerate = 30;
    settings.minBitrate = 1000;
    [self.decoder configWithSettings:settings onQueue:_decoderQueue];
}
- (void)receiveData {
    struct sockaddr_in rest;
    socklen_t rest_size = sizeof(struct sockaddr_in);
    self.acceptSocket = accept(self.socket, (struct sockaddr *) &rest, &rest_size);
    while (self.acceptSocket != -1) {
        DataHeader dataH;
        memset(&dataH, 0, sizeof(dataH));
        if (![self receiveData:(char *)&dataH length:sizeof(dataH)]) {
            continue;
        }
        PreHeader preH = dataH.preH;
        char pre = preH.pre[0];
        if (pre == '&') {
            // rongcloud socket
            NSUInteger dataLenght = preH.dataLength;
            char *buff = (char *)malloc(sizeof(char) * dataLenght);
            if ([self receiveData:(char *)buff length:dataLenght]) {
                NSData *data = [NSData dataWithBytes:buff length:dataLenght];
                [self.decoder decode:data];
                free(buff);
            }
        } else {
            NSLog(@"pre is not &");
            return;
        }
    }
}
- (BOOL)receiveData:(char *)data length:(NSUInteger)length {
    LOCK(lock);
    int receiveLength = 0;
    while (receiveLength < length) {
        ssize_t res = recv(self.acceptSocket, data, length - receiveLength, 0);
        if (res == -1 || res == 0) {
            UNLOCK(lock);
            NSLog(@"receive data error");
            break;
        }
        receiveLength += res;
        data += res;
    }
    UNLOCK(lock);
    return YES;
}
- (void)didGetDecodeBuffer:(CVPixelBufferRef)pixelBuffer {
    _frameTime += 1000;
    CMTime pts = CMTimeMake(_frameTime, 1000);
    CMSampleBufferRef sampleBuffer = [RongRTCBufferUtil sampleBufferFromPixbuffer:pixelBuffer time:pts];
    // Check to see if there is a problem with the decoded data. If the image appears, you are right.
    UIImage *image = [RongRTCBufferUtil imageFromBuffer:sampleBuffer];
    [self.delegate didProcessSampleBuffer:sampleBuffer];
    CFRelease(sampleBuffer);
}
- (void)close {
    int res = close(self.acceptSocket);
    self.acceptSocket = -1;
    NSLog(@"shut down server: %d", res);
    [super close];
}
- (void)dealloc {
    NSLog(@"dealoc server socket");
}
@end

主 App 通过 Socket 会持续收到数据包,再将数据包进行解码,将解码后的数据通过代理 didGetDecodeBuffer 代理方法回调给 App 层。App 层就可以通过融云 RongRTCLib 的发送自定义流方法将视频数据发送到对端。



iOS 基于实时音视频 SDK 实现屏幕共享功能——1

WebRTCadmin 发表了文章 • 0 个评论 • 381 次浏览 • 2020-12-03 18:21 • 来自相关话题

iOS 基于实时音视频 SDK 实现屏幕共享功能——1iOS 基于实时音视频 SDK 实现屏幕共享功能——2iOS 基于实时音视频 SDK 实现屏幕共享功能——3iOS 基于实时音视频 SDK 实现屏幕共享功能——4Replaykit 介绍在之前的 iOS 版... ...查看全部

微信截图_20201203181458.png

iOS 基于实时音视频 SDK 实现屏幕共享功能——1

iOS 基于实时音视频 SDK 实现屏幕共享功能——2

iOS 基于实时音视频 SDK 实现屏幕共享功能——3

iOS 基于实时音视频 SDK 实现屏幕共享功能——4

Replaykit 介绍

在之前的 iOS 版本中,iOS 开发者只能拿到编码后的数据,拿不到原始的 PCM 和 YUV,到 iOS 10 之后,开发者可以拿到原始数据,但是只能录制 App 内的内容,如果切到后台,将停止录制,直到 iOS 11,苹果对屏幕共享进行了升级并开放了权限,既可以拿到原始数据,又可以录制整个系统,以下我们重点来说 iOS 11 之后的屏幕共享功能。

系统屏幕共享

- (void)initMode_1 {
    self.systemBroadcastPickerView = [[RPSystemBroadcastPickerView alloc] initWithFrame:CGRectMake(0, 64, ScreenWidth, 80)];
    self.systemBroadcastPickerView.preferredExtension = @"cn.rongcloud.replaytest.Recoder";
    self.systemBroadcastPickerView.backgroundColor = [UIColor colorWithRed:53.0/255.0 green:129.0/255.0 blue:242.0/255.0 alpha:1.0];
    self.systemBroadcastPickerView.showsMicrophoneButton = NO;
    [self.view addSubview:self.systemBroadcastPickerView];
}

在 iOS 11 创建一个 Extension 之后,调用上面的代码就可以开启屏幕共享了,然后系统会为我们生成一个 SampleHandler 的类,在这个方法中,苹果会根据 RPSampleBufferType 上报不同类型的数据。

- (void)processSampleBuffer:(CMSampleBufferRef)sampleBuffer withType:(RPSampleBufferType)sampleBufferType

那怎么通过融云的 RongRTCLib 将屏幕共享数据发送出去呢?

1. 基于 Socket 的逼格玩法

1.1. Replaykit 框架启动和创建 Socket

//
//  ViewController.m
//  Socket_Replykit
//
//  Created by Sun on 2020/5/19.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "ViewController.h"
#import <ReplayKit/ReplayKit.h>
#import "RongRTCServerSocket.h"
@interface ViewController ()<RongRTCServerSocketProtocol>
@property (nonatomic, strong) RPSystemBroadcastPickerView *systemBroadcastPickerView;
/**
 server socket
 */
@property(nonatomic , strong)RongRTCServerSocket *serverSocket;
@end
@implementation ViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    self.view.backgroundColor = [UIColor whiteColor];
    // Do any additional setup after loading the view.
    [self.serverSocket createServerSocket];
    self.systemBroadcastPickerView = [[RPSystemBroadcastPickerView alloc] initWithFrame:CGRectMake(0, 64, [UIScreen mainScreen].bounds.size.width, 80)];
    self.systemBroadcastPickerView.preferredExtension = @"cn.rongcloud.sealrtc.RongRTCRP";
    self.systemBroadcastPickerView.backgroundColor = [UIColor colorWithRed:53.0/255.0 green:129.0/255.0 blue:242.0/255.0 alpha:1.0];
    self.systemBroadcastPickerView.showsMicrophoneButton = NO;
    [self.view addSubview:self.systemBroadcastPickerView];
}
- (RongRTCServerSocket *)serverSocket {
    if (!_serverSocket) {
        RongRTCServerSocket *socket = [[RongRTCServerSocket alloc] init];
        socket.delegate = self;
        _serverSocket = socket;
    }
    return _serverSocket;
}
- (void)didProcessSampleBuffer:(CMSampleBufferRef)sampleBuffer {
    // 这里拿到了最终的数据,比如最后可以使用融云的音视频SDK RTCLib 进行传输就可以了
}
@end

其中,包括了创建 Server Socket 的步骤,我们把主 App 当做 Server,然后屏幕共享 Extension 当做 Client ,通过 Socket 向我们的主 APP 发送数据。

在 Extension 里面,我们拿到 ReplayKit 框架上报的屏幕视频数据后:

//
//  SampleHandler.m
//  SocketReply
//
//  Created by Sun on 2020/5/19.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "SampleHandler.h"
#import "RongRTCClientSocket.h"
@interface SampleHandler()
/**
 Client Socket
 */
@property (nonatomic, strong) RongRTCClientSocket *clientSocket;
@end
@implementation SampleHandler
- (void)broadcastStartedWithSetupInf(NSDictionary<NSString *,NSObject *> *)setupInfo {
    // User has requested to start the broadcast. Setup info from the UI extension can be supplied but optional.
    self.clientSocket = [[RongRTCClientSocket alloc] init];
    [self.clientSocket createCliectSocket];
}
- (void)processSampleBuffer:(CMSampleBufferRef)sampleBuffer withType:(RPSampleBufferType)sampleBufferType {
    switch (sampleBufferType) {
        case RPSampleBufferTypeVide
            // Handle video sample buffer
            [self sendData:sampleBuffer];
            break;
        case RPSampleBufferTypeAudioApp:
            // Handle audio sample buffer for app audio
            break;
        case RPSampleBufferTypeAudioMic:
            // Handle audio sample buffer for mic audio
            break;
        default:
            break;
    }
}
- (void)sendData:(CMSampleBufferRef)sampleBuffer {
    [self.clientSocket encodeBuffer:sampleBuffer];
}
@end

可见 ,这里我们创建了一个 Client Socket,然后拿到屏幕共享的视频 sampleBuffer 之后,通过 Socket 发给我们的主 App,这就是屏幕共享的流程。

1.2 Local Socket 的使用

//
//  RongRTCSocket.m
//  SealRTC
//
//  Created by Sun on 2020/5/7.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "RongRTCSocket.h"
#import <arpa/inet.h>
#import <netdb.h>
#import <sys/types.h>
#import <sys/socket.h>
#import <ifaddrs.h>
#import "RongRTCThread.h"
@interface RongRTCSocket()
/**
 receive thread
 */
@property (nonatomic, strong) RongRTCThread *receiveThread;
@end
@implementation RongRTCSocket
- (int)createSocket {
    int socket = socket(AF_INET, SOCK_STREAM, 0);
    self.socket = socket;
    if (self.socket == -1) {
        close(self.socket);
        NSLog(@"socket error : %d", self.socket);
    }
    self.receiveThread = [[RongRTCThread alloc] init];
    [self.receiveThread run];
    return socket;
}
- (void)setSendBuffer {
    int optVal = 1024 * 1024 * 2;
    int optLen = sizeof(int);
    int res = setsockopt(self.socket, SOL_SOCKET, SO_SNDBUF, (char *)&optVal,optLen);
    NSLog(@"set send buffer:%d", res);
}
- (void)setReceiveBuffer {
    int optVal = 1024 * 1024 * 2;
    int optLen = sizeof(int);
    int res = setsockopt(self.socket, SOL_SOCKET, SO_RCVBUF, (char*)&optVal,optLen );
    NSLog(@"set send buffer:%d",res);
}
- (void)setSendingTimeout {
    struct timeval timeout = {10,0};
    int res = setsockopt(self.socket, SOL_SOCKET, SO_SNDTIMEO, (char *)&timeout, sizeof(int));
    NSLog(@"set send timeout:%d", res);
}
- (void)setReceiveTimeout {
    struct timeval timeout = {10, 0};
    int  res = setsockopt(self.socket, SOL_SOCKET, SO_RCVTIMEO, (char *)&timeout, sizeof(int));
    NSLog(@"set send timeout:%d", res);
}
- (BOOL)connect {
    NSString *serverHost = [self ip];
    struct hostent *server = gethostbyname([serverHost UTF8String]);
    if (server == NULL) {
        close(self.socket);
        NSLog(@"get host error");
        return NO;
    }
    struct in_addr *remoteAddr = (struct in_addr *)server->h_addr_list[0];
    struct sockaddr_in addr;
    addr.sin_family = AF_INET;
    addr.sin_addr = *remoteAddr;
    addr.sin_port = htons(CONNECTPORT);
    int res = connect(self.socket, (struct sockaddr *) &addr, sizeof(addr));
    if (res == -1) {
        close(self.socket);
        NSLog(@"connect error");
        return NO;
    }
    NSLog(@"socket connect to server success");
    return YES;
}
- (BOOL)bind {
    struct sockaddr_in client;
    client.sin_family = AF_INET;
    NSString *ipStr = [self ip];
    if (ipStr.length <= 0) {
        return NO;
    }
    const char *ip = [ipStr cStringUsingEncoding:NSASCIIStringEncoding];
    client.sin_addr.s_addr = inet_addr(ip);
    client.sin_port = htons(CONNECTPORT);
    int bd = bind(self.socket, (struct sockaddr *) &client, sizeof(client));
    if (bd == -1) {
        close(self.socket);
        NSLog(@"bind error: %d", bd);
        return NO;
    }
    return YES;
}
- (BOOL)listen {
    int ls = listen(self.socket, 128);
    if (ls == -1) {
        close(self.socket);
        NSLog(@"listen error: %d", ls);
        return NO;
    }
     return YES;
}
- (void)receive {
    dispatch_async(dispatch_get_global_queue(0, 0), ^{
        [self receiveData];
    });
}
- (NSString *)ip {
    NSString *ip = nil;
    struct ifaddrs *addrs = NULL;
    struct ifaddrs *tmpAddrs = NULL;
    BOOL res = getifaddrs(&addrs);
    if (res == 0) {
        tmpAddrs = addrs;
        while (tmpAddrs != NULL) {
            if (tmpAddrs->ifa_addr->sa_family == AF_INET) {
                // Check if interface is en0 which is the wifi connection on the iPhone
                NSLog(@"%@", [NSString stringWithUTF8String:inet_ntoa(((struct sockaddr_in *)tmpAddrs->ifa_addr)->sin_addr)]);
                if ([[NSString stringWithUTF8String:tmpAddrs->ifa_name] isEqualToString:@"en0"]) {
                    // Get NSString from C String
                    ip = [NSString stringWithUTF8String:inet_ntoa(((struct sockaddr_in *)tmpAddrs->ifa_addr)->sin_addr)];
                }
            }
            tmpAddrs = tmpAddrs->ifa_next;
        }
    }
    // Free memory
    freeifaddrs(addrs);
    NSLog(@"%@",ip);
    return ip;
}
- (void)close {
    int res = close(self.socket);
    NSLog(@"shut down: %d", res);
}
- (void)receiveData {
}
- (void)dealloc {
    [self.receiveThread stop];
}

@end

首先创建了一个 Socket 的父类,然后用 Server Socket 和 Client Socket 分别继承类来实现链接、绑定等操作。可以看到有些数据可以设置,有些则不用,这里不是核心,核心是怎样收发数据。

1.3 发送屏幕共享数据

//
//  RongRTCClientSocket.m
//  SealRTC
//
//  Created by Sun on 2020/5/7.
//  Copyright © 2020 RongCloud. All rights reserved.
//
#import "RongRTCClientSocket.h"
#import <arpa/inet.h>
#import <netdb.h>
#import <sys/types.h>
#import <sys/socket.h>
#import <ifaddrs.h>
#import "RongRTCThread.h"
#import "RongRTCSocketHeader.h"
#import "RongRTCVideoEncoder.h"
@interface RongRTCClientSocket() <RongRTCCodecProtocol> {
    pthread_mutex_t lock;
}
/**
 video encoder
 */
@property (nonatomic, strong) RongRTCVideoEncoder *encoder;
/**
 encode queue
 */
@property (nonatomic, strong) dispatch_queue_t encodeQueue;
@end
@implementation RongRTCClientSocket
- (BOOL)createClientSocket {
    if ([self createSocket] == -1) {
        return NO;
    }
    BOOL isC = [self connect];
    [self setSendBuffer];
    [self setSendingTimeout];
    if (isC) {
        _encodeQueue = dispatch_queue_create("cn.rongcloud.encodequeue", NULL);
        [self createVideoEncoder];
        return YES;
    } else {
        return NO;
    }
}
- (void)createVideoEncoder {
    self.encoder = [[RongRTCVideoEncoder alloc] init];
    self.encoder.delegate = self;
    RongRTCVideoEncoderSettings *settings = [[RongRTCVideoEncoderSettings alloc] init];
    settings.width = 720;
    settings.height = 1280;
    settings.startBitrate = 300;
    settings.maxFramerate = 30;
    settings.minBitrate = 1000;
    [self.encoder configWithSettings:settings onQueue:_encodeQueue];
}
- (void)clientSend:(NSData *)data {
    //data length
    NSUInteger dataLength = data.length;
    // data header struct
    DataHeader dataH;
    memset((void *)&dataH, 0, sizeof(dataH));
    // pre
    PreHeader preH;
    memset((void *)&preH, 0, sizeof(preH));
    preH.pre[0] = '&';
    preH.dataLength = dataLength;
    dataH.preH = preH;
    // buffer
    int headerlength = sizeof(dataH);
    int totalLength = dataLength + headerlength;
    // srcbuffer
    Byte *src = (Byte *)[data bytes];
    // send buffer
    char *buffer = (char *)malloc(totalLength * sizeof(char));
    memcpy(buffer, &dataH, headerlength);
    memcpy(buffer + headerlength, src, dataLength);
    // tosend
    [self sendBytes:buffer length:totalLength];
    free(buffer);
}
- (void)encodeBuffer:(CMSampleBufferRef)sampleBuffer {
    [self.encoder encode:sampleBuffer];
}
- (void)sendBytes:(char *)bytes length:(int)length {
    LOCK(self->lock);
    int hasSendLength = 0;
    while (hasSendLength < length) {
        // connect socket success
        if (self.socket > 0) {
            // send
            int sendRes = send(self.socket, bytes, length - hasSendLength, 0);
            if (sendRes == -1 || sendRes == 0) {
                UNLOCK(self->lock);
                NSLog(@"send buffer error");
                [self close];
                break;
            }
            hasSendLength += sendRes;
            bytes += sendRes;
        } else {
            NSLog(@"client socket connect error");
            UNLOCK(self->lock);
        }
    }
    UNLOCK(self->lock); 
}
- (void)spsData:(NSData *)sps ppsData:(NSData *)pps {
    [self clientSend:sps];
    [self clientSend:pps];
}
- (void)naluData:(NSData *)naluData {
    [self clientSend:naluData];
}
- (void)deallo c{
    NSLog(@"dealoc cliect socket");
}
@end


30万+App都在用的服务商,有什么特别之处?

科技创新融云那些事 发表了文章 • 0 个评论 • 125 次浏览 • 2020-08-03 16:57 • 来自相关话题

两个月前,一款名为 Clubhouse 的 App 开始流行于美国 VC、名人圈层,并且一直热度不减。尽管它的用户只有几千人,但其估值却已超过 1 亿美元。Clubhouse 是一款语音社交软件,被誉为是“音频 Twitter”。打开 Clubhouse,选一... ...查看全部

两个月前,一款名为 Clubhouse 的 App 开始流行于美国 VC、名人圈层,并且一直热度不减。尽管它的用户只有几千人,但其估值却已超过 1 亿美元。

Clubhouse 是一款语音社交软件,被誉为是“音频 Twitter”。

讯飞1.webp.jpg

打开 Clubhouse,选一个房间进入,人们可以查看房间里都有哪些参与者,并可以听到他们的谈话,再决定是否继续听或直接加入群聊。

如果要说它最大的规则是什么,那就是:只用语音,没有文字

近年来,移动互联网飞速发展,语音功能已开始成为 App 的标配,各种属性的音频类 App 尤其是声音社交类 App 也在悄然壮大。

红杉中国发布的《创造未来——红杉 00 后泛娱乐消费研究报告》显示,社交性、潮流性和个性化是“00 后”用户最看重的三大产品特征。因此,比图片和文字有温度,比视频更含蓄的声音社交方式,开始在他们之中风靡。

而根据艾瑞咨询的数据,2019 年中国网络音频行业市场规模为 175.8 亿元,同比增长 55.1%,预计 2020 年中国网络音频行业市场规模达 272.4 亿元。越来越多的资本和资源看到了声音背后蕴藏的更多可能性。

讯飞2.png

随着 5G 网络的逐渐普及,网络速度变得更快,以音频、视频为主要交互方式的互联网产品或将大行其道。

今年年初的疫情期间,我们已经看到各种音视频软件在在线教育、在线办公中发挥着巨大的作用。但有一个不得不面对的事实是,它们都曾因短时期内使用人数过多而崩溃。

对于音视频类互联网产品来说,保证用户使用过程中不会出现卡顿、声音效果差等问题十分重要,这就需要技术上的强力支持与保证,在这一方面能够提供“实时音视频”技术的服务商做的相当专业。

目前,在我国从事“实时音视频”技术底层搭建的服务商主要分为两大阵营。其一,是只专注“实时音视频”技术的单一产业服务商;其二,是 IM 领域已经耕耘多年,现将 IM 即时通讯及实时音视频两大业务版块交融聚合的服务商。例如,已多年稳居 IM 市场占有率第一的融云。

讯飞3.webp.jpg

北京云中融信网络科技有限公司(简称融云),是一家安全、可靠的全球互联网通信云服务商,向开发者和企业提供即时通讯和实时音视频通信云服务。虽成立时间不长,但发展迅速,成立不久就获得了 1 亿元人民币 B 轮融资。

截止目前,已有中原地产、汽车之家、融创地产、丽兹行、寺库、哈啰出行、核桃编程、易车网、编程猫以及 Castbox、Opera 等超过 30 万款海内外 App 通过融云实现了全球化的互联网通信能力。

融云现已在科大讯飞旗下人工智能全产业链综合服务平台——讯飞 AI 服务市场入驻,来一起看看,它的哪些技术能让如此之多的 App “钟情”于它?

融云IM即时通讯

许多 85 后甚至 90 后的大学记忆中都有一款即时通讯工具,飞信。在那个短信 1 毛钱一条,流量 5 块钱只有 30M 的年代,飞信免流量、免费发短信的功能,很有吸引力。作为当初中国移动即时通讯的扛鼎之作,飞信注册用户最高时达到了 5 亿,高峰时拥有高达 9000 万的活跃用户,其技术水平自不必多说。

融云的技术团队源自飞信技术团队,在即时通讯领域有着丰富的经验和强大的核心技术实力。

融云即时通讯支持多聊天模式、多消息类型、自定义界面等功能,同时支持聊天记录漫游、消息回执与召回、消息内容全文搜索、消息内容审核等功能。用户可以根据自己的需求调用相关接口,大大节约在通信能力上的研发时间和成本。

讯飞7.png

基于融云私有通信协议,可以保障消息不丢不重不乱,支持无上限用户数的群组和聊天室互动,公有云平台 150 亿条日均消息量2218 亿条日消息量峰值。融云建立了全球多数据中心,服务覆盖全球所有国家及地区(共 233 个),实时监控全球网络,基于融云分布在全球的数据中心与节点建设,向客户提供链路接入方案,持续的海外链路优化让消息发送稳定可靠,畅通无阻。

讯飞8.webp.jpg

无论是私密社交、兴趣社交还是商业沟通、系统消息等场景,融云都可以轻松应对,它也是业内唯一承诺消息可靠性 100% 的厂商。

融云RTC实时音视频

为了适应移动互联网发展和市场需求,融云在即时通讯之外还发展了实时音视频业务。融云实时音视频主要包括音视频通话、低延迟直播、音视频会议、云端录制等功能。用户可以根据自己的需求调用相关接口,大大节约在通信能力上的研发时间。

讯飞9.png

融云实时音视频具备低延迟、低成本、高流畅、高品质、部署简单、扩展灵活等技术优势。在整体网络架构上,全球分布式架构的部署让扩容时间大幅缩短,能轻松应对海量流量的激增。弱网优化策略方面,增强了抗丢包及抗网络抖动能力,音频能对抗 80% 丢包,视频能对抗 40% 丢包,延时最低可达 66ms,以保证低成本输出高性能的实时音视频能力(可以提供最高 1080P 的高清画质和最高 48KHz 的音频采样率) 。经过海量客户业务验证,融云实时音视频业务在稳定性、连通性、并发/负载等方面服务可用性达到 99.9%

融云在疫情期间还免费开放了在线医疗、在线教育及协同办公场景的通信能力,并开发了 VR 看房等新的业务场景。

最新活动推荐:

 融云年中大促活动海报.png


芥末堆专访:线上教学交付能力背后,在线音视频通信技术成刚需

科技创新融云那些事 发表了文章 • 0 个评论 • 186 次浏览 • 2020-08-03 16:43 • 来自相关话题

2020 年过半,疫情加速在线教育发展已成事实。疫情防控常态化使得线下教育场景面临着长期挑战,线上教学交付能力俨然成为教培机构的标配。伴随着线下机构转型线上探索教育 OMO,线上教学背后的技术能力开始受到重视。相比线下场景天然的临场感和及时的互动性,线上化教学... ...查看全部

2020 年过半,疫情加速在线教育发展已成事实。疫情防控常态化使得线下教育场景面临着长期挑战,线上教学交付能力俨然成为教培机构的标配。

伴随着线下机构转型线上探索教育 OMO,线上教学背后的技术能力开始受到重视。相比线下场景天然的临场感和及时的互动性,线上化教学不是仅仅利用音视频工具就足够。线下场景中的信息传递是基于面对面的沟通,如何在线上场景“重现”甚至“超越”面对面沟通的信息传递方式是关键问题。

 芥末堆1_副本.jpg

无论教学形式或场景怎样变化,教育始终是效果为王。“全民网课”的时代,教学效果的保证离不开高质量的音视频信息传递、全方位的及时互动和多维度的数据分析。然而这些对于教培机构,尤其是以教学见长的线下机构,都并不熟悉。

全球通信云服务商融云 CPO 任杰表示:“在互联网时代,教育创业者应该聚焦自己的核心业务逻辑,而不是去关心通用型能力的实现。”

为此,融云专注于互联网云通信领域,为包括在线教育在内的互联网行业提供“IM 即时通讯+实时音视频+推送”的一体化解决方案,凭借技术积累实现安全、可靠、实时的即时通讯及音视频服务,满足各类教育场景的通用型和定制化的信息交互需求。

“IM 即时通讯+实时音视频+推送”,在线教育一体化解决方案

据任杰介绍,融云最初选择互联网云通信领域,就是看到互联网发展的趋势和通信需求的刚性。时至今日,伴随着移动互联网的发展,云通信已经成为标配能力。融云也从最初的“IM 即时通讯”业务,发展到“用一套 SDK,解决所有通信场景”,涵盖“IM 即时通讯+实时音视频+推送”的一体化解决方案。

任杰告诉芥末堆,融云整体的服务形式是以客户端 SDK 的方式体现,App 只要通过简单的几行代码就可以完成通信 SDK 集成,实现通信和社交能力。此外,融云还提供实时音视频相关功能和整体解决方案。

芥末堆2_副本.jpg 

去年 11 月 30 日,融云正式宣布已完成数亿元 C 轮融资

技术的发展背后是需求的演变。从图文时代到音视频时代,信息传播的媒介和方式都在发生着巨大变化。与之相应的是互联网企业对音视频通信技术的更高要求。任杰表示,如何打造一流的实时音视频服务,赋能开发者追赶音视频领域的技术红利,是融云始终关注的。

而作为互联网通信的主要应用场景之一,在线教育的内容以视频直播为主要形式。相比娱乐内容,教育内容的严肃性和互动性使得低延迟的高质量音视频传输成为刚需。任杰告诉芥末堆,以 PC 或平板为设备载体的在线教育对画质的要求,要远远高于移动端。

 芥末堆3_副本.jpg

如果将内容看作在线教育的产品核心,那么音视频质量可以看作在线教育的技术核心。相比其他内容行业,同样面对卡顿或延迟,在线教育用户的容忍度更低。任杰介绍,融云在今年 5 月份对融云实时音视频业务进行全面升级,针对开发者最关心的音视频通话质量,融云使用的是 WebRTC 技术,完全可以满足在线教育等场景中低延迟、强互动的需求。

据了解,在视频方面,融云目前能够提供最高 1080P 的分辨率,画面纤毫毕现,尤其适合特殊高清场景,如在线教育领域中的双师课堂场景的大屏直播。同时,融云还提供各种高中低分辨率供不同业务场景调用,实现画面和流量平衡,帧率最高支持 30FPS,可以匹配不同设备端的教学需求。

在音频方面,融云采用最高音频采样率 48KHz,可真实还原对端声音,高清音质。任杰介绍,融云目前可以提供高清音乐模式,针对乐器的高频音段和弱音音阶进行优化处理,高度还原音乐细节,带给用户更贴近线下场景的体验。在音频方面,融云完全可以满足素质教育领域的音乐培训的需求。

云通信能力之后,融云要延伸到更多在线教育场景

在沟通中,任杰始终强调融云在做的是底层技术能力的支持。但在介绍在线教育场景的应用时,芥末堆发现针对不同角色、不同班型、不同细分赛道的差异化需求,融云在技术上都有设计并满足。

提到融云通信云能力的特点,任杰总结到:性能稳定、全平台覆盖、全方位互动和全球部署。

 芥末堆4_副本.jpg

性能稳定是融云的核心优势。依托技术优势,融云可以为大型直播课程提供无用户上限和消息量限制的聊天室服务,亿级消息并发即时到达,互动稳定流畅、延迟低。任杰表示,在弱网优化策略上,融云的核心策略是能够迅速预估宽带,并采用降低码率来确保以声音与流畅优先的原则,保证用户最优体验。

在覆盖平台方面,融云实时音视频 SDK 可覆盖全平台,包括 iOS、Android、Web、Windows、macOS、Linux、Electron 等,并全面适配市场主流的各类终端设备,包括在智能手表、智能音箱、智能门禁等多种智能硬件设备中实现平台间通信,全面保障融云实时音视频在各类终端上的良好应用。

在全方位互动方面,任杰介绍,融云支持 1080P 高清视频,视频窗口放大缩小可切换不同分辨率;具备互动白板功能,支持上传常见办公文档,实时进行课堂演示;一对一、小班课、大班课、双师课等不同班型的实时直播、举手答疑和视频回看都能实现。他特意强调,为保障在线课程可 100% 回看,融云是采用两条线路双向录制的。

在全球部署方面,融云拥有覆盖全球的通信加速网络,全球多个数据中心,数千个加速点,触达全世界 233 个国家和地区,能够帮助教育企业实现全球范围内的高质量教学。

提到融云在在线教育领域的探索,任杰表示,教育的未来趋势一定是线上,但这离不开技术的发展和应用。融云后续将继续利用技术优势,持续在降低高质量音视频网络流量占用的方向上发力。

此外,将技术应用延伸到教育的各个场景也是融云的发力点之一。除了今年爆发的在线 K12 领域外,素质教育、在线考试等领域也亟待技术的重构。任杰以音乐教育为例,融云为管乐培训机构大雅乐盟做了针对性的音频通信改善,给出管乐培训的线上教育解决方案。而后续,钢琴、舞蹈等线上教学领域也是融云将会深化去探索的场景。

最新活动推荐:

融云年中大促活动海报.png

实时音视频选型 开发者应该避开哪些坑?

IM即时通讯融云那些事 发表了文章 • 0 个评论 • 141 次浏览 • 2020-07-24 15:19 • 来自相关话题

实时音视频技术的专业度和复杂度都很高,通过 PaaS 服务商来集成实时音视频,快速开发 App,是时下开发者的优先选择。所选 RTC 是否好用易用、契合所需场景,将直接影响项目开发进度和后期运维成本。开发者需要... ...查看全部

实时音视频技术的专业度和复杂度都很高,通过 PaaS 服务商来集成实时音视频,快速开发 App,是时下开发者的优先选择。所选 RTC 是否好用易用、契合所需场景,将直接影响项目开发进度和后期运维成本。

开发者需要了解实时音视频技术选型中要避开的坑点,以便提高开发集成效率。具体来说,以下四个方面要综合考虑。

一、实时音视频与 IM 能力不宜分散

几乎 100% 的实时音视频在线应用都有文字/语音消息、文件传输、图片显示等 IM 需求。

目前市场上 PaaS 服务商这两方面能力强弱不一:有的大厂虽然两方面能力都提供,但不能确保两种能力同样高质量;有的专业 RTC 厂商,只能提供 RTC 能力,IM 能力还得由第三方专业服务商提供。

这样,便迫使开发者在集成过程中不得不分别选择服务商。当实时音视频与 IM 质量不稳定时,需要逐一协调各个服务商,逐一排查问题,无形中增加了后期的运营成本。其实,IM 和音视频在很多场景下有耦合,建议开发者在选型一开始就要考虑具有 RTC+IM 双重高保障能力的通信云厂商,尽量“用一套 SDK,解决所有通信场景”。

任杰总2.png

对开发者来说两项功能同时开发,开发包相对比较小;如果前期只用到了 IM,没有用到 RTC,那么只需要学习 IM 方面的开发文档就可以了,一旦有了 RTC 需求,再去学习 RTC文档,开发者只需接入相关接口,快速与 IM 能力做对接和匹配,即可完成两类功能在 App 生命周期里的全覆盖。

除了开发上的易快速上手外,选择“IM+RTC+推送”整合的解决方案,开发者还可以享受一致的网络架构,提高传输的效率和质量,获得一致的服务保障。例如,融云近期升级了实时音视频能力,RTC的通信信令是复用 IM 信令通道,可以确保消息 100% 的连通率和到达率,使底层的通信优势发挥到最大。

二、延时、卡顿、抖动的质量问题要解决好

通过调研发现,用户最不能接受实时音视频的三个质量问题是延时、卡顿、抖动。

低延时要靠两个方面解决,一个是传输协议,一个是优化整体传输环节。实时音视频的主流传输协议有 RTMP 和 UDP 两种,一种支持 CDN 技术,一种支持 WebRTC 技术,相对来说,CDN 技术延时性在 3-5 秒,WebRTC 可以在几百毫秒以内,现在很多厂商可以同时支持这两种技术,分别适用于不同的场景。

整体传输环节中,采集/渲染、编解码/网络往返都会有一定的延时,有些是硬件的物理延迟,需要靠 5G 这样底层网络技术的提升,或者布更多的数据中心、边缘结点,便于就近接入;有些要针对实际场景,在具体形态上做一些权衡,比如在处理粒度上粗细的考虑,越细的粒度传输的数据包相对较大,延迟也会更高。

当音视频出现卡顿时,有一个视频流畅优先的原则。我们通过降低一些码率和帧率,即使画面模糊一点,也要让用户视觉上是流畅不卡顿的。这样在选型时候,要考虑几个方面:一个是优化低码率下的视频清晰度;二是要有带宽估算能力,当预判到这个带宽没法承受高清晰视频传输时,自动转化成低码率并通过优化算法,使低码率视频清晰度能媲美高清视频。

音视频弱网优势_副本.png


另外,数据包通常会以错误的顺序到达,从而产生抖动相关问题,或者直接丢失,造成音视频空白。谷歌一份资料显示,视频聊天应用 Duo 99% 的通话都有数据包丢失、过度抖动或网络延迟情况。20% 的通话丢失了超过 3% 的音频,10% 的通话丢包率超过 8%,也就是说每次通话都有很多音频需要替换。

处理上述问题,很多厂商会采用抗丢包及抗网络抖动能力的 NACK(丢包重传)、FEC(前向纠错)、自适应带宽调整(动态调整码)、接收端 Jitter Buffer(媒体流平稳)等各种机制,有些是组合使用,有些是单独使用,开发者在选型前一定要做到深入了解。

  • 拥有全球通信和场景化能力

    刚才谈到低延时、抗丢包的解决策略,有些是与网络接入路径长短直接相关的。比如中美两地的音视频连接,没有全球通信网络支持、数据中心和节点布局的厂商是提供不了服务的。开发者选型开发前,就要考虑到自己业务的所属范围。   

    选择全球化服务的云厂商,除了看数据中心和节点分布外,还要仔细考察全球网络布局的品质,简单说,有的厂商提供了全球网络优化能力,中美之间的音视频连接在未优化前要经过 100 多跳,而优化后仅 6 跳就能完成连通。这是由于,这些厂商拥有自有的路径最优算法,通过智能路由就近接入,即使在异国/地网络环境较差的情况下,仍然能够及时切换到更好的线路上去。比如融云拥有全球优化加速网络,实时音视频通话可做到全球端到端延时小于 400ms,最低延时 66ms,保障端到端之间延迟无感知的实时互动。

在场景化能力上,实际上相比 IM,实时音视频更加通道化,在各个场景中复用的程度也相对较高,能力也更基础。优秀的 PaaS 厂商会按场景提供不同的 Demo,音视频技术的升级也针对解决更多的应用场景去优化,便于开发者拿来即用,这种方式对入门级的开发者都十分友好。各种 API 接口相对独立,开发者只需关注和使用所需要的 SDK,就可以实现想要的场景,大大降低集成开发的难度。

四、开发者服务足够完善

在一些社区中,我们常常会看到一些技术文档下,开发者提出问题而没有回复。开发者为提高开发效率,越来越倾向于自助完成工作,因此,开发文档是否易懂,Demo 是否易用,都显得十分重要。

另外,工单回复的速度,微信群、社区的值守和响应程度等都能反映 PaaS 厂商服务意识的强弱。通常来说,7×24 小时技术支持服务,1 小时工单快速回复、快速远程接入、快速恢复的故障应急响应机制,这些都是对开发者很完善的服务支持。

有些厂商还会提供特色的质量监控服务,比如融云“北极星”的质量问题排查平台,通过可视化图表,快速定位卡顿位置,实时统计丢包率,使开发者可以自助排查每一次音视频通话过程中的丢包率、网络带宽等通信技术参数。可以直接定位用户问题,提高排查效率,提升用户体验。

点击阅读原文

最新活动推荐:

融云年中大促活动海报.png


LiveVideoStackCon 深圳站:融云解析 WebRTC 低延迟直播技术

WebRTC融云那些事 发表了文章 • 0 个评论 • 242 次浏览 • 2020-06-16 18:36 • 来自相关话题

“基于 WebRTC 的低延迟直播将会是未来直播行业的主流解决方案!”这是融云联合创始人兼CTO 杨攀在 8 月 LiveVideoStackCon 2019 音视频技术大会北京站上对于未来行业趋势的判断。仅仅 4 个月之后,当大会首次落户有“中国硅谷”之称的... ...查看全部

“基于 WebRTC 的低延迟直播将会是未来直播行业的主流解决方案!”这是融云联合创始人兼CTO 杨攀在 8 月 LiveVideoStackCon 2019 音视频技术大会北京站上对于未来行业趋势的判断。仅仅 4 个月之后,当大会首次落户有“中国硅谷”之称的深圳时,融云的另一位技术专家,首席架构师李淼就“基于 WebRTC 的低延迟直播方案”进行了深入的技术分享。

12 月 13-14 日,LiveVideoStackCon 音视频技术大会在深圳举办,大会聚焦音视频、图像、AI 等技术的最新探索与应用实践,覆盖社交、游戏、直播、智能设备等行业领域,面向开发者分享技术创新与最佳实践。本次大会,聚集了数十名海内外技术专家和上千名开发者围绕前沿技术发展进行探讨。


融云首席架构师李淼
随着我国 5G 正式走向商用,直播行业在获得更多发展机遇的同时,也对直播技术提出了新的挑战。传统直播解决方案如果无法解决技术层面导致的延时问题,那么这一弊病将在 5G 的高速网络环境下被无限放大,这也进一步促使了低延迟音视频直播技术方案的演化。对此,李淼结合 WebRTC 的低延迟特性,在现场展示了融云 WebRTC 直播场景的构建全过程及服务架构设计,并向开发者们分享了技术实践细节,希望通过新技术的应用来解决视频直播的延时问题。

为什么要选用 WebRTC 来做直播?李淼表示,相较于传统的直播解决方案,WebRTC 拥有着不可比拟的三大优势。首先是低延时,让直播用户可以享受低延时的观看体验。目前直播行业中绝大多数产品是基于 RTMP、HLS、HDL 方式构建的,即使在不考虑网络链路的情况下,也会产生秒级的延迟,而 WebRTC 则天生具备低延迟的优势,使用 WebRTC 直播可有效将延迟降低至 200ms 以下。

其次是流量消耗小。基于 UDP 传输的 WebRTC 相比基于 TCP 传输的 RTMP 等协议,由于 UDP 协议内容较 TCP 小,且数据包是基于 NACK 进行传输等特点,对于流量的使用也有明显的降低。对于开发者和直播企业而言,流量消耗大幅削减,成本也因此可以得到有效的控制。

而最重要的优势在于 WebRTC 技术方案可以使主播端与观众端保持一致。当主播端使用  WebRTC 进行推流时,主播端与观众端保持一致,可以减少开发的编码量,对于团队人员的占用和后期对于代码的维护,都能保证最低的资源消耗。

在 LiveVideoStackCon 现场,李淼向开发者讲解了如何通过 WebRTC 完成直播场景构建的全过程,并对于 WebRTC 直播的技术细节一一进行了详细解读。李淼表示,使用 WebRTC 直播方案,MCU 服务器的设计至关重要。一方面 MCU 可以按需进行编解码,另一方面需要以房间号进行聚合,记录每台MCU的状态并按最小资源分配新房间,通过这种设计来减少 WebRTC 直播方案的资源消耗。


WebRTC 直播发布订阅流程
当然,对于很多开发者而言,实际的生产环境中仍面临着如何做到秒开视频、降低 MCU 带宽压力以及避免流量风暴等难题,李淼从 GOP 缓存结构和 GOP 控制策略两个层面进行了分析。以解决首帧卡顿延迟为例,直播数据在客户端与 Media Sever 进行交互之后,通常会对 SPS 和 I 帧进行正常下发,但是在随后的 P 帧或 B 帧的下发阶段,融云会采用 1.2 倍速下发的方式进行,直至所有数据包与 MCU 端推包进程同步,这就将直播延迟降至了最低。

此外,李淼还指出,客户端的设计必须考虑就近接入,且支持多链路选择,数据中心间同源音视频只有一路级联;同时还可以利用 IaaS 层的能力,进行中心间级联链路的优化。遵循这些直播网络设计原则都可以有效地降低直播延迟。

在分享的最后,李淼表示在 5G 时代,直播、短视频等内容传播形态将迎来新一轮技术升级,用户体验将成为行业洗牌的关键,此次将 WebRTC 低延迟直播的设计理念和技术要点与开发者和行业人士们一同分享,希望能够给业界带来一些启发和思考。作为互联网通信云行业的技术领导者,融云也将持续优化实时音视频技术和场景化解决方案,助力音视频直播行业在 5G 时代的创新发展。

融云助力嘉和海森 以通信云技术服务在线医疗“战疫”到底

科技创新融云那些事 发表了文章 • 0 个评论 • 52 次浏览 • 2020-06-16 18:30 • 来自相关话题

这些天,新型冠状病毒肺炎疫情一直牵动着全国人民的心,与疫情相关的健康咨询需求也明显呈现激增趋势。然而,扎堆去发热门诊咨询问诊,在增加线下门诊压力的同时也极有可能会引发交叉感染。为平衡医疗资源,疏导人民群众进行针对性就医,提升问诊效率,安全便捷的线上咨询成为近期... ...查看全部

这些天,新型冠状病毒肺炎疫情一直牵动着全国人民的心,与疫情相关的健康咨询需求也明显呈现激增趋势。然而,扎堆去发热门诊咨询问诊,在增加线下门诊压力的同时也极有可能会引发交叉感染。为平衡医疗资源,疏导人民群众进行针对性就医,提升问诊效率,安全便捷的线上咨询成为近期就医形式的首选。

在这个全民抗疫的时刻,医疗软件行业知名企业嘉和海森与互联网通信云服务商融云联合多家医疗机构开展了网上免费健康咨询服务,包括北京朝阳医院、通辽市医院等全国各地的众多医疗机构纷纷通过嘉和海森互联网医疗软件开展网上咨询。所有在线咨询的患者,可通过文字、图片、音频和视频进行网络咨询,与医生进行实时互动,在线获取医生的健康指导,实现足不出户在线问医。


融云助力在线医疗App
以朝阳医院上线的朝阳健康云APP为例。在当患者进行健康咨询时,通常问的都是一些偏基础性的问题,医患之间可以通过图文、语音消息的方式进行互动。而在网络问诊中,考虑到需要对患者进行更详尽的检查,医患之间需要通过音频+视频的形式进行实时互动,同时通过图片+文字进行补充沟通。除了医患之间的在线问诊,App还可以让身处不同地区的医疗工作者,能够在同一群组中通过图文+语音的形式远程对患者的病情进行实时讨论,合理地平衡和调用各地医疗资源。


医生通过音视频在线问诊
毋庸置疑,在线问诊最需要的就是稳定可靠的互联网通信能力。无论是医疗行业的高精专属性还是考虑到病患问诊时紧张心理,医疗类App对于问诊时音视频画面和声音的稳定流畅性、图文交互的即时性都有着极高的要求。据了解,在嘉和海森医疗App中,所有医生与问诊者之间的图文、语音、视频的交互,都是通过融云互联网通信云实现的。

作为一家以技术立命的互联网科技公司,融云致力于为开发者和企业提供 IM即时通讯和实时音视频通信云服务。融云提供的 PaaS 层服务,可以通过 SDK 的形式集成到应用中,开发者可以根据自身业务的需要调用不同功能,自由组合下载。同时融云还针对在线医疗等不同行业属性,针对性地推出场景化解决方案,让开发者拿来即用,降低集成难度和开发时间。

在医疗资源紧张的当下,融云坚信“科技向善”,以安全稳定的即时通讯和实时音视频技术驰援互联网医疗。“足不出户,网络问医”这一模式不仅能有效分流患者,缓解门诊压力,同时通过在线问诊,医师可通过症状初步判断其发热原因,减少非新型肺炎患者前往医院就诊的交叉感染机率。

在此,融云也承诺从即日起至疫情结束,针对在线医疗场景不收取任何费用,向各在线健康咨询平台、政府疫情防控平台、互联网医院等平台免费开放即时通讯和实时音视频通信云服务。此外,融云也面向企业、机构免费开放在线教育以及协同办公场景下的实时音视频服务。

目前,融云已经开通了 7*24 小时咨询热线 13161856839,欢迎有需求的政府部门、医疗机构、企业机关与我们联系,待沟通确认符合相关场景需求后,我们将以最快的速度进行技术对接,助力政府和医疗机构应对此次疫情,为这场“战疫”献出一份绵薄之力。

疫情期间远程协同办公成刚需 融云助力拓维打造视频会议系

科技创新融云那些事 发表了文章 • 0 个评论 • 41 次浏览 • 2020-06-16 18:29 • 来自相关话题

一场新型冠状病毒疫情的突袭,严重影响了社会各领域的正常运行,也使得春节后的企业正常复工成为难题。为了减少人员流动和聚集,防止交叉感染,大量企业响应国家的号召,选择通过远程协同办公的形式来维持企业正常运营。如果说此前远程协同办公只是企业办公的一项补充条件,那么在... ...查看全部

一场新型冠状病毒疫情的突袭,严重影响了社会各领域的正常运行,也使得春节后的企业正常复工成为难题。

为了减少人员流动和聚集,防止交叉感染,大量企业响应国家的号召,选择通过远程协同办公的形式来维持企业正常运营。如果说此前远程协同办公只是企业办公的一项补充条件,那么在疫情期间显然已经成为一种用户刚需。据媒体报道,仅在 2 月 3 日当天,全国就有上千万企业、近 2 亿人开启远程办公模式。

为了帮助更多企业实现稳定高效的远程协同办公,拓维信息积极响应国家号召,免费向企业提供1个月的远程视频会议服务,同时对于原有客户免费增加用户许可,保证企业全员远程办公的需求,直到疫情结束。在这段视频会议流量大规模爆发的时期,拓维无纸化会议系统稳定可靠地支持了众多企业远程会议同时进行,有效地为企业在疫情期间正常运行提供了保障。


拓维无纸化会议系统
据了解,拓维无纸化会议系统可满足远程资料共享、远程视频通话、会议资料安全等会议需求,且支持多个会议同时召开,单个会议场景可支持数百人同时在线。而拓维无纸化会议系统之所以在用户量激增的情况下仍能保持平台的持续稳定运行,与其底层通信能力服务商融云多年来在实时音视频领域的技术积累和稳定服务密不可分。

作为国内领先的互联网通信云服务商,融云致力于为开发者和企业提供 IM 即时通讯和实时音视频通信云服务。融云 CPO 任杰介绍称,融云在实时音视频领域拥有多年研发经验,各项技术指标保持市场领先水平,支持流畅稳定的一对一、多对多音视频通话、服务端录像,同时通过分层编码、大小流设计、带宽估计以及多服务器优化等方面来实现对更多路的支撑。目前融云在视频会议方面可以做到同时支持 14 路,纯音频则能做到同时支持 25 路,优于市场上一般软件的能力表现。此外融云还在不断强化技术支持能力,让开发者 30 分钟即可快速集成音视频能力,加速产品的上线效率。

同时,在这次疫情期间,视频会议系统很容易出现在线人数激增、海量消息并发的峰值情况,往往因难以准确预估流量,错误部署服务器导致系统崩溃,非常考验系统架构稳定性。融云通过“锦囊”服务可以在前期以最佳实践经验安排专家团队协助客户进行服务器部署,当遇大规模流量涌入的峰值期时,运维人员和技术人员通过实时监控,可以动态调整服务器部署,针对可能的并发问题量身定制相应的保障方案,确保在疫情期间企业协同办公的正常运行。

在此,融云也向社会承诺,从即日起至疫情结束,免费向企业、机构提供协同办公场景下的实时音视频服务,同时免费开放在线医疗场景下的 IM 及实时音视频服务和在线教育场景下的实时音视频服务。目前,融云已经开通了 7*24 小时咨询热线 13161856839,欢迎有需求的企业、机构与我们联系,待沟通确认符合相关场景需求后,我们将以最快的速度进行技术对接,帮助更多企业解决疫情期间的协同办公难题,实现办公方式的迭代升级,为坚决打赢这场疫情防控阻击战提供更多助力。

科技向善 共克时艰:融云在疫情期间免费开放三大场景通信云服务

科技创新融云那些事 发表了文章 • 0 个评论 • 62 次浏览 • 2020-06-16 18:27 • 来自相关话题

一场突如其来的疫情打乱了所有人的生活。然而,这个史上最没有存在感且令人压抑的春节也已经结束了。除了在抗疫一线奋战的医护人员外,我们大多数普通民众也纷纷迎来了返工和在线复学的日子。实际上,在这个特殊的春节假期,很多人一直处于家庭在线办公模式。而为了最大程度地规避... ...查看全部

一场突如其来的疫情打乱了所有人的生活。

然而,这个史上最没有存在感且令人压抑的春节也已经结束了。除了在抗疫一线奋战的医护人员外,我们大多数普通民众也纷纷迎来了返工和在线复学的日子。

实际上,在这个特殊的春节假期,很多人一直处于家庭在线办公模式。而为了最大程度地规避出行和返岗带来的交叉感染可能性,不少人的家庭在线办公模式可能还需要持续一段时日。同时,学生群体作为最脆弱和亟需保护的人群之一,多地政府早已下达文件通知各类学校开学时间不得早于3月份,使得在线教育亦成为眼下疫情期间的巨大市场刚需。此外,尤其值得注意的是,在我们的出行不那么方便的这段时间,人们对于在线医疗尤其是有关疫情的相关健康咨询也呈现骤增态势。

针对这样的市场需求,中国cPaaS领域的通信云领军企业融云近日宣布,从即日起至疫情结束,向企业、机构免费提供在线医疗场景下的IM及实时音视频服务,同时免费开放在线教育以及协同办公场景下的实时音视频服务。

“作为一家互联网通信云公司,我们决定免费开放这三大场景下的通信能力,是希望能够在国家遭遇这样的疫情期间,尽我们所能为社会提供一些帮助。通过我们技术人员的协助,最短2-3天时间,有这方面需求的单位和机构就能够快速用上我们的服务。”融云CPO任杰在近日接受C114采访时表示。

共同抗疫:在线医疗让我们更有安全感

随着感染者和就诊者数量的不断增多,疫区很多医院的发热门诊已不负重堪,对于大多数问诊者而言,专家建议可以在线问诊,通过线上IM及实时音视频交流,医生可以直观地了解和检查问诊者的真实情况,为问诊者提供医疗帮助,以减轻线下医院发热门诊的超负荷运转,同时也可以降低线下就医交叉感染的风险。

任杰介绍道,“通过我们的IM即时通讯和实时音视频能力,在线医疗可以帮助对端的医生跟患者之间实现线上沟通,从而帮助患者进行一些初步的诊断,使患者实现足不出户便可网络问医。”他指出,在线医疗除了可以实现医生对患者的初步诊断外,另一方面在疫情期间还能帮助患者渡过心理层面上的难关。


图:融云助力在线医疗 App
毋庸置疑,在线问诊最需要的就是稳定可靠的互联网通信能力。无论是医疗行业的高精专属性,还是考虑到病患问诊时的紧张心理,医疗类App对于问诊时音视频画面和声音的稳定流畅性、图文交互的即时性都有着极高的要求。而融云此前在在线医疗方面已经积累了不少经验。

例如,医疗软件行业知名企业嘉和海森已与融云联合多家医疗机构开展了网上免费健康咨询服务,包括北京朝阳医院、通辽市医院等全国众多医疗机构都已通过嘉和海森互联网医疗软件开展网上咨询。

共克时艰:协同办公提高社会运转效率

除了在线医疗外,在线协同办公亦是此次融云免费开放实时音视频服务的重要场景之一。与阿里钉钉、企业微信等SaaS层服务不同,融云更加专注于向不同规模企业提供协同办公的底层PaaS能力,然后企业可根据自身需求来实际进行部署和采用。

具体来说,融云提供的是IM即时通讯和实时音视频通信云服务等PaaS层服务,这些服务可以通过SDK的形式集成到应用中,开发者可以根据自身业务的需要调用不同功能,自由组合下载。同时融云还根据不同行业属性,针对性地推出了场景化解决方案,包括上述在线医疗和协同办公等诸多场景,让开发者可以拿来即用,大幅地降低了集成难度和开发时间。

“我们协同办公能力最主要的特点是,我们的服务一般都是企业采用私有部署模式,可以支持高达几十万人这样的超大企业规模,这是其他办公软件所不具备的。其他软件往往仅支持几千到上万人的规模上限,而我们达到几十万量级上,依然可以稳定运行。”任杰强调到。

他谈到,融云的协同办公能力中组件非常完整,包括企业通讯录、视频会议、电子白板、屏幕共享以及企业隐私权限的控制,同时包括网盘、文件、存储、传输等相关的非常完整的功能。融云的合作伙伴可以直接调用这些能力来做私有化部署产品或者SaaS产品。

在任杰看来,疫情期间,在线协同办公是保持社会机器逐步恢复正常运转的有效手段之一,对于减弱疫情对整个社会经济的冲击影响非常重要。

共渡疫情 :在线教育让学生停课不停学

与2月开始陆续复工的企业不同,全国各地几乎都已宣布各类学校需在3月以后才能开学。由此也使得不少老师和学生开始了“网课”生涯。这也正是融云此次在疫情期间免费开放能力的另一重要场景。

与上述在线医疗和协同办公场景一样,融云在在线教育方面主要提供的也是底层IM+实时音视频能力,但与现在不少学生使用的企业微信等非标准在线教育软件不同,融云除了提供基础的通信能力外,还可以实现整个授课过程中的控场能力,老师作为一个主持人身份可以对麦克风等权限进行管理,从而有效防止课堂秩序的混乱。


图:融云在线教育服务场景
同时,任杰向我们介绍,融云的在线教育服务在提供屏幕共享和电子白板等标准功能的同时,还支持将外部的音视频等文件导入进行播放,这使老师不仅可以轻松实现PPT共享和白板讲义等基础教学操作,还可以进行更多的外部资源分享和延伸。

事实上,尽管融云提供的是PaaS层服务,其本身并不涉及SaaS层软件的直接提供。但眼下有需求的单位和企业若想快速用上服务,可以直接将融云提供的不同场景的Demo作为源码来进行改写,然后与自身业务进行对接整合,从而实现服务快速上线。

例如,融云在办公场景中的产品名为安信,它与企业微信和钉钉类似,核心用的是融云的底层能力;而在教育场景中,融云也有一个名为SealClass的Demo——这是一个小班课场景,里面有各种基础功能和控制功能。

科技向善:最快2-3天让所需单位用上服务

在采访中,任杰对于融云在疫情期间应对各种场景下的高并发流量表现得十分有信心。而他的底气则源于该公司在IM领域的长久积累,从2014年融云创立至今,该公司通过良好的基础架构设计和普惠千行百业的发展理念,早已具备亿级并发处理能力。

“例如,IM在企业协同办公领域最重要的核心就是通讯录,我们针对几十万人的企业通讯录做了专门的优化,包括围绕通讯录的拉取方式、加载方式、组织方式和权限管理等,我们都做了海量并发的一系列的优化。这是其他很多企业办公软件所不具备的。”任杰说到。“在音视频方面,我们在支持多路方面也有很多经验和技巧,比如通过分层编码、大小流设计来实现对更多路的支撑;当然还有带宽估计、多服务器等方面的优化。”他表示,目前融云在视频会议方面可以做到同时支持14路左右,纯音频则能做到同时支持22-25路,优于市场上一般软件的能力表现。

任杰表示,在线医疗、在线教育和协同办公这三类企业,眼下只要提供相关企业证明,就可以使用融云的免费服务。“我们面对在线医疗的所有服务都是免费的——即IM和实时音视频两大产品线全部都是免费的,而在线办公和在线教育是实时音视频产品全部免费,因为这些场景主要用到的也是音视频能力。”他详细介绍道。

目前,针对这些企业,融云专门开通了一个绿色通道。“融云会在第一时间去处理这些申请,之后会有专门的服务支撑人员去协助快速地完成集成。在疫情期间,最快我们可以做到将此前需要7-10天的部署上线时间缩短到2-3天,当然,这也要取决于对方的时间和实际需求情况。”

科技向善,此次疫情期间,涌现出许许多多像融云这样无偿贡献自身服务和能力的企业。一个企业的力量可能比较微弱,但我们相信,通过这一股股善意的汇聚和支撑,这一次的全民“战疫”一定会更快取得胜利,我们的社会也将更快恢复正常运转。

期待春暖花开到来的那一天。

疫情之下单日消息量破千亿 融云以通信云技术助力全行业战疫

科技创新融云那些事 发表了文章 • 0 个评论 • 45 次浏览 • 2020-06-16 18:25 • 来自相关话题

通过协同办公软件实现远程视频会议、通过在线教育平台让学生“停课不停学”、进入电商App直播间与主播互动并购买各类商品,疫情之下的我们无论是主动拥抱还是被动接受,曾经所构想的云上生活都已经在疫情期间成为了现实。 根据 Questmobile 最新公布的数据显示,... ...查看全部

通过协同办公软件实现远程视频会议、通过在线教育平台让学生“停课不停学”、进入电商App直播间与主播互动并购买各类商品,疫情之下的我们无论是主动拥抱还是被动接受,曾经所构想的云上生活都已经在疫情期间成为了现实。


根据 Questmobile 最新公布的数据显示,2020 年春节假期过后,日均活跃用户增量 Top10的行业中,办公和教育类占据了半壁江山,视频、社交和电商也成功入围。

远程办公、在线教育等行业的井喷也引发了互联网通信云业务量的急剧增长。各类 SaaS 通信产品正在全面占据我们的工作生活,PaaS 云服务商也在持续地为各行业的 App 们提供底层通信能力。作为互联网通信云行业的领航企业,融云 IM即时通讯和实时音视频云服务在疫情期间正在呈现出几何倍数的增长态势。

疫情期间,融云平台单日消息量破千亿

据融云平台统计数据显示,2019 年依托融云通信云平台实现通信能力的 App 超过 30 万款,日均消息量达 150 亿条。而进入 2020 年后,受疫情影响大部分交流均通过网络远程进行,日均消息量明显激增,每日的消息量相较于 2019 年提升了 3 倍以上,单日峰值消息量更是突破千亿条。

与此同时,视频会议、直播课堂等也带动了融云平台上实时音视频流量的倍数增长,2020年 2 月,融云平台实时音视频单月使用分钟数较 2019 年平均值增长了 4 倍以上。


融云通信云服务在教育、医疗、协同办公中的应用
根据行业分析来看,最典型的就是这次疫情期间涌现出的线上“四大天王”:在线医疗、在线教育、协同办公以及线上泛娱乐行业,这些客户占据了融云消息分发量的 7 成以上。在线教育和协同办公在春节假期结束后便进入了消息的爆发期,日均消息量增长6倍,而在线医疗在经历了疫情初期的爆发后开始趋于平缓,但消息量仍实现了翻倍增长。至于社交、直播等泛娱乐行业,无论是活跃人数还是日消息量均持续保持高发态势。

与此同时,面临着复工难题的线下行业也在寻求新的发展机遇,在线视频招聘、VR看房、直播卖车等等一系列线上服务在疫情之下成为了新的流行趋势。在高端房地产服务平台丽兹行上,通过VR直播看房的形式,让客户无需亲临实地也能体验房间的面宽和进深,同时经纪人可以在直播间里与客户即时交流,针对性地解答客户问题,让客户更好地掌握房子的各项细节;在北京某4S店内,销售们借助直播平台,摇身一变成为了汽车主播,对着直播镜头介绍不同车型和相关配置,而在屏幕的另一端,数千名同时在线的网友提出了一个个促销优惠、车辆保养、直播抽奖等问题与其互动。


通信云服务实现VR看房实时互动
上述的这些场景正不断地在网络上一次次上演,每一套房屋的成交、每一辆汽车的售卖、每一次人才的成功招聘……这都离不开互联网通信云为其构建的交流平台。疫情之下,正在有越来越多的行业企业借助融云互联网通信云平台稳定可靠的服务,来拓展新机遇。

技术致胜,稳定支撑海量消息的秘钥

一切皆远程,一切在云上,巨大流量带来的不仅是机会更是挑战。

对于很多企业机构而言,突然到来的大规模、高并发流量把风口变成了风暴,微博热搜时常被软件崩溃占据,话题下有许多网友诉说着平台崩溃对办公、学习带来的不便,保证平台稳定的重要性已经不言而喻。

作为国内领先的互联网通信云服务商,融云为了更好地应对高并发压力,通过构建数据存取模型、优化缓存策略以及采用异步化请求处理等方式,不断提升平台的承载能力,并针对群聊、聊天室等不同场景进行具体分析和应对,通过最佳实践方案来解决高并发问题。

在群聊场景中,融云在系统中使用消息分发控制策略,在群消息分发中引进快、中、慢三个队列,通过消息直推与通知拉取相结合的方式,进行快速处理,同时融云还通过“引用分发”机制来降低消息缓存的存储,可极大地减轻系统承载压力。

而针对于直播聊天室场景的高并发消息服务请求,融云部署了环形队列的内存缓存,滚动保存最近的50条消息。在终端完全改用通知拉取的方式,用户收到通知后,可从服务端的缓存中批量获取消息,这极大的提高了消息下发效率,提升了聊天室系统的吞吐量。同时融云根据多年服务客户的经验以及自身的技术模型,制定了一套按消息类型进行消息处理机制。根据消息属性和优先级进行叠加或抛弃,确保在消息并发量极大的情况下,能起到很好的限流左右,保证用户端可以享受流畅的直播互动体验。

在实时音视频通信云服务方面,融云支持流畅稳定的一对一、多对多音视频通话、服务端录像,同时通过分层编码、大小流设计、带宽估计以及多服务器优化等方面来实现对更多路的支撑。同时,通过不断地技术更迭,融云音频抗丢包可达到 80%,视频可对抗 40% 丢包,保障音视频的高流畅性。

此外,融云技术服务团队也梳理了技术系统可能存在的风险,以防在流量爆发性增长时确保不出故障,除了采用链路切换、数据中心灾备等常规手段外,融云也做好了故障迁移工作,在出现问题的情况下可以将之前的业务全部迁移,确保在客户业务即使面临大规模的流量冲击依然能够正常运行。

结语:

疫情之下,众多行业从火热的旺季突然冰封至零度以下,如何在疫情期间寻找新的发展机遇,企业自救的同时更需要全社会的帮助。作为一家有社会责任感的企业,融云坚信科技向善,愿以互联网通信云服务助这些行业一臂之力,目前融云已开通了 7*24 小时咨询热线 13161856839,欢迎有需求的企业、机构与我们联系。融云将竭尽全力来帮助企业快速构建通信能力,助力复工复产,打赢这场疫情防控阻击战。

实时音视频交流