重庆分公司,新征程启航
为企业提供网站建设、域名注册、服务器等服务
/**
为资溪等地区用户提供了全套网页设计制作服务,及资溪网站建设行业解决方案。主营业务为成都做网站、网站建设、资溪网站设计,以传统方式定制建设网站,并提供域名空间备案等一条龙服务,秉承以专业、用心的态度为用户提供真诚的服务。我们深信只要达到每一位用户的要求,就会得到认可,从而选择与我们长期合作。这样,我们也可以走得更远!
* Android视频聊天
* 1、初始化SDK 2、连接服务器、 3、用户登录;4、进入房间;5、打开本地视频;6、请求对方视频
*/
public class VideoChatActivity extends Activity implements AnyChatBaseEvent
{
private AnyChatCoreSDK anychat; // 核心SDK
private SurfaceView remoteSurfaceView; // 对方视频
private SurfaceView localSurfaceView; // 本地视频
private ConfigEntity configEntity;
private boolean bSelfVideoOpened = false; // 本地视频是否已打开
private boolean bOtherVideoOpened = false; // 对方视频是否已打开
private TimerTask mTimerTask; // 定时器
private Timer mTimer = new Timer(true);
private Handler handler; // 用Handler来不间断刷新即时视频
private ListString userlist = new ArrayListString();//保存在线用户列表
private int userid; // 用户ID
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_video_chat);
remoteSurfaceView = (SurfaceView) findViewById(R.id.surface_remote);
localSurfaceView = (SurfaceView) findViewById(R.id.surface_local);
configEntity = ConfigService.LoadConfig(this);//加载视频通话设置
loginSystem();// 初始化SDK 连接服务器
mTimerTask = new TimerTask(){
public void run(){
Message mesasge = new Message();
handler.sendMessage(mesasge);
}
};
mTimer.schedule(mTimerTask, 1000, 100);
handler = new Handler(){
@Override
public void handleMessage(Message msg){
VideoChat();// 不间断显示即时视频通话画面
super.handleMessage(msg);
}
};
}
本文之所以有必要编写并作记录,主要原因是因为在工作中开发出一个万能的自定义camera预览控件之后,本是一个提高效率以及提供一个强大能力的控件,但是产品并不能理解这个万能控件存在的意义,产品无法与技术设计相结合的理解使用;并且发现我们的智能业务部Camera自定义预览技术虽然是使用多年,但是我们并没有真正的形成规范,由于产品在不能够理解系统平台(Android/iOS)给产品和研发带来了什么,导致产品可能会出现在不理解系统平台以及系统知识的情况下,臆想产品所谓的形态;当产品设计脱离了系统平台所支持的技术点以及设计的初衷,就会导致回归问题的时候,出现不必要的讨论,其根结就是一点:“信息不同步,知识不同步”。
所以,为了提高效率,就采用记录和分享的方式,尝试性推动产品、测试、研发三者对工程与架构的同步理解,更深的懂得程序架构设计意义,尝试性通过信息同步的方式,在一个统一的知识储备的平台下,共同完成一个更高效,和高品质的工程产品。(为了能够让非技术:产品设计,以及测试都能够理解,所以,使用了更多的白话解释)
附:强大灵活的FsCameraTextureView(第一版,自适应截取)( 第二版本版本:自适应展示)
首先,抛出几个问题,
1)什么是摄像头支持的previewSize?
2)什么是视频或者图片的pictureSize?
3) 如何获取和查看摄像头支持的PreViewSize 和PictureSize ?
4)手机预览所见的区域SurfaceView(TextureView)与camera 的previewSize的关系是什么?
5)为什么会设计了两种预览方式view,两种预览方式都会有什么样子的效果呢?
一,概述
通过Android Camera拍摄预览中设置setPreviewCallback实现onPreviewFrame接口,实时截取每一帧视频流数据(简单说来,就是通过设置一个接口,接收系统回调通知我们的每一帧数据)
二,知识点
1, camera支持的格式:
2,拍照流程
3,camera权限
三,Android Camera中PreviewSize、 PictureSize、 SurfaceView(TextureView)之间的关系
1,PreviewSize:
相机预览时候的能支持的尺寸,简单的说一下,就是预览的大小,也就是拍照前能够看到的图片大小。(通过Android手机相机可以试一下,这个参数设置不同,同样的焦距下,拍摄桌子上一个固定距离的东西,看到的视野会不同)
相机的预览尺寸,不能随意的设置值,只能通过camera的parameters的getSupportedPreviewSizes方法,获取支持的预览尺寸列表,并从列表中选择一个设置在parameters中。(通俗简单的说就是,获取camera中能够支持的预览大小合集,如果你想要查看某个预览对应的尺寸,就把该尺寸设置到camera的属性中即可,则camera会返回相对应尺寸的预览数据流提供显示)。
2,PictureSize :
指的是拍照之后,最终拍摄到的图片大小,也就是图片的质量。图片尺寸同样也只能从支持的列表中选取一个设置。 调用camera的takePicture方法(拍照)后,获得拍照的图像数据,注意picturesize和previewsize的宽高比也要保证一致,否则获取的图片会将preview时的图像裁剪成picturesize的比例。 previewsize的分辨率,只会影响预览时的分辨率,不会影响获取图片的分辨率,所以preview只是确定了图像的取景最大范围。最终图片的分辨率是由picturesize来决定。 所以,最好的设置方法,例如:previewsize为1280*720,picturesize为2560*1440。(由于我们没有拍照业务,目前这个知识,不做深究)
3,SurfaceView(TextureView)
用于展示camera预览图像的view,就是将preview获得的数据,放在这个view上。所以如果preview的宽高比和SurfaceView的宽高比不一样,就会导致看到的图像拉伸变形。图像拉伸变形解决的办法:
(1)就是在确定preview的分辨率后,重新设置SurfaceView宽高;
(2)如果SurfaceView宽高定死,则需要获取一个比例适合SurfaceView尺寸的PreviewSize 的preview,尽量小的裁剪,然后填充在SurfaceView中。
4,利用图片的显示方式,理解Preview与SurfaceView(TextureView)显示关系
ImageView (UI上面设计的一个控件)与图片bitmap 的关系,比如限定死一个ImageView的大小,但是图片与ImageView尺寸不一致,就会有几种方案,首先选取一张长方形1920*1080的图片,ImageView就是紫色部分,无论长宽比都比ImageView要大。
图片适配例1:拉伸填充ScaleType.FIT_XY :虽然被全部填充,但是整个图片为了适配图片已经扭曲,失真,图片缩放到控件大小,完全填充控件大小展示。
图片适配例2:等比例裁剪填充ScaleType.CENTER_CROP ,因为在该模式下,图片会被等比缩放直到完全填充整个ImageView,并居中显示。该模式也是最常用的模式了。如图可以看到,图片的高度是能完全展示出来的,但是左右部分被进行了裁剪,并没有完全显示。
图片适配例3 : ScaleType.CENTER_INSIDE,此模式,用以完全展示图片内容为目的。图片将被等比缩放到能够完整展示在ImageView中并居中,如果图片大小,小于控件尺寸,那么就直接居中展示该图片
图片适配ImageView方式还有很多,就不一一列举,这三种已经足够重要,为什么讲解camera预览,却穿插了图片的适配,其实可以这么理解,camera的preview就是由多张图片组成,不断的像帧动画一样变化,而SurfaceView就是一个载体,相当于ImageView,业务中定死了SurfaceView的大小之后,被动的承载你选择的previewSize,来展示camera的Preview,你可以选择类似于前面三种例子来理解preview的填充,以下会举例说明preview的填充策略选择有哪几种方式,我们会采用哪种方式:
1)拉伸填充,自适应view,不可取,比如:手机的SurfaceView是整个手机的屏幕尺寸(全屏填充),或者任意尺寸比例的surfaceView,使用这种方式,就如同(图片适配例1)的方式,导致视频扭曲,拉伸。
2)等比例裁剪填充,目前我们项目中,采用的就是这种方式,并且提供给很多三方使用,已经成为一种独立,并且稳定的技术实现自定义view,简单说一下视频的适配策略方式,SurfaceView随便由业务方,自定义宽度大小,比如业务方选择了1900*1000的SurfaceView, 我们的适配过程是:(1)从PreviewSize列表中选取最接近SurfaceView尺寸的PreviewSize(假设该摄像头,只支持1920*1080,和320*640),1920*1080最接近,所以被获取;(此处展示一下蹩脚的英文Try to find an size match aspect ratio and size,尝试找到纵横比与view大小比适中的一个尺寸)(2)等比例裁剪填充到SurfaceView,首先我们设计的逻辑是,先选取一个缩放比例,假设等比例1920的图片按照SurfaceView的宽度等比例缩小到1900,而为了不让Preview失真,则高度1080等比例缩小的值是1068.75(等比例方程式,这里就不重复初中的知识,请自行计算),所以图片被压缩成为1900*1068这个尺寸,依旧保证图片完整,并且不失真。(3)将等比例缩减的图片,1900*1068进行显示在1900*1000的SurfaceView中,就会有一种效果类似(图片适配例2),宽度全部展示,高度被裁剪。(如同 图片适配例2中左右部分裁剪一样的道理)
3)完全展示camera内容的缩放填充(类似图片适配例3),我们打开任意一部手机的camera,预览图像都没有全屏幕展示,类似拍照功能,所见即所得,PreviewSize是多少,就显示什么样子的比例尺寸,以及最后生产的照片比例就是多少,我们的自定义view,也可以随意设置大小,此模式下,用以完全展示camera内容为目的。Preview将被等比缩放到能够完整展示在SurfaceView中并居中,但是可能会有部分位置无法填充(类似图片适配例3显示效果)。
(该方式只是进行了技术储备,由于没有业务场景设计,所以没有使用,目前只是储备了这样的自定义控件)
四,灵活的自定义TextureView预览控件
FsCameraTextureView(第一版,自适应截取):等比例裁剪填充,方式(适配方式2),采用前面说的适配方式2,而产出的一种自定义view,2019年5月产出至今,在金融APP,以及商城的app中使用,经过逐步优化,和多版本检验,目前该控件,拥有以下特点: 1)稳定:目前各个使用场景,均无逻辑崩溃,内存泄漏,线程等任意问题; 2)灵活:随意设置预览view的尺寸大小,自适应任意业务设计;不仅仅满足刷脸业务,并且满足任意相机预览业务方使用; 3)提高效率,减轻工作量:使用简单,操作步骤简洁,接入只需要两步;减轻接入端,或者想要使用相机预览的业务的工作量,不需要重复造车,并且安全稳定。
输出的业务方有(经不完全统计):(目前业务为保密进行公网保密处理)1)**创新科技业务部-区块链部门 2)泰国人脸识别业务SDK3)S D**Bank 人脸业务4)核验身份证业务5)HT**Bank 人脸业务 6)**云,商业平台部门
FsAllPreviewCameraTextureView(技术储备版,全预览模式显示):完全展示camera内容的缩放填充,采用前面说的(适配方式3)适合拍照相关的业务使用,优点同样是,外部业务随意改变view大小,可以自适应view,由于目前没有业务方使用,暂时做储备,不深入讲解。
如果可以控件开源成功,后期,我将开源这两个控件,让更多的使用方使用,我们也希望共同技术进步,提高工程产出的使用能力。
预计下一次分享内容是(临时命名)
1)人脸核验内存和线程爆表到泄漏为零
2)分享七年前参于的Scrum(如何提高岗位间效率所定制的敏捷开发过程)
本文参考:
1、使用FFMpeg进行视频采集,使用Live555进行RTP传输,使用VideoView进行播放。
csdn提到:重载FrameSource,写一个服务类,可以从FrameSource的派生类读取帧数据,转发给live555.
评价:本方案大型访问量大的不行,少量连接比如100以内的可以。
2、用gstreamer完成采集、编码、组播。客户端使用VideoView进行播放。
评价:本方案优点为可以实现大访问量。缺点是基本从底层架构,代码量比较大。
3、使用FFmpeg进行视频采集,使用ffserver进行视频转发,客户端使用VideoView播放。
评价:优点是实现简单、容易演示,缺点是实时性不好以及用户量大不行。