FFMPEG编码debug模式没问题,release模式报错

FFMPEG编码debug模式没问题,release模式报错

我在做“火灾监控预警软件”时编译工程,需要使用ffmpeg对H264码流解码。发现在用到ffmpeg debug版本运行正常,切换到release时,出现“无法定位程序输入点?。。。于动态链接库avcodec-56.dll”。

我是直接从http://ffmpeg.zeranoe.com/builds/网站上下好的已经编译通过的dll。当时我就怀疑dll只是debug模式下编译的,而非release版本。

但我下载的文件中并没有区分debug与release版本的dll。

所幸查找关键词“ffmpeg release 错误 动态链接库无法”,发现了解决方案:

只要修改工程属性可以解决这个问题。首先打开工程属性,找到链接项目,在优化中有个引用项,选择保留未引用数据(/OPT:NOREF)即可,我的工程是英文版,截图如下:

在MSDN上查找/OPT(优化)相关信息

REF | NOREF

/OPT:REF 清除从未引用的函数和数据;

/OPT:NOREF 保留从未引用的函数和数据。

当启用 /OFT:REF时,LINK会移除未引用的已打包函数和数据。 如果对象已经用 /Gy 选项编译过,它将包含打包的函数和数据
(COMDAT)。 此优化称为可传递的 COMDAT 消除。 默认情况下,在非调试生成中启用 /OPT:REF。 若要重写此默认值并在程序中保留未引用的 COMDAT,请指定 /OPT:NOREF。 可以使用 /INCLUDE 选项重写特定符号的移除。

在显式或默认启用 /OPT:REF 后,将启用受限形式的 /OPT:ICF(仅会折叠相同的函数)。 如果需要 /OPT:REF 而不是 /OPT:ICF,则必须指定 /OPT:REF,NOICF 或 /OPT:NOICF

如果指定了 /DEBUG,则 /OPT 的默认项是 NOREF,而且所有函数都保留在映像中。 若要重写此默认项并优化调试生成,请指定 /OPT:REF。 由于 /OPT:REF 隐式使用 /OPT:ICF,建议你同时指定 /OPT:NOICF 以在调试生成中保留相同的函数。 这样更容易读取堆栈跟踪以及在本应折叠在一起的函数中设置断点。 /OPT:REF 选项禁用增量链接。

你必须将 const 数据显式标记为 COMDAT;使用 __declspec(selectany)

指定 /OPT:ICF 不启用 /OPT:REF 选项。

    ICF[= iterations ]| NOICF

使用 /OPT:ICF[=iterations] 执行相同的 COMDAT 折叠。 可以从链接器输出中删除冗余 COMDAT。 可选 iterations 参数指定遍历符号以查找重复项的次数。 默认迭代次数是两次。 附加的迭代可以找到更多前一次迭代中未通过折叠发现的重复项。

指定 /OPT:REF 并且 ICF 默认为有效时的链接器行为方式与显式指定 /OPT:REF,ICF 时的行为方式不同。 单独使用 /OPT:REF 启用的 ICF 的窗体不折叠只读数据(包括
.rdata、.pdata 和 .xdata)。 因此,为 x64 生成映像时将折叠较少的函数,因为这些模块中的函数更依赖于只读数据(例如.pdata 和 .xdata)。 若要获取完整的 ICF 折叠行为,请显式指定 /OPT:ICF

若要在 COMDAT中放置函数,请使用 /Gy 编译器选项;若要放置 const 数据,请将其声明为 __declspec(selectany)。 有关如何指定用于折叠的数据的详细信息,请参阅 selectany

默认情况下,如果 REF 处于打开状态,则 ICF 处于打开状态。 若要重写此默认值,当指定 REF 时,请使用 NOICF。 当未在调试生成中指定 /OPT:ICF 时,你必须显式指定 /OPT:REF 以启用
COMDAT 折叠。 但是,由于 /OPT:ICF 能合并相同的数据或函数,因此它也能更改显示在堆栈跟踪中的函数名。 它还能使你无法在某些函数中设置断点或在调试器中检查某些数据,并让你在单步执行代码时进入意外的函数。 因此,建议不在调试生成中使用 /OPT:ICF,除非较小的代码的好处能弥补这些不足。

时间: 2024-10-07 04:50:49

FFMPEG编码debug模式没问题,release模式报错的相关文章

debug运行可以,release运行报错的原因及修改方法

通常我们开发的程序有2种模式:Debug模式和Release模式在Debug模式下,编译器会记录很多调试信息,也可以加入很多测试代码,方便我们程序员测试,以及出现bug时的分析解决Release模式下,就没有上述那些调试信息,而且编译器也会自动优化一些代码,这样生成的程序性能是最优的,但是如果出现问题,就不方便分析测试了,Release模式通常用于正式发布.原因:debug运行比release少一些文件,qt保证能在debug下运行,但并不能保证它在release下就能正常运行.修改方法:1.首

QSqlDatabase: QMYSQL driver not loaded 解决方法(debug下正常,release下报错)

环境: QT 5.11 Mysql 5.5 MSVC 2015 编译器 以上全为64位 症状为: Debug下连接数据库正常,Release下连接数据库失败 提示如下: QSqlDatabase: QMYSQL driver not loaded QSqlDatabase: available drivers: QSQLITE QMYSQL QMYSQL3 QODBC QODBC3 QPSQL QPSQL7 注意,这种情况下根本就不需要手动编译Mysql driver,因为Qt已经自带了 按网上

使用Gradle编译release apk报错:Please correct the above warnings first

在开发SDK的过程中,遇到了一个研发,使用了自己的SDK之后遇到了各种问题,于是我们自己帮忙接入. 所有代码都接入完成之后,准备export出一个release包,但是此时却报错: 此时出现了很多的warning,要求修改,并且还退出了编译,导致打包失败. 仔细看了一下相关的warning的提示,都是自己的SDK出现的,然后去检查一下自己的SDK: 应该是自己添加了对应的依赖,但是没有加入自己的SDK,所以导致混淆时候被检查出来了, 此时只需要去proguard-project.txt中去忽略他

MyEclipse8.5 以debug模式启动tomcat6.0服务器 报错cannot connect to vm。

打开MyEclipse8.5 想以debug模式启动tomcat6.0服务器,报  a configuration error occurred during startup.please verify  the  perference  field with the prompt: cannot connect to vm. 解决办法一:运行cmd,输入netsh winsock reset   再 ,重启,这个也是一个解决方案,这个是重置winsock,可能是那个软件篡改了winsock 解

ios unit test 工程选择release时候报错Undefined symbols for architecture i386

Undefined symbols for architecture i386: "_OBJC_CLASS_$_ItemReturn", referenced from: objc-class-ref in JenknisDemoTests.o "_OBJC_CLASS_$_ViewController", referenced from: objc-class-ref in ViewControllerTest.o (maybe you meant: _OBJC_

MRC模式下声明property属性为strong可能不会报错

定位了项目的一个问题,居然与strong有关系.首先说明一下项目是MRC内存管理的.一个NSDictionary变量在赋值一段时间后再次访问就会出现EXC_BAD_ACCESS错误,打印日志看了一下地址没变但是内容已经看不到,估计是野指针了,显然内存管理出现问题了.看这个变量的定义,是加了strong属性的,说明对应的m文件是ARC内存管理的.再在Build Phase里看这个文件有没有加-fobjc-arc选项,居然没有,加上就好了. 对于这个问题,我想着Xcode应该会对MRC模式下使用st

解决部分在Debug模式下程序没问题但是Release模式下出现问题的方法

编译策略介绍 关于优化级别:GCC_OPTIMIZATION_LEVEL 描述如下 None: Do not optimize.  [-O0]With this setting, the compiler's goal is to reduce the cost of compilation and to make debugging produce the expected results. Statements are independent: if you stop the program

IOS中(Xcode) DEBUG模式(RELEASE模式)控制NSLog输出,NSLog两种不同情况的输出方式

[新年新气象,2016/01/04] 俺们在开发IOS程序过程中,经常需要用到NSLog输出一些信息,甚至有的开发过程,必须在控制台查看输出,有经验的程序员通过控制台输出就能知道整个数据交互的一个流程.但是一个发布的程序,里面带有太多的NSLog输出,肯定对于App性能有所影响,这时候我们可以使用一个宏定义来处理,在开发的时候使用DEBUG模式,在发布的时候使用RELEASE模式.这样,发布的App就不会在程序内部做大量的NSLog输出了

iOS开发技巧(系列十七:使用Xcode DEBUG模式和RELEASE模式)

在开发过程中,我们经常需要用到NSLog输出一些信息,甚至有的开发过程,必须在控制台查看输出,有经验的程序员通过控制台输出就能知道整个数据交互的一个流程.但是一个发布的程序,里面带有太多的NSLog输出,肯定对于App性能有所影响,这时候我们可以使用一个宏定义来处理,在开发的时候使用DEBUG模式,在发布的时候使用RELEASE模式.这样,发布的App就不会在程序内部做大量的NSLog输出了. 简单的代码如下, #if defined(DEBUG)||defined(_DEBUG)     NS