android采集视频流

Ⅰ android 开发 怎么通过地址链接访问获取视频流,并解析播放

你可以直接把这个链接发送给系统播放器播放，或者用videoview播放， 你的地址链接是个参数，set一下就可以播放了

Ⅱ android中做视频监控系统，使用海康威视的摄像头，如何获取视频留，如何在android端实现编码解码

你为什么在手机端做编码呢

Ⅲ android中关于接收摄像头视频流的问题懂的指点了思路

我个人结合自己的了解，谈一点点个人的看法吧：
使用手机去查看交通、景点或是家里装的监控，与android关系不大，很多系统都可以实现。
交通、景点或是家里装的监控，可以通过网络协议，传入网络服务器，并且存储在服务器中，供随时调用。
用户使用终端，如电脑、手机等设备，按指定的方法进入到相应的服务器，通过服务器验证，输入用户名和密码，即可查看相应的内容。
前几年，杭州交-警申请IP4，用于监控各交通路口的交通情况，实现的原理就是这样的。
当然，除了使用互联网，还可以通过一些特定波段的无线来实现，但原理都是一样的。

至于说手机将这种视频流显示出来，就相对简单多了，相当于播放网络视频。

Ⅳ Android 实时视频采集—Camera预览采集与显示（平台系统camera功能理解分享）

        本文之所以有必要编写并作记录，主要原因是因为在工作中开发出一个万能的自定义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（如何提高岗位间效率所定制的敏捷开发过程）

本文参考：

https://www.jianshu.com/p/32e335d5b842

https://www.cnblogs.com/skyseraph/archive/2012/03/26/2418665.html

Ⅳ Android 编程中，MediaRecord中据说有个Icamera可以获取视频流，详细如下

MediaMetadataRetriever retriever = new MediaMetadataRetriever();
retriever.setDataSource(filePath);

Ⅵ Android 音视频01 --- H264的基本原理01

H264压缩技术主要采用了以下几种方法对视频数据进行压缩。包括：

解决的是空域数据冗余问题。

解决的是时域数据冗徐问题

将空间上的相关性变为频域上无关的数据然后进行量化。

经过压缩后的帧分为：I帧，P帧和B帧:

关键帧，采用帧内压缩技术。

向前参考帧，在压缩时，只参考前面已经处理的帧。采用帧音压缩技术。

双向参考帧，在压缩时，它即参考前而的帧，又参考它后面的帧。采用帧间压缩技术。
除了I/P/B帧外，还有图像序列GOP。

H264的基本原理其实非常简单，下我们就简单的描述一下H264压缩数据的过程。通过摄像头采集到的视频帧（按每秒 30 帧算），被送到 H264 编码器的缓冲区中。编码器先要为每一幅图片划分宏块。

划分好宏块后，计算宏块的象素值。以此类推，计算一幅图像中每个宏块的像素值。

对于视频数据主要有两类数据冗余，一类是时间上的数据冗余，另一类是空间上的数据冗余。其中时间上的数据冗余是最大的。为什么说时间上的冗余是最大的呢？假设摄像头每秒抓取30帧，这30帧的数据大部分情况下都是相关联的。也有可能不止30帧的的数据，可能几十帧，上百帧的数据都是关联特别密切的。
H264编码器会按顺序，每次取出两幅相邻的帧进行宏块比较，计算两帧的相似度。如下图：

在H264编码器中将帧分组后，就要计算帧组内物体的运动矢量了。
H264编码器首先按顺序从缓冲区头部取出两帧视频数据，然后进行宏块扫描。当发现其中一幅图片中有物体时，就在另一幅图的邻近位置（搜索窗口中）进行搜索。如果此时在另一幅图中找到该物体，那么就可以计算出物体的运动矢量了。
运动矢量计算出来后，将相同部分（也就是绿色部分）减去，就得到了补偿数据。我们最终只需要将补偿数据进行压缩保存，以后在解码时就可以恢复原图了。压缩补偿后的数据只需要记录很少的一点数据。
我们把运动矢量与补偿称为 帧间压缩技术 ，它解决的是视频帧在时间上的数据冗余。除了帧间压缩，帧内也要进行数据压缩，帧内数据压缩解决的是空间上的数据冗余。

人眼对图象都有一个识别度，对低频的亮度很敏感，对高频的亮度不太敏感。所以基于一些研究，可以将一幅图像中人眼不敏感的数据去除掉。这样就提出了帧内预测技术。
一幅图像被划分好宏块后，对每个宏块可以进行 9 种模式的预测。找出与原图最接近的一种预测模式。然后，将原始图像与帧内预测后的图像相减得残差值。再将我们之前得到的预测模式信息一起保存起来，这样我们就可以在解码时恢复原图了，经过帧内与帧间的压缩后，虽然数据有大幅减少，但还有优化的空间。

可以将残差数据做整数离散余弦变换，去掉数据的相关性，进一步压缩数据。

上面的帧内压缩是属于有损压缩技术。也就是说图像被压缩后，无法完全复原。而CABAC属于无损压缩技术。
无损压缩技术大家最熟悉的可能就是哈夫曼编码了，给高频的词一个短码，给低频词一个长码从而达到数据压缩的目的。MPEG-2中使用的VLC就是这种算法，我们以 A-Z 作为例子，A属于高频数据，Z属于低频数据。看看它是如何做的。
CABAC也是给高频数据短码，给低频数据长码。同时还会根据上下文相关性进行压缩，这种方式又比VLC高效很多。

制定了相互传输的格式，将宏快 有组织，有结构，有顺序的形成一系列的码流。这种码流既可 通过 InputStream 网络流的数据进行传输，也可以封装成一个文件进行保存，主要作用是为了传输。

组成H264码流的结构中 包含以下几部分 ，从大到小排序依次是：
H264视频序列，图像，片组，片，NALU，宏块 ，像素。

NAL层:（Network Abstraction Layer,视频数据网络抽象层） ： 它的作用是H264只要在网络上传输，在传输的过程每个包以太网是1500字节，而H264的帧往往会大于1500字节，所以要进行拆包，将一个帧拆成多个包进行传输，所有的拆包或者组包都是通过NAL层去处理的。
VCL层:（Video Coding Layer,视频数据编码层） ： 对视频原始数据进行压缩

起始码0x 00 00 00 01 或者 0x 00 00 01 作为 分隔符 。
两个 0x 00 00 00 01之间的字节数据 是表示一个NAL Unit。

I 帧的特点：

1.分组:把几帧图像分为一组(GOP，也就是一个序列),为防止运动变化,帧数不宜取多。
2.定义帧:将每组内各帧图像定义为三种类型,即I帧、B帧和P帧;
3.预测帧:以I帧做为基础帧,以I帧预测P帧,再由I帧和P帧预测B帧;
4.数据传输:最后将I帧数据与预测的差值信息进行存储和传输。

1．更高的编码效率：同H.263等标准的特率效率相比，能够平均节省大于50％的码率。
2．高质量的视频画面：H.264能够在低码率情况下提供高质量的视频图像，在较低带宽上提供高质量的图像传输是H.264的应用亮点。
3．提高网络适应能力：H.264可以工作在实时通信应用（如视频会议）低延时模式下，也可以工作在没有延时的视频存储或视频流服务器中。
4．采用混合编码结构：同H.263相同，H.264也使用采用DCT变换编码加DPCM的差分编码的混合编码结构，还增加了如多模式运动估计、帧内预测、多帧预测、基于内容的变长编码、4x4二维整数变换等新的编码方式，提高了编码效率。
5．H.264的编码选项较少：在H.263中编码时往往需要设置相当多选项，增加了编码的难度，而H.264做到了力求简洁的“回归基本”，降低了编码时复杂度。
6．H.264可以应用在不同场合：H.264可以根据不同的环境使用不同的传输和播放速率，并且提供了丰富的错误处理工具，可以很好的控制或消除丢包和误码。
7．错误恢复功能：H.264提供了解决网络传输包丢失的问题的工具，适用于在高误码率传输的无线网络中传输视频数据。
8．较高的复杂度：264性能的改进是以增加复杂性为代价而获得的。据估计，H.264编码的计算复杂度大约相当于H.263的3倍，解码复杂度大约相当于H.263的2倍。
H.264的目标应用涵盖了目前大部分的视频服务，如有线电视远程监控、交互媒体、数字电视、视频会议、视频点播、流媒体服务等。H.264为解决不同应用中的网络传输的差异。定义了两层：视频编码层（VCL：Video Coding Layer）负责高效的视频内容表示，网络提取层（NAL：Network Abstraction Layer）负责以网络所要求的恰当的方式对数据进行打包和传送。

Ⅶ android视频流处理

《android逆向视频》网络网盘资源免费下载

链接:https://pan..com/s/1W1NAE-AeKbz0bb6E4mdXfA

Ⅷ android mediarecorder硬编码获取音视频流，怎样设置时间戳达到音视频同步

参考spydroid开源项目，这个开源项目有音频(aac)，视频(H264)流的读取，具体操作都有，就是音视频时间戳不知怎么弄，音视频同步搞不定，您有想法记得分享哦！

Ⅸ Android 如何实现摄像头不进行预览显示，只获取视频流数据

好像是强制要求有预览的,安全问题,比如偷窥什么的所以不允许无预览画面的使用摄像头