上回對avformat_open_input進(jìn)行了解析，在avformat_open_input內(nèi)部，對samba網(wǎng)絡(luò)協(xié)議的匹配其實(shí)是通過函數(shù)指針去調(diào)用samba的libsmbc_open()
我們先回顧一下：
static av_cold int libsmbc_open(URLContext *h, const char *url, int flags)
{
LIBSMBContext *libsmbc = h->priv_data;
int access, ret;
struct stat st;
libsmbc->fd = -1;
libsmbc->filesize = -1;
if ((ret = libsmbc_connect(h)) < 0)
goto fail;
if ((flags & AVIO_FLAG_WRITE) && (flags & AVIO_FLAG_READ)) {
access = O_CREAT | O_RDWR;
if (libsmbc->trunc)
access |= O_TRUNC;
} else if (flags & AVIO_FLAG_WRITE) {
access = O_CREAT | O_WRONLY;
if (libsmbc->trunc)
access |= O_TRUNC;
} else
access = O_RDONLY;
/* 0666 = -rw-rw-rw- = read+write for everyone, minus umask */
if ((libsmbc->fd = smbc_open(url, access, 0666)) < 0) {
ret = AVERROR(errno);
av_log(h, AV_LOG_ERROR, "File open failed: %s\n", strerror(errno));
goto fail;
}
if (smbc_fstat(libsmbc->fd, &st) < 0)
av_log(h, AV_LOG_WARNING, "Cannot stat file: %s\n", strerror(errno));
else
libsmbc->filesize = st.st_size;
return 0;
fail:
libsmbc_close(h);
return ret;
}
此函數(shù)內(nèi)部調(diào)用了libsmbclient庫的smbc_open()函數(shù)
回到上回的問題：為什么基于ffmpeg的播放器在模擬器上可以正常播放smb://的鏈接拌阴，到真機(jī)上就是報(bào)錯(cuò)了呢：
[smb @ 0x107d041d0] File open failed: Permission denied
為了查明真相，我們先分析問題：
- 1.報(bào)錯(cuò)為Permission denied，是否真的是權(quán)限問題因篇？
其實(shí)就是對ffmpeg內(nèi)部日志的不信任
當(dāng)我們遇到問題時(shí)，如果對日志表示懷疑的笔横，那么我們就要去源碼里面才能找到答案
所以竞滓，此問題一般很棘手，我們先放著吹缔，稍后在分析
- 2.權(quán)限報(bào)錯(cuò)商佑，一般分為密碼錯(cuò)誤或者賬戶錯(cuò)誤或者根本所用賬戶沒有訪問權(quán)限
我的賬戶默認(rèn)開啟了Guest訪問可讀寫權(quán)限，并且模擬器可以正常播放（訪問）厢塘，為何真機(jī)不行莉御？
是不是真機(jī)內(nèi)部使用的默認(rèn)賬戶并非Guest？
是不是真機(jī)內(nèi)部沒有傳遞賬戶驗(yàn)證信息俗冻？
真機(jī)和模擬器的CPU架構(gòu)不同礁叔，是否ffmpeg在調(diào)用smbc_open時(shí)沒有使用驗(yàn)證信息
解決思路
帶著上面的疑問，首先想到的就是要調(diào)試迄薄，那如何調(diào)試呢琅关？當(dāng)然是寫一個(gè)demo，一個(gè)用于測試smbc_open的demo讥蔽。
回到最開始關(guān)于libsmbc_open的ffmpeg源碼涣易，我發(fā)現(xiàn)在使用smbc_open之前還需要建立smb的連接：
static av_cold int libsmbc_connect(URLContext *h)
{
LIBSMBContext *libsmbc = h->priv_data;
libsmbc->ctx = smbc_new_context();
if (!libsmbc->ctx) {
int ret = AVERROR(errno);
av_log(h, AV_LOG_ERROR, "Cannot create context: %s.\n", strerror(errno));
return ret;
}
if (!smbc_init_context(libsmbc->ctx)) {
int ret = AVERROR(errno);
av_log(h, AV_LOG_ERROR, "Cannot initialize context: %s.\n", strerror(errno));
return ret;
}
smbc_set_context(libsmbc->ctx);
smbc_setOptionUserData(libsmbc->ctx, h);
smbc_setFunctionAuthDataWithContext(libsmbc->ctx, libsmbc_get_auth_data);
if (libsmbc->timeout != -1)
smbc_setTimeout(libsmbc->ctx, libsmbc->timeout);
if (libsmbc->workgroup)
smbc_setWorkgroup(libsmbc->ctx, libsmbc->workgroup);
if (smbc_init(NULL, 0) < 0) {
int ret = AVERROR(errno);
av_log(h, AV_LOG_ERROR, "Initialization failed: %s\n", strerror(errno));
return ret;
}
return 0;
}
分析上述libsmbc_connect，可以學(xué)習(xí)到smbc建立連接的方法：
smbc也是純c的思想冶伞，但凡寫得好的第三方c語言庫新症，都會(huì)用到context思想，一個(gè)神秘的翻譯：上下文响禽。
后續(xù)操作都是基于context的操作徒爹。
廢話不多說荚醒，查閱smbclient的文檔，模仿ffmpeg的調(diào)用把這個(gè)demo寫成：
+ (void)test
{
//構(gòu)造context
SMBCCTX * ctx = smbc_new_context();
if (!ctx) {
NSLog(@"smbc_new_context failed");
}
//初始化context
if (!smbc_init_context(ctx))
{
NSLog(@"smbc_init_context failed");
}
smbc_set_context(ctx);
//初始化smbc
if (smbc_init(NULL, 0) < 0) {
NSLog(@"smbc_init failed");
}
//打開鏈接
if ((smbc_open("smb://172.16.9.10/video/test.mp4", O_RDONLY | O_WRONLY, 0666)) < 0) {
NSLog(@"File open failed");
}
到此運(yùn)行隆嗅，在模擬器上界阁，發(fā)現(xiàn)smbc_open是成功了的
我切換到真機(jī)，居然把我們的之前遇到的問題復(fù)現(xiàn)了
這就好辦了胖喳，那既然問題能復(fù)現(xiàn)泡躯，并且范圍也被縮小到這段代碼之內(nèi)，還排除了ffmpeg的嫌疑（對應(yīng)問題1：Permission denied的準(zhǔn)確性）
接下來劃重點(diǎn)了
既然我們通過上述幾行代碼能建立smb的連接丽焊，那之前提到的--傳遞賬戶驗(yàn)證信息--又是在哪里調(diào)用呢较剃？
答案還是在ffmpeg的源碼中，我們不難發(fā)現(xiàn)libsmbc_connect中有個(gè)smbc_setFunctionAuthDataWithContext函數(shù)技健，此函數(shù)正式設(shè)置context驗(yàn)證信息的
smbc_setFunctionAuthDataWithContext為context設(shè)置一個(gè)回調(diào)函數(shù)写穴，用于傳遞auth三要素
SMBCCTX的賬戶驗(yàn)證信息包括三個(gè)部分：
- 工作組：默認(rèn)WORKGROUP
- 賬戶：默認(rèn)GUEST
- 密碼：默認(rèn)為空
那么，我么繼續(xù)優(yōu)化demo:
static void my_smbc_get_auth_data_with_context_fn(SMBCCTX *c,
const char *srv,
const char *shr,
char *workgroup, int wglen,
char *username, int unlen,
char *password, int pwlen)
{
}
+ (void)test
{
SMBCCTX * ctx = smbc_new_context();
if (!ctx) {
NSLog(@"smbc_new_context failed");
}
if (!smbc_init_context(ctx))
{
NSLog(@"smbc_init_context failed");
}
smbc_set_context(ctx);
//為context設(shè)置auth的回調(diào)函數(shù)
smbc_setFunctionAuthDataWithContext(ctx, my_smbc_get_auth_data_with_context_fn);
if (smbc_init(NULL, 0) < 0) {
NSLog(@"smbc_init failed");
}
if ((smbc_open("smb://172.16.9.10/video/test.mp4", O_RDONLY | O_WRONLY, 0666)) < 0) {
NSLog(@"File open failed");
}
這里關(guān)鍵的smbc_setFunctionAuthDataWithContext是為SMBCCTX設(shè)置賬戶驗(yàn)證信息的
通過調(diào)試發(fā)現(xiàn)凫乖，在執(zhí)行到smbc_open時(shí)确垫，會(huì)調(diào)用my_smbc_get_auth_data_with_context_fn，我們打個(gè)斷點(diǎn)看看此方法中帽芽，參數(shù)都是些什么妖魔鬼怪
上面的調(diào)試信息是在真機(jī)運(yùn)行下出現(xiàn)的删掀，我們一眼看出username為mobile肯定是不對的，因?yàn)槲也]有為我的samba服務(wù)器配置過名字為mobile的用戶
至此导街，原因算是找到了披泪，真機(jī)下，smbc的默認(rèn)賬戶為mobile搬瑰，而模擬器是x86_64架構(gòu)款票，在smbc執(zhí)行時(shí)會(huì)為此類設(shè)備設(shè)置默認(rèn)賬戶名為Guest，我們再驗(yàn)證一下：
好了泽论，那問題來了
我們?nèi)绾螢閒fmpeg解決這個(gè)問題呢?
一個(gè)最簡單的方案就是在我們的samba服務(wù)器上添加一個(gè)無密碼的名字為“mobile”的賬戶
我偏不這樣該咋辦艾少？
先回顧ffmpeg的源碼，在libsmbclient.c中翼悴，驗(yàn)證信息回調(diào)函數(shù)被設(shè)置為libsmbc_get_auth_data缚够，有一句注釋很出戲
static void libsmbc_get_auth_data(SMBCCTX *c, const char *server, const char *share,
char *workgroup, int workgroup_len,
char *username, int username_len,
char *password, int password_len)
{
/* Do nothing yet. Credentials are passed via url.
* Callback must exists, there might be a segmentation fault otherwise. */
}
正是這句：/* Do nothing yet. Credentials are passed via url.
好一個(gè)”via url“， 我又該如何鹦赎？
我沒查到資料谍椅，瞎蒙了一個(gè)（完全憑經(jīng)驗(yàn)），原鏈接為：
通過”via url"啟發(fā)古话，我改為這個(gè)：
運(yùn)氣不錯(cuò)雏吭，通過真機(jī)調(diào)試發(fā)現(xiàn)my_smbc_get_auth_data_with_context_fn回調(diào)中的username打印日志確實(shí)為“guest”,并且smbc_open成功！
