→ darthv:改這個很難唷，工研院有一個小組做這個，CC 09/09 21:44
→ iincho:1.3熟的話...120開始喊....看你能力多強XD 09/09 21:53
推 tomore:如果有時是順的話 可能是BUFFER問題吧 09/09 22:08
→ tomore:直接改底層就怕到時連影像都出不來XD 先從上層試試吧 09/09 22:09
→ qrtt1:配合版本控制系統的話，沒什麼好怕的。 09/09 22:33
→ tomore:其實主要是擔心改底層 進而影響到上下層的應用 DEBUG上會困 09/09 22:49
→ tomore:難許多 並不是擔心出錯後救不回來 09/09 22:49
推 Muscovy:我猜 2.) 應該還是做不出來, 頂多減低出槌機率而已. O_o 09/09 22:59
→ zekewang:看起來 3.是多此一舉, 可以由 1.先去找問題 09/09 23:25
→ zekewang:2. 要看command是不是你們自己訂的.. 09/09 23:27
→ zekewang:andorid系統跟window系統傳送有big-endian,little-endian 09/09 23:28
→ zekewang:的問題, 你注意到了嗎.. 09/09 23:29
→ zekewang:ㄟ我忘了跟iOS會不會也有...好像都會有..有點忘了 09/09 23:30
→ qrtt1:他說是 delay 跟 timedout 的問題，我想跟 endian 關係不大 09/09 23:31
→ zekewang:總之原本的media player如果是ok的,應該是ok才對 09/09 23:31
→ zekewang:你移植一個外來的protocol..很容易做白工.... 09/09 23:32
→ zekewang:恩恩不過停止的真正問題有很多. endian也是其中之一 09/09 23:34
→ zekewang:我就遇過了...在轉換的函數出錯, 09/09 23:35
→ zekewang:總之..會造成停止的原因太多了.說也說不清楚.努力trace吧 09/09 23:36
→ zekewang:會搞media,就我所知, android(linux),iOS,window都會的話 09/09 23:38
→ zekewang:你有機會拿到八九十萬的年薪啦...是有機會但要看公司 09/09 23:39
→ zekewang:當然百萬的也有...所以等於白說...哈哈哈哈哈哈哈哈哈哈 09/09 23:40
→ zekewang:3不用考慮.要釐清1or2很簡單的方法..你以2的command傳送 09/09 23:45
→ iincho:沒有吧，你真的熟OpenCore一堆豬屎屋等著要... 09/09 23:46
→ iincho:要談到一百以上應該是一塊蛋糕.... 09/09 23:47
→ zekewang:到iOS, window平台,用內建軟體撥放.如果沒問題就是1.啦 09/09 23:47
→ zekewang:樓上說的是擎展科技??擎展內搞media加上分紅破百吧 09/09 23:50
→ zekewang:看錯了...一塊蛋糕是啥咪意思.... 09/09 23:52
→ iincho:peace of cake, 很簡單的意思...只要你不要只看純軟... 09/09 23:56
→ iincho:基本上這塊熟，一堆IC Design house搶著要, 蓮花廟也有機會 09/09 23:56
→ iincho:上了就是一百起跳，雖然現在沒過去好.... 09/09 23:57
→ andymai:@@應該不是Endian的問題+1~因為如果是這個~就會解析不出送 09/10 00:00
→ andymai:來的內容~直接停了~不會delay吧?懷疑這個的話~就查查送出 09/10 00:01
→ andymai:的封包內容就好了... 09/10 00:02
→ zekewang:蓮花廟很重血統...血統不好~...很難很難有機會 09/10 00:02
→ iincho:現在已經沒有當年那麼難進了啦..最近品質要求低很多 09/10 00:02
→ iincho:蓮花廟已經不是當年血統純正書卷獎才能進去的地方 09/10 00:03
→ iincho:這種問題如果local放片不會Lag, 多半出在接收機制太慢 09/10 00:04
→ iincho:或是jitter太大, 問題出在底層的機率不是很高... 09/10 00:05
→ zekewang:如果中間某一段endian出錯呢..樓上說的也是原因...但 09/10 00:05
→ iincho:你先查一下socket餵進來的資料到底是怎麼樣八成就有底了吧 09/10 00:06
→ zekewang:真正原因只有原po trace才能知道..再講下去就變爭論了c8 09/10 00:07
→ iincho:endian在某一段出錯的機率應該不高，這種通常是從頭錯到尾 09/10 00:07
→ zekewang:看怎麼寫吧.....我看過只錯一段的..而有些format錯一段 09/10 00:09
→ zekewang:也是可以撥....總之反正..再講下去一人一個調. 09/10 00:10
→ zekewang:我只是提供我曾看過的範例.....就降啦 09/10 00:10
→ andymai:沒錯~通常是從頭錯到尾XD 不知道中間是否會跳~如果會跳就 09/10 00:12
→ andymai:可能是"漏接"~如果不會跳~只是delay~那就是播放程式的處理 09/10 00:12
→ andymai:問題了吧? 我只是瞎猜XDDD 09/10 00:13
→ walao81:如果每次都卡或停同一個地方，找個熟format的人幫你看看影 09/10 00:22
→ walao81:片的IFrame之類的特徵吧，之前遇過IFrame爆高導致buffer爆 09/10 00:23
→ walao81:掉的怪問題， 09/10 00:23
推 sosorry:可以考慮用DLNA,有linux和android的source 09/10 01:24
→ happy321:真的糾感心，大家提供好多思路，我現在有滿滿的動力去挑 09/10 01:55
→ happy321:戰這個問題了，真的非常感謝大家的建議。 09/10 01:56
推 meltice:會delay正常吧 播放端都要留一小段buffer吧 09/10 09:21
→ meltice:不然就兩邊灌個Skype 然後就可以無線視訊通話了 09/10 09:22
推 Muscovy:我以前遇過類似的問題, 怎麼查都查不出原因. 09/10 10:03
→ Muscovy:沒有 buffer underflow, 沒有 format error... 09/10 10:04
→ Muscovy:但是任何一段影片, 連續播了兩三天就會停... 09/10 10:05
→ Muscovy:停下來的影片位置很不一定, 停的時間也很不一定. 09/10 10:05
→ Muscovy:一模一樣的影片, 從網路收下來存到硬碟上, 再開始撥放... 09/10 10:06
→ Muscovy:咦？又沒問題了... 哈哈哈. 09/10 10:07
→ Muscovy:最後我懷疑是 player 的 driver/codec layer... 09/10 10:07
→ Muscovy:不曉得哪個部份的 streaming model 有寫錯... 但是沒證據. 09/10 10:08
→ Muscovy:那一次做得人仰馬翻, 我也搞不懂最後怎麼驗收成功的. 09/10 10:10
→ Muscovy:我當初就是類似用 2.) 的想法去湊參數. 09/10 10:11
→ Muscovy:有沒有幫助呢？有, 從兩三個小時就停, 延長到兩三天. Orz 09/10 10:12
推 Mozar:看起來像通訊問題, 從1是正途, 如果android有另一個player可 09/10 21:00
→ Mozar:比對的話,也可以比較一下行為,我的經驗是某一方的timeout剛 09/10 21:01
→ Mozar:好落在臨界值,調參數有機會減少問題發生,但要長時間測試確認 09/10 21:02
→ Mozar:認參數是有效的,畢竟是把接收端當做黑盒子處理... 09/10 21:02
→ qrtt1:如果你的 device 能用有線網路的話，可以先試試看會不會改善 09/10 21:10
推 readonly:這…裝傻囉、推掉、找workaround。別傻了真的要自己看… 09/11 14:44