精华内容
下载资源
问答
  • Android 云游戏实现

    2020-08-07 17:14:20
    公司最近有和云游戏相关的业务,最开始采用的是virtualdisplay +mediacodec实现,屏幕视频录制编码推流。但是mediacodec编码有很多参数设置不了,而且云主机的cpu性能完完全全高于GPU 所以,就准备采用软件编码实现...

           公司最近有和云游戏相关的业务,最开始采用的是virtualdisplay +mediacodec实现,屏幕视频录制编码推流。但是mediacodec编码有很多参数设置不了,而且云主机的cpu性能完完全全高于GPU 所以,就准备采用软件编码实现。基于X264+minicap实现也可以理解为把bitmap转为H264视频通过RTMP传输。

     

    先上流程图:

    1 minicap :是一个高速的截图工具,具体如何安装使用可以查看github上的流程

    2 数据解析:minicap提供了一个localsocket往外吐数据我们可以在Android端解析该数据,关键代码如下

       private void getMinicapData() {
            new Thread(new Runnable() {
                @Override
                public void run() {
                    try {
                        mMinicapClientSocket.connect(mAddr);
                        InputStream inputStream = mMinicapClientSocket.getInputStream();
    
                        long start = System.currentTimeMillis();
                        while (isLiving) {
                            byte[] buffer = new byte[FRAME_SIZE];
                            int realLen = inputStream.read(buffer);
                            if (buffer.length != realLen) {
                                buffer = subByteArray(buffer, 0, realLen);
                            }
    
                            int len = buffer.length;
                            for (int cursor = 0; cursor < len; ) {
                                int byte10 = buffer[cursor] & 0xff;
                                if (readBannerBytes < bannerLength) {
                                    cursor = parserBanner(cursor, byte10);
                                } else if (readFrameBytes < 4) {
                                    // 第二次的缓冲区中前4位数字和为frame的缓冲区大小
                                    frameBodyLength += (byte10 << (readFrameBytes * 8)) >>> 0;
                                    cursor += 1;
                                    readFrameBytes += 1;
                                    Log.i(TAG, "解析图片大小 = " + readFrameBytes);
                                } else {
                                    if (len - cursor >= frameBodyLength) {
                                        Log.i(TAG, "frameBodyLength = " + frameBodyLength);
                                        byte[] subByte = subByteArray(buffer, cursor,
                                                cursor + frameBodyLength);
                                        frameBody = byteMerger(frameBody, subByte);
                                        if ((frameBody[0] != -1) || frameBody[1] != -40) {
                                            Log.i(TAG, String.format("Frame body does not start with JPG header"));
                                            return;
                                        }
                                        final byte[] finalBytes = subByteArray(frameBody, 0, frameBody.length);
                                        // 转化成bitmap
                                        mBitmap = BitmapFactory.decodeByteArray(finalBytes, 0, finalBytes.length);
                                        // 这里开始推送
                                        mLivePusher.native_push_video(miniCapRGBChange.getYUVByBitmap(mBitmap));
    
                                        long current = System.currentTimeMillis();
                                        Log.i(TAG, "图片已生成,耗时: "
                                                + TimeUtil.formatElapsedTime(current
                                                - start));
                                        start = current;
                                        cursor += frameBodyLength;
                                        restore();
                                    } else {
                                        Log.i(TAG, "所需数据大小 : " + frameBodyLength);
                                        byte[] subByte = subByteArray(buffer, cursor, len);
                                        frameBody = byteMerger(frameBody, subByte);
                                        frameBodyLength -= (len - cursor);
                                        readFrameBytes += (len - cursor);
                                        cursor = len;
                                    }
                                }
                            }
                        }
    
                    } catch (Exception e) {
                        Log.i(TAG, String.format(" get mini data Exception"+e));
                    }
    
                }
    
    
            }).start();
    
    
        }
    
    

    3 .android 移植x264

      x264是一个免费的开源库,可以移植到Android上来,具体可查看官网或者网上搜索如何移植。

     编码参数关键代码

    void VideoChannel::setVideoEncodeInfo(int width, int height, int fps, int bitrate) {
    
        // 编码参数设置可以参考
        //https://www.cnblogs.com/wainiwann/p/5647521.html
        pthread_mutex_lock(&mutex);
    
        mWidth = width;
        mHeight = height;
    
        mFps = fps;
        mBitrate = bitrate;
    
        ySize = width * height;
        uvSize = ySize / 4;
    
        if (videoCodec) {
            x264_encoder_close(videoCodec);
            videoCodec = 0;
        }
        if (pic_in) {
            x264_picture_clean(pic_in);
            delete pic_in;
            pic_in = 0;
        }
    
        //打开x264解码器
        //x264解码器的属性
        x264_param_t param;
        //ultrafast 最快
        //zerolatency 无延迟解码
        x264_param_default_preset(&param, "ultrafast", "zerolatency");
        param.i_level_idc = 30;
        //输入数据格式 int csp=X264_CSP_BGR|X264_CSP_VFLIP;    //这个格式是BITMAP的那种颠倒的BGR的格式
        param.i_csp = X264_CSP_I420;
        param.i_width = width;
        param.i_height = height;
    
        //无b帧
        param.i_bframe = 0;
        //参数i_rc_method表示码率控制, CQP(恒定质量) CRF(恒定码率) ABR(平均码率)
        param.rc.i_rc_method = X264_RC_CRF;
        //码率(比特率 单位Kbps)
        param.rc.i_bitrate = bitrate / 1000;
    
    
        LOGI("set_i_bitrate------------------>%d",bitrate/1000);
        //瞬时最大码率
        param.rc.i_vbv_max_bitrate = bitrate / 1000 * 1.2;
        //设置了i_vbv_max_bitrate必须设置此参数, 码率控制区大小 单位kbps
        param.rc.i_vbv_buffer_size = bitrate / 1000;
    
        //帧率
        param.i_fps_num = fps;
        param.i_fps_den = 1;
        param.i_timebase_den = param.i_fps_num;
        param.i_timebase_num = param.i_fps_den;
    
        //用fps而不是时间戳来计算帧间距离
        param.b_vfr_input = 0;
        //帧距离(关键帧) 2s一个关键帧
        param.i_keyint_max = fps * 2;
    
        //是否赋值sps和pps放在每个关键帧的前面 该参数设置是让每个关键帧(I帧)都附带sps/pps
        param.b_repeat_headers = 1;
        //多线程
        param.i_threads = 1;
        x264_param_apply_profile(&param, "baseline");
    //    x264_param_apply_profile(&param, "high");
        //打开解码器
        videoCodec = x264_encoder_open(&param);
        pic_in = new x264_picture_t;
    
        x264_picture_alloc(pic_in, X264_CSP_I420, width, height);
        pthread_mutex_unlock(&mutex);
    }

    4 rtmp移植 :网上教程比较多可自行参考。

     

    5最后效果图:

     

    时间来不及就先看看图片吧。

    老版本的屏幕录制可以看看上一篇文章,新版的屏幕录制需要搭好minicap环境,有些9.0手机可能不能允许minicap,如果是手机的话还是建议采用上一篇文章的方案,如果是自己要做这方面的业务可以采用新版本。 新版本的可以等我后面放到github上。

     

     

       

    展开全文
  • 云游戏的概述 1.概念  云游戏(Cloud gaming)又可称为游戏点播(gaming on demand),是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高...

    一.云游戏的概述

    1.概念

      云游戏(Cloud gaming)又可称为游戏点播(gaming on demand),是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高品质游戏[1]。在云游戏场景下,游戏并不在玩家游戏终端,而是在云端服务器中运行,并由云端服务器将游戏场景渲染为视频音频流,通过网络传输给玩家游戏终端。玩家游戏终端无需拥有强大的图形运算与数据处理能力,仅需拥有基本的流媒体播放能力与获取玩家输入指令并发送给云端服务器的能力即可。

    2.优势与问题

      云游戏相较传统游戏有如下优势:

      a.省硬盘。游戏本身不需要下载到本地,能节省大量的硬盘空间;

      b.硬件弱相关。游戏对客户端所需要的显卡、CPU、内存要求很低,只要具备播放基本流媒体的瘦客户端就可以运行云游戏;

      c.游戏安全性。由于游戏使用的是视频流机制,因此可以100%杜绝游戏外挂,大大节省开发商在游戏反外挂上的投入;

      d.游戏的随意迁移。当游戏控制问题得到合理的键位映射,可以将电脑上的游戏放在手机上运行,动态适配设备分辨率播放流媒体游戏;

      但是,目前还存在一下几个重要的问题:

      a.PING高。游戏由于在服务器端运行,因此由于网络传输问题,游戏从控制输入到接受视频到客户端正常游戏,目前会有相当一部分时延;

      b.耗流量。由于播放的是流媒体,因此比传统游戏在数据传递上会有不一样的机制,云游戏传递用户输入数据控制流,返回游戏渲染后的视频流,而传统游戏传递的是的交互数据(为了安全一般都会进行加密处理);

      c.服务器压力大。由于所有的游戏都需要在云端的服务器上运行,对于很多高画质需要渲染的游戏将非常占用系统资源,在当前的云计算话的环境下部署云游戏仍有待优化。

    3.商业化云游戏的发展

      云游戏并非是近两年才被提出的,在2009年,OnLive初次亮相在旧金山GDC游戏开发者大会,当时OnLive的云游戏平台展示引起轰动,成为展会上最大的亮点,但是由于经营不善以及过于自负,一再错失机会,最终其专利被Sony收购。身为OnLive的竞争对手,GaiKai曾一度吸引全球注目,GaiKai与各大知名深度厂商合作,例如:Ubisoft,Valve等,不过不久,GaiKai也最终被Sony斥巨资收购,并被纳入Sony PS NOW项目[4]。在中国,阿里巴巴、百度也都有进军云游戏的尝试以及设想,但是由于技术资金原因,目前大部分国内云游戏服务提供商都相继不再提供服务。“云游戏”这个产业可以说很年轻而且很有潜力,目前的云游戏在世界上引起各大游戏硬件巨头的兴趣,其中包括微软Azure、索尼PlayStation Now、英伟达GRID,各大厂商都在云游戏上有不小的投入,因此云游戏的市场潜力非常巨大,由此也可见一斑。

      Microsoft,云游戏项目:Delorean,并且依其强大的云计算服务Azure云,但是时延高,用户体验差。目前距Sony和Nvidia有一定的差距,差距主要体现在提供同等的服务,但是却比两个竞争对手要求更高的带宽。

      Sony,云游戏项目:PlayStation Now(简称:PS Now),Sony提供的云游戏服务在60M以上的能获得不错的体验,但是对于目前的大部分家庭网络似乎承载不了,并且,当用户在进行云游戏的同时,开启了另一个视频流服务(例如:观看Twitch直播)时,画面卡顿会变得比较明显。此外,就在2017年3月14日,索尼宣布PS NOW将支持PS4的游戏在云端运行,目前只有订阅PS NOW的玩家才拥有测试资格。

      Nvidia,云游戏项目:GRID,在硬件显卡这一块,Nvidia绝对是世界领跑者,早在2008年就开始设计云游戏芯片硬件架构,到现在从未中断,一直到其发布Shield TV——一款真正意义的云游戏机,再到最近的与世界各大游戏平台,如Steam、Origin、UPlay合作,将于2017年3月提供商业化的云游戏服务,其数据中心搭载自家的1080显卡,采用自家的GameWorks引擎渲染。

    表3-1 云游戏大厂各项对比

     

    商业优势

     硬件优势

     软件优势

    2017年动向

    Sony PS NOW

    收购2大云游戏公司

    PS系列主机

     云游戏公司的技术继承

     全部PS3和部分PS4云端化

    Microsoft Delorean

    Azure累积的大量用户

     Xbox系列主机

    商业化的Azure云服务

     暂无

     

    商业优势

     硬件优势

     软件优势

    2017年动向

    Nvidia GRID

     高新能显卡合作伙伴遍布世界各地

     Shield TV云游戏机

     以Nvidia显卡为核心的GPU加速,Gameworks引擎

    与Steam合作,开放商业化云游戏服务

    4.小结

      当下流行的云计算环境将云游戏部分的推入了公众的视野,但是现在任由很多问题亟待解决,为了能够从科研到真正有机会将云游戏像大公司一样推上商业化市场,从很多方面人有很多问题要去优化和解决,但是毫无疑问的是,云计算的环境给了云游戏很好的平台,如何将云计算与云游戏结合起来。将云游戏的实例也采用虚拟机化,以及如何去设计这样一个大规模虚拟化的架构,还有很长的路要走。

     

    作者:letcafe

    出处:http://www.cnblogs.com/letcafe/

    -------------------------------------------

    个性签名:编程水太深,先会造轮子!

    展开全文
  • 首先简单做个自我介绍。我本人主要是从事游戏行业...所以就有了这样一个游戏和云计算相结合的项目,这是我去年跟上海劢驰数字技术有限公司合作的项目,我作为技术顾问参与了这个项目的架构设计和一些核心技术的研发...

    首先简单做个自我介绍。我本人主要是从事游戏行业的,经历比较复杂,早年做 PC 端网游,然后又做了几年虚拟现实,接着又做页游和手游, 现在主要是做 HTML5 游戏。这跟云计算可能有点远,但是我个人对云计算技术很感兴趣,所以业余也会关心这项技术的发展。所以就有了这样一个游戏和云计算相结合的项目,这是我去年跟上海劢驰数字技术有限公司合作的项目,我作为技术顾问参与了这个项目的架构设计和一些核心技术的研发。

    什么是云游戏?

    云游戏这个概念非常简单,就是我把游戏放到服务器上去运行,把游戏渲染出来的的音视频画面,通过流的形式传送到终端,终端上不再需要安装游戏,各种终端比如说电视、手机、PC、平板都可以运行。这样我们就不需要关心游戏怎么去适配不同的软硬件平台、终端性能够不够等等这些问题。这个概念本身是非常好的,在2009年的时候,这个技术就已经出现了,美国有家叫Onlive 的公司第一个推出云游戏服务,但是他最终在商业上还是失败了,技术最后被索尼公司收购,并运用在PS Now上。云游戏的概念虽然非常好,但里面技术挑战性非常高,有非常多的技术问题需要解决,那个时代可能还比较早,软硬件都还不太成熟,所以最后没有能够成功的商业化。到了现在这个时间点上,云游戏技术开始慢慢成熟起来,已经具备了商业化的基础。

    下面是对我们产品的介绍。对云游戏来说,用户主要会关心延迟问题,玩一个对抗性很强的游戏,如果中间卡个几百毫秒那肯定受不了,游戏体验就会非常差。所以我们最核心的关注点就是要把延迟降低到最小、并且把画质保持在一个相对可以接受的程度。目前我们产品的整体延迟(从用户按下操作按钮到看到画面变化)可以控制到50毫秒以下,在这样的延迟水平下玩格斗游戏赛车游戏感觉都是非常流畅的,画面可以支持到720P/1080P,网络带宽只要4兆以上就可以了。我们单台服务器可以支持 20-50 路的并发游戏数量,也就是单台服务器可以同时为 50 个玩家提供服务,单个并发用户的整体服务器硬件成本在500元左右,可以说是一个非常有竞争力的成本。当年 OnLive 失败的主要原因是因为他的硬件成本非常高,他的一台服务器仅能服务一个用户,单个并发用户的成本可能就要上万,在这样的成本水平上要实现商业上的成功是非常困难的。目前这个项目已经在小范围的内测,他们主要是 toB 的业务,为宽带运营商提供增值游戏服务。

    云游戏的技术挑战

    第一个是实时性

    游戏的整体延迟包括了游戏逻辑运算时间、音画渲染的时间,加上编码的延时、网路传输的延时、客户端解码的延时、客户端向服务端发送控制信息的延时,云游戏的实时性要达到一个可令玩家接受的程度,这个技术挑战是非常高的,当然也要依靠硬件和网络本身的性能,如果没有足够的带宽也不可能做到。

    第二是虚拟化技术

    虚拟化在服务端已经非常成熟,我们有虚拟机技术以及各种容器技术,但是在桌面上就不是那么成熟,普通的虚拟桌面不支持 GPU 的虚拟化,而游戏非常依赖 GPU 渲染,若没有 GPU 的虚拟化就没办法实现云游戏了,所以虚拟化是一个很大的技术瓶颈。

    第三是经济性

    每个并发用户的服务器硬件成本关系到这个模式能否成功商业化,如果成本超出了用户可接受的范围,那就没有办法实现盈利。

    最后是运维管理

    云游戏的运维管理跟传统的服务器运维管理不一样,因为用到的服务器硬件不一样,同时硬件负载又很高,这对运维管理提出了新的挑战,所以在技术上就要解决这些问题。

    平台选择

    游戏的运行平台非常多,各种各样,但是比较适合的只有windows平台。Linux 平台虽然开放,但是它没有什么游戏支持,其他的主机游戏平台基本都属于封闭技术,微软和索尼自己都在研发主机上的云游戏,那我们是没有办法去做的。

    android平台也是非常适合做云游戏。服务器跑个android游戏再传到android设备上这个概念看上去比较怪异,但实际上IPTV运营商非常喜欢这个概念,因为机顶盒不允许安装第三方的应用,监控比较严,那我们通过云端化来绕过这种限制,这对机顶盒这种产品非常有帮助,所以android平台也是我们要考虑的。但今天主要是介绍 windows 平台游戏的虚拟化,android上是用硬件方案跑的,所以就不介绍了。

    windows游戏的虚拟化技术主要是两条路线。一个是虚拟机方案,但主要问题是 GPU 虚拟化技术不成熟,可能需要一些专业级的显卡支持,成本非常高、性能损耗非常大,每一个游戏都跑一个 Guest OS 非常浪费内存,所以这条方案就被我们否掉了。同时windows 上也缺少可用的容器级技术,我们只能采取 API Hook 方式手工实现虚拟化,我们称之为 Sandbox 方案。

    Sandbox方案就是把游戏所用到的系统 API 全部hook接管,让游戏认为自己运行在一个正常的 OS 上面,但实际上是我们接管的一个 OS。这样做的好处是性能损耗很小,基本上没有额外的损耗,但是比较痛苦的要针对每个 API 做适配,需要对每个游戏进行适配,而且游戏通常不开源,游戏开发商通常也不会配合你去修改代码,需要一些 hack 技术来针对每个游戏做适配。

    技术实现细节

    图像和声音的采集

    图形API有 DirectX 9,10,11,12还有OpenGL,接管这些API后我们就可以把画面重定向到视频编码器,不不在屏幕上输出了。音频比较简单,只要接管Windows Audio Session API就可以了。

    输入操作的虚拟化

    手柄比较麻烦,因为手柄支持的API接口比较多样化,比如 DirectInput, XInput, RawInput,还有些游戏直接读 USB 设备,实现这些API的接管工作是比较琐碎的。

    存储的虚拟化分

    一是游戏的资源部分,比如执行程序、图片、声音等等。这些资源文件都是只读的,需要一个共享存储来放这些文件,因为这些文件体积比较大,通常一个游戏需要几十个G的容量,如果全部都放在本地节点上的话,对节点的存储容量要求很大,而且以后更新维护起来也比较困难。所以我们用 NAS 来共享这些文件,这么做的网络 I/O 开销会非常大,后面我会介绍如何来优化这一块。第二是用户配置和存档数据等等可变数据,这些数据需要集中化存储,同时可能存在跨机房的访问需求。用户离机房越近延迟越小,所以需要多地、异地部署服务器,让玩家在全球漫游访问你的服务,这需要有跨机房文件共享的能力。

    其他需要适配的内容

    比如游戏一般都是单实例,我们需要绕过游戏的防多启动机制。还有些游戏无法后台窗口运行,我们需要通过 API Hook 的方式,让游戏认为它处于一个正常的状态。最理想的适配方式是通过 SDK,让 CP 来适配你的云游戏平台,但目前来说还不实际,因为云游戏的商业化还没有完全的落地,需要技术去慢慢的推进。

    音视频编码技术

    视频流采用的是 H.264 编码,主要是 720P/1080P@30fps,1080P@60fps 对网络和硬件的要求过高,暂时还做不到。音频编码使用AAC。因为标准的封装格式不含控制流,不能传输用户的操作数据,所以我们自己定义了一种封装格式,简单的把 H.264 和 AAC 的裸流封装起来传送给客户端。

    目前用软件编码器基本不可行,一路视频编码就要消耗掉一个CPU核的资源,跑个三四路就把 CPU 资源吃光了,游戏就没办法运行了。幸运的是三大硬件厂商 Intel、AMD 和 NVIDIA 都推出了自己的硬件编码器,Intel的CPU自带硬件编码器,支持20+路的720P实时编码没有问题。NVIDIA 的硬件编码性能更高,可以直接对GPU的 FrameBuffer 做编码并传到 CPU 上,节省了很多内存的拷贝,性能是最好的。

    视频编码的参数调优

    首先避免使用 B 帧以减小延迟;较大的 GOP 设置来减少 I 帧的比例,保证每一帧消耗的码率都在一个最大可控的范围内;0 延迟设置,保证每输入一帧数据编码器都立刻输出这帧的编码数据,避免编码器缓冲帧数据;bitrate控制,使用固定比特率的算法是不适合的,因为游戏中经常会存在一段时间的静止画面,此时比特率很低,对接下来的变化帧编码器就会分配大量的比特来编码,这就会造成这一帧数据特别巨大,从而带来了额外的网络数据传输延迟。所以我们采用了自适应算法,在保证比特率总体在最大范围内的同时,保证每一帧消耗的码率都在一个最大可控的范围内,确保每帧的数据传输延迟可控。

    终端的视频解码优化

    H264 的解码是比较头疼的,因为android平台适配起来比较痛苦,尤其是它的硬件解码坑非常多。如果直接使用mediacodec封装的硬件解码器,那个延迟非常高,基本没有办法用。有一些芯片厂商会提供一个后门,让你把缓冲关掉直接输出画面,但是这需要对接具体的芯片厂商,无法做到通用,只适合一些机顶盒类的产品。所以还是需要用软件解码的方式来支持 0 延迟的输出。android设备的性能参差不齐,早期的低端芯片性能不满足实时解码 ,需要利用 GPU 做一些加速。

    网络传输的优化

    用UDP传输的话,因为H264 本身不支持容错,一旦丢包就会出现花屏,在下一个I帧到来前都无法恢复,通常要持续好几秒,严重影响用户体验,无法接受;而TCP 丢包的话只是出现几百毫秒的卡顿,实测还是可以接受的,所以我们放弃了 UDP 协议传输,利用TCP在网络层做一些调优使延迟降低。实测下来,现在的宽带网络延迟基本没有问题,主要问题反而是在用户侧的 WiFi 上,一旦出现无线信号干扰,网络抖动会比较厉害。

    服务器和客户端的同步算法

    我们的云游戏把所有环节的缓冲都关掉了,全部是零延迟自出,原来缓冲设计的目的就是为了抵抗颠簸,比如网络的颠簸、或某一个编解码环节出现了抖动,通过缓冲把这个抖动抹平,现在把缓冲都关掉后对同步会造成很大的影响。有很多因素会造成颠簸,比如服务器发送数据过快,客户端来不及消费,造成的结果就是延迟非常大。所以我们自己设计了一套算法来解决这个同步的问题。具体的做法就是让客户端在完成一帧画面的显示后向服务器反馈一个消息,服务端根据客户端反馈的消息就知道客户端消费到了第几帧,跟服务器现在编码的帧数做比较,在一定的阈值内就继续传输下一帧,否则等待客户端的确认消息,直到客户端赶上来。这样做的结果就是当颠簸发生时服务器能及时感知并停止发送数据,等颠簸消除后再继续发送最新的游戏画面,实测下来获得了比较理想的同步效果。

    存储的优化。只读资源数据是放在 NAS 上的,几百个游戏共享一个 NAS,加载游戏时的网络 I/O 开销非常大,所以我们做了一个优化来本地缓存这些共享文件,利用dokan实现了一个虚拟磁盘来访问资源文件,再把虚拟磁盘重定向到NAS上,同时利用节点的本地 SSD 硬盘来缓存热点文件,从而降低了网络 I/O 的开销。

    更多的云游戏玩法

    旁观模式,一个玩家玩的时候其他玩家可以接入这个视频流,看他怎么玩;对战模式,其他玩家可以切到这个游戏流里面两个人在一起对战;还有直播模式,把视频流封装为 HLS,推送到 CDN 上进行直播,这是非常流行的主播模式,云游戏都可以支持。

    云游戏运维方面的挑战

    云游戏需要维护大量的服务器节点,而且跟普通的服务器管理不一样,需要自己造一些轮子。由于所有的硬件资源都是高负荷运行,我们要最大化的增加硬件利用率,一般的服务器 CPU 占 10% 就很不错了,而云游戏的 CPU 都是在接近 100% 的情况下运行,另外还需要GPU的参与,这导致了硬件的可靠性相对比较低。

    软件因为没有隔离性,可靠性也会降低,一旦出现问题怎么维护、怎么恢复,成了比较麻烦的问题,因为没有现成的方案,就我们需要自己设计服务器集群来解决这些问题。另外还有跨机房部署的问题。

    硬件方案的选型,我们主要有三套方案,一套是 GRID 显卡方案,这是 NVIDIA 为云游戏专门设计的专业显卡,上面带有编码器可以将游戏画面直接编码输出,但它的缺点是价格比较昂贵,一台服务器的硬件成本大约在 5 万元左右。

    还有就是消费级独显方案,去掉了昂贵的专业显卡的同时还能获得更好的GPU性能,所以这套方案的性价比要高很多,每路并发的硬件成本可以降低到 500 元以下。

    最后一个方案是 Intel 核显方案。完全不需要用独立显卡,但 Intel 核心显卡的性能偏弱,运行大型的 3D 游戏会比较吃力,运行一些休闲游戏没有问题。这个方案的优点是不需要显卡,1U 的尺寸下可以装入多个节点,集成度提高,而且易于维护,也是一个值得考虑的方案。

    下面来解释一下云游戏一下集群的概念。Node(节点)对应一台物理计算机,一个节点可以同时运行多个游戏实例为用户提供服务。多个节点组成一个 Group(节点组),一个Group内包含了若干节点和NAS,对应于一个机柜, 多个机柜用万兆交换机串连起来,部署在一个机房,称之为 Cluster(集群),再上面一层是云游戏平台,包括用户的入口管理、登录计费等,可以跨越多个机房。

    下图是系统架构图:


    User Profile Storage  用来存放用户的存档数据,Log Storage 用来存储日志数据,还有数库等等。

    Group 内的各 Node 组成对等网络,可以任意添加或者删除 Node,各个 Node 通过竞争算法选举出来一个 Master,由 Master 与 Manager 建立连接,对整个 Group 进行管理,如果Master出现故障则由剩余的节点重新选举出一个新的Master进行接管,从而保证了任何节点的故障不会影响到其他节点的正常服务。在Node 上仅需要安装好操作系统和 Daemon 服务,无须配置,即插即用。Node daemon对服务器进行管理和监控;游戏文件存放于 NAS 上,由各 Node 共享;内网/外网流量隔离,防止互相影响。

    Manager 用于对集群内的所有 Node 进行管理, 配置/更新/上线/负载均衡/监控,游戏数据管理更新,用户数据管理等等。提供 web 后台给运维操作,实现运维的自动化和可视化操作。Manager使用双机热备模式实现高可用,避免单点故障造成整体系统瘫痪。

    日志和监控。我们需要有完整的日志来记录和追踪系统行为,保障整个系统的可维护性。同时系统会实时监控每个游戏实例以及 Node 的状态,包括 cpu、gpu、网络io 的使用率,游戏帧率、延迟等等数据,所有数据保存下来,后面可以通过一些数据分析的手段来找到性能的瓶颈,然后再针对性的进行优化,进一步优化我们的系统。

       

    提问:对家用的wifi做一些支持,能详细说说吗?

    乔捷:首先,要提示用户wifi信号不好会造成延迟,终端检测到网络信号不好时及时的提示用户。其次,对于网络延迟的抖动,我们的同步控制算法能够补偿一部分抖动。最后,可以在服务器上调优一下TCP参数,比如说减小数据重传的超时时间,加快数据包的重传,可以有效缓解抖动。

    提问:对用户体验有影响吗?

    乔捷:目前肯定有,我们是标清的 720P 的画面质量,因为要考虑硬件成本和网络传输成本。但随着成本的逐步降低,未来要支持1080P甚至4K画质也是没有问题的。

    提问:对于 CP 的开发模式有哪些影响?

    乔捷:目前没有影响,我们只是买一个授权,然后由我们进行对接,不需要CP方去改动代码。当然如果 CP 方愿意来对接我们的SDK话那是最好的,可以加入对战、排名、内购等各种功能,利用云游戏的特点为游戏增加更多的玩法。

    提问:我们这么多年下来的计算,最早开始所有的计算都是在中心,随着终端计算能力的增强,计算很多功能都到终端上面去,现在你的方案是把所有的终端都放在中心,这对服务器成本要求很高?如果能够容纳一些用户同时运行大型游戏,服务器成本是否会非常高?

    乔捷:对。为什么我们要中心化?因为终端的种类太多了,手机、平板、电视、PC,这么多平台,你一个游戏要去移植这么多平台,本身的工作量就非常大,而且用户要去下载安装,推广的成本非常高,网络游戏单个用户的获客成本已经到了几十到上百块钱。所以,服务器成本表面上看是有点高,但是算上开发成本分发成本推广成本,这点服务器成本已经完全可以接受。

    这就和视频一样,最早我们看视频是买光盘的,后来有了网络以后是从网络上下载,而现在宽带普及了之后已经没有人下载了,都是直接视频点播,因为它方便,门槛越低越容易被用户接受,现在还会有人买光盘吗?基本上已经没有了吧。电视电脑都不是我们的工具了,大家现在用的比较多就是手机。计算资源越来越中心化集中,管理成本不断降低。现在买游戏机、ps3、ps4,每隔 5 年换一个游戏机,以后不需要游戏机更新换代了,更新换代对于厂商来说是一个比较痛苦的过程,有一个漫长的迁移过程。将来根本不用关心什么硬件,比如今年的“吃鸡”游戏非常流行,但是很多玩家的显卡性能不足,跑不起来。将来游戏都是放在服务器上跑,用户根本不用担心跑不跑得动,接上就可以玩。一旦这个服务模式成立,硬件厂商都会向这个方向投入资源,最早2011年的时候我们就预研过云游戏的技术,当时做了以后就放弃,后来看到这个机会以后推出来了grid显卡,一下子拉很高,看这一块商业模式什么时候落地,现在还是在探索的过程当中,将来是大趋势。

    提问:除了服务上面成本,要求终端的网络非常好吗?对解码要求高么?

    乔捷:对,因为网络非常普及的情况下,宽带已经无处不在了,所以这个问题基本已经被解决了。现在的主流中低端芯片可以实时软件解码720P的视频流。

    提问:我知道游戏有很多种类,目前云游戏技术支持的范围怎么样?云游戏的交互目前为止是否还很有限?

    乔捷:主要是主机游戏,用手柄玩的游戏。看类型,使用键盘鼠标的游戏比如FPS在电脑上比较好操作,在电视上就不太方便了,目前主要还是适配手柄操作的游戏。
    --------------------- 
    作者:Go中国 
    来源:CSDN 
    原文:https://blog.csdn.net/RA681t58CJxsgCkJ31/article/details/79226317 
    版权声明:本文为博主原创文章,转载请附上博文链接!

    展开全文
  • 1.云游戏在哪里 云游戏解决网游画质提升瓶颈。根据中国通信院定义,云游戏本质上为交互性在线视频流,游戏在云端服务器上运行,...云游戏将在打破本地终端存储空间限制基础上,实现游戏画质大幅提升。 ...

     

    1.云游戏在哪里

    云游戏解决网游画质提升瓶颈。根据中国通信院定义,云游戏本质上为交互性在线视频流,游戏在云端服务器上运行,并将渲染完毕后的游戏画面或指令压缩后通过网络传送给用户。云游戏和用户数据存储在服务器上,本地终端上不再需要安装游戏文件和存储用户数据。过去网游厂商一直在游戏画质与终端性能之间博弈。云游戏将在打破本地终端存储空间限制基础上,实现游戏画质大幅提升。
     

    1.1云游戏用户

    云游戏主要消费群体是核心及硬核游戏用户。核心及硬核游戏用户对游戏可玩性、游戏画质以及游戏操控感等品质要求较高,画质大幅提升的云游戏击中该群体痛点。我们判断,网游向云游戏进化过程将是核心及硬核游戏用户向云游戏用户转化过程。根据游戏工委及易观千帆统计,2019年国内手游用户规模6.4亿人,其中核心及硬核游戏用户占比分别为18%和2%,合计超过1亿人。
     

    1.2云游戏品类

    云游戏利好追求高画质的游戏品类。以手游为例,手游画质与游戏下载包及资源拓展包大小呈现正相关性。根据国家手游测试中心2019上半年《手游测试白皮书》,基于对10313款游戏测试数据,角色扮演、策略经营、虚拟养成类游戏在内存占用排名前三。可以认为,该三个大游戏品类将会受益于云游戏技术。
     

    1.3云游戏研发商

    云游戏利好端游研发商、主机游戏研发商以及二次元游戏研发商。核心及硬核游戏用户对游戏画质的较高追求是驱动游戏研发商打造高品质游戏核心动力,云游戏技术解决了困扰研发商及游戏用户关于高画质游戏对终端性能要求苛刻的问题。因此,掌握这批硬核用户的研发商具有研发云游戏的诉求,反过来讲,这类研发商具有用户优势。可以看到,这类研发商主要为端游研发商、主机游戏研发商以及二次元游戏研发商。

    2.云游戏商业模式在哪里

    2.1端游商业模式

    盛大网络创立端游商业模式。2001年,盛大网络代理韩国网络游戏《热血传奇》,凭借代理合同,浪潮、戴尔向盛大提供两个月服务器试用;中国电信给予盛大网络两个月测试期免费的带宽试用,国内单机游戏分销商上海育碧负责代销盛大游戏点卡。盛大网络实现以其游戏运营平台为中心的游戏产业链整合,创立网络游戏商业模式。
     

    端游是国内网络游戏商业模式起点。游戏运营商处于产业链中心环节,与各方形成商业交易:运营商通过自主研发或代理开发商游戏产品获得游戏运营权;向服务器厂商购买或租赁服务器,向网络服务商租赁网络带宽,为游戏运营提供硬件设施和网络条件;借助媒体进行游戏推广及搭建游戏用户充值收费渠道。
     

    运营为王。端游研发商、端游运营商与渠道代理商是产业链核心环节,采用分成模式分配游戏用户充值,运营商收获端游价值链最大分成比例。电信运营商、服务器供应商以及媒体获得的收益取决于运营商经营计划,不参与游戏分成。
     

    2.2页游商业模式

    页游公司商业模式创新主要体现在联运和买量。端游运营商倾向于独家代理运营游戏,页游运营商则会将独代游戏产品再次授权第三方运营平台,形成联运模式;买量模式是页游运营商将流量网站的用户导入自有页游运营平台,并根据用户充值分成给流量网站。联运和买量有助于页游运营商快速获取用户并盈利。
     

    研发为王。页游研发商、页游运营商与页游渠道商是产业链核心环节,研发商收获页游价值链最大分成比例。采用分成模式分配游戏用户充值。服务器商、IDC企业以及媒体获得的收益取决于运营商经营计划,不参与游戏分成。
     

    2.3手游商业模式

    IP版权方成为手游产业链一环。IP版权方向手游研发商授权IP,为游戏开发角色、图像及故事情节提供基础。研发商、运营商、渠道商、游戏媒体、支付商、基础设施供应商等角色均保留在手游产业链。页游联运模式在手游产业链中并未得到发展,买量模式在手游产业链中得到进一步发展。
     

    渠道为王。IP版权方、研发商、运营商与渠道商用分成模式分配游戏用户充值,渠道商收获手游价值链最大分成比例。云计算公司以及媒体获得的收益取决于运营商经营计划,不参与游戏分成。
     

    2.4云游戏商业模式

    云游戏产业链或与端游较为接近,运营为王。目前国内云游戏产业链尚处于探索之中,参与者包括电信运营商、云计算服务商(包含垂直云服务提供商)、CPU/GPU供应商、游戏研发商等。我们认为,云游戏产业链或与端游较为接近,运营为王。
     

    云游戏商业模式会发生较大变化。在端游、页游及手游发展阶段,游戏公司商业模式均有创新之处。云游戏是一门新兴技术,可以预判围绕云游戏产品的商业模式将发生较大变化,包括研发模式、运营模式、盈利模式、渠道模式、推广模式等。
     

    2.4.1研发模式

    云游戏研发更注重游戏美术设计。云游戏核心优势在于突破网游画质瓶颈,推动网游研发商对美术资源竞赛。一般而言,游戏角色模型面数越高,角色越生动形象。《崩坏3》和《阴阳师》是注重游戏画质的代表性手游产品。2016年公测的手游《崩坏3》中角色建模多边形数量达到15000面,接近端游《剑网3》重制版水平(16000至20000面);2019年公测的手游《闪耀暖暖》中角色建模数达到50000-80000面,接近一流主机游戏水平。云游戏将助推手游画质接近主机游戏水平。目前国内手游研发已经具有较高门槛,头部产品研发团队达到数百人,研发周期2-3年,云游戏将提高游戏研发成本,进一步提高游戏行业壁垒。

    2.4.2运营模式

    网游运营成本随IDC崛起而降低。早期国内端游运营商向服务器商购买服务器以及向电信运营商采购带宽,采购成本与维护成本较高,约占到游戏收入的10%;为降低成本,后期游戏运营商倾向租赁服务器和带宽并交由第三方IDC公司托管,成本降低至游戏收入的5%;目前国内手游运营商向云计算公司租赁云服务器及采购增值服务,成本进一步降低至游戏收入的2%。可以看到,网游产业由新兴向成熟发展过程中,第三方IDC企业会逐步发展,降低游戏运营成本。

    备注:1)游戏运营商:负责提供游戏运营平台,架设服务器组安装服务器端软件,租赁带宽提供网络游戏下载,并对游戏进行推广、运营维护以及客户服务等;2)IDC公司:基础业务包括主机托管、宽带出租、IP地址出租、服务器出租和虚拟主机出租等,增值业务包括数据备份、负载均衡、设备检测、远程维护、代理维护、系统集成、异地容灾、安全系统等。
     

    云游戏运营成本或随第三方云游戏服务商发展而降低。目前云游戏运营成本大幅高于端游和手游。主要源于目前云游戏运营商需要独立覆盖服务器及网络成本。按照电脑游戏及手游运营成本降低轨迹,目前国内云计算商、电信运营商云游戏平台、垂直云游戏服务提供商将部分向产业下游拓展转化为第三方云游戏服务商,驱动云游戏成本降低。
     

    2.4.3盈利模式

    国内网游盈利模式由点卡模式转为道具模式。2000年,华义国际在中国大陆代理发行《石器时代》,引入中国台湾网游市场获得认可的计时点卡模式,并成为国内网游主要盈利模式;2006年,《征途》采用道具收入模式,并验证道具收费模式产生的收益远大于游戏点卡收益。道具收费逐步成为国内主流端游以及之后页游和手游盈利模式。
     

    国内硬核游戏用户付费能力已经能支撑云游戏运营成本。根据产业调研:720P云游戏,游戏运营商承担的单用户成本约1.5-2元/小时;1080P云游戏,游戏运营商承担的单用户成本约需要在6-7元/小时;以及极光大数据统计,2019年国内人均手游使用时长10小时/月。可以得到:对720P/1080P云游戏,游戏运营商承担的单用户成本分别为15-20元/月、60-70元/月。对比腾讯2019年三季度披露的旗下手游付费用户付费能力为61-64元/月。考虑到重度和硬核用户付费能力远高于平均水平。因此,面向重度游戏用户和硬核游戏用户的云游戏具备商业运营条件。

    云游戏适合采用前向付费模式。理由如下:1)云游戏运营商承担的用户成本(服务器及网络等成本)与在线用户人数和用户游戏时长呈正相关关系。前向收费模式可以将不付费的用户排除在外,降低运营商成本;2)国内重度游戏用户和硬核游戏用户与单机游戏用户、主机游戏用户的消费习惯重合度较高。这类消费群体具有时长收费、买断制及订阅制等前向付费习惯。
     

    2.4.4渠道模式

    游戏用户入口即为渠道。端游早期发展阶段,网吧、软件分销渠道承担网游实体点卡和虚拟点卡销售任务,成为主要渠道商,分成比例为点卡面值的15%-20%。端游发展后期,线下销售网点渠道角色弱化,退化为网游可选支付方式之一,返点比例降低为点卡面值的2%-3%;在页游行业发展期,百度、360等流量巨头成为页游渠道商,渠道商不参与游戏运营,负责将流量转化为页游用户,分成比例20%-30%;手游渠道商主要为应用商店,分成比例30%-50%。

    电信运营商或是云游戏早期阶段渠道商。不考虑硬件成本,目前国内云游戏玩家试玩云游戏需要三重付费,分别为运营商套餐、云游戏流量费、游戏付费。与端游和手游消费体验相比,目前云游戏消费方式设置的门槛较多。我们认为,在5G流量费用无法快速下降条件下,电信运营商具有将云游戏与手机流量套餐相融合优势,形成云游戏研发商/运营商——电信运营商——游戏用户的渠道链条。此销售模式在国内端游发展早期曾被电信运营商普遍采用。电信运营商则成为云游戏渠道商,与运营商采用分成方式。

    举例:2005年,上海电信与盛大网络合作推出:上海玩家如果采用拨号上网的方式,只需使用95877拨号上网,就能免费玩传奇,不需购买点卡。上海电信与盛大网络根据用户在线时长分成。
     


    2.4.5推广模式

    国内网游推广由线下地推转变为线上买量推广。网吧曾是国内游戏用户主要的上网场所之一。2007年之前国内网吧用户与网游用户重合度超过70%。各大网游运营商建立地推团队进行网吧资料的收集以及网吧的定期回访。2009年之后,游戏推广模式逐步由地推转变为线上买量推广。以手游为例,根据《2018硬核联盟白皮书》报告,2018年手游买量市场规模约563亿元,占比手游市场的42%。

    口碑传播及意见领袖推荐将是云游戏主要推广方式。理由如下:云游戏主要消费群体是核心游戏用户及硬核游戏用户。该群体主要聚集在游戏直播以及游戏社区等平台,易于口碑传播;核心游戏用户及硬核游戏用户会关注知名游戏主播推荐的游戏,例如目前敖厂长在哔哩哔哩粉丝超过600万。

    云游戏或将运营为王,运营商获得产业链最大分成比例。云游戏主要消费群体是核心及硬核游戏用户。国内这批游戏用户主要聚集在部分网游产品及游戏社区平台,背后公司将在云游戏浪潮中具有发展优势。

    本文章转载至:https://www.gameres.com/864916.html

     

    感谢关注个人博客

    展开全文
  • 什么是云游戏云游戏这个概念非常简单,就是我把游戏放到服务器上去运行,把游戏渲染出来的的音视频画面,通过流的形式传送到终端,终端上不再需要安装游戏,各种终端比如说电视、手机、PC、平板都可以运行。这样...
  • 云游戏

    2019-11-19 18:45:27
    还是电脑的,又或者是手机的,市场最关注的,往往是硬件性能,但云的出现改变了这一块,通过高速的网络传输,云可以实现,硬件计算后,仅仅把最后的画面结果,传输到另一个地方,这便是云计算产物下的:云游戏 ...
  • 云游戏是一种以云计算、渲染及云传输为基础的游戏实现方式,与传统游戏区别在于游戏的运行在云端边缘计算节点上,而非用户本地终端上;用户本地终端通过网络接收云端边缘计算节点发送的数据进行游戏声音与画面的本地...
  • 5G 技术与云计算技术的融合作用于游戏产业,将为诸多领域带来颠覆性变革和发展机会。...5G 助力云游戏实现了向移动端的迁移,让用户在移动端侧玩3A 级大型游戏成为可能。随着5G时代来临,2019 年被喻为云游戏元年。
  • 以云计算厂商为例,华为发布智能边缘平台 IEF,预计在 2020 年实现 80%的省份边缘计算节点全覆盖;阿里明确将战略布局边缘计算,未来的核心战略是“+边+端”三位一体的计算 模式,并推出边缘计算产品 Link ...
  • 《热血传奇》云游戏主要亮点在于“云多屏”和“云组队”玩法,实现其他玩家游戏画 面在游戏内以直播形式展现,随时加入组队同屏互动,对于传统直播有了更多的玩法,但在解决多端同操作方面仍有待进步。
  • 它旨在为用户提供媲美旗舰真机的游戏体验和完整的Android系统,实现低延迟、高传输、安全可靠的统一,使用户摆脱自有设备性能制约,完美支持云游戏、应用智能托管等应用场景。并在无需ROOT自己手机的情况下,在云.
  • 9月27日消息,云游戏的概念已经流行了很长一段时间,随着5G时代的到来,云游戏再次受到青睐。国外的谷歌、微软、亚马逊,国内的腾讯、网易等巨头均在布局云游戏。在首届北京国际游戏创新大会腾讯...
  • GamingAnywhere是一个开源的实现云游戏的引擎,并且高效、跨平台、易扩展、可调配。  GitHub地址:https://github.com/chunying/gaminganywhere GamingAnywhere官网:http://www.gaminganywhere.org 下图是...
  • 前言: 遥想当年阿法狗战败一众围棋国手,风气一转,似乎所有人都懂AI。这次谷歌又放出了stadia,国内鹅厂再次跑步进场,贵州某xx云提前布局。...1、云游戏主机端(云游戏运行端,或者叫云游戏画面渲染...
  • Photo from《The Matrix》李志成腾讯云视频云技术负责人,主要负责视频云直播、媒体处理、云游戏等一些技术开发工作.“未来游戏将由传统的通用计算型服务器转向定制化专用的云...
  • 云游戏的概述 1.概念  云游戏(Cloud gaming)又可称为游戏点播(gaming on demand),是一种以云计算技术为基础的在线游戏技术。云游戏技术使图形处理与数据运算能力相对有限的轻端设备(thin client)能运行高...
  • 可落地的云游戏解决方案

    千次阅读 2020-05-19 11:43:58
    云游戏解决方案是一套可以落地的技术方案,已经有过客户案例并经过了一年多的线上运营,踩过了很多坑,也解决了很多云游戏相关的核心技术问题、视频流、底层协议问题等,现在把方案设计思路分享给大家,为大家提供...
  • 可大规模商业化的云游戏网络环境标准已基本确定,5G 在带宽和时延 方面成倍优于 4G 使得移动环境下的云游戏真正具备可行性。 50-100Mbps 的独占下行带宽足以满足云游戏高标准运行。我们梳理了 目前主流的云游戏服务...
  • Stadia云游戏平台

    2020-06-17 17:07:03
    Google Stadia 是谷歌推出的云游戏平台,玩家无需安装与下载,只要你网速够快,即可在各种设备上畅玩 3A 大作,当前最高支持 4K 分辨率与 60 帧。 云服务将允许用户使用 Chrome 浏览器,Chromecast 设备或 Google ...
  • 5g云游戏的战略布局

    2020-11-07 06:07:56
    随着5g的逐渐成熟和商业化应用,云游戏的最后一块技术基石已经被填满。云游戏也有望成为首个在5g应用中脱颖而出的行业应用。 国内外不同企业加快了云游戏的战略布局。 网络游戏内容提供商,提供云游戏的游戏内容,如...
  • 云游戏是一种以云计算、渲染及云传输为基础的游戏实现方式,与传统游戏的区别在于游戏的运行在云端边缘计算节点上,而非传统的在用户本地终端上运行;用户本地终端通过网络接受云端边缘计算节点发送的数据进行游戏...
  • 云游戏的1.0和2.0

    千次阅读 2021-01-20 20:29:37
    纵观历史,基础科学和基础设施的发展都会开创新的时代。...而云游戏正是同时利用了5G和云计算,所以前途不可限量。 目前绝大部分游戏公司都在开发移动端游戏,那么为什么要发展云游戏呢?痛点主要有两方面:手机
  • 作者 | 年素清责编 | 伍杏玲出品 | CSDN云计算(ID:CSDNcloud)伴随5G技术加速落地,云游戏作为5G应用落地的最佳场景,已经成为全球游戏厂商和云服务厂商布局的重要战...
  • 云计算新亮点:云游戏

    千次阅读 2012-08-31 14:15:22
    一个多月前,索尼电脑娱乐(以下简称SCE)公司宣布,他们已经与美国互动云游戏公司Gaikai达成最终协议,计划以3.8亿美元将Gaikai收购。此次收购标志着,索尼现在已经进入云服务器和云游戏领域,将包括技术优势和工程...
  • 云游戏解决方案

    2020-12-16 10:04:09
    实现方案 三 测试方案 四 技术难点 一 国内现状 国内手游解决方案大致分为三种: 1 真实手机机器插卡方案 2 使用ARM服务器 3 用X86方式虚拟化ARM 二 实现方案 2.1 在x86机器上安装vbox虚拟化软件...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 66,122
精华内容 26,448
关键字:

云游戏如何实现的