Discussion:
Time interval between FillBuffer function call.
(too old to reply)
john
2010-01-30 09:44:43 UTC
Permalink
Hi All,

I have written a push source filter which gets the data from network.
The frame rate is 25fps.

I done some test to check the time interval between the FillBuffer
function call and I observed that the time interval
is varying. The average time interval is 40 milisecond which is
correct for 25fps But I need accurate time interval.

I would like to know why the time interval is varying? And can we make
this time interval more accurate.

Please anyone may suggest me on this. Any help would be appreciated.

Thanks.
Alessandro Angeli
2010-01-31 04:03:36 UTC
Permalink
From: "john"
Post by john
I would like to know why the time interval is varying?
FillBuffer() is invoked as fast as possible. What limits the
invocation rate it the time the call itself blocks and the
time the downstream filter blocks when receiving the
samples. If the downstream filter chain ends with a renderer
and the graph as a clock (both are the default behaviors of
the filter graph manager), the chain will on average block
for the duration of a sample or, in other words, the
invocation rate will on average match the sample rate.
Post by john
And can we make this time interval more accurate.
Why?
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
john
2010-02-01 09:53:23 UTC
Permalink
Post by Alessandro Angeli
From: "john"
Post by john
I would like to know why the time interval is varying?
FillBuffer() is invoked as fast as possible. What limits the
invocation rate it the time the call itself blocks and the
time the downstream filter blocks when receiving the
samples. If the downstream filter chain ends with a renderer
and the graph as a clock (both are the default behaviors of
the filter graph manager), the chain will on average block
for the duration of a sample or, in other words, the
invocation rate will on average match the sample rate.
Post by john
And can we make this time interval more accurate.
Why?
Because the varying time interval affecting my audio video sync.
I just want to know, Is it possible or not?

Thanks for reply.
Post by Alessandro Angeli
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
//http://www.riseoftheants.com/mmx/faq.htm
Alessandro Angeli
2010-02-01 17:26:15 UTC
Permalink
This post might be inappropriate. Click to display it.
john
2010-02-02 13:35:11 UTC
Permalink
Post by Alessandro Angeli
From: "john"
Post by john
Because the varying time interval affecting my audio
video sync.
I just want to know, Is it possible or not?
No, because you can not control the buffering of the
downstream filters. Even if you could, that would not be the
right way to keep the streams in sync.
Synchronization is mantained by the renderers by
synchronizing the rendering of the timestamped samples to a
common clock. All you have to do is properly timestamp the
samples.
http://msdn.microsoft.com/en-us/library/dd407202.aspx
Read the above, including the page on live sources, since
yours is.
If your source filter is the one that also produces the
audio, you can implement IReferenceClock on your filter.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
//http://www.riseoftheants.com/mmx/faq.htm
Thanks for reply.

I explored about the DirectShow clock and Times.

I have a confusion if the media sample arrive late at renderer filter
and its time stamps has expired
what will the video renderer do?

I am confused when the media sample is rendered immediately and when
the media sample is droped.

As per my observation and knowledge, A media sample will never arrive
at its correct presentation time
and before presentation time because of the latency in downstream
filter chain. It means that the media
sample always arrive late at video renderer.

I have one more confusion in Clock Times doc : "When a media sample
has a time stamp t, it means the sample should be rendered at stream
time t."

As per my knowledge, The time stamps defines the sample's start and
end time not a fixed time as t mentioned in above statement.

Please correct me if I am wrong.
Alessandro Angeli
2010-02-02 23:28:50 UTC
Permalink
From: "john"
Post by john
I have a confusion if the media sample arrive late at
renderer filter and its time stamps has expired
what will the video renderer do?
http://msdn.microsoft.com/en-us/library/dd407208.aspx

<<<If the sample arrives late, or has no time stamp, the
filter renders the sample immediately.>>>
Post by john
I am confused when the media sample is rendered
immediately and when the media sample is droped.
The stock renderers never drop samples.
Post by john
As per my observation and knowledge, A media sample will
never arrive at its correct presentation time
and before presentation time because of the latency in
downstream filter chain. It means that the media
sample always arrive late at video renderer.
That is not so. Time starts at 0 when the graph enters the
running state. The buffers of all filters in the pipeline
are filled before that while the graph is paused (you can
not transition from stopped to running directly) so the
renderers already have at least the sample 0 at time 0.
After that, the samples will always arrive early as long as
processing takes at most 1 sample duration (if it doesn't,
then the machine is not powerful enough to process the media
in real-time).

If the source can not fill the buffers while paused (as is
the case for live/capture sources, like yours), it must
notify the graph and the renderers will not wait for the
buffers to be filled. However, in this case the sample would
always be late since <<<Every sample is time stamped with a
start time equal to the stream time when it was captured>>>
(http://msdn.microsoft.com/en-us/library/dd407208.aspx).
That is why you should add a constant to the timestamp so
that the samples will be rendered in the future (1 or 2
frames is enough).
Post by john
As per my knowledge, The time stamps defines the sample's
start and end time not a fixed time as t mentioned in
above statement.
The stock renderers only use the start time as presentation
time. The stop time is used by some muxers.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
john
2010-02-03 12:34:46 UTC
Permalink
Post by Alessandro Angeli
From: "john"
Post by john
I have a confusion if the media sample arrive late at
renderer filter and its time stamps has expired
what will the video renderer do?
http://msdn.microsoft.com/en-us/library/dd407208.aspx
<<<If the sample arrives late, or has no time stamp, the
filter renders the sample immediately.>>>
Post by john
I am confused when the media sample is rendered
immediately and when the media sample is droped.
The stock renderers never drop samples.
Post by john
As per my observation and knowledge, A media sample will
never arrive at its correct presentation time
and before presentation time because of the latency in
downstream filter chain. It means that the media
sample always arrive late at video renderer.
That is not so. Time starts at 0 when the graph enters the
running state. The buffers of all filters in the pipeline
are filled before that while the graph is paused (you can
not transition from stopped to running directly) so the
renderers already have at least the sample 0 at time 0.
After that, the samples will always arrive early as long as
processing takes at most 1 sample duration (if it doesn't,
then the machine is not powerful enough to process the media
in real-time).
If the source can not fill the buffers while paused (as is
the case for live/capture sources, like yours), it must
notify the graph and the renderers will not wait for the
buffers to be filled. However, in this case the sample would
always be late since <<<Every sample is time stamped with a
start time equal to the stream time when it was captured>>>
(http://msdn.microsoft.com/en-us/library/dd407208.aspx).
That is why you should add a constant to the timestamp so
that the samples will be rendered in the future (1 or 2
frames is enough).
Post by john
As per my knowledge, The time stamps defines the sample's
start and end time not a fixed time as t mentioned in
above statement.
The stock renderers only use the start time as presentation
time. The stop time is used by some muxers.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
//http://www.riseoftheants.com/mmx/faq.htm
Thanks for reply Angeli.

Now most of the doubts cleared. Its really helpful.
Anand MR
2011-01-07 04:30:39 UTC
Permalink
Hi,

I am very much new to Directshow programming......I am also working with Push source filter.....I need to call FillBuffer function from DoBufferProcessingLoop function at every 40ms intervals to get 25fps. Now at present I am not reading frames from a network, reading from a local file of YUV format. But in future I need to read frames from network only. Please suggest me is there any way you found for giving 40ms delay.
Post by john
Hi All,
I have written a push source filter which gets the data from network.
The frame rate is 25fps.
I done some test to check the time interval between the FillBuffer
function call and I observed that the time interval
is varying. The average time interval is 40 milisecond which is
correct for 25fps But I need accurate time interval.
I would like to know why the time interval is varying? And can we make
this time interval more accurate.
Please anyone may suggest me on this. Any help would be appreciated.
Thanks.
Post by Alessandro Angeli
From: "john"
FillBuffer() is invoked as fast as possible. What limits the
invocation rate it the time the call itself blocks and the
time the downstream filter blocks when receiving the
samples. If the downstream filter chain ends with a renderer
and the graph as a clock (both are the default behaviors of
the filter graph manager), the chain will on average block
for the duration of a sample or, in other words, the
invocation rate will on average match the sample rate.
Why?
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
Post by Alessandro Angeli
From: "john"
No, because you can not control the buffering of the
downstream filters. Even if you could, that would not be the
right way to keep the streams in sync.
Synchronization is mantained by the renderers by
synchronizing the rendering of the timestamped samples to a
common clock. All you have to do is properly timestamp the
samples.
http://msdn.microsoft.com/en-us/library/dd407202.aspx
Read the above, including the page on live sources, since
yours is.
If your source filter is the one that also produces the
audio, you can implement IReferenceClock on your filter.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
Post by Alessandro Angeli
From: "john"
http://msdn.microsoft.com/en-us/library/dd407208.aspx
<<<If the sample arrives late, or has no time stamp, the
filter renders the sample immediately.>>>
The stock renderers never drop samples.
That is not so. Time starts at 0 when the graph enters the
running state. The buffers of all filters in the pipeline
are filled before that while the graph is paused (you can
not transition from stopped to running directly) so the
renderers already have at least the sample 0 at time 0.
After that, the samples will always arrive early as long as
processing takes at most 1 sample duration (if it does not,
then the machine is not powerful enough to process the media
in real-time).
If the source can not fill the buffers while paused (as is
the case for live/capture sources, like yours), it must
notify the graph and the renderers will not wait for the
buffers to be filled. However, in this case the sample would
always be late since <<<Every sample is time stamped with a
start time equal to the stream time when it was captured>>>
(http://msdn.microsoft.com/en-us/library/dd407208.aspx).
That is why you should add a constant to the timestamp so
that the samples will be rendered in the future (1 or 2
frames is enough).
The stock renderers only use the start time as presentation
time. The stop time is used by some muxers.
--
// Alessandro Angeli
// MVP :: DirectShow / MediaFoundation
// mvpnews at riseoftheants dot com
// http://www.riseoftheants.com/mmx/faq.htm
Post by john
Because the varying time interval affecting my audio video sync.
I just want to know, Is it possible or not?
Thanks for reply.
Post by john
Thanks for reply.
I explored about the DirectShow clock and Times.
I have a confusion if the media sample arrive late at renderer filter
and its time stamps has expired
what will the video renderer do?
I am confused when the media sample is rendered immediately and when
the media sample is droped.
As per my observation and knowledge, A media sample will never arrive
at its correct presentation time
and before presentation time because of the latency in downstream
filter chain. It means that the media
sample always arrive late at video renderer.
I have one more confusion in Clock Times doc : "When a media sample
has a time stamp t, it means the sample should be rendered at stream
time t."
As per my knowledge, The time stamps defines the sample's start and
end time not a fixed time as t mentioned in above statement.
Please correct me if I am wrong.
Post by john
Thanks for reply Angeli.
Now most of the doubts cleared. Its really helpful.
Submitted via EggHeadCafe
Microsoft ASP.NET For Beginners
http://www.eggheadcafe.com/training-topic-area/ASP-NET/7/ASP.aspx
Loading...