|
List Info
Thread: discussion for how to reduce interrupts when playback video
|
|
| discussion for how to reduce interrupts
when playback video |

|
2008-04-09 04:44:10 |
|
All,
When playback video in helix, the number of interrupts per
second is high. Below is an analysis from source code:
Two threads are started in CVideoRenderer::StartSchedulers(void)
function in vidrend.cpp.
One for pumping of video decoder,
m_pDecoderPump->Start(this,
GetDecodePriority(),
DECODER_INTERVAL,
m_ulDecoderPacemakerId);
The actually ThreadRoutine is in CVideoPaceMaker::ThreadRoutine(void*
pArg) function in Cpacemkr.cpp.
There is a event wait operation with limited time.
m_pEvent->Wait(pThis->m_ulInterval)
Since m_ulInterval= DECODER_INTERVAL = 5ms, there is 200 calls/s to
m_pEvent->Wait.
So this is like a poll mechanism.
200 times in one second, thread will be back from wait of the event
then call
pThis->m_pResponse->OnPace(pThis->m_ulId);
Which finally goes to function BOOL CVideoFormat: ecodeFrame(UINT32
ulMaxExtraFrames) in vidrendf.cpp.
I also found most of the calls just do nothing.
Since following condition is false:
((!m_InputQueue.IsEmpty())
&&
(!m_pOutputQueue->IsFull())
&&
(!m_bDecodeSuspended))
Could modify the poll mechanism to another policy?
Do decoder frame when condition is ready.
- In the ThreadRoutine
wait for a event without time limitation
- In CVideoFormat class,
trig the event when there are input frame in the queue & the output
queue is not full & decoder is not suspended
Please give me some advices on
1. Whether the poll mechanism is the source of the interrupts?
2. Whether it is possible and valuable to do such a modification to
reduce interrupts?
Thanks,
Donald
|
| RE: discussion for how to reduce
interrupts whenplayback video |
  United States |
2008-04-09 08:40:43 |
Donald,
I think you have described how threaded decoding
is done in the base video renderer very accurately.
As to your questions:
> 1. Whether the poll mechanism is the source of the
interrupts?
>
There may be other sources of interrupts in helix,
but this is certainly one of the sources of
all the interrupts you are seeing.
> 2. Whether it is possible and valuable to do such a
> modification to reduce interrupts?
>
It would certainly be possible to change the way we
do threaded decoded (away from a polling approach),
and it looks like it would be valuable as well for
power conservation.
However, it is a very fairly significant change in
a very important class, since the base video renderer
touches every video renderer (every video datatype).
There might also be some other ways to change this
which can get us part of the way there toward reducing
wakeups without having to totally change how we
do this.
I will discuss this with Milko, the original author and
architect of the base video renderer, and try to have
an answer for Rusty by the afternoon call between Intel
and Real this afternoon.
Eric
=============================================
Eric Hyche (ehyche real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: helix-client-dev-bounces helixcommunity.org
> [mailto:helix-client-dev-bounces helixcommunity.org] On
> Behalf Of Wei, Donald
> Sent: Wednesday, April 09, 2008 5:44 AM
> To: helix-client-dev helixcommunity.org;
> player-dev helixcommunity.org;
> midplayer-private-dev lists.helixcommunity.org
> Subject: [Helix-client-dev] discussion for how to
reduce
> interrupts whenplayback video
>
> All,
>
> When playback video in helix, the number of interrupts
per
> second is high. Below is an analysis from source
code:
>
>
>
>
>
> Two threads are started in
> CVideoRenderer::StartSchedulers(void) function in
vidrend.cpp.
>
> One for pumping of video decoder,
>
> m_pDecoderPump->Start(this,
>
> GetDecodePriority(),
>
> DECODER_INTERVAL,
>
> m_ulDecoderPacemakerId);
>
>
>
> The actually ThreadRoutine is in
> CVideoPaceMaker::ThreadRoutine(void* pArg) function in
Cpacemkr.cpp.
>
>
>
> There is a event wait operation with limited time.
>
> m_pEvent->Wait(pThis->m_ulInterval)
>
>
>
> Since m_ulInterval= DECODER_INTERVAL = 5ms, there is
200
> calls/s to m_pEvent->Wait.
>
>
>
> So this is like a poll mechanism.
>
> 200 times in one second, thread will be back from wait
of the
> event then call
>
> pThis->m_pResponse->OnPace(pThis->m_ulId);
>
>
>
> Which finally goes to function BOOL
> CVideoFormat: ecodeFra
me(UINT32 ulMaxExtraFrames) in vidrendf.cpp.
>
> I also found most of the calls just do nothing.
>
> Since following condition is false:
>
> ((!m_InputQueue.IsEmpty()) &&
>
> (!m_pOutputQueue->IsFull()) &&
>
> (!m_bDecodeSuspended))
>
>
>
> Could modify the poll mechanism to another policy?
>
> Do decoder frame when condition is ready.
>
> 1. In the ThreadRoutine wait for a event without time
limitation
> 2. In CVideoFormat class, trig the event when there are
> input frame in the queue & the output queue is not
full &
> decoder is not suspended
>
>
>
> Please give me some advices on
>
> 1. Whether the poll mechanism is the source of the
interrupts?
>
> 2. Whether it is possible and valuable to do such a
> modification to reduce interrupts?
>
>
>
> Thanks,
>
> Donald
>
>
>
>
_______________________________________________
Helix-client-dev mailing list
Helix-client-dev helixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
|
|
| RE: discussion for how to reduce
interrupts whenplayback video |

|
2008-04-10 01:43:46 |
Eric,
Thanks for your quick response. I fully understand the
concern of
modification these key code.
Just share my personal idea on this topic with community,
wish it is
helpful.
Regards,
Donald
-----Original Message-----
From: Eric Hyche [mailto:ehyche real.com]
Sent: Wednesday, April 09, 2008 9:41 PM
To: Wei, Donald; helix-client-dev helixcommunity.org;
player-dev helixcommunity.org;
midplayer-private-dev lists.helixcommunity.org
Cc: Milko Boic
Subject: RE: [Helix-client-dev] discussion for how to reduce
interrupts
whenplayback video
Donald,
I think you have described how threaded decoding
is done in the base video renderer very accurately.
As to your questions:
> 1. Whether the poll mechanism is the source of the
interrupts?
>
There may be other sources of interrupts in helix,
but this is certainly one of the sources of
all the interrupts you are seeing.
> 2. Whether it is possible and valuable to do such a
> modification to reduce interrupts?
>
It would certainly be possible to change the way we
do threaded decoded (away from a polling approach),
and it looks like it would be valuable as well for
power conservation.
However, it is a very fairly significant change in
a very important class, since the base video renderer
touches every video renderer (every video datatype).
There might also be some other ways to change this
which can get us part of the way there toward reducing
wakeups without having to totally change how we
do this.
I will discuss this with Milko, the original author and
architect of the base video renderer, and try to have
an answer for Rusty by the afternoon call between Intel
and Real this afternoon.
Eric
=============================================
Eric Hyche (ehyche real.com)
Technical Lead
RealNetworks, Inc.
> -----Original Message-----
> From: helix-client-dev-bounces helixcommunity.org
> [mailto:helix-client-dev-bounces helixcommunity.org] On
> Behalf Of Wei, Donald
> Sent: Wednesday, April 09, 2008 5:44 AM
> To: helix-client-dev helixcommunity.org;
> player-dev helixcommunity.org;
> midplayer-private-dev lists.helixcommunity.org
> Subject: [Helix-client-dev] discussion for how to
reduce
> interrupts whenplayback video
>
> All,
>
> When playback video in helix, the number of interrupts
per
> second is high. Below is an analysis from source
code:
>
>
>
>
>
> Two threads are started in
> CVideoRenderer::StartSchedulers(void) function in
vidrend.cpp.
>
> One for pumping of video decoder,
>
> m_pDecoderPump->Start(this,
>
> GetDecodePriority(),
>
> DECODER_INTERVAL,
>
> m_ulDecoderPacemakerId);
>
>
>
> The actually ThreadRoutine is in
> CVideoPaceMaker::ThreadRoutine(void* pArg) function in
Cpacemkr.cpp.
>
>
>
> There is a event wait operation with limited time.
>
> m_pEvent->Wait(pThis->m_ulInterval)
>
>
>
> Since m_ulInterval= DECODER_INTERVAL = 5ms, there is
200
> calls/s to m_pEvent->Wait.
>
>
>
> So this is like a poll mechanism.
>
> 200 times in one second, thread will be back from wait
of the
> event then call
>
> pThis->m_pResponse->OnPace(pThis->m_ulId);
>
>
>
> Which finally goes to function BOOL
> CVideoFormat: ecodeFra
me(UINT32 ulMaxExtraFrames) in vidrendf.cpp.
>
> I also found most of the calls just do nothing.
>
> Since following condition is false:
>
> ((!m_InputQueue.IsEmpty()) &&
>
> (!m_pOutputQueue->IsFull()) &&
>
> (!m_bDecodeSuspended))
>
>
>
> Could modify the poll mechanism to another policy?
>
> Do decoder frame when condition is ready.
>
> 1. In the ThreadRoutine wait for a event without time
limitation
> 2. In CVideoFormat class, trig the event when there are
> input frame in the queue & the output queue is not
full &
> decoder is not suspended
>
>
>
> Please give me some advices on
>
> 1. Whether the poll mechanism is the source of the
interrupts?
>
> 2. Whether it is possible and valuable to do such a
> modification to reduce interrupts?
>
>
>
> Thanks,
>
> Donald
>
>
>
>
_______________________________________________
Helix-client-dev mailing list
Helix-client-dev helixcommunity.org
http://lists.helixcommunity.org/mailman/listinf
o/helix-client-dev
|
|
[1-3]
|
|