田克平(94338047) 16:57:34
能自己設置某幀為關鍵幀嗎?
抱柱者(86311414) 16:57:59
to 田克平
可以
田克平(94338047) 17:00:00
呵呵,把丟包后的下一幀設置為I幀可以嗎?來處理丟幀現象
☆雪天/kf☆(279373002) 17:00:42
這個難度大了
田克平(94338047) 17:01:15
難度在哪?
抱柱者(86311414) 17:01:53
如果1to1那應該可行,但是要是傳到多點那可能比較麻煩
田克平(94338047) 17:03:54
謝謝
抱柱者(86311414) 17:04:05
比如傳至A、B兩點,到A的丟包很少,而到B丟包較多,那A也要因為B點而經常接受關鍵幀
抱柱者(86311414) 17:04:29
不過你也可以現象折中的方法
抱柱者(86311414) 17:04:38
不過你也可以想想折中的方法
田克平(94338047) 17:04:48
就1to1的話、、、
田克平(94338047) 17:05:11
怎么做
抱柱者(86311414) 17:05:22
就像你說的做啊
抱柱者(86311414) 17:05:50
丟包了就通知編碼端,下一幀編為關鍵幀
田克平(94338047) 17:06:07
好的,謝謝
☆雪天/kf☆(279373002) 17:06:16
田克平(94338047) 17:00:00
呵呵,把丟包后的下一幀設置為I幀可以嗎?來處理丟幀現象
編碼的時候你怎么會知道哪一幀會丟?
☆雪天/kf☆(279373002) 17:07:55
除非你有反饋通道
抱柱者(86311414) 17:08:58
肯定是反饋啊,正常可能是丟包了就通知編碼端重發,現在改為通知編碼端設置關鍵幀
傻子更聰明(120928606) 17:09:43
這樣好象實時性比較差啊,也難免不會再被丟。
呵呵(369873095) 17:10:11
網絡的來回時間考慮了嗎(RTT)
☆雪天/kf☆(279373002) 17:10:15
這樣效率很低呀
☆雪天/kf☆(279373002) 17:10:25
你編碼器一直要等在那里
抱柱者(86311414) 17:11:07
他是設置下一幀為關鍵幀,而不是處理丟了的那一幀,所以實時性應該沒有問題
田克平(94338047) 17:11:09
丟包了不通知嗎
☆雪天/kf☆(279373002) 17:11:21
兩次傳輸路徑時間+解碼器處理時間 編碼器無法并行
☆雪天/kf☆(279373002) 17:12:25
就是說你反饋回來的時候 編碼器已經編到后面去了 丟的哪一幀后面的一幀 早編完了
抱柱者(86311414) 17:12:57
編碼器為什么要等?
編碼器就按正常的編碼,如果解碼器反饋丟包了,應用程序就修改編碼參數設置關鍵幀,與并行扯不上關系
田克平(94338047) 17:12:58
好像是這樣啊
傻子更聰明(120928606) 17:14:09
網絡UDP不可靠傳輸,多少秒來一個關鍵幀比較合適?
抱柱者(86311414) 17:14:16
為什么要局限于下一幀,下兩幀也沒關系啊
抱柱者(86311414) 17:14:35
反正只是要盡快出現一個關鍵幀就行了
☆雪天/kf☆(279373002) 17:15:13
你說的沒錯 但是一個反饋的時間編碼器可能已經編碼了好多幀了
☆雪天/kf☆(279373002) 17:15:56
所以只能說是一接到反饋就立即置I幀
☆雪天/kf☆(279373002) 17:22:06
可以結合周期插入I幀一起來用 周期可以大一點
田克平(94338047) 17:23:10
關鍵幀間隔是定好的、、、
抱柱者(86311414) 17:23:15
肯定是會有固定關鍵幀周期的
傻子更聰明(120928606) 17:23:48
這種方法是在關鍵幀間隔比較大的情況下可以用。
田克平(94338047) 17:24:42
2s間隔有什么問題
傻子更聰明(120928606) 17:25:06
而且非關鍵幀丟失后怎么處理?會有花屏之類的。
傻子更聰明(120928606) 17:25:39
把導致花屏的幀丟掉后,圖象會有停頓。
田克平(94338047) 17:25:52
間隔很小的話當然是作用不大
☆雪天/kf☆(279373002) 17:25:58
那也沒有辦法 只能跳到下一個I幀
呵呵(369873095) 17:26:24
在碼率大的時候,一幀的數據都是由幾十個包承載的,多個包里掉一個包(幾個包)是否反饋要求I幀
☆雪天/kf☆(279373002) 17:27:21
那倒不用 使用EC足夠應付了
傻子更聰明(120928606) 17:27:22
網絡傳輸應該不用I幀吧?把I幀全變為IDR幀,這樣才有意義。
sunj(39310543) 17:28:42
這個問題有rfc來定義的
傻子更聰明(120928606) 17:28:42
錯誤掩藏,解碼器不支持的話,怎么整。也需要編碼器支持吧?。
sunj(39310543) 17:28:52
消息已經標準化了
☆雪天/kf☆(279373002) 17:29:34
簡單的塊copy就可以搞定這個了 不需要編碼器做什么
傻子更聰明(120928606) 17:31:12
這樣子,也是會引起連續的失真。。
☆雪天/kf☆(279373002) 17:22:06
可以結合周期插入I幀一起來用 周期可以大一點
田克平(94338047) 17:23:10
關鍵幀間隔是定好的、、、
抱柱者(86311414) 17:23:15
肯定是會有固定關鍵幀周期的
傻子更聰明(120928606) 17:23:48
這種方法是在關鍵幀間隔比較大的情況下可以用。
田克平(94338047) 17:24:42
2s間隔有什么問題
傻子更聰明(120928606) 17:25:06
而且非關鍵幀丟失后怎么處理?會有花屏之類的。
傻子更聰明(120928606) 17:25:39
把導致花屏的幀丟掉后,圖象會有停頓。
田克平(94338047) 17:25:52
間隔很小的話當然是作用不大
☆雪天/kf☆(279373002) 17:25:58
那也沒有辦法 只能跳到下一個I幀
呵呵(369873095) 17:26:24
在碼率大的時候,一幀的數據都是由幾十個包承載的,多個包里掉一個包(幾個包)是否反饋要求I幀
☆雪天/kf☆(279373002) 17:27:21
那倒不用 使用EC足夠應付了
傻子更聰明(120928606) 17:27:22
網絡傳輸應該不用I幀吧?把I幀全變為IDR幀,這樣才有意義。
sunj(39310543) 17:28:42
這個問題有rfc來定義的
傻子更聰明(120928606) 17:28:42
錯誤掩藏,解碼器不支持的話,怎么整。也需要編碼器支持吧?。
sunj(39310543) 17:28:52
消息已經標準化了
☆雪天/kf☆(279373002) 17:29:34
簡單的塊copy就可以搞定這個了 不需要編碼器做什么
傻子更聰明(120928606) 17:31:12
這樣子,也是會引起連續的失真。。
?
?
main()
{
...
???? while (decode_one_frame(img, input, snr) != EOS);
...
}
然后在decode_one_frame()
{
???? ...
??? currSlice->next_header = -8888;
??? .....
???? while ((currSlice->next_header != EOS && currSlice->next_header != SOP))
???? {
??????????? current_header = read_new_slice();
??????????? if (current_header == EOS)
??????????? {
????????????????? exit_picture();
????????????????? return EOS;
???????????? }
??????????? decode_slice(img, inp, current_header);
???????????????? ...
?????? }
???? ...
???? exit_picture();
???? return (SOP);
}
按照上面的代碼,經過跟蹤發現,currSlice->next_header 一直不變,那么decode_one_frame()中的while循環永遠不會因為條件的不滿足而跳出循環,只會因為current_header == EOS條件的滿足而推出該函數。
因此 decode_one_frame()函數只可能返回EOS,而不會是SOP;那么main()中的while循環將只會執行一次。而且在代碼跟蹤的過程中發現,輸入碼流的所有序列是在decode_one_frame()函數中全部解出,然后才推出該函數。
請教各位,jm為什么要這樣呢?還是我什么地方沒注意到?謝謝了
A:再次仔細跟蹤了一下代碼發現,jm整個解碼的結構是這樣的:
1。在main中調用while (decode_one_frame(img, input, snr) != EOS);
但實際上,這個while只會循環一次,因為decode_one_frame()只可能返回EOS(下面講為什么?)
2。在decode_one_frame()中通過調用
??? while ((currSlice->next_header != EOS && currSlice->next_header != SOP))
??? {
?? ?? ?? current_header = read_new_slice();
?? ?? ?? if (current_header == EOS)
?? ?? ?? {
?? ?? ?? ?? ?? exit_picture();
?? ?? ?? ?? ?? return EOS;
?? ?? ?? }
?? ?? ?? decode_slice(img, inp, current_header);
?? ?? ?? ?? ??? ...
?? }
解碼所有幀。如上所述,currSlice->next_header根本沒有起到任何作用,因為沒有其他地方為 其賦值,為什么呢?
因為如果要想知道next_header必須要將下一個slice碼流讀進來,再進行解析,既然已經讀進來,不管判斷的是一個新的pic,還是同一個pic中的新的slice,都必須立刻進行解碼,也就沒有必要再回到main()中的while循環了。
實際上起作用的是current_header,即通過read_new_slice()來獲得,(sop or sos):
?? ??? if(is_new_picture())
?? ??? {
?? ?? init_picture(img, input);
?? ?? current_header = SOP;//start of pic
?? ??? }
?? ??? else
?? ?? current_header = SOS;//start of slice
如果current_header=sop,那么將會調用init_picture(),這個函數主要實現兩個功能:首先,通過exit_picture()把上一次解碼的圖像及相關信息進行保存等處理 然后,再為當前slice(新的一幀)的解碼做好準備。如果current_header=sos,那么將不會調用init_picture(),直接利用當前pic的準備信息進行解碼。如果在read_new_slice()中發現已經到碼流的結尾了,那么將返回EOS.
這時在decode_one_frame()中,一旦current_header==EOS,那么將退出解碼,返回到main()中來。值得注意的是,返回之前,它還是調用了exit_picture(),從而將最后一個解碼幀進行保存。
大概流程應該就是這樣,如果有漏掉或錯誤的地方還請高手補充指正。總之jm中的有些函數的內容并不一定與其函數名稱相吻合,這可能也是他們開發到后期沒有辦法的事情。不知道x264或其他的解碼器是不是如此復雜?