---
title: Lab Meeting Minutes 2024/04/24
tags: lab_meeting
---
> Outline
> [TOC]
---
# PERAL Lab Meeting
- 時間：113 年 4 月 24 日 17:00
- 地點：線上
- 線上會議連結 : [Online](https://meet.google.com/zfi-zmnc-qfw)
- 出席者：吳坤熹老師、謝萬霖、劉怡君、田蕙瑜、沈家正、梁宇騰、劉冠伶、繆亭霄、蘇翊荃、陳嘉璐、陳品妤、陳姿綾(請假)、陳姿澖

- 會議主題：[A survey of packet loss recovery techniques for streaming audio](https://docs.google.com/presentation/d/1sCs1BB1A-1tJ16amGtAAPZGvLXu_PP1yYlueif6vPC8/edit?usp=sharing)
- 主講者: 劉怡君
- 主記: 沈家正

## 會議內容
### IP Multicasting
- hosts 可以加入 group，這個 group 有個 group address IP
- 發送端只要往這個 IP 送，router 會幫忙轉送到所有在這個 group 裡的人

### Streaming Audio
- Mbone = Multicast Bone
### Packet Loss
- 約 2 - 5% 的 loss
- allow trade-off between two roles
- passive observers (high latency, low loss)
- active partcipants (low latency, higher loss)
### Types of Recovery Techniques
- Sender-based 發送端角度 (今天 focus)
- Active
- retransimission 重送
- Passive
- Interleaving 交錯
- Forward Error Correction
- Media-independent
- Media-specific
- 接收端角度
#### Sender-based: Interleaving 交錯
- 讓有一大段資料不見時，傷害降到最少
- 無交錯：一整句話不見
- 交錯：把每句話的第一個字抽出來成一段，若這段不見只有每句話第一個字不見
- Solomon: 概念應該是 OK 的。不過整個字遺失就聽不懂了。例子若改成「一個字持續 0.3秒，遺失了中間 0.1 秒，還是可以聽得懂。」似乎比較合理。
#### Sender-based: Forward Error Correction (FEC)
- 冗餘資料，出錯時有機會用這段多的資料來修復回去
- 2 types:
- Systematic
- 能從中看得出來原始資料
- Non-systematic
- 無法直接從中窺見原始資料
- Media-independent
- 編碼對象是多個封包
- 生成多的封包來幫助丟封包時修復
- (n, k) FEC Code 意思是：每 n 個封包會產生 n-k 個多餘的封包來用於修正
- Parity Coding
- 做 XOR
- 簡報上以 bit stream 舉例
- 好處
- 不依賴本身的內容
- 缺點
- 額外 delay
- 需要多傳東西
- Media-specific
- 一段音訊會同時放在一個以上個封包裡面傳出去
- 要是這個封包不見，還能從另一個封包中找到這段音訊
- Primary Encoding & Secondary Encoding
- 會用不同方法來 Encode.
- 如果沒有封包遺失，就只從 primary 拿出來
- 通常 secondary 的壓縮程度會比 primary 還高一些 (lower-bandwidth/quality). 例如 primary 用 G.711 (64kbps), secondary 用 G.729, 壓成 8kbps. 把第一個封包的 secondary 和第二個封包的 primary 併在一起送出。
- 好處
- delay 較低: 備份的那個通常離比較近，通常是藏在下一個而已
- 缺點
- 可能 只能涵蓋短時間的遺失

---

### 建議&問題
1. [name=Louise] 如果 FEC 的那個封包也遺失了，那還有機會還原嗎
Ans: [name=Phoebe] 可以選擇容錯率更高的 code，挑能遺失不只一個的
[name=Solomon] 像 Phoebe 做的允許遺失超過 20 個封包
2. [name=Yukino] P.7 連續 4 個封包遺失怎麼辦
[name=Phoebe] 所以我 P.14 說缺點是涵蓋範圍比較小
3. [name=Yukino] 可以不要把備份的東西放在下一個，而是 random 放嗎
[name=Solomon] 這樣他不知道要等多久才能拿到備份的，可能 overhead 有點大，且語音應用要求 low latency。Good question on "Why not"!
[name=Phoebe] 若延遲比較久，也可以放在下兩個
4. [name=Ellie] P.12 Media-Specific FEC 壓縮後再回復聽起來一樣嗎？
[name=Phoebe] 看 secondary 的 encode 方式，若不是太不同就不會聽起來差不多。你如果不在乎花太多頻寬的話備份的那份可以用壓縮率低的方法，空間換取時間
[name=Solomon] 澄清：不會聽起來時間比較短，只是音質略差例如雙聲道變單聲道，無線的會比較喜歡用 secondary 會壓的比較小的方法，來避免浪費頻寬
5. [name=Ellie] 現在我們常用的是哪種
[name=Phoebe] 就我所知 G.723 就是 primary 和 secondary 用同一種
[name=Solomon] 大家平常在線上串流音訊視訊有沒有觀察到，音質下降 vs 直接不見。就我使用經驗是降低品質的手段較常見，為 media-specific。也可根據傳送的資料種類做取捨: 視訊 media-specific，字幕/檔案或許用直接消失的方法也行
6. [name=Ryan] P.7 Interleaving 這種會不會延遲比較高一點，因為要等有冗餘這個傳到才能做解碼給人聽到，可能 4 個封包以後 80ms 才能聽到。好像現在 Google Meet 感覺延遲沒那麼高，是怎麼做到的
[name=Phoebe] 我也不知有沒有人真的用這方法
[name=Solomon] 我覺得 LINE 的 buffer 其實比 Google Meet 大蠻多，Microsoft Teams的delay也比Google Meet長。看有沒有人幫忙設計個方法測一下各大平台的 delay 長短。Google Meet的 delay短很合理，可能是 TURN server / relay 放在台灣離我們較近.
ITU-T G.114 說 one-way latency 500ms 是使用者能察覺的門檻，開發者可用這數字來計算決定 buffer 要給多少才不會爆，還要考慮壓縮解壓縮、transmission
當年 Mbone video streaming 直播的 delay 其實可以相當久，15s - 20s，根據經驗 buffer 設低於 10 秒就很容易來不及收到造成停格。可以測看看現代 YouTube 是多久
[name=Phoebe]

7. [name=Ashley] P.13 的意思是把前一個封包 encode 後放到後一個嗎
[name=Phoebe] 編碼的對象不一定是封包，是把一段原始音訊用另一種編碼方式再多放
8. [name=Ashley] secondary 的方法具體是選用哪個 codec?
[name=Phoebe] 這 paper 是給個分類與概念的介紹，並沒有實際提供建議的 codec
[name=Solomon] 像 iLBC 就可以壓很小。
9. [name=August] 實際上可以 repair 的百分比?
[name=Phoebe]我不是做 media. FEC 更 sensitive on 連續的遺失
10. [name=August] FEC 會用哪種 metric 來比較
[name=Phoebe] capacity, fault tolerancy, delay
[name=Solomon] Ryan 的研究可以多納入來量測說不同 error correction 的效能差異。因此要做：1.容易掛上不同種 correction code 的界面，像是設計 callback function。2.統計的指標，例如 VLC Media Player 可以看得到統計說成功解碼或失敗的 counter
11. [name=Cooper] 有沒有說大家通常犧牲幾 % 的頻寬來做 error correction
[name=Phoebe] 這部分還沒有看到有一個實際的數據是大家傾向用的
12. [name=Miller] P.12 連續兩個都遺失
[name=Phoebe] 例如這張圖 3, 4 個封包都遺失的話，第 3 段資料就修不回來了
13. [name=Angela] 你目前的研究有沒有參考這裡提到的方法
[name=Phoebe] media-independent FEC 因為我是傳檔案，直接把多個封包編碼掉放在另一個多餘的封包來傳。
14. [name=Egar] paper 有提到這些方法會延遲的提昇貢獻多少嗎
[name=Phoebe] 只有講概念，沒有特別去做比較。
15. [name=Egar] 最近5年的paper有沒有講到比較偏好的編碼方式。
[name=Phoebe] 我都往 independent 的資料看居多
16. [name=Solomon] cite in previous work chapter?
[name=Phoebe] 會在 Reference，並在 FEC 的章節會提到
[name=Solomon] 如果一件事情花了很多時間準備，那這個東西必須要能夠在很多地方都有用處，這樣花的時間才有意義。

## 待追蹤事項
1. [name=Ashley] 本月路跑(4/27)已公佈，記得去請假/點餐；畢業路跑(五月)時間記得投票.

## 臨時動議

---
散會結束時間： 18:33