討論區快速選單
知識庫快速選單
網路投保旅行平安險 網路投保旅行平安險
[ 回上頁 ] [ 討論區發言規則 ]
請教自己寫的transform filter,source來的sample停不下來
更改我的閱讀文章字型大小
作者 : leoliu(Lord_SadSea)
[ 貼文 83 | 人氣 6745 | 評價 60 | 評價/貼文 0.72 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/12/29 上午 10:01:27
我是接Directshow的Ball來試驗,transform filter在GraphEdit上,按下pause,Ball不會停止,Stop則是可以,是我input pin哪邊沒寫好嗎?
是否有人能提點一下,問題可能出在哪邊?
作者 : leoliu(Lord_SadSea)
[ 貼文 83 | 人氣 6745 | 評價 60 | 評價/貼文 0.72 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/12/29 下午 01:36:34
我在input pin下pause給source filter,也是一樣沒有停下

PIN_INFO *p;
hr = this->m_Connected->QueryPinInfo(p);
if(NOERROR == hr){
ASSERT(p);
     p->pFilter->Pause();//有設中斷確定有發出pause
}

我的transfilter是來自於Infinite Pin Tee這個directshow sample
起源是看到本版以前一個增加一個input pin的討論串,裡面 pernghy大的步驟,我都做了。
http://www.programmer-club.com.tw/ShowSameTitleN/directx/7118.html

不過實做之後才發現,對於兩個source的同步問題才是最傷腦筋的。
我的作法是保持input pin1連接到output pin不變。

Receive進來的media sample都先存在buffer裡面,所以有pin1跟pin2各自的media smaple list
然後送到filter的transform()處理。

不過因為pin2的NotifyAllocator無法連接到filter的m_pAllocator上(已經被pin1連接了),
目前是直接return NOERROR的,不知道是不是這部份出問題。

作者 : pernghy(pernghy) DirectX卓越專家貼文超過500則人氣指數超過30000點
[ 貼文 618 | 人氣 37721 | 評價 2990 | 評價/貼文 4.84 | 送出評價 48 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2010/12/31 上午 01:08:10
基本上即使有兩個input pin你應該是不需要碰到allocator才對, 只要兩個input pin 各自que住各自進來的media sample, 然後
比較兩個pin上media sample的time stamp. 儘量讓他們在接近的時間丟到filter 的 transform function才是..

還有就是...兩個input pin的filter要由cbasefilter開始改, 不能用ctransform filter開始改.


>我在input pin下pause給source filter,也是一樣沒有停下
>
>PIN_INFO *p;
>hr = this->m_Connected->QueryPinInfo(p);
>if(NOERROR == hr){
> ASSERT(p);
> p->pFilter->Pause();//有設中斷確定有發出pause
>}
>
>我的transfilter是來自於Infinite Pin Tee這個directshow sample
>起源是看到本版以前一個增加一個input pin的討論串,裡面 pernghy大的步驟,我都做了。
>http://www.programmer-club.com.tw/ShowSameTitleN/directx/7118.html
>
>不過實做之後才發現,對於兩個source的同步問題才是最傷腦筋的。
>我的作法是保持input pin1連接到output pin不變。
>
>Receive進來的media sample都先存在buffer裡面,所以有pin1跟pin2各自的media smaple list
>然後送到filter的transform()處理。
>
>不過因為pin2的NotifyAllocator無法連接到filter的m_pAllocator上(已經被pin1連接了),
>目前是直接return NOERROR的,不知道是不是這部份出問題。
>
>
作者 : leoliu(Lord_SadSea)
[ 貼文 83 | 人氣 6745 | 評價 60 | 評價/貼文 0.72 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/1/3 下午 04:32:03
先感謝回答。
>基本上即使有兩個input pin你應該是不需要碰到allocator才對, 只要兩個input pin 各自que住各自進來的media sample, 然後
>比較兩個pin上media sample的time stamp. 儘量讓他們在接近的時間丟到filter 的 transform function才是..
>
這我有疑問,兩個Input pin送Media sample的速度不一定一樣,不先做控制讓兩個速度接近的話,會有一邊一直累積不是嗎?
我有輸出累積的media sample 數量msg來看,我一直是碰到input2比較快。

速度快的,多出來的media sample丟掉會掉frame,畫面不會斷斷續續嗎?
我是用buffer存,也遲早會爆掉,
所以我才想用Quality Control先去控制送Media Sample的速度。

>還有就是...兩個input pin的filter要由cbasefilter開始改, 不能用ctransform filter開始改.

其實兩種方式我都做過了,transform是用Inftee下去改,
cbasefilter我用Ball下去改,因為ball是用CSourceStream等於已經幫我做很多事了
用cbasefilter的確比用transform簡單。

但是兩種作到最後,都卡在會有一邊送的sample太快,導致buffer爆掉
我是用Ball當Source,有trace進去的確有收到Qulity訊息,只是奇怪速度還是太快。

>各自cue住各自進來的media sample…比較兩個pin上media sample的time stamp.

我用兩個Ball當Source來試驗的時候,因為在同個IGraphBuilder上,時間是一樣的…沒有time stamp的問題。
倒是input餵資料太快很傷腦筋…還是我得適當地丟掉一些frame不處理看看?
作者 : pernghy(pernghy) DirectX卓越專家貼文超過500則人氣指數超過30000點
[ 貼文 618 | 人氣 37721 | 評價 2990 | 評價/貼文 4.84 | 送出評價 48 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
主題發起人leoliu註記此篇回應為很有道理 2011/1/3 下午 09:02:44
基本上在寫Muxer/Encoder類型的filter時,都會有一個預先的假設,就是各個input的資料的時間差不能太多,目前我遇過的muxer/encoder,包括自己寫的,這個時間差預設大部分是在3∼6秒以內,你可以把他變成參數來設定,在這個範圍內的資料都要儘量去buffer起來,如果你的source各個input的時間差太多,基本上一般的muxer跑起來都會有問題,因為沒辦法queue這麼多資料,最後一定得丟掉一些sample才行。所以如果你的source來源速度差太多,比較簡單的方式就是自己放慢抓取資料的速度來互相配合。Quality control 印象中是常常遇到問題,還不如自己handle比較簡單。


作者 : leoliu(Lord_SadSea)
[ 貼文 83 | 人氣 6745 | 評價 60 | 評價/貼文 0.72 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/1/10 上午 11:24:57
我現在已經用SourceStream改出一版接Device看起來是正常的版本。(沒有check media time)
buffer沒有爆掉疑慮,因為我的debug輸出buff起來的media sample數量都幾乎是0或1。

但是這版本接Ball來試驗就有很奇怪的結果。

我自己做了很多不同實驗,
發現只要在ball之後,接上Inftee這個filter,再接我的Mux Filter,可以同時輸出到三個media window,
這樣速度就正常,但是會有無法stop的問題。

但是如果兩個ball直接接上我的Mux Filter,會出現不正常的速度…就像放快了幾倍。
而且會有奇怪的不穩定錯誤,兩個input pin的sample gettime有時後會當掉,兩個buffer內竟然會取到同一個sample…?
兩個是不同ball的輸入,應該是不同media smaple才對。

個人懷疑Ball這個source是不是還有一些條件下,才能當作模擬的device source input?
因為看來我的mux filter還正常,但是為什麼還要透過Infinte tee filter才會正常的速度?
而且Stop會有Graphedit pop pause超時messge window的問題,按取消button之後,卻又正常可以跑…?

真的有很多疑問?directshow filter真的不是我這個剛摸三個月的新手可以搞的?
作者 : leoliu(Lord_SadSea)
[ 貼文 83 | 人氣 6745 | 評價 60 | 評價/貼文 0.72 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/1/10 上午 11:25:25
我現在已經用SourceStream改出一版接Device看起來是正常的版本。(沒有check media time)
buffer沒有爆掉疑慮,因為我的debug輸出buff起來的media sample數量都幾乎是0或1。

但是這版本接Ball來試驗就有很奇怪的結果。

我自己做了很多不同實驗,
發現只要在ball之後,接上Inftee這個filter,再接我的Mux Filter,可以同時輸出到三個media window,
這樣速度就正常,但是會有無法stop的問題。

但是如果兩個ball直接接上我的Mux Filter,會出現不正常的速度…就像放快了幾倍。
而且會有奇怪的不穩定錯誤,兩個input pin的sample gettime有時後會當掉,兩個buffer內竟然會取到同一個sample…?
兩個是不同ball的輸入,應該是不同media smaple才對。

個人懷疑Ball這個source是不是還有一些條件下,才能當作模擬的device source input?
因為看來我的mux filter還正常,但是為什麼還要透過Infinte tee filter才會正常的速度?
而且Stop會有Graphedit pop pause超時messge window的問題,按取消button之後,卻又正常可以跑…?

真的有很多疑問?directshow filter真的不是我這個剛摸三個月的新手可以搞的?
作者 : pernghy(pernghy) DirectX卓越專家貼文超過500則人氣指數超過30000點
[ 貼文 618 | 人氣 37721 | 評價 2990 | 評價/貼文 4.84 | 送出評價 48 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/1/10 下午 07:49:28
看不太懂...
基本上SourceStream應該是source filter在用的.
但是你又說和ball接起來????
這兩個都是source filter, 應該不能接才對..

要模擬簡單的兩個input...用兩個ball當source就好了...不用去改他..
作者 : leoliu(Lord_SadSea)
[ 貼文 83 | 人氣 6745 | 評價 60 | 評價/貼文 0.72 | 送出評價 1 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/1/11 上午 10:15:56

>看不太懂...
>基本上SourceStream應該是source filter在用的.
>但是你又說和ball接起來????
>這兩個都是source filter, 應該不能接才對..
>

我最後這個版本是用BALL的CSourceStream跟CSource改出來的,加兩個inputpin比較簡單。
因為input只要收資料,CSourceStream本身有做output thread,整個輸出都不用改。

之前用Inftee改得版本,需要改的地方更多。

>要模擬簡單的兩個input...用兩個ball當source就好了...不用去改他..
>
我也是這樣想,但是實際上測試,用Ball跟webcam有不同的結果…所以才有疑惑。
兩個ball是320x240 32bit RGB直接接上我的Muxfilter,會變成非常快速播放,還隨機會當在wxlist.h,CNodeCache裡面(奇怪的是可以取消,還能繼續執行…)。
webcam因為不是RGB格式,必須先經過AVI decompressor轉成32bit RGB,接上我的MuxFilter看起來一切都正常。

我的muxfilter只有把兩個input pin收到的media sample儲存起來,outputpin上Fillbuff有自己的work thread會做處理發出去。
所以想不大出來,有哪部份會影響到。
作者 : pernghy(pernghy) DirectX卓越專家貼文超過500則人氣指數超過30000點
[ 貼文 618 | 人氣 37721 | 評價 2990 | 評價/貼文 4.84 | 送出評價 48 次 ] 
[ 給個讚 ]  [ 給個讚 ]  [ 回應本文 ]  [ 發表新文 ]  [ 回上頁 ] [ 回討論區列表 ] [ 回知識入口 ]
2011/1/30 下午 11:36:52

>
>>看不太懂...
>>基本上SourceStream應該是source filter在用的.
>>但是你又說和ball接起來????
>>這兩個都是source filter, 應該不能接才對..
>>
>
>我最後這個版本是用BALL的CSourceStream跟CSource改出來的,加兩個inputpin比較簡單。
>因為input只要收資料,CSourceStream本身有做output thread,整個輸出都不用改。
>
>之前用Inftee改得版本,需要改的地方更多。
>
>>要模擬簡單的兩個input...用兩個ball當source就好了...不用去改他..
>>
>我也是這樣想,但是實際上測試,用Ball跟webcam有不同的結果…所以才有疑惑。
>兩個ball是320x240 32bit RGB直接接上我的Muxfilter,會變成非常快速播放,還隨機會當在wxlist.h,CNodeCache裡面(奇怪的是可以取消,還能繼續執行…)。
很抱歉,沒注意到這篇有新的回覆。

這是因為CSourceStream有自己的thread, 它會能丟多快就多快,解決的辦法只有自己放慢丟的時間,不然就是在收的那一方(就是你的muxer)限制收的速度。
基本上MediaSample的傳輸必須要參考timestamp的資訊才行,不管是誰,至少都要有一個人要處理才行,不然會亂跑是正常的。
此外,你可能要看一下你整的graph的reference clock是誰,亂跑有一個可能是reference clock 沒設好造成的。你找一下reference clock相關的介紹
,注意一下syncsource這個關鍵字

http://msdn.microsoft.com/en-us/library/aa924825.aspx

>webcam因為不是RGB格式,必須先經過AVI decompressor轉成32bit RGB,接上我的MuxFilter看起來一切都正常。
>
>我的muxfilter只有把兩個input pin收到的media sample儲存起來,outputpin上Fillbuff有自己的work thread會做處理發出去。
>所以想不大出來,有哪部份會影響到。

如果你是指停不下來的話,你可以把你自己所有的filter都實作stop這個function, 然後monitor一下看是誰沒被stop,再開始追可能會比較簡單。
 板主 : 白老鼠(Gary)
 > DirectX - 討論區
 - 最近熱門問答精華集
 - 全部歷史問答精華集
 - DirectX - 知識庫
  ■ 全站最新Post列表
  ■ 我的文章收藏
  ■ 我最愛的作者
  ■ 全站文章收藏排行榜
  ■ 全站最愛作者排行榜
  ■  月熱門主題
  ■  季熱門主題
  ■  熱門主題Top 20
  ■  本區Post排行榜
  ■  本區評價排行榜
  ■  全站專家名人榜
  ■  全站Post排行榜
  ■  全站評價排行榜
  ■  全站人氣排行榜
 請輸入關鍵字 
  開始搜尋
 
Top 10
評價排行
DirectX
1 aming 4010 
2 pernghy 1780 
3 白老鼠(Gary) 1120 
4 Akira 1020 
5 冷眼 980 
6 PLAYER 690 
7 阿西德倫 480 
8 andre 450 
9 小弦 430 
10 藍斯洛 410 
DirectX
  專家等級 評價  
  一代宗師 10000  
  曠世奇才 5000  
  頂尖高手 3000  
  卓越專家 1500  
  優秀好手 750  
Microsoft Internet Explorer 6.0. Screen 1024x768 pixel. High Color (16 bit).
2000-2019 程式設計俱樂部 http://www.programmer-club.com.tw/
0.0625