tiktok鏡像版(怎樣在切入切出虛擬攝像頭時營造卡頓效果)

TikTok為什么會0播放？怎么解決？

這是每一位新人任一道必過的坎

很多剛入門的小伙伴都會遇到一個普遍的問題，就是零播放，就像下面這張圖一樣，唯一一個播放還是自己用另一個號進去點的，很難受。

那么我來幫大家分析一下視頻零播放的原因，并給出一定的解決方法。

導致0播放的原因主要有以下五個方面：

1、硬件環境問題

2、軟件環境問題

3、視頻內容問題

4、視頻查重問題

5、審核延遲問題

下面按照順序給大家一一講解

01

硬件環境問題

硬件簡單來講，就是手機問題。

我們首先檢查手機有沒有拔出SIM卡，然后檢查手機有沒有殘留運營商信息，因為TikTok就是讀取運營商信息來限制國內用戶的，如果不知道怎么看直接刷機最穩妥。沒有什么事是刷機解決不了的，譬如for you 黑屏 刷機就能解決。

同時隨著TikTok軟件的更新，有些手機的型號也會受到影響，例如iPhone6這一型號手機的有很多人被限流，有40%都遇到了無法破0的問題，這時便應該及時更換手機。

02

軟件環境問題

軟件環境問題主要涉及到的參數有以下幾個：

IP地址

DNS

系統語言

系統時間

iPhone手機的廣告追蹤

IP地址定位在海外是使用TikTok的基礎條件，否則將無法正常使用TikTok，那么具體怎么查看IP定位到了那個國家或者地區，主要看自己的V買的目標在哪，例如你是想做洛杉磯，那么就要把IP定位在洛杉磯。

特別需要注意的是，定位好一個IP后不要隨機更換位置，否則被系統檢測到賬戶一直跳來跳去就會被打上標簽，賬號一旦被打上標簽，就算后期環境運營的再好，也是無法破0的。

這里就要強調下公共IP和動態IP了。

有的小伙伴為了方便買了現成的公共IP有很多線路那種。

那種就是很多人在用，也不包括里面有人在TikTok，如果有一個違規這個IP里所有人都會受牽連。

還有動態IP就是你每次登錄的IP都不同，一般偶爾一下沒事經常換官方就會檢測到。

什么是動態IP這里的朋友可以打開 whoer.買粉絲 查看

你可以先查看我的IP：這里的這一串IP記錄起來，然后關掉小火箭，然后半小時后在打開小火箭，在打開whoer看下IP有沒有變化來判斷是不是動態IP

與此同時DNS和系統語言也要與IP地址國家地區保持一致，例如做洛杉磯地區的賬號，那么系統語言就應該改成英語，如果是做日本區的，語言大家懂得改成什么。

還有就是系統時間的要求上做到與國家一致，根據IP定位的城市來選，最好手動設置，因為有些國家不同城市的時區都有所不同，例如:美國就是橫跨了，西五區至西十區。

上述條件是否滿足可以用whoer.買粉絲這個網站來進行檢測。

下面這一條是針對IOS用戶無法用網站檢測的，很多小伙伴會漏掉，如果是蘋果手機的用戶，那么一定要在 通用→隱私→廣告中， IOS14以下的版本需要把 限制廣告追蹤打開 ， IOS14以上的版本，則需要把 個性化廣告 關閉。

當然，除了這幾個指標外，還存在節點污染問題，有些IP節點被人使用太多，仍然會被檢測異常導致0播放，那么此時就應該重啟一個IP來進行起號。

03

視頻內容問題

視頻在發布的時候，TikTok首先會對它進行機器審核，如果視頻質量太差，模糊不清，滿屏幕的像素點，則會導致機器審核無法通過這個視頻，必然的就會出現0播放。

有些視頻模糊不清，很大原因就是你在解析視頻的時候視頻被壓縮了，或者在傳輸視頻的時候被壓縮，從而導致畫質降低，這個時候我們就需要掌握無損解析技術和無損傳輸視頻的方法。無損解析這個就可以看看一些解析視頻的工具，是不是有無壓縮解析的，無損互傳視頻的辦法就很多了，例如蘋果手機可以隔空投送或者用愛思助手，或者電腦和手機數據線連接導入，安卓和安卓可以QQ面對面快傳。

這里我像大家推薦一個Windows、Mac、安卓、iOS之間的無縫互傳的網站。

snapdrop.買粉絲這個工具可以實現Windows、Mac、安卓、iOS之間的無縫互傳，前提只有一個：設備連接的是同一個網絡，并在各自的瀏覽器輸入以上買粉絲即可 界面簡單易用 手機鎖屏也不影響傳輸 我還嘗試過手機B連手機A的熱點，也可以實現傳送 像我們幾十兆的這種短視頻，都是妙傳 使用幾天來一直比較穩定，特此推薦給大家。

在視頻內容上，有時會因為視頻類目的問題導致0播放，例如視頻類目過于枯燥，視頻內容毫無波動，不符合TikTok短視頻的邏輯，這樣便會有很大概率導致TikTok完全不給視頻進行推送。

04

視頻查重問題

視頻查重的問題也是0播放中非常常見的問題，也是大概率出現的問題。造成視頻查重的主要原因有兩個，一個是剪輯的手法不夠深度，另一個是視頻被搬運的次數過多。

這里提到的視頻剪輯深度需要簡單的說明一下，不是簡單的加濾鏡 加蒙版 就好了，因為視頻濾鏡蒙版過多就會遇到第三點視頻的質量變差，我們一般運用的剪輯手法：鏡像翻轉、抽幀插針、掐頭去尾、加蒙版、加濾鏡、變速、放大縮小、加文案、改變音樂 等等很多種。但是我們一般用3/4種的處理手法就行了。太多會導致視頻觀感嚴重下降。

05

審核延遲問題

在某些時間段，會因為某些原因事物對某一類的視頻素材審核進行嚴格監控，例如前段時間美國白人Policeman和黑人小伙的事件，不斷發酵之后，便導致相關視頻審核時間變長，所以這個時候就需要耐心等待。

這里可以給大家一個標準，一般正常有權重的號在發布視頻的5小時內都會有播放量，如果遇到審核延遲的問題，最多可以等到12小時，如果12小時依舊0播放，那么建議直接重新起號，節約寶貴的時間。

06

合拍破0法

綜合上面的幾點，可以看出導致0播放的原因非常的多，但是并不會有人告訴你問題出在那里，所以我們需要用到一些方法對問題進行一個一個的排除。

具體方法如下：

打開TikTok的搜索界面，找一個熱門視頻，這個熱門視頻需要具備以下幾個條件：

1、藍V認證

2、5M粉絲以上

3、真人IP

4、12小時以內發布的新視頻

找到一個這樣的視頻之后，點分享→合拍，隨便拍一些內容，發布即可。

操作完后，觀察6-12小時，看是否突破0播放，如果突破，則環境沒有問題，如果仍然無法破0，則需要仔細檢查自己的環境。

怎樣在切入切出虛擬攝像頭時營造卡頓效果

背景介紹：本人原先是android逆向工程師，后來因為工作變動，離開了協議分析這類的崗位，目前在做直播機與第三方應用兼容性分析相關分析，所以就有了這篇兼容性分析文章。

問題：tiktok在我們推流設備直播時，經過幾個特定步驟后切換前后置攝像頭會出現卡住的問題。

現象：直播畫面卡住不動了。

解決思路：找到點擊切換按鈕后的點擊事件回調，找到切換攝像頭的核心邏輯，來找到卡住原因。

1、如果了解ART虛擬機的同學會知道，jni函數和java函數都會調用到art虛擬機ArtMethod的Invoke函數。



輸出日志：

find target method: android.view.View.performClick

ArtMethod Invoke【22955】: ; lr:0x4af78c; libart.so: android.view.View.performClick

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.lang.Enum.toString

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.Ggh.LIZ

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.LinkedHashMap.<init>

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.HashMap.putAll

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: java.util.HashMap.put

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.DED.LIZ

ArtMethod Invoke【22955】: ; lr:0x2e2800; libart.so: X.D5k.onClick

通過frida hook libart.so的ArtMethod的Invoke函數，我們找到了點擊事件的回調類X.D5k.



找到這個類對應的onClick函數后，我對整個流程做個簡單的研讀，感覺發現了核心代碼在注釋直播流處理。



跟著核心代碼一路往下找到LiveCore這應該就是直播的核心代碼，其實現類為LiveCoreImpl，ILiveStream的實現類為LiveStream。





發現此處只是做了日志信息的合成和應用鏡像之類的代碼，但是又找到一個核心的類LiveStreamVideoCapture。



追蹤到這里發現鏈路斷了，又湊巧通過frida打開tiktok卡死在啟動頁上，那么接下來使用Xposed繼續理流程。

上面的代碼雖然沒有追中到切換攝像頭的核心邏輯，但是我們找到了兩個核心邏輯的類LiveStreamVideoCapture和LiveCoreImpl，分別和直播視頻流控制直播核心流程控制相關，所以Xposed繼續走的時候以這兩個類為重點，那么此處就開始放大招了，hook這兩個類的所有函數，貼上代碼。注意這里使用的classloader是application的classloader。





日志太多了，這里通過shell命令setprop做了個日志控制。







然后找到CameraVideoCapturer類的tryDeliverFrame，這里是處理相機的視頻幀，感覺越來越接近真相了，繼續hook這個方法，然后發現相機切換卡住以后，這個方法也停止調用了，那么沒辦法，繼續往上找堆棧中run方法的調用調用處。



繼續hook。





找到這個類。



至此，熟悉相機開發的同學應該知道，這就是SurfaceTexture.setOnFrameAvailableListener后，相機的可用幀會回調到這個函數，切換相機后卡頓，可用幀也同時不回調。

接下來hook原生相機。







調用的是android.hardware.Camera，也就是camera1相關的api，切換卡頓的時候并沒有調用Camera.open函數。





首次開直播的時候調用了這兩個函數，點擊切換相機的時候并沒有調用，在X.HCF這個類里找到switchCamera函數，那么猜測首次開相機，和切換前后相機走的并不是同一個流程，因為這個bug只有在切換相機時才會出現，所以我們就不關注首次開相機的流程。





果然，切換相機的時候走了這個流程，這是又發現了LiveStreamVideoCapture這個核心類，那么簡單進去看看SwitchCaptureRunnable這個有沒有被創建。





經過測試，發現這個類只會被創建一次，而run方法每次切換都會被調用，而且卡住的情況下也會被調用，那么結合上面Camera.open卡住時沒有調用，可以大膽的猜測中間過程某個條件不滿足被return了。根據堆棧信息繼續往下找幾個關鍵點。





發現CameraVideoCapture里也有切換相機的流程，切一步步往下走，能調用到上面我們hook過的X.HCF的switchCamera，那么我們就看看這里的switchCamera有沒有調用吧。

•情況一：先滑動直播界面，再按home鍵，然后回到tiktok，再切換相機，此時status()函數返回1，走了后續Camera.open流程。





•情況二：先滑動界面，再切換相機，然后按home鍵，接著回到tiktok，最后切換相機，此時status()函數返回2，沒走后續Camera.open流程。



從日志看switchCamera兩種情況都走了，再結合switchCamera的源碼看，源碼里的status()函數的返回值決定了是否繼續往下調用切換相機的流程，很遺憾的是，兩種情況都出現了，而且都會卡住（為什么兩個status值會不一樣呢，這里先留個坑，最后來填）。這可把我難住了！

就在這時腦子突然開竅，既然畫面卡住，那么必然有錯誤信息回調，果然一搜索CameraVideoCapture這個核心類有onError函數，毫不猶豫hook它，發現每次出錯時，這個函數的錯誤碼都會報-421錯誤（截圖省略-421錯誤碼的測試過程）。





錯誤信息非常明確的告訴我們是因為相機不支持縮放，導致的打開相機失敗，那么至此相機卡住的直接原因找到了，但是還沒找到為什么特殊的操作流程后會卡住，而正常的操作不會。于是乎繼續跟著堆棧信息往上找。



發現走進了這里的流程，導致的相機進縮放流程，為了驗證猜想，我決定在這個函數調用前，把message里的what字段改成2，讓它不走這個流程，來看看是不是就不會導致界面卡住，于是就有了下面這段代碼。



經過這一番篡改，果真隨便怎么折騰，直播界面都不會卡住了。那么我只要找到那里給handler發送的這個message就應該離真想很近了。





然后找這個handler的sendMessage相關切message的what字段賦值為1的函數。



然后我找到了它，這個函數還和縮放相關，那就八九不離十了。





按之前的堆棧繼續hook，發現卡住的時候這些方法確實都走了，而正常的時候是不走的，那么在X.Dvc的LIZ繼續用拋堆棧大法。

得到如下兩種堆棧：

•X.DCM接收到了touch事件，然后交由X.DCc這個類進行手勢判斷，發現是需要執行縮放的手勢，于是執行了相機的縮放功能（由于我們業務原因需要隱藏底部NavigationBar，在Window底部上劃會顯示NavigationBar，上劃的手勢同時觸發了控件的以為需要執行相機縮放），但是我們的虛擬攝像頭又不支持縮放，導致打開相機失敗，畫面就卡在了之前相機拿到的最后一幀。



X.DCc類



X.DCO的invoke方法



•點擊tiktok的切換相機Button，觸發進入相機的縮放，這里就和我們之前的點擊事件聯系上了，紅框部分就是補上了之前沒關注但是最重要的相機縮放功能判斷部分。





至此，我們已經把相機卡住的直接原因和根本原因都找到了，先手勢再點擊切換相機觸發了進入相機縮放功能判斷流程，由于我們的虛擬相機不支持縮放，導致打開相機失敗，卡在相機的最后一幀（也可能是黑屏）。所以只要交付給framework組開發人員，讓他們支持相機縮放相關功能就可以了。

接下來來填前面留下的坑，為什么退到后臺會導致status函數的返回值不一樣？

我們回到CameraVideoCapturer類，看看這個status()函數到底是個什么鬼！



發現他是父類ExternalVideoCapturer的函數，而且就是返回個字段，那再看看他那里進行了賦值。



通過AndroidStudio自帶的字段讀寫索引功能，很容易找到父類里的start、stop和release函數，以及自身的onErrorOnHandler函數里（也就是我們之前拋-421錯誤堆棧的函數）。如果熟悉相機開發的同學應該知道，一般我們界面退到后臺會釋放相機，然后回到前臺重新打開。那么接下來我們把這幾個函數都hook一下，來驗證猜想。



這里我多hook了一個onCaptureStarted函數，這個函數會調用父類的onStart函數，想看看是否會有調了onCaptureStarted但是沒調父類的onStart的情況。然后還hook了CameraVideoCapturer自身重寫的onStart和父類ExternalVideoCapturer的onStart函數。

下面是剛打開直播時的日志，此時status=1。



•情況一：先滑動直播界面，再按home鍵，然后回到tiktok，再切換相機，此時status()函數返回1，走了后續Camera.open流程。

這是直播退到后臺時的調用，說明確實釋放掉了，但是又調用了父類的onStart函數，那么此時的應該為2的status又變回了1。



接下來回到前臺，此時一切正常status還是為1，而且重走了自身的onStart函數，相當于相機整個流程完全重開。



再接著切換相機第一次，這時的status還是為1，相機正常，緊接著我們發現了-421錯誤，發現又重走了父類的onStart函數，那么此時status還是1。



接下來切換相機畫面卡住了，但還是走了父類的onStart。





以上就是第一種情況，由于每次切換相機都會拋完-421錯誤后，再調用父類ExternalVideoCapturer的start函數來重置status，也就造成了能調用Camera.open但是畫面卡住的情況。

•情況二：先滑動界面，再切換相機，然后按home鍵，接著回到tiktok，最后切換相機，此時status()函數返回2，沒走后續Camera.open流程。

前面流程就不貼了，直接開后面的流程記錄。

退到后臺 status=1



回到前臺status=1



切換相機第一次，畫面正常status=1



切換相機第二次，在調用switchCamera之前先拋了一次-421的錯誤，導致status=2，然后switchCamera函數里判斷status為2就被return，沒有調用Camera.open函數，接下來也沒有更多函數來重置status的狀態，所以無論怎么切換相機，都無法執行到Camera.open(),除非tiktok退到后臺，再回到前臺。





以上就是第二鐘情況。

很赞哦!（45）