PTT職涯區 / Soft_Job (軟體人)

[請益] 任務超過我的負荷

看板Soft_Job (軟體人)作者 (男生一枚)時間14年前 (2011/09/09 21:33), 編輯推噓7(7推 0噓 67→)
留言74則, 13人參與, 最新討論串1/1
最近我們小組在搞無線影像傳輸的程式。 其實我們也沒有真的從頭到尾自己寫， 而是base on VLC這個很有名的程式來做， 可是目前卻有瓶頸了。 遇到接收端接收影像會delay和停止的問題， 目前想到的解決方向有3個 1.接收端是android系統，mediaplay和底層 是opencore，在這裡面想辦法修改程式解決。 2.發送端是用vlc，那麼也有可能問題出在發 送端，所以去修改對vlc下的command，想辦 法解決。 3.移植VLC用的stream 程式Live555到android 系統中。 說實在的，小弟真的沒有領很多，這三個方向 我只有第2個還有點把握，其它1,3二點我目前 自問...我沒移植這麼大程式碼的經驗，這中間 還包含了一堆protocol。 我想問大家二個問題~~~ 1.可以做1,3這種事的人應該可以談多少年薪？ 2.這麼大的程式要去移植它 ，該如何下手？ 唉！看了皮皮挫，但是依然不能投降，做出來 應該會很爽才對... 可是，總覺得有點強人所難，還是我太弱了T.T -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 111.240.215.216
→
09/09 21:44, , 1F
改這個很難唷，工研院有一個小組做這個，CC
09/09 21:44, 1F
→
09/09 21:53, , 2F
1.3熟的話...120開始喊....看你能力多強XD
09/09 21:53, 2F
推
09/09 22:08, , 3F
如果有時是順的話 可能是BUFFER問題吧
09/09 22:08, 3F
→
09/09 22:09, , 4F
直接改底層就怕到時連影像都出不來XD 先從上層試試吧
09/09 22:09, 4F
→
09/09 22:33, , 5F
配合版本控制系統的話，沒什麼好怕的。
09/09 22:33, 5F
→
09/09 22:49, , 6F
其實主要是擔心改底層 進而影響到上下層的應用 DEBUG上會困
09/09 22:49, 6F
→
09/09 22:49, , 7F
難許多 並不是擔心出錯後救不回來
09/09 22:49, 7F
推
09/09 22:59, , 8F
我猜 2.) 應該還是做不出來, 頂多減低出槌機率而已. O_o
09/09 22:59, 8F
→
09/09 23:25, , 9F
看起來 3.是多此一舉, 可以由 1.先去找問題
09/09 23:25, 9F
→
09/09 23:27, , 10F
2. 要看command是不是你們自己訂的..
09/09 23:27, 10F
→
09/09 23:28, , 11F
andorid系統跟window系統傳送有big-endian,little-endian
09/09 23:28, 11F
→
09/09 23:29, , 12F
的問題, 你注意到了嗎..
09/09 23:29, 12F
→
09/09 23:30, , 13F
ㄟ我忘了跟iOS會不會也有...好像都會有..有點忘了
09/09 23:30, 13F
→
09/09 23:31, , 14F
他說是 delay 跟 timedout 的問題，我想跟 endian 關係不大
09/09 23:31, 14F
→
09/09 23:31, , 15F
總之原本的media player如果是ok的,應該是ok才對
09/09 23:31, 15F
→
09/09 23:32, , 16F
你移植一個外來的protocol..很容易做白工....
09/09 23:32, 16F
→
09/09 23:34, , 17F
恩恩不過停止的真正問題有很多. endian也是其中之一
09/09 23:34, 17F
→
09/09 23:35, , 18F
我就遇過了...在轉換的函數出錯,
09/09 23:35, 18F
→
09/09 23:36, , 19F
總之..會造成停止的原因太多了.說也說不清楚.努力trace吧
09/09 23:36, 19F
→
09/09 23:38, , 20F
會搞media,就我所知, android(linux),iOS,window都會的話
09/09 23:38, 20F
→
09/09 23:39, , 21F
你有機會拿到八九十萬的年薪啦...是有機會但要看公司
09/09 23:39, 21F
→
09/09 23:40, , 22F
當然百萬的也有...所以等於白說...哈哈哈哈哈哈哈哈哈哈
09/09 23:40, 22F
→
09/09 23:45, , 23F
3不用考慮.要釐清1or2很簡單的方法..你以2的command傳送
09/09 23:45, 23F
→
09/09 23:46, , 24F
沒有吧，你真的熟OpenCore一堆豬屎屋等著要...
09/09 23:46, 24F
→
09/09 23:47, , 25F
要談到一百以上應該是一塊蛋糕....
09/09 23:47, 25F
→
09/09 23:47, , 26F
到iOS, window平台,用內建軟體撥放.如果沒問題就是1.啦
09/09 23:47, 26F
→
09/09 23:50, , 27F
樓上說的是擎展科技??擎展內搞media加上分紅破百吧
09/09 23:50, 27F
→
09/09 23:52, , 28F
看錯了...一塊蛋糕是啥咪意思....
09/09 23:52, 28F
→
09/09 23:56, , 29F
peace of cake, 很簡單的意思...只要你不要只看純軟...
09/09 23:56, 29F
→
09/09 23:56, , 30F
基本上這塊熟，一堆IC Design house搶著要, 蓮花廟也有機會
09/09 23:56, 30F
→
09/09 23:57, , 31F
上了就是一百起跳，雖然現在沒過去好....
09/09 23:57, 31F
→
09/10 00:00, , 32F
@@應該不是Endian的問題+1~因為如果是這個~就會解析不出送
09/10 00:00, 32F
→
09/10 00:01, , 33F
來的內容~直接停了~不會delay吧?懷疑這個的話~就查查送出
09/10 00:01, 33F
→
09/10 00:02, , 34F
的封包內容就好了...
09/10 00:02, 34F
→
09/10 00:02, , 35F
蓮花廟很重血統...血統不好~...很難很難有機會
09/10 00:02, 35F
→
09/10 00:02, , 36F
現在已經沒有當年那麼難進了啦..最近品質要求低很多
09/10 00:02, 36F
→
09/10 00:03, , 37F
蓮花廟已經不是當年血統純正書卷獎才能進去的地方
09/10 00:03, 37F
→
09/10 00:04, , 38F
這種問題如果local放片不會Lag, 多半出在接收機制太慢
09/10 00:04, 38F
→
09/10 00:05, , 39F
或是jitter太大, 問題出在底層的機率不是很高...
09/10 00:05, 39F
→
09/10 00:05, , 40F
如果中間某一段endian出錯呢..樓上說的也是原因...但
09/10 00:05, 40F
→
09/10 00:06, , 41F
你先查一下socket餵進來的資料到底是怎麼樣八成就有底了吧
09/10 00:06, 41F
→
09/10 00:07, , 42F
真正原因只有原po trace才能知道..再講下去就變爭論了c8
09/10 00:07, 42F
→
09/10 00:07, , 43F
endian在某一段出錯的機率應該不高，這種通常是從頭錯到尾
09/10 00:07, 43F
→
09/10 00:09, , 44F
看怎麼寫吧.....我看過只錯一段的..而有些format錯一段
09/10 00:09, 44F
→
09/10 00:10, , 45F
也是可以撥....總之反正..再講下去一人一個調.
09/10 00:10, 45F
→
09/10 00:10, , 46F
我只是提供我曾看過的範例.....就降啦
09/10 00:10, 46F
→
09/10 00:12, , 47F
沒錯~通常是從頭錯到尾XD 不知道中間是否會跳~如果會跳就
09/10 00:12, 47F
→
09/10 00:12, , 48F
可能是"漏接"~如果不會跳~只是delay~那就是播放程式的處理
09/10 00:12, 48F
→
09/10 00:13, , 49F
問題了吧? 我只是瞎猜XDDD
09/10 00:13, 49F
→
09/10 00:22, , 50F
如果每次都卡或停同一個地方，找個熟format的人幫你看看影
09/10 00:22, 50F
→
09/10 00:23, , 51F
片的IFrame之類的特徵吧，之前遇過IFrame爆高導致buffer爆
09/10 00:23, 51F
→
09/10 00:23, , 52F
掉的怪問題，
09/10 00:23, 52F
推
09/10 01:24, , 53F
可以考慮用DLNA,有linux和android的source
09/10 01:24, 53F
→
09/10 01:55, , 54F
真的糾感心，大家提供好多思路，我現在有滿滿的動力去挑
09/10 01:55, 54F
→
09/10 01:56, , 55F
戰這個問題了，真的非常感謝大家的建議。
09/10 01:56, 55F
推
09/10 09:21, , 56F
會delay正常吧 播放端都要留一小段buffer吧
09/10 09:21, 56F
→
09/10 09:22, , 57F
不然就兩邊灌個Skype 然後就可以無線視訊通話了
09/10 09:22, 57F
推
09/10 10:03, , 58F
我以前遇過類似的問題, 怎麼查都查不出原因.
09/10 10:03, 58F
→
09/10 10:04, , 59F
沒有 buffer underflow, 沒有 format error...
09/10 10:04, 59F
→
09/10 10:05, , 60F
但是任何一段影片, 連續播了兩三天就會停...
09/10 10:05, 60F
→
09/10 10:05, , 61F
停下來的影片位置很不一定, 停的時間也很不一定.
09/10 10:05, 61F
→
09/10 10:06, , 62F
一模一樣的影片, 從網路收下來存到硬碟上, 再開始撥放...
09/10 10:06, 62F
→
09/10 10:07, , 63F
咦？又沒問題了... 哈哈哈.
09/10 10:07, 63F
→
09/10 10:07, , 64F
最後我懷疑是 player 的 driver/codec layer...
09/10 10:07, 64F
→
09/10 10:08, , 65F
不曉得哪個部份的 streaming model 有寫錯... 但是沒證據.
09/10 10:08, 65F
→
09/10 10:10, , 66F
那一次做得人仰馬翻, 我也搞不懂最後怎麼驗收成功的.
09/10 10:10, 66F
→
09/10 10:11, , 67F
我當初就是類似用 2.) 的想法去湊參數.
09/10 10:11, 67F
→
09/10 10:12, , 68F
有沒有幫助呢？有, 從兩三個小時就停, 延長到兩三天. Orz
09/10 10:12, 68F
推
09/10 21:00, , 69F
看起來像通訊問題, 從1是正途, 如果android有另一個player可
09/10 21:00, 69F
→
09/10 21:01, , 70F
比對的話,也可以比較一下行為,我的經驗是某一方的timeout剛
09/10 21:01, 70F
→
09/10 21:02, , 71F
好落在臨界值,調參數有機會減少問題發生,但要長時間測試確認
09/10 21:02, 71F
→
09/10 21:02, , 72F
認參數是有效的,畢竟是把接收端當做黑盒子處理...
09/10 21:02, 72F
→
09/10 21:10, , 73F
如果你的 device 能用有線網路的話，可以先試試看會不會改善
09/10 21:10, 73F
推
09/11 14:44, , 74F
這…裝傻囉、推掉、找workaround。別傻了真的要自己看…
09/11 14:44, 74F
‣ 更多 happy321 的文章
文章代碼(AID): #1EQXMckl (Soft_Job)
Soft_Job 近期熱門文章
更多 近期熱門文章 >>
PTT職涯區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 happy321 的文章
文章代碼(AID): #1EQXMckl (Soft_Job)