您当前位置: 首页 » 音视频_图像相关 »

音视频编解码

分类目录归档: 音视频编解码

实践正当时(二)

继上次的更新 实践正当时(一)

上次的版本已经支持了:

1. 支持264
2. 简单解析nalu
3. 解码出码流
4. 拿到运动适量
5. mv ui绘制(用了ffmpeg的codecview来绘制运动适量)

这次新增有:

  1. 当前帧poc
  2. decode/disp顺序计算(在外部进行计算的,实际上可以通过vui里面的信息来计算,还没开始完全看decoder的代码,对vui也不熟悉,所以暂时实现功能先)
  3. 增加fp/bp的mv显示功能
  4. 基本播放、调试功能
  5. 能够获取当前预览帧中的具体某个16*16快的mv信息并显示出来(mv方向、位置信息)
  6. 块信息:块类型(例如,intra 8*8 L0L1),delta_qp
  7. 帧信息:avg_qp, delta_qp(这个应该还有问题,一直都是-2,看上去是从pps获取的估计哪里不对,需要继续了解一下vui语法和解码器内部*)

下一个版本准备新增:

  1. slice_type(一个硬骨头,其他参数获取会更麻烦点,因为需要看明白代码,parser组帧完成后就需要关联到picture上)
  2. 修改codecview filter,增加16*16 block绘制
  3. vui信息获取
  4. 参考信息关联(也是个硬骨头,比slice_type麻烦些*)

未来需求:

  1. 性能优化(优先级最低,除非出现不可忍受的情况)
  2. 残差图
  3. 频域图
  4. 支持265
  5. 自动化诊断码流问题(等其他功能差不多再说,这个需要大量实践经验,还需要了解vui)

实践正当时(一)

之前给自己定过一个3年左右的计划,原因很简单,不管什么上天还是入地的公司,对我来说无非就是一个打工的地方而已;随时也要做好被公司用完就丢的准备。

既然到了所谓就业歧视年龄线,那就应该拿出一定的所谓能力来,不是技术上有一些自己可以落地的时间,就是管理上有很强的的软实力。

目前来说,进入管理通道之前,该有的技术实践还是需要跟上,后续想走资源受限场景下的卡顿、画质方向的优化,所以对网络和编解码相关有一个感性到浅层的了解时必须的。

为了了解编解码,为了不受到一些所谓的技术专家和算法专家的歧视,业余时间自己倒腾一个码流分析工具,同时也是为了自己可以用。

目前是ffmpeg + duilib来做的,首先我想当排斥做界面,一方面我自己不感兴趣,另一方面这东西要做深门槛很高,奈何这玩意入门门槛太低,庄家太多受不了这种乌烟瘴气的环境。

用ffmpeg来做码流处理,主要是因为解码器开源,可以看到代码也能试着去按照自己的需求改,另一个确实什么更快又更好的选择。

目前完成的功能有:

  1. 支持264
  2. 简单解析nalu
  3. 解码出码流
  4. 拿到运动适量
  5. fuck ui绘制(用了ffmpeg的codecview来绘制运动适量)

接下来要做的功能:

  1. 拿到qp
  2. 拿到参考信息,帧级,块级
  3. vui信息解析

后续需要完成的功能:

  1. 性能优化(优先级最低,除非出现不可忍受的情况)
  2. 残差图
  3. 频域图
  4. 支持265
  5. 自动化诊断码流(等其他功能差不多再说,这个需要大量实践经验,还需要了解vui)

ffmpeg + vs2017 编译(持续更新)

前言

2022的计划,就是开始做个小工具,拿来分析es流,主要通过解码器解码es流,来获取编码中一些过程,比如预测方向,slice qp等等。当然也包括最基本的parser,虽然这块会有很多bug(只要是字节流相关的代码都很容易出现解析和打包问题)

所以现在最先需要解决的是ffmpeg的编译,然后再找一个稳定简易的界面库来先基本完成264的码流解析和解码工作。

脚手架选择

windows terminal

msys2

vs 2017

安装

略过

编译

配置

windows terminal

msys2

这里需要说明的是,msys2现在支持ucrt和mingw64两种链接方式,区别在于前者使用系统自带的crt链接到编译出来的库中,后者使用msvs的。目前还是继续使用mingw64的版本

#先更新一下
pacman -Syu

#库管理工具
pacman -S pkgconf diffutils


pacman -S make

#sdl2必须品
pacman -S mingw-w64-x86_64-nasm mingw-w64-x86_64-gcc mingw-w64-x86_64-toolchain

vs 2017

其他

关于ffplay的编译

由于msys2自带的sdl2包和本地vs编译环境可能存在一些不兼容的情况,所以有两种办法。所以需要单独下载sdl2编译后,再创建ffplay的vs工程来做。

2022-01-08 | | 爱捣腾的小玩具, 码流学习, 编码技巧, 音视频_图像相关, 音视频编解码

ffmpeg + vs2017 编译(持续更新)已关闭评论

2022计划定一下

虽然我一直都是将自身技能分为软技能和硬技能,并且按照一定规则来进行计划,不过还是有必要重新考虑一下侧重点,这么几年下年,折腾来折腾去,东搞搞西弄弄,一直没有很好的执行一个系统性或者专业化的自身知识技能体系。但维度有一点很明确的是,自身工作方向一定要和自己的目标知识建设是存在较大关联或重合的,这方面做的还是不错,所以大部分时间都没有跑题跑的太偏了。

硬技能

  • 学历、院校、就职单位
    • 可遇不可求,有些事情已经定型了不行了。
  • 性格
    • 江山难改本性难移,只能说尽量保持克制和改善。不忘初心也很重要
  • 为人处世
    • 最讨厌乌烟瘴气、帮派和小圈子,除非有必要,小圈子是一个不错的选择,但是小圈子很容易会和前两者有很强的关联性。还是需要一定程度上的假装合群
    • 站队,不站队远比站队还严重。一直以来都不站队,或者抗拒站队,在一个比较强调控制的团队或组织里面,很容易被弄,最后过得也很惨,不过也从侧面反映了,这种团队和组织没必要长待,长久不了;事实却是证明了,不管多少年过去,这种组织或机构要么都死掉了,要么勉强维持着现状。
    • 有时候少一点有意而为,很多时候明知道这样做的结果会如何。但自己偏偏不信邪,并且带着好奇心的故意做一些事情,反过来观察大家的反应,尽管确实很有效果,也相对客观准确的能观察到信息,但实际上不太理想,容易变成掘地自焚。
  • 管理 & 洞察
    • 尽管不喜欢也不想做管理岗位,也不愿意去做。主要还是不愿意和人打交道,不想去搞那些麻烦的人和事,也不想承当责任。
    • 但事与愿违,年纪上去了,就该适当的考虑扩宽自身的路子。所以管理岗的一些同事,他们的行为风格是一个较好的学习习惯,和观察机会。透过他们可以间接学习一些成与败的经验。
    • 从小到大洞察能力是不需要做任何评价的,这一个点是先天有优势,但还需要注意一下,不能让自身主观兴趣过多的去主导洞察的目标和信息的获取。先收集信息,后整理和分类。然后适当的对洞察结果做出相应,稳优先,切莫太急躁,因为现在认为干扰信息也挺多的。

软技能

  • 知识深度
    • 这里需要明确,这里提到的知识深度不同于公司层面,因为公司层面更多是通过所谓的知识深度来淘汰人的一个借口罢了。
    • 这里更多是结合现阶段自身岗位情况,和未来目标可达岗位情况去指定的知识深度学习计划
      • 编解码
        • 目标:<了解>编码原理,能够通过码流的一些现象来判断大致的问题
        • 知识范围(粗略,待二次细化):
          • <了解> x264预处理过程
          • <了解> x264图像分割的过程(预测、宏块划分)
          • <了解> x264熵编码特点(非了解算法内部)
          • <选择了解> x264 码控等相关模块
        • check point(2-3年完成):
          • 产出工具或matlab脚本,演示预处理过程
          • 产出工具,可视化预测、宏块信息(先帧内,后帧间)
  • 知识广度
    • 这里需要明确,这里提到的知识深度不同于公司层面,因为公司层面更多是通过所谓的知识广度来淘汰人的一个借口罢了。
    • 这里更多是结合现阶段自身岗位情况,和未来目标可达岗位情况去指定的知识广度学习计划
      • 策略器
      • 目标:搞清楚现有的一些策略器,对媒体“流畅”和“质量”的影响有哪些,如何做到的。
      • 知识范围:
        • <了解> 采集 <-> 前处理 策略通路
        • <了解> 前处理 <-> 编码 策略通路
        • <了解> 编码 <-> 编码 策略通路
        • <了解> 编码 <-> 网络 策略通路
        • <了解> 总控 <-> 各子控 策略通路
      • check point(1-2年把大致流程搞清楚):
        • 产出详细图(正在做)

留意几类人

  • 没自知之明,自以为是;关系不便搞僵,不过距离要保持住
  • 自私的人,这些人靠利益维系
  • 小圈子,小帮派。凡是”小“这个东西就很成问题
  • 虚的人
  • 看似很好打交道,其实很难的人

【英伟达】nvenc/nvdec/sm关系猜测

因为不是做cuda相关开发,临时被拿来做调试一些相关代码。看到官方的一些介绍并不是很清晰,并没有完全说明cuda计算单元和nvenc/nvdec关系。仅仅提到nvenc和nvdec是两个编解码引擎。

并且还对特定显卡做了nvdec和nvenc的限制,对于一些老卡上,并没有nvdec和nvenc引擎。

官方给出的定义是nvdec、nvenc是独立于cuda核心,并不是很理解。或许nvdec和nvenc是相对于cuda核心的单纯的计算功能而划分出来给视频编解码使用的一个特定模块。

上网查了一下,以前的GPU加速编解码,实际上是利用cuda计算单元做一些数学计算,加快编解码速度。而nvenc和nvdec可以直接未编码数据或已编码数据进行处理。

那么这里就很好奇了,nvenc是一个单独的物理模块,还是一个逻辑模块。

通过对比实验发现还是稍有区别:

  • 第一个实验,仅使用nvdec、nvenc,以及ffmpeg的混流滤镜。得到的数据如下:
  • 第二个实验,通过外部加载一个推理模型。将解码好的数据丢给推理模型进行推理后,再返回解码,所有的过程均在显存中进行。

通过nvidia-smi dmon,可以发现除了流处理使用率有所增长,在程序初始化初期,从数据是上来看,可以推测nvenc和nvdec实际上还是利用到了部分流处理器,至于把这些流处理器拿来做什么就不得而知,也许只是作为解码初始化的一些树的加速计算,也许仅仅是被划分到nvenc、nvdec中参与编解码工作。

后续还需要一些相应深入和系统性的了解才好做判断。

2020-10-27 | | GPU相关, unix编程环境学习, 音视频_图像相关, 音视频编解码

【英伟达】nvenc/nvdec/sm关系猜测已关闭评论

【ios、x264】将静态库打包成动态库,链接时的text relocations错误

最近在ios上出现将多个sdk放到一个app时,有各种开源静态库冲突的问题;于是考虑将自己用到的库进行打包成动态库版本,以此解决冲突问题。

在进行打包成动态库时,发现x264问题最大。打包出来的库在链接期出现text relocations错误,网上找了以后发现基本都是进行忽略这个错误,事实上这个错误忽略了没用,app启动时还是会出现相应的crash。

换了几个版本的xcode进行测试,发现x264编译会出现不同情况的告警和错误,根据底部罗列的参考文章,估计xcode的编译器可能也有一些bug。

后来模仿android上的编译方式,在x264里加入了–enable-pic和–disable-asm顺利编译通过,但由于osx和xcode版本的因素,模拟器上的并没有编译出来,仅仅编译了armv7和arm64。

 

参考文章:

MacOSX下编译linphone(text-relocation错误说明)

libxxx.so- text relocations问题的终极解决方案(android)

Linker error when using incremental builds on iPhone

Android Gradle编译so库或运行时出现 text relocations 崩溃的正确解决方法

2018-06-15 | | [linux总结], unix编程环境学习, 编码技巧, 音视频_图像相关, 音视频编解码

【ios、x264】将静态库打包成动态库,链接时的text relocations错误已关闭评论

【h264、baseline、flv】使用baseline做双向强交互直播不利的几点因素

再说baseline做强交互不利因素之前,先说说现在直播的场景情况。

 

场景如上图,推流段不是移动平台,就是PC机。当然最近几年也出现专门用来推流的定制盒子,本质不是一个嵌入式windows,就是一个android设备(android设备较多)。

  • 而对于PC机作为推流端来说其实问题并不大,只要在保证带宽足够理想的情况下,采用264的任何一种profile都能尽可能的做到最大延时接近编码器固有延时的效果。同样对于使用何种容器来说问题都不大。

 

  • 但对于移动设备来说,需要匹配的情景就很多了,主要是由于移动设备的电池续航能力、操作系统小类别太多、整体性能表现。在使用264编解码时,一般尽量采用硬编解码,对于实在没有办法的情况下才使用软编解码。就仅仅一个硬编解码上就存在诸多差异,例如有些profile硬件不支持,或者rom上存在一些问题导致本该支持的profile,支持的不好或者根本不支持。

 

  • 除了上述提到的问题以外,其实还有一个隐形问题,那就是用户使用习惯问题。现在的用户越来越偏向于使用web方式展现的产品,一方面对于开发者来说,界面改动较为简单灵活,另一方面对于用户来说,只需要打开浏览器即可,简化使用步骤。

然而上述提到的这些问题,就造就了可能大家会想到flash、h5和native应用,对于native应用来说还好,开发起来虽然周期长,但可塑性比较强。对于flash和h5来说可选择余地就非常小了。

暂时不说flash和h5本身在做双向强交互直播是否可行,先说一说两者采用的协议类型。对于flash来说:

  • 通讯协议为rtmp系列协议(包括rtmpt等),协议本身并不是太复杂,但涉及当初并不是用来做双向强交互的直播协议,因此协议本身就没有在双向强交互上做太多的考虑。

 

  • 由于协议本身所承载的流媒体容器格式为flv或f4v,现在大部分直播平台基本采用的是flv作为容器,同时flv也是一种较为简单易用的容器

 

  • 但由于flv容器格式的限制,在adobe官方手册中就已经说明,flv容器支持的264的profile范围中,目前仅对baseline、extended、main、high、high10、high4:2:2、high4:4:4,在经过简单测试之后,如果不考虑flash端推流的情况下,用户电脑(移动端一般用h5,不用flash)性能具备一定保证的情况下,再根据官方手册并测试(as3手册),没有实际去测试过high10,不过脑补得知high10也是可以的,但延时太大,也有可能会引起其他flash异常。因此往往最佳的选择就在baseline、main、high中选择,因为他们的颜色编码是8bit的。从解码效率和广泛性来说,这三种都可以。

 

  • 但由于是双向直播,因此,在这时就需要考虑编解码器的时延问题。这时,大家一贯的做法就是关闭B帧编码,这样即可极大的提高编解码延时。当关闭了B帧编码之后,剩下几种profile互相比拼的就是在给定的一个平均分辨率、gop的情况下,编解码固有时延和数据码率,以及支持的广泛性。实测之后发现high其实在不同浏览器的flash上表现存在一定差异,主要情形为编解码速度、性能开销等等。因此在flash上使用high这种方式时,还需要综合考虑。

 

接下来说一说h5方式的直播:

  • h5方式的直播一般是通过websocket进行通讯,协议是hls,容器格式为ts、ps。然而我对hls和ts、ps都不是很了解。

 

  • h5支持还有待进一步推广,目前在较新的chrome系浏览器和较新的firefox浏览器上均支持较好。IE系暂时较弱(我把edge理解成IE系)。

 

  • 就目前来说,从开发手机端开发难度,和各手机厂商的支持力度上,无论是webview app还是native app来说,hls+ps/ts也是较优选择。

 

  • 通过看了苹果官方的FAQ得知,hls协议似乎仅仅支持baseline、main、high三种,不清楚是由于ts、ps容器特性导致的,还是hls协议特点。因此在决定使用哪一种profile时,又回到了和flash一样的情况下。

 

通过以上可以得知,实际上在使用x264编码时,最终在profile的选择上基本就限制在了baseline、main、high三种。从算法复杂度上来上讲,baseline是最为简单,而high是较为最为复杂(主要是预测模型比前两者多不少)。

不过在实际工程应用中,我们还是做了一个比较脑残又没有办法的决定,那就是使用baseline。原因有二:

  1. 我们使用的编码库是openh264,早期版本的openh264宏块分割方式较小,也仅仅支持baseline,对main也只是仅限于试验阶段。
  2. 在同样的profile级别下,参数大致相同的情况下,openh264的编码时延比x264的utral模式下略高,但码率略低(未做定量测试,简单定性测试得到的结论)。编码完的数据解码出来的视觉感受差别不大,反正都是渣画质。

考虑到使用场景和当时网络的大环境,确实选择openh264,即是无奈的选择,也是一个极其脑残的选择。说无奈主要是现实,说脑残是因为压根就没有做过定性分析。。。。。。

然后接下来就开始“数落数落”baseline不适合做双向强交互直播的原因。在看x264的代码时,偶然对编码中的预测做了少许的了解。

—- 我是装逼的分割线 1号 —-

传统上对一副图像的处理,一般的理论是基于“分割”,由于图像一般情况下具有前景和后景之分,也就是说,前景和背景之间存在着大量的局部图像细节,对于图像压缩中的思路往往是,尽量将相似的区域用差别不大的统一一个区域去表达,对于差异较大的区域,尽量在用较多的数据量去存储以此保留图像的局部细节。

那么就会存在如何分割图像的问题。如果是一副简单单值图,例如大学时代我做的非矢量图压缩(理论基础差不多),那么只需要根据图像分辨率,做相应的最佳分割快大小计算,并做简单切割即可。将区域内的有色的点和无色的点进行记录,并按做纵向或横向切割成色带,记录色带中有色点或者无色点的坐标值即可。整个思路转换成代码思维,类似于多级联映射表。当然这个做法的关键还在于公式如何设计,即如何动态计算切割区域的大小。由于是做印章方面,所以图像不会太大,因此公式也非常简单。

最终压缩可以理解成单值图的无损压缩,实测试之后,和转换成矢量图之后的文件大小相比,应该两者都会比现在主流的大部分图像编码小非常多。

接着通过类似7z、rar工具里面的二进制压缩算法进行再次压缩,文件最大还能缩小60%左右。一个500k的位图最终生成文件在3k左右。

—- 我是装逼的分割线 2号 —-

由于有上面的实践基础,因此在理解264的压缩时,我也能够理解到“分割”时的重要性。

首先,在baseline模式下,x264的预测模型相对于其他high来说,非常简单。这样的情况就决定了,在局部的细节切块相比high来说有着很多不足,对二进制数据进行压缩前就已经输在起跑线了。即细节丢失比high多。

其次在编码算法上(或者说压缩算法上),baseline仅仅使用cavlc,而对其他两者来说他们既可以使用cavlc也可以使用cabac。没有做过定性或者定考量分析,但通过网上资料获知,cavlc的效率似乎没有cabac高,具体在哪些指标有所体现目前暂时并不清楚。

因此,可以得知。baseline除了在实时性上满足了双向强交互直播对时间的要求,对于相同质量下的压缩比并不是很好。但又由于baseline相对其他profile的简单特点,其实广泛性还是比较不错的。

手里有台android 2.3时代的三星手机,对baseline的视频进行解码,手机基本可以应付(不清楚是硬解还是软解,因为当时的arm好像还有没有对264硬解做太多优化),但相同视频长度的main和high的话,那就有点头疼了。看来baseline对老旧手机还是比较“良好”的。

2017-11-22 | | matlab, 数据结构 & 算法, 音视频_图像相关, 音视频编解码

【h264、baseline、flv】使用baseline做双向强交互直播不利的几点因素已关闭评论

【x264、宏块、邻居】x264中对宏块预测方向与邻居类型的定义

在x264中,由于单一宏块预测方向与264规范定义实际上是一直的,即预测方向只有:左(left)、上(top)、左上(left-top)、右上(right-top)。

没有其他的另外四个方向,估计可能是zig-zag的数据排列有关,或只是由于对称关系,不需要做重复预测。

有上述4中预测方向,x264中定义了几种邻居关系(下面拿I帧4×4的宏块距离说明):

  • 垂直方向,即I_PRED_4x4_V、I_PRED_4x4_DC_TOP,实际上是向上方向预测(top)
  • 水平方向,即I_PRED_4x4_H、I_PRED_4x4_HU、I_PRED_4x4_DC_LEFT,实际上是向左方向预测(left)
  • 左边和向上方向,即I_PRED_4x4_DC
  • 向上旋转到右上方向,即I_PRED_4x4_DDL、I_PRED_4x4_VL
  • 左边旋转到向上方向,即I_PRED_4x4_DDR、I_PRED_4x4_VR、I_PRED_4x4_HD
  • 左边旋转到向上方向,即I_PRED_4x4_VL
  • I_PRED_4x4_DC_128代表自身?
2017-11-21 | | 数据结构 & 算法, 音视频_图像相关, 音视频编解码

【x264、宏块、邻居】x264中对宏块预测方向与邻居类型的定义已关闭评论

【x264、视频、编码、宏块】编码成不同帧时,宏块参数的变化情况

出于好奇最近在看x264的源代码。

对于不管是263、264还265编码来说,图像的压缩大题思路实际上是没有太大变化的。

对图像的压缩和编码,分为相关和非相关部分。又由于263、264、265并没有定义一定是无损压缩,所以在压缩和编码上与音频的编码和压缩也有着相似的处理方式;即,按照人的视觉特性进行编码(人眼分辨画面细节的能力是有限的)。

相关性压缩(和编码)又分为帧内相关和帧间相关,即编码出来的I帧就是我们所说帧内相关,B、P帧则是帧间相关。

对于非相关编码部分,大部分都集中在图像的前期处理上,例如归一化、白平衡、色度调节等。步骤大致如下:

  • 在图像预处理完成后(归一化、降噪等),接下来就是x264较多需要做的事情图像编码与压缩(虽然x264自身也会做一些降噪、再降噪、色度调节等)。
  • 先说编码部分,x264里面先将一副raw数据(可能是yuv420,可能是yv12等等),进行切块(即宏块分割,图像简单预测)。
  • 将分割好的图像在做块内再分割(细节预测,找出图像细节部分,对细节部分在切割,变成小块)
  • 接着又对每一个块做相邻之间的差异化计算(其实就是求出差异),这个过程是最复杂的一个。

 

下面是对于不同类型帧切块分类的说明其他具体的解释会在后续说:

 


 

其中对于不同类型的输出帧,宏块的大小如下:

I帧:

16*16、8*8、4*4


P帧:

L0、8*8、SKIP


B帧:

DIRECT、L0L0、L0L1、L0BI、L1L0、L1L1、L1BI、BIL0、BIL1、BIBI、8*8、SKIP

 


 

 

2017-11-20 | | 音视频_图像相关, 音视频编解码

【x264、视频、编码、宏块】编码成不同帧时,宏块参数的变化情况已关闭评论

【编译、ffmpeg、msvc】windows下编译ffmpeg

由于最近使用的ffmpeg及其相关的库太过于老旧,所以需要进行更新。

对于视频方面的编码主要用到h264,音频则用到mp3、aac、speex。

其中最为坑的,还是mp3和aac。因为mp3中的分支太多,为了简化问题,最后还是选用lamemp3作为编码器。在ffmpeg 3.0开始,ffmpeg就停止了aacplus的使用,改为使用fdk aac。并且ffmpeg还自带了一个aac编码器。

在编译过程中由于没有注意到这个问题,因此使用了内置编码器,导致he aac编码出来的数据缺少sbr段。因此需要外部加入fdk aac来完成。

 

  • 先说一说需要提前做的一些准备:

1、lamemp3源代码

2、speex源代码

3、fdk_aac源代码

4、x264源代码

5、ffmpeg源代码

6、安装msys2极其相应的工具(如果在windows上编译)

7、vs2015(如果在windows上编译)

 

lamemp3编译步骤:

直接代开源代码下vc_solution目录,使用vs2015编译即可

 

speex编译步骤:

打开win32目录下的vs2008直接用vs2015编译即可

 

fdk_aac编译步骤:

fdk_aac编译比较坑,不能在msys2中编译,需要用nmake(vs工具链)直接编译就好……

 

x264编译步骤:

在msys2中直接编译即可

 

ffmpeg编译步骤:

1,将speex、mp3、aac中include的部分代码拷贝到ffmpeg根目录下

2,在将相应的lib文件拷贝到根目录下的某个文件,这里用3rdparty来代表目录

3,执行编译命令

./configure –prefix=/c/work/github/ffmpeg_src_3.2/out –toolchain=msvc –enable-libx264 –enable-libmp3lame –enable-libfdk-aac –enable-nonfree –enable-libspeex –enable-gpl –extra-cflags=-IC:\\work\\github\\ffmpeg_src_3.2 –enable-shared –extra-ldflags=-LIBPATH:C:\\work\\github\\ffmpeg_src_3.2\\3rdparty\\lib

4,执行make和 make install之后即可

 

2017-08-31 | | win, 编码技巧, 音视频_图像相关, 音视频编解码

【编译、ffmpeg、msvc】windows下编译ffmpeg已关闭评论

【vs2013、msys2】vs2013命令行环境变量不继承到msys2

编译一些开源的时候不得不需要用到msys2。所以需要现在vs2013的命令行环境中启动msys2环境,这样就可以把vs的命令行环境变量继承到msys2。

目前最新版本的msys2会出现不继承的情况,主要由于msys2 中/etc/profile文件中继承脚本的过滤了vs的一些有效环境,参考csdn上一个博客的修改方法,修改成如下:

 

2017-05-17 | | [奇葩类]求上进系列, 编码技巧, 音视频_图像相关, 音视频容器, 音视频编解码

【vs2013、msys2】vs2013命令行环境变量不继承到msys2已关闭评论

【winxp、vista、webrtc、chromium】放弃支持xp的路上webrtc跟上了!

最近拿了59的分支代码,后来偶然看到webrtc把wavein/waveout函数族相关的代码删除掉,看git注释另外根据chrome弃疗的心语路程,webrtc终于放弃xp了。

但苦了我了。。。。。。因为国内还有着一大群xp用户。。。。

2017-05-08 | | *生活*, 思考, 音视频_图像相关, 音视频容器, 音视频编解码

【winxp、vista、webrtc、chromium】放弃支持xp的路上webrtc跟上了!已关闭评论

【chrome、webrtc】python-boto代理设置

webrtc最近半年的时间里又改代码框架,又改下载脚本!真***法科!

 

目前除了使用到python-curl、git、还用到了一个叫做python-boto的玩意,用来从aws上下东西的。不理解为啥不用自家的云。。。。

现在拿webrtc的代码,除了需要配置git、python-curl的代理,还需要配python-boto的代理。

python-boto的代理配置方式如下:

1,在某个目录中创建一个.cfg后缀的文件

2,然后填入内容如:

  1. [Boto]
    proxy=127.0.0.1
    proxy_port = 10808

3,命令行中输入!

  1. NO_AUTH_BOTO_CONFIG=C:\work\depot_tools\boto.cfg

2017-05-08 | | shell, windows-shell, 编码技巧, 音视频_图像相关, 音视频容器, 音视频编解码

【chrome、webrtc】python-boto代理设置已关闭评论

【c++11、webrtc、stl】利用stl“就地构造”提高代码性能

最近在看webrtc的trunk上最新的代码,今天无意间留意到了stl容器中的“std::vector<T>::emplace_back”。事实上在接触webrtc之初我就经常能看到这个方法的使用,只不过那时候的对webrtc完全不了解,所焦点都在webrtc是个什么东西上。

 

后来查stl官方文档,看到的解释为:

构造并插入元素

同时网站上也给出了列子,但并不是很明确。看vs2015中对该函数的实现,实在看不懂(因为和push_back的一个分支实现很非常相似)。google看到这个函数代表在vector内部进行构造并放到数组里。

这样做的好处在于不需要去特意写移动构造函数,也不需要进行任何移动操作。间接的加快了性能。

 

 

 

ps:由于网上的说法存在问题,所这里要明确更正一下。

emplace_backpush_back两个函数都是通过“布局new”的方式将元素对象的内存放到自己的中(并非栈中)。

 

 

2017-05-02 | | 思考, 算法导论, 编码技巧, 音视频_图像相关, 音视频容器, 音视频编解码

【c++11、webrtc、stl】利用stl“就地构造”提高代码性能已关闭评论

【MacOSX、iOS、跨平台编译】在跨平台编译时MacOSX Serria/XCode是我遇到bug最多的平台

最近被安排来搞定android、ios、mac、windows下的webrtc、ffmpeg和x264的编译问题。

除了由于webrtc配置工程的问题在windows下我自己的搭建环境无法使用,最终求助于之前使用的虚拟机环境以外,android下的webrtc都比较顺利,同样也是编译anroid环境的和windows环境的ffmpeg,相对来说也是比较顺畅(虽然还是出现了一些坎坷)。

但在Mac环境下编译webrtc、ffmpeg和x264就没有那么幸运了。简直就是人间地狱,首先说明一下,这个Mac机原先是有其他开发者在上面编译成功过这三个工程的,到我之后就开始出现了一大堆问题(当然也有可能我用的是用户新帐号的缘故)。

 

人间地狱的开始

  • 先说一说编译webrtc遇到的坑爹问题。由于webrtc编译环境我们只输出静态库,并不输出一个framework或者app,所以并不需要关心太多app层面的问题(如证书相关)。虽知道在webrtc的gyp检查项目中会对证书冲突做检查,由于机器中存在多个证书,导致gyp阶段无法生成正确的编译配置参数。导致折腾了一周,最后才发现和证书有关。虽然这个问题和gyp有一定的关系,但也只是我对mac上编译和交叉编译的被坑的起点。

 

  • 接着是x264和ffmpeg编译时,由于给我的工程之前都是能够成功编译的,现如今拿过来,除了Mac平台可以通过以外,真机和模拟器都不行。折腾来折腾去几天,最后发现是clang去找依赖的时候找错了,找了mac的依赖环境,而不是去找iphoneos的依赖,然后怎么调都没用。很是坑爹,就拿网上的现成脚本来跑也是不行。

最后去查config.log,发现一堆错误,其中ffmpeg的错误还有一个叫做gas-preprocessor.pl的执行错误,由于是通过git直接从网上拿下来的脚本,在没有任何修改的情况下,通过sftp发到mac里面,给了执行权限之后通过命令行直接执行一点问题都没有,但通过configure执行时就一直报没有权限的错,怎么也想不明白;后来试着用curl拿文件,居然通了。当时我就估计如果不是字符集的问题,就是权限标记位的问题。

接着再继续修改关于依赖的问题,仅仅一个交叉编译工具clang,居然在不同的工程里面对同一个路径参数能够出现多种不同的行为,后来还特意看了一下clang是不是GNU开源社区的代码,通过–version看到的内容如下:

Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin16.4.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

可见这个坑是苹果自己的。可能是由于命令行的长度的不同,导致解析命令行的bug?或者其他什么坑爹问题?反正我是不知道了,近几年开始苹果的产品也不见得有多少优势了,正在被一点点拉小差距。如果不是为了混口饭吃,苹果的任何产品我真的不想去碰!

2017-03-20 | | linux-shell, shell, unix编程环境学习, 图像处理, 音视频_图像相关, 音视频编解码

【MacOSX、iOS、跨平台编译】在跨平台编译时MacOSX Serria/XCode是我遇到bug最多的平台已关闭评论