OPUS压缩与解压的JNI调用（.DLL版本）
一、写在开头：
理论上讲，这是我在博客园的第一篇原创的博客，之前也一直想找个地方写点东西，把最近做的一些东西归纳总结下，但是一般工程做完了一高兴就把东西丢一边就很久不碰了，久而久之就淡忘了。这不是一个很好的习惯，古人也说更好记性不如烂笔头，无论是做学术还是做工程，定期总结与归纳都是一个不错的巩固与提高的方法。另外，也希望给后来者一点可行性的参考（有误导的地方请轻喷）。
二、引言：
言归正传，最近在做Android的一个工程，大体是实现在Android平台的录音、压缩、传输、解压、识别的功能。其中，识别包括语音识别与音乐片段的识别，这是两个很大的模块，有其他的工程师负责。我负责录音、压缩、传输、解压等几个小模块。
其中录音功能是比较简单的，网上参考的范例比较多，以后找时间再整理下。压缩部分包括语音压缩（VAD+压缩）与旋律的压缩，因为用过Speex压缩，所以语音压缩模块就直接沿用了之前的范例，但是Speex只能对语音进行压缩，不能对旋律进行压缩（失真较大，影响片段的检索），所以考虑采用一种较新的压缩方式：Opus压缩。
三、OPUS简介：
Opus编码器 是一个有损声音编码的格式，由互联网工程任务组（IETF）进来开发，适用于网络上的实时声音传输，标准格式为RFC 6716。Opus 格式是一个开放格式，使用上没有任何专利或限制。
Opus压缩几乎包含了Speex压缩的所有功能，并且支持对旋律的压缩，可以说功能是相当强大的，同Speex一样，Opus也是开源的，可以在官网上下载到Opus的源码。我下载的是最新的1.1版本的，解压后如下图所示：
但是除了官网外，Opus压缩的参考比较少，跨平台应用的就更少了点，做惯了伸手党的我对此相当郁闷，所以就花了点时间研究了下，实现了Android客户端（.so库）与windows服务器端（.dll库）的调用。
服务器端相对简单一点，基本思路是：利用VS2010创建生成相应的dll库，然后在服务器端利用NDK实现JNI接口，继而在主函数中实现调用。
四、Opus的DLL生成过程
Opus使用C语言实现的，并且官网上给了几个不错的DEMO，要实现Java对C/C++跨平台的调用，首先我们要保证我们的C语言接口是正确的，也就是说，首先要在VS2010等平台上将调用的函数跑通，只有测试函数通过了，才能保证我们移植到JVM上的程序是正确的。之后要根据正确的测试函数书写C语言接口，然后将C语言写的接口编译生成相应的dll库。
4.1、书写完整的测试函数
打开Opus官网上给的工程，其中，测试了一下，test_opus_encode工程和test_opus_decode工程里面都有完整的压缩与解压实体。所以，我们只需要改写其中的一个工程的主函数OK了，主函数书写的基本思路为：压缩与解压对象的创建、参数的设置、压缩/解压、资源的释放，代码如下：
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <stdint.h>
#include <math.h>
#include <string.h>
#include <time.h>
#if (!defined WIN32 && !defined _WIN32) || defined(__MINGW32__)
#include <unistd.h>
#else
#include <process.h>
#define getpid _getpid
#endif
#include "opus_multistream.h"
#include "opus.h"
#include "../src/opus_private.h"
//#include "test_opus_common.h"
/*#define MAX_PACKET (1500)
#define SAMPLES (48000*30)
#define SSAMPLES (SAMPLES/3)
#define MAX_FRAME_SAMP (5760)*/
int error;
;
;
int application=OPUS_APPLICATION_AUDIO;
OpusEncoder *enc=NULL;
opus_int32 bitrate_bps=;
int bandwidth = OPUS_AUTO;
;
;
;
;
;
opus_int32 max_data_bytes=;
unsigned char *data;
const opus_int16 *pcm;
opus_int16 *pcm_re;
OpusDecoder *dec=NULL;
unsigned ][];
opus_int16 pcm_re_1[][];
opus_int16 pcm_bf[][];
#define PI (3.141592653589793238462643f)
int i;
int j;
int n;
int m;
;
*;
int output_samples;
opus_uint32 dec_final_range;
int dur;
FILE *fp;
FILE *fp_1;
int num_pcm;
int num_pcm_re;
];
int main(int _argc, char **_argv)
{
];
FILE *foo;
printf("I am lzhen\n");
//memset(temp,1,600);
if((fp=fopen("e:\\dkdt.pcm","rb"))==NULL)
{
printf("cant open the file");
}
num_pcm=fread(&temp[],,fp);
printf("%d ",num_pcm);
//for(i=0;i<19200;i++)
//{
//printf("%d ",temp[i]);
//}
fclose(fp);//将打开的文件关闭
;i<;i++)
;j<;j++)
{
pcm_bf[i][j]=temp[*i+j];
}
enc = opus_encoder_create(Fs, channels, application, &error);
if (error != OPUS_OK)
{printf("创建失败");
}else
{printf("创建成功");
}
//for(pcm=number,i=0;i<2000;i++,pcm++)
//{printf("%d ",*pcm);}
opus_encoder_ctl(enc, OPUS_SET_BITRATE(bitrate_bps));
opus_encoder_ctl(enc, OPUS_SET_BANDWIDTH(bandwidth));
opus_encoder_ctl(enc, OPUS_SET_VBR(use_vbr));
opus_encoder_ctl(enc, OPUS_SET_VBR_CONSTRAINT(cvbr));
opus_encoder_ctl(enc, OPUS_SET_COMPLEXITY(complexity));
opus_encoder_ctl(enc, OPUS_SET_PACKET_LOSS_PERC(packet_loss_perc));
/*opus_encoder_ctl(enc, OPUS_SET_INBAND_FEC(use_inbandfec));
opus_encoder_ctl(enc, OPUS_SET_FORCE_CHANNELS(forcechannels));
opus_encoder_ctl(enc, OPUS_SET_DTX(use_dtx));
opus_encoder_ctl(enc, OPUS_SET_PACKET_LOSS_PERC(packet_loss_perc));
opus_encoder_ctl(enc, OPUS_GET_LOOKAHEAD(&skip));
opus_encoder_ctl(enc, OPUS_SET_LSB_DEPTH(16));
opus_encoder_ctl(enc, OPUS_SET_EXPERT_FRAME_DURATION(variable_duration));*/
;i<;i++)
{
pcm=pcm_bf[i];
data=data_1[i];
n=opus_encode(
enc,
pcm,
frame_size_1,
data,
max_data_bytes);
}//OPUS压缩
opus_encoder_destroy(enc);//释放资源
dec = opus_decoder_create(Fs, channels, &error);
output_samples = max_frame_size;
/*opus_decoder_ctl(dec, OPUS_GET_LAST_PACKET_DURATION(&output_samples));
opus_decoder_ctl(dec, OPUS_GET_FINAL_RANGE(&dec_final_range));
opus_decoder_ctl(dec, OPUS_GET_LAST_PACKET_DURATION(&dur));*/
;i<;i++)
{
data=data_1[i];
pcm_re=pcm_re_1[i];
m=opus_decode(
dec,
data,
n,
pcm_re,
frame_size_2,
);
}
opus_decoder_destroy(dec);
printf("\n\n\n解压后的长度为：%d\n ",m);
;i<;i++)
;j<;j++)
{
temp_end[*i+j]=pcm_re_1[i][j];
}
if((fp_1=fopen("e:\\dkdt_re.pcm","wb"))==NULL)
{
printf("cant open the file");
}
num_pcm_re=fwrite(&temp_end[],,fp_1);
getchar();
}
这里面我用一个dkdt.pcm的语音文件做范例，分帧进行压缩与解压，每一帧为320short，压缩后为40byte，压缩比为16，之后进行解压还原，生成相应的dkdt_out.pcm文件。这里给出我的测试结果，如下图所示：第一个是压缩前的音频信号，第二个是压缩解压后恢复的音频文件。
可以看到压缩前后还原后的波形几乎是一致的（听起来无差别），所以我们写的测试函数中压缩与解压是没有问题的。这一步很关键，是我们接下来的基础。
4.2、JNI接口的C语言部分
上一步OK了之后，就可以根据书写的测试函数书写JNI接口的C语言部分，这部分是比较简单的，稍微改下就OK了，JNI的书写规则，网上参考的东西比较详细，这里就不在赘述，直接给出代码如下：
#ifdef HAVE_CONFIG_H
#include "config.h"
#endif
#include "StdAfx.h"
#include <stdio.h>
#include <stdlib.h>
#include <limits.h>
#include <stdint.h>
#include <math.h>
#include <string.h>
#include "jni.h"
#include <time.h>
#if (!defined WIN32 && !defined _WIN32) || defined(__MINGW32__)
#include <unistd.h>
#else
#include <process.h>
#define getpid _getpid
#endif
#include "opus_multistream.h"
#include "opus.h"
#include "../src/opus_private.h"
int opus_num;
int pcm_num;
];
unsigned ];
];
unsigned ];
OpusEncoder *enc=NULL;
OpusDecoder *dec=NULL;
JNIEXPORT int JNICALL Java_audioTest_OpusJni_test(JNIEnv *env, jobject thiz)
{
;//测试函数
}
JNIEXPORT void JNICALL Java_audioTest_OpusJni_Init(JNIEnv *env, jobject thiz)
{
int error;
;
;
int application=OPUS_APPLICATION_AUDIO;
opus_int32 bitrate_bps=;
int bandwidth = OPUS_AUTO;
;
;
;
;
enc = opus_encoder_create(Fs, channels, application, &error);
dec = opus_decoder_create(Fs, channels, &error);
opus_encoder_ctl(enc, OPUS_SET_BITRATE(bitrate_bps));
opus_encoder_ctl(enc, OPUS_SET_BANDWIDTH(bandwidth));
opus_encoder_ctl(enc, OPUS_SET_VBR(use_vbr));
opus_encoder_ctl(enc, OPUS_SET_VBR_CONSTRAINT(cvbr));
opus_encoder_ctl(enc, OPUS_SET_COMPLEXITY(complexity));
opus_encoder_ctl(enc, OPUS_SET_PACKET_LOSS_PERC(packet_loss_perc));
}
JNIEXPORT jint JNICALL Java_audioTest_OpusJni_opusEncoder(JNIEnv *env, jobject thiz,jshortArray encoder_insrc,jbyteArray encoder_out)
{
;
opus_int32 max_data_bytes=;
jshort* pcm_data_encoder=(*env)->GetShortArrayElements(env, encoder_insrc, );
jbyte* opus_data_encoder=(*env)->GetByteArrayElements(env, encoder_out, );
opus_num=opus_encode(
enc,
pcm_data_encoder,
frame_size,
opus_data_encoder,
max_data_bytes);
(*env)->ReleaseShortArrayElements(env, encoder_insrc, pcm_data_encoder, );
(*env)->ReleaseByteArrayElements(env, encoder_out, opus_data_encoder, );
if((*env)->ExceptionCheck(env))
{
;
}
return opus_num;
}
JNIEXPORT jint JNICALL Java_audioTest_OpusJni_opusDecoder(JNIEnv *env, jobject thiz,jbyteArray decoder_insrc,jshortArray decoder_out)
{
;
jshort* pcm_data_decoder=(*env)->GetShortArrayElements(env, decoder_out, );
jbyte* opus_data_decoder=(*env)->GetByteArrayElements(env, decoder_insrc, );
pcm_num=opus_decode(
dec,
opus_data_decoder,
,
pcm_data_decoder,
frame_size,
);
(*env)->ReleaseShortArrayElements(env, decoder_out, pcm_data_decoder, );
(*env)->ReleaseByteArrayElements(env, decoder_insrc, opus_data_decoder, );
if((*env)->ExceptionCheck(env))
{
;
}
return pcm_num;
}
JNIEXPORT void JNICALL Java_audioTest_OpusJni_Destroy(JNIEnv *env, jobject thiz)
{
opus_encoder_destroy(enc);
opus_decoder_destroy(dec);
}
这里面稍微说一下，一个师兄跟我说，写这种跨平台的东西总会遇到各种莫名奇妙的问题，但是一切的BUG都是有原因的，这里写一个JNIEXPORT int JNICALL Java_audioTest_OpusJni_test(JNIEnv *env, jobject thiz)这样的测试函数，就可以简单地判断我们的JNI时候调用成功，成功的话，其他的就是调用函数内部的问题了。这样可以很快的缩小BUG的范围。
4.3、编译生成相应的dll库
写完JNI接口之后，就要将我们用到的所有依赖的文件（包括.c 、.h）一起打包编译为.dll文件。在VS2010中新建dll工程，dll工程里面有一个DEMO，我们这里用不到，可以讲里面的东西删了，将上一步写的接口文件拷贝其中，如下图所示：
和一般的C/C++工程一样，我们需要添加依赖的.C文件与.h文件，首先我们需要添加头文件，Opus依赖头文件分布的比较零散，不像speex全部在include文件里面，不过这里我们也只需要指定好路径，编译器会自动链接到相应的头文件，如下图所示：
此外，我们还要设置好依赖（调用）的.C文件，最直观的办法是将所有需要的.C文件都添加进工程，要不重不漏，重了会报重复定义的错误，漏了会报缺少定义的错误，编译Android的依赖库.so文件的时候，我的确是这么做的，这个过程需要一定时间的调试，要理清开源库中函数之间的关系，知道需要调用哪些函数。这里其实有个更加简单粗暴地办法，之前我们第一步编译测试工程的时候，会生成四个相应的.lib库，如下图所示：
只需要指定依赖的库文件的路径，如下图所示：
并将这四个库添加到依赖库中，如下图，编译器在编译的时候就可以直接连接到相应的函数实体。
这步成功之后，就可以在Release或者Debug文件夹中找到我们编译成功的opus.dll文件，157KB，沉甸甸的。接下来就就是Java部分对dll文件的调用了。
五、Opus的DLL调用过程
首先，我们需要书写Java端的JNI接口部分，这部分代码比较简单，直接给出。如下所示：
package audioTest;
/**
* 压缩库
*
* @author lzhen
*
*/
public class OpusJni
{
static
{
System.loadLibrary("opus");
}
public native int test();
public native void Init(); // 压缩初始化
public native int opusEncoder(short[] src, byte[] out); // 压缩数据，长度为320short->40byte
public native int opusDecoder(byte[] src, short[] out);// 解压缩数据，长度为40byte->320short
public native void Destroy(); // 释放内存
}
剩下的就是简单的Java对象的调用了。这里，我们可以首先测试下test（）函数是否成功，如果成功的话，说明dll库至少是没问题的。
在之后.so库的调用的时候再具体总结一下Opus压缩与解压调用的详细过程，这里就不再赘述了。
六、BUG与调试
BUG1：
Exception in thread "main" java.lang.UnsatisfiedLinkError: E:\jni\testopus\libs\opus.dll: Can't load IA 32-bit .dll on a AMD 64-bit platform
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965)
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890)
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1880)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at audioTest.OpusJni.<clinit>(OpusJni.java:12)
at audioTest.Server.main(Server.java:22)
DEBUG1：
这里是因为Opus官网上给的程序是根据32bit系统给出的，如果采用64bit系统，在VS2010中设置为X64会报错，所以只能按照X86编译，但是如果JDK是64bit的话，在eclipse中就会报上面的错误。
解决的办法是：将64bit的JDK卸载掉，安装一个32bit的JDK就可以编译通过，但是有一个问题，JDK如果卸载重装的话，有可能会失败，原因是重装的时候，之前注册表没有完全删除的问题，可以用Windows Installer Clean Up将之前的注册表彻底删除。不过，我觉得最简单的办法是重新安装一个其他版本的JDK就OK了，方法是死的，人是活的，我喜欢简单粗暴又能解决问题的方法。
BUG2：
java.lang.UnsatisfiedLinkError: E:\jni\testopus\libs\opus.dll: Can't find dependent libraries。
DEBUG2：
意思是找不到依赖库，我们编译生成的opus.dll文件可以放在系统的DLL库中（C:\Windows\System32），当然，也可以直接放在工程中，这样都是可以load到的，所以Can't find dependent libraries不是说找不到我们编译生成的DLL文件，而是我们编译生成的DLL文件也需要一些依赖库，这里面有两种情况：
一种是，我们在一台主机上编译生成的，拿到另外一台主机上面跑，可能两台主机配置或者是其他种种不同，系统DLL库会有所差异，可以用DLL依赖查看工具这个软件查找缺失的依赖库，如下图所示：
黄色标记表示缺失的DLL，我这里是因为，换了一台没有安装VS2010的主机上测试导致的，解决办法很简单，可以在网上下载缺失的DLL放到C:\Windows\System32中，或者，直接在编译的那台PC上拷贝，都是可以的。
第二种情况比较复杂一点，就是，我们在编译的时候，没有添加最原始的.lib库，这在不同的工程中会有所不同，一般用DLL依赖查看工具检察缺失的为.exe文件就是这种情况，那就要回头检察，我们在编译之前添加的.lib文件是不是有问题了。
BUG3：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x15c21781, pid=5264, tid=14016
#
# JRE version: Java(TM) SE Runtime Environment (8.0_11-b12) (build 1.8.0_11-b12)
# Java VM: Java HotSpot(TM) Client VM (25.11-b03 mixed mode, sharing windows-x86 )
# Problematic frame:
# C [test_opus_decode.exe+0x51781]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\test\Desktop\Music0808_sever\hs_err_pid5264.log
#
# If you would like to submit a bug report, please visit:
# http://bugreport.sun.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#
DEBUG3：
这个bug在很多游戏里面会出现，在JNI的跨平台调用中，出现类似情况，其实也是容易判断的，首先，我们要看一下，我们在Java端查看test（）函数是否运行成功，如果成功过了，那么说明DLL库的编译是没有问题的，那么接下来，就可以通过单步调试，查找具体在哪一个调用函数出现问题了，同时，在C语言端要通过注释等方式联合调试，最终确定具体是哪一个函数的哪一句出现了问题，目前，我还没有发现在DLL内部单步调试的方法，所以只能用这种方法尝试，不过效果还是很明显的，我的问题是初始化函数出现了一点问题。
另外，现在eclipse已经支持直接的NDK编译了，所以在Android平台上，好像是可以对.so库进行单步调试的，这个以后再说。
七、后记
写到这里，本章差不多结束了，有机会希望能够跟大家一起沟通交流，相互促进，相互提高。最后，跟大家分享一句OPUS官网上对开源的解释，我觉得很赞！
——Imagine a road system where each type of car could only drive on its own manufacturer's pavement. We all benefit from living in a world where all the roads are connected. This is why Opus, unlike many codecs, is free.
Reference：