Realtek TV SD一職感想

Hugh Hsieh
Nov 3 · 6 min read

在這個工作也做了兩年十個月了,對在ic design產業也有了粗略地了解。以下就來略略分享我這兩年十個月的工作吧。

【背景】
兩年多前,約莫是十月左右的時候,結束了歐洲的小旅行回來之後便開始投履歷。那時候的自己其實對自己未來想要做的事情其實有點不知所措,好像什麼都能做(不知道自己真正喜歡做的事情是什麼),但好像也什麼都不能做(什麼都不懂)。那陣子面了各種position,電競電腦product manager, 半導體代工製造代線課長, 電信業營運分析師, 物料管理專員, 數位影像處理相關developer……等等。
因為大學在學的時候對未來職涯發展規劃挺不上心的,沒有太關心產業相關的訊息,因此也是透過面試的過程來了解什麼樣的工作可能是自己會喜歡的。
然而在面試一輪之後,對於寫代碼當developer是最有興趣的,覺得有很多技術可以學習以及挑戰面對。於是進入了Realtek TV SD部門。

【工作內容】

  1. Module: DCC
    我一開始被指派接觸Dynamic Contrast Control算法的工作,直接針對客戶或者QC回報的問題去對現有算法去做改善。步驟大概是分析為什麼會產生該問題,是哪一個sub module造成該問題或者整體flow哪個環節造成問題。然後針對問題做算法改善(解決方法大致是: 用時間軸來smooth、用weighting的方法來讓Contrast導向某個目標曲線)。
  2. Parameter loading flow and adjusting flow simplification
    因為Picture Quality有相當多的參數如sharpness, Noise, Deinterlace, Gamma, Color matrix and etc. 這些客戶的參數調整原先都是必須透過重新compile新的kernel execute file來置換設定,導致這樣的過程費時又容易需與系統的其他限制綁定,因此我們有做了可以透過置換參數大表的方式幫助PQ調整及客戶能夠更迅速的完成新參數的更新,並且這可以讓他們自行管理pq參數版本,不需要我們vendor不間斷地支援就能獨立作業。
  3. Frame Rate Control
    FRC的目的是要讓tv motion performance更流暢和更穩定。因為stream來源可能會有不同的frame rate或不同的frame pattern,我們需要24p 30p 50p 60p插補成display panel的輸出frame rate,因此會透過MEMC的複雜演算法來幫助動態插補出缺少的資訊以達到motion流暢的目的。
    MEMC的算法包含層面很廣,包含logo保護、dehalo、字幕出現時的處理、cadence detect等等。
    目前我處理的比較著重在字幕出現時的處理以及cadence detect。
  4. 雜事
    a. sync patches
    開發系統的過程中會有一個公版,當有客戶開發需要branch out的時候,就會與公版慢慢越走越遠,因此在customer branch解的bugs或功能有時候會需要被sync到公版或者客戶開的另一個案子。
    sync patches其實是一個有風險的工作,因為code base不同,sync後的效果能否達到預期也是不可預測的。可能input data不同、某些register setting or hardware支援程度不同,甚至可能會造成更多bugs,因此其實是吃力不討好的工作,而且這個工作是沒什麼技術累積性的。

【工作上遇到的挑戰】
1. Trace Code: 說實在的code其實蠻亂的,因此要看懂如此雜亂的code就需要花費一段時間,我認為這也算是軟實力的培養吧。

2. Project切換: 由於系統系統之間的規則相異,在不同project之間交錯工作,會需要時時update最新的rule是甚麼以及重新了解一些基本的環境作業。

3. 千一髮動全身的可能: 因為系統巨大,需要考慮的case相當多,因此有的修改可能需要思考一下整個流程可能會造成什麼樣的問題; 如何去避免問題發生; 以及問題發生的時候如何迅速釐清問題發生原因。

4. Priority排定: 我們部門的主要任務包含demo, 開發階段的技術支援, 量產後的技術支援,因此雖然都是在做事情,要先搞清楚目前做的這件事情的目的是什麼,才能知道輕重緩急,如果真的不知道哪一件事情的priority比較高,那就直接問打考績的老闆,由他來決定哪一件事情的緊急程度較高。

5. 打發突發雜事: 每個禮拜一,老闆都會給我這週的任務(應完成事項),但這時候可能會突然有急事打岔,因此要花多少時間處理這件打岔進來的事情也是一個輕重緩急的恆量。但原則上還是會以打發為主,真正重要的事情會再去請主管幫忙衡量。

【學習到什麼】

  1. 技術面:
    version controlling(git) , system flow of tv, middleware porting(hal) , driver optimization, debug skill(version, log, 中斷點, raw data analysis)
  2. 向上管理:確切讓老闆知道自己的進度,以避免老闆與真實狀況有不切實際的出入。
  3. 面對壓力:
    因為人力不足又有許多不確定的案子懸在那邊,常常身上會擺了很多事情,負責的層面很廣。因此收到問題的正確態度,就我們部門的最高原則就是快速處理,先能快速找到人協助處理,知道問題發生原因以及解決辦法是最好的,如果真的不行真的只能慢慢摸。
    不過在自己慢慢摸問題的時候,leader最擔心的點就是這個問題解決時程無法被估算,我認為估算未知問題的schedule這點對我來說還是難的,這時候就會比較有壓力一點。
    但其實這個壓力不應該完全在自己身上,未知的問題,每個人遇到問題都會是一樣的狀況,我們只能就現有已知的東西以及未來可能可以查找的方向來估計可能查到原因的時間長短。
    改善的work,我認為也是做到一個程度就必須上傳,以避免檯面上都沒看到一個進度,先有80分就要上,後續再依照事情的priority看看要不要繼續處理。以避免客戶一直來來回回,導致檯面上的進度一直都是0。

以上是我工作兩年十個月以來的工作心路歷程,可能還是有一些漏掉的地方,但是在這邊做個紀錄讓自己也讓未來的有志之士可以參考參考。

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade