系統Memo - Silverlight Player影片起始載入問題

為了這個DRM專案被Silverlight搞了好久，菊花都痛了。

自行開發的Silverlight player一直有個問題，就是載入影片"有時候"會卡住，player狀態就停在manifest_ready和media_open中間不上不下。其實困擾有一大半都來自這個"有時候"出現的錯誤，說一是一說二是二程式有錯就不給跑簡單多了，所以我們花了滿多時間在釐清這個問題的原因。

最後從wireshark抓封包以及IIS server log發現，卡住的時候，player不會再送出任何request去抓video / audio fragment，大約是在第六秒和第八秒，切換抓取不同bitrate的時候就出了問題。

What the....!!!!!! How the hell would this happen

所以在載入影片的時候不能切換bitrate? Fuck!!!  這沒有道理啊!!! (後來發現切換bitrate真的跟卡住無關，因為測試用的silverlight player載入影片的時候切bitrate一點他媽的問題也沒有!!)

呼，真是太氣憤了。

我花了一下午新轉了一部低bitrate的影片，讓它容易切換，然後在測試player上卻捅出另一個樓子= = 太過頻繁的切換似乎會讓認證的cookie塞不進去(這只是猜測，實際讓認證抓不到cookie的原因不明)，然後我又針對認證裡cookie null的處理作修改之後回來正式環境測試，一試就中，卡住的瞬間有夠想屎!!
所以下午他媽的白忙，player卡住不送request跟cookie null而被認證踢掉根本是兩個問題。

而且照這個情況看來，不送request對silverlight player或是IIS認證來說都不算是個錯誤，單純只是類似thread卡住而便秘又不敢講而已。

既然測試player沒問題，那就把正式player的流程改成跟它一樣吧!

所以我們把正式player的AutoPlay改成true，然後就跟喝了通樂一樣一路順暢............

What the F!!!!!!!!!!

至於為什麼會這樣到現在還沒搞懂。

另外，在載入影片的時候，如果預先載入的30秒都是同一個bitrate(ex. 1200k)，什麼問題都沒有，所有的request也都會順利出現在wireshark以及server log裡；但只要載入的時候去抓另一個bitrate的fragment(ex. 2000k)，就只會出現抓那個bitrate的request，也就是說，如果第六秒去抓，那就只看到第六秒的request(有時候會有第八秒的)。
為什麼其他的request都消失了，原因一樣不曉得，說不定跟cache有關係？

Update:
(冷靜)

1. 消失的request的確跟cache有關。
2. AutoPlay改成true之後，在第八秒卡住的問題依然存在，雖然無法確定跟AutoPlay無關，但至少不是唯一的原因。又做了一些測試後，我們猜測或許跟解析度有關，因為嵌在網頁上的player大小是400x300(4:3)，所以在載入同樣是4:3的1200K影片(640x480)時一切正常，直到bitrate切換16:9的2000K影片(960x540)，就立刻爆炸。這也是為什麼一開始在測試player沒有出現過這問題的原因，測試player一直是全螢幕打滿的，不會有比例不符合的錯誤。
但是網頁上的player牽涉到版面設計，沒辦法為了技術問題改變大小，所以我們改成在一開始載入的階段(manifest_ready -> media_opened)限制player抓取影片的bitrate，載入完成後才恢復成原先的multi-bitrate。
問題總算是解決了。

系統Memo - IIS Root Module 設定

指掛在Default Web Site層級的Module，掛載方式如一般應用程式(application)層級，
將DLL檔放在bin資料夾裡，讓web.config去讀取即可。

要注意的是，在這個層級的module，會影響底下所有應用程式的module，
必須額外加上不讓底下應用程式繼承本身設定的宣告，如下：

web.config內容:


< ?xml version="1.0" encoding="UTF-8"? >
< configuration >
< system.web >
        < customErrors mode="Off"/ >
< /system.web >
< location path="." inheritInChildApplications="false" >
    < system.webServer >
        < modules >
            < add name="DomainRedirect" type="DomainRedirect.Redirect"/ >
        < /modules >
    < /system.webServer >
< /location >
< /configuration >

       


   
       
           
       
   

系統Memo - Cookie的使用

串流服務的http request分兩種，一種是manifest request，一種是chunk request；(manifest request： http://myserver.com/videopath/sample.ism/manifest?queryString，chunk request: /videopath/sample.ism?QualityLevels(128000)&Fragments(audio=460683900))

queryString只有在manifest request裡才會出現，也無法用程式加在接下來的chunk request上，所以為了辨別連線是屬於哪一個使用者，想到的最好解法就是使用cookie。

cookie的限制有以下幾點：

1. 無法即時改變cookie的值：cookie儲存在client端，在server端建立並設定值之後，由response帶過去client，下一次的request才會抓的到cookie；要改變其中的值或是刪除它，都必須由response通知client端，也就是cookie的變更一定存在request和response的時間差。

2. 瀏覽器的安全設定不相同：由於服務是由兩台不同domain的server提供，認證程式發給的cookie屬於第三方，這方面Chrome比較開放，並不禁止任何第三方cookie寫入，對認證沒有什麼影響；IE有限制第三方cookie，必須在cookie header中加入P3P設定 - HttpContext.Current.Response.AddHeader("P3P", "CP=\"CAO PSA OUR\""); Safari一樣有限制第三方cookie，且對於Domain的認定並不是看cookie內的設定來決定，而是直接看來源，這就很麻煩了，代表為了Safari一種瀏覽器，我必須將兩種服務放在同一個domain下。

3. 相同的request url不會更新cookie：也就是說，如果我要把cookie的值當作session用，我必須確定不同session的request url不會一樣，所攜帶的cookie值才會不一樣；經測試，相同的url無視於response的更新指令，而被瀏覽器視作cookie無須更新。

4. cookie允許設定string以外的值，但是request只取的到string的值

總而言之，cookie並不好用，

如果能夠像Wowza那樣將sessionid加在url上就不用被cookie搞了。