Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RE: CEPlayer Fast Rewind doesn't work

39 views
Skip to first unread message

Broofus

unread,
Mar 21, 2008, 3:29:04 PM3/21/08
to
I just wanted to update this. I put breakpoints at the point where the
CEPlayer issues the put_Rate() call and where the error message box is
displayed with all of the Debug Zones in quartz.dll enabled and these are the
only prints I got:

275153 PID:4c6000e TID:4c7000a CFGControl::CImplMediaSeeking::GetRate()
275154 PID:4c6000e TID:4c7000a CFGControl::CImplMediaSeeking::SetRate()

It doesn't look like a single call is issued to my demux, which makes me
believe the problem is in Microsoft code that perhaps needs to be
overwridden. I'm confused as to where this error is coming from or how to
debug this any further.

Would appreciate any help.

"Broofus" wrote:

> I have custom Demuxes and Decoders that I've used on WinCE 5.0 with no
> problems, but upon moving to WinCE 6.0 Fast Rewind stopped working. Now if I
> press the fast rewind button a message box pops up with "An unknown error has
> occurred (0x80070057)". The video continues to play at normal play rate. I
> assume the issue is with the Demuxer because if I play WMV content with the
> ASF Parser supplied by Microsoft fast rewind works fine.
>
> The problems appears to be with the put_Rate() call made in playerwindow.cpp
> when a negative rate is passed in as the argument. It looks like the
> 0x80070057 code comes from E_INVALIDARGS being returned from somewhere.
>
> Do I need to override some virtual function now that I wouldn't need to in
> WinCE 5.0?
>
> I'd appreciate any thoughts or ideas. Thanks

Haitao Jiang (MS)

unread,
Mar 21, 2008, 8:23:55 PM3/21/08
to
Can you give more details about your playback pipeline? What is your media
format? After you render the file, can you use
IMediaSeeking::CheckCapabilities to see if AM_SEEKING_CanSeekBackwards is
supported or not? If not, SetRate with negative rates will return invalid
argument error. For details, check out
http://msdn2.microsoft.com/en-us/library/aa921453.aspx.

Thanks,
--
Haitao Jiang
Software Design Engineer in Test
Windows Device Core Multimedia

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.

"Broofus" <Bro...@discussions.microsoft.com> wrote in message
news:3308C70E-9184-4838...@microsoft.com...

Broofus

unread,
Mar 24, 2008, 6:06:02 PM3/24/08
to
Thanks for responding.

I have the following custome decoders:
Mpeg1/2, Mpeg4, DivX, and WMV9

and the following custom demuxers:
Mpeg1/2, Mpeg4, and AVI


If I try to use any of my demuxers I can not do fast rewind. But using the
MS demuxers everything works fine. So for instance WMV works because we use
the ASF splitter provided by MS, but if I play WMV in AVI container it
doesn't. Previously all of these filters worked fine in WinCE 5.0. Upon
testing them in WinCE 6.0 the fast rewind issue was encountered.

I have done some more debugging and have found that in
CImplMediaSeeking::SetRate() there is some sort of check to see if the
desired rate is less than some number (this is assembly since I don't have
the sources, so I'm not sure exactly where this number comes from). That
returns TRUE and causes the E_INVALIDARG error message. If I change the
return value to FALSE the graph is then halted and the rate is changes.
Appears to be a check to see if the desired rate is smaller than the minimum
rate.

This seems to indicate that I'm not reporting the ability to play backwards.
I would have thought that the capabilities would be determined in the
GetCapabilities() funtion. This is what I currently have and it doesn't work:

class CBaseSeeking : public CUnknown, public IMediaSeeking, public
IAMExtendedSeeking

CBaseSeeking::GetCapabilities()
{
*pCapabilities = AM_SEEKING_CanSeekAbsolute |
AM_SEEKING_CanSeekForwards |
AM_SEEKING_CanSeekBackwards |
AM_SEEKING_CanGetStopPos |
AM_SEEKING_CanPlayBackwards | AM_SEEKING_CanGetCurrentPos
| AM_SEEKING_CanDoSegments |
AM_SEEKING_CanGetDuration;

return S_OK

Broofus

unread,
Mar 25, 2008, 3:06:02 PM3/25/08
to
I've noticed that when playing WMV content that CImplMediaSeeking::SetRate()
is not called, but instead CImplWMSeeking::SetRate(). If you step through
this assembly there is only a check to see if the desired rate is equal to
some number (I'm assuming the current rate) and if it's greater than some
other number (Max speed?). There is no check to see if the desired rate is
less than something as you find in the CImplMediaSeeking implementation.

I don't understand how to override this function as is being done for WMV.
For example in my AVI demux I have overridden SetRate() functions as follows:

class CBaseDemuxFilter : public CBaseFilter
HRESULT CBaseDemuxFilter::SetRate(double dRate)

class CDemuxInputPin : public CBaseInputPin
HRESULT CDemuxInputPin::SetRate(int nRate, BOOL bReStartPuller)

class CAVIDemux : public CBaseDemux
HRESULT CAVIDemux::SetRate(double dRate)

class CBaseSeeking : public CUnknown, public IMediaSeeking, public
IAMExtendedSeeking

STDMETHODIMP CBaseSeeking::SetRate(double dRate)

Am I missing something?

Thanks...

Haitao Jiang (MS)

unread,
Mar 28, 2008, 9:40:30 PM3/28/08
to
The filter graph manager distributes IMediaSeeking calls to the filter in
the graph which has the implementation. Since the WM source filter reports
the right seeking capabilities, the filter graph manager knows it supports
rewinding and forwards calls to it. Somehow your demuxers were not exposing
the caps correctly, so the filter graph manager responded the seeking calls
with no actions because it didn't know your demuxer's capabilities.

The check in the SetRate is to make sure you couldn't pass a negative rate
if the filters don't support it. But from your code, it did support
AM_SEEKING_CanPlayBackwards. A couple of things you can try is:

1. After the graph is built, use IMediaSeeking::GetCapabilities to see
if AM_SEEKING_CanPlayBackwards is supported.

2. If the result is not supported, check to see how many filters in
your pipeline support IMediaSeeking interface and make sure only one filter
exposing IMediaSeeking.

Thanks,

--
Haitao Jiang
Software Design Engineer in Test
Windows Device Core Multimedia

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.

"Broofus" <Bro...@discussions.microsoft.com> wrote in message

news:C5DD30FA-0028-4ED2...@microsoft.com...

Haitao Jiang (MS)

unread,
Apr 1, 2008, 2:52:18 PM4/1/08
to
It seems you implemented IMediaSeeking on the input pin. Can you try to
implement it on the output pin of the demuxer? From the directx
documentation, "The application queries the Filter Graph Manager for
IMediaSeeking and uses it to issue seek commands. The Filter Graph Manager
distributes each seek command to all of the renderer filters in the graph.
Each renderer passes the command upstream, through the output pins of the
upstream filters, until it reaches a filter that can execute the seek"

Also please check out information at
http://msdn2.microsoft.com/en-us/library/aa930719.aspx to see if you
implemented the interface correctly.

Thanks,
--
Haitao Jiang
Software Design Engineer in Test
Windows Device Core Multimedia

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.

"Haitao Jiang (MS)" <hai...@online.microsoft.com.noonlineemail> wrote in
message news:OowIf3Tk...@TK2MSFTNGP06.phx.gbl...

emb...@comcast.net

unread,
Apr 3, 2008, 4:38:44 PM4/3/08
to
It would appear in WinCE 6 that the direct show framework was changed
and no longer matches the published documentation. A filter that
works on WinCE 5.0 and WinXP no longer is able to rewind on WinCE
6.0. Also sample applications that can rewind on WinCE5.0 and WinXP
can no longer rewind either since the negative rates are not making it
through the directshow framework to the filters themselves.

Their is a new check done for negative rates, that didn't exist
previously or the conditions for the check have changed. Could you
let us know why the check was added or what conditions have changed
that cause the check to happen now when it doesn't with WinCE 5.0
directshow framework or the WinXP Directshow framework?

Thanks.


On Apr 1, 2:52 pm, "Haitao Jiang \(MS\)"
<hait...@online.microsoft.com.noonlineemail> wrote:
> It seems you implementedIMediaSeekingon the input pin.  Can you try to


> implement it on the output pin of the demuxer?  From the directx

> documentation, "The application queries the Filter Graph Manager forIMediaSeekingand uses it to issue seek commands. The Filter Graph Manager


> distributes each seek command to all of the renderer filters in the graph.
> Each renderer passes the command upstream, through the output pins of the
> upstream filters, until it reaches a filter that can execute the seek"
>

> Also please check out information athttp://msdn2.microsoft.com/en-us/library/aa930719.aspxto see if you


> implemented the interface correctly.
>
> Thanks,
> --
> Haitao Jiang
> Software Design Engineer in Test
> Windows Device Core Multimedia
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> You assume all risk for your use.
>

> "Haitao Jiang (MS)" <hait...@online.microsoft.com.noonlineemail> wrote in
> messagenews:OowIf3Tk...@TK2MSFTNGP06.phx.gbl...
>
>
>
> > The filter graph manager distributesIMediaSeekingcalls to the filter in


> > the graph which has the implementation.  Since the WM source filter
> > reports the right seeking capabilities, the filter graph manager knows it
> > supports rewinding and forwards calls to it.  Somehow your demuxers were
> > not exposing the caps correctly, so the filter graph manager responded the
> > seeking calls with no actions because it didn't know your demuxer's
> > capabilities.
>
> > The check in the SetRate is to make sure you couldn't pass a negative rate
> > if the filters don't support it.  But from your code, it did support
> > AM_SEEKING_CanPlayBackwards.   A couple of things you can try is:
>

> > 1.      After the graph is built, useIMediaSeeking::GetCapabilities to


> > see if AM_SEEKING_CanPlayBackwards is supported.
>
> > 2.      If the result is not supported, check to see how many filters in

> > your pipeline supportIMediaSeekinginterface and make sure only one


> > filter exposingIMediaSeeking.
>
> > Thanks,
>
> > --
> > Haitao Jiang
> > Software Design Engineer in Test
> > Windows Device Core Multimedia
>
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > You assume all risk for your use.
>

> > "Broofus" <Broo...@discussions.microsoft.com> wrote in message


> >news:C5DD30FA-0028-4ED2...@microsoft.com...
> >> I've noticed that when playing WMV content that
> >> CImplMediaSeeking::SetRate()
> >> is not called, but instead CImplWMSeeking::SetRate().  If you step
> >> through
> >> this assembly there is only a check to see if the desired rate is equal
> >> to
> >> some number (I'm assuming the current rate) and if it's greater than some
> >> other number (Max speed?).  There is no check to see if the desired rate
> >> is
> >> less than something as you find in the CImplMediaSeeking implementation.
>
> >> I don't understand how to override this function as is being done for
> >> WMV.
> >> For example in my AVI demux I have overridden SetRate() functions as
> >> follows:
>
> >> class CBaseDemuxFilter : public CBaseFilter
> >> HRESULT CBaseDemuxFilter::SetRate(double dRate)
>
> >> class CDemuxInputPin : public CBaseInputPin
> >> HRESULT CDemuxInputPin::SetRate(int nRate, BOOL bReStartPuller)
>
> >> class CAVIDemux : public CBaseDemux
> >> HRESULT CAVIDemux::SetRate(double dRate)
>

> >> class CBaseSeeking : public CUnknown, publicIMediaSeeking, public


> >> IAMExtendedSeeking
> >> STDMETHODIMP CBaseSeeking::SetRate(double dRate)
>
> >> Am I missing something?
>
> >> Thanks...
>
> >> "Broofus" wrote:
>
> >>> Thanks for responding.
>
> >>> I have the following custome decoders:
> >>>      Mpeg1/2, Mpeg4, DivX, and WMV9
>
> >>> and the following custom demuxers:
> >>>     Mpeg1/2,  Mpeg4, and  AVI
>
> >>> If I try to use any of my demuxers I can not do fast rewind.  But using
> >>> the
> >>> MS demuxers everything works fine.  So for instance WMV works because we
> >>> use
> >>> the ASF splitter provided by MS, but if I play WMV in AVI container it
> >>> doesn't.  Previously all of these filters worked fine inWinCE5.0.
> >>> Upon

> >>> testing them inWinCE6.0 the fast rewind issue was encountered.


>
> >>> I have done some more debugging and have found that in
> >>> CImplMediaSeeking::SetRate() there is some sort of check to see if the
> >>> desired rate is less than some number (this is assembly since I don't
> >>> have
> >>> the sources, so I'm not sure exactly where this number comes from).
> >>> That
> >>> returns TRUE and causes the E_INVALIDARG error message.  If I change the
> >>> return value to FALSE the graph is then halted and the rate is changes.
> >>> Appears to be a check to see if the desired rate is smaller than the
> >>> minimum
> >>> rate.
>
> >>> This seems to indicate that I'm not reporting the ability to play
> >>> backwards.
> >>>  I would have thought that the capabilities would be determined in the
> >>> GetCapabilities() funtion.  This is what I currently have and it doesn't
> >>> work:
>

> >>> class CBaseSeeking : public CUnknown, publicIMediaSeeking, public

> >>> > "Broofus" <Broo...@discussions.microsoft.com> wrote in message


> >>> >news:3308C70E-9184-4838...@microsoft.com...
> >>> > >I just wanted to update this.   I put breakpoints at the point where
> >>> > >the
> >>> > > CEPlayer issues the put_Rate() call and where the error message box
> >>> > > is
> >>> > > displayed with all of the Debug Zones in quartz.dll enabled and
> >>> > > these are
> >>> > > the
> >>> > > only prints I got:
>
> >>> > > 275153 PID:4c6000e TID:4c7000a
> >>> > > CFGControl::CImplMediaSeeking::GetRate()
> >>> > > 275154 PID:4c6000e TID:4c7000a
> >>> > > CFGControl::CImplMediaSeeking::SetRate()
>
> >>> > > It doesn't look like a single call is issued to my demux, which
> >>> > > makes me
> >>> > > believe the problem is in Microsoft code that perhaps needs to be
> >>> > > overwridden.  I'm confused as to where this error is coming from or
> >>> > > how to
> >>> > > debug this any further.
>
> >>> > > Would appreciate any help.
>
> >>> > > "Broofus" wrote:
>

> >>> > >> I have custom Demuxes and Decoders that I've used onWinCE5.0 with
> >>> > >> no
> >>> > >> problems, but upon moving toWinCE6.0 Fast Rewind stopped working.


> >>> > >> Now
> >>> > >> if I
> >>> > >> press the fast rewind button a message box pops up with "An unknown
> >>> > >> error
> >>> > >> has
> >>> > >> occurred (0x80070057)".  The video continues to play at normal play
> >>> > >> rate.
> >>> > >> I
> >>> > >> assume the issue is with the Demuxer because if I play WMV content
> >>> > >> with
> >>> > >> the
> >>> > >> ASF Parser supplied by Microsoft fast rewind works fine.
>
> >>> > >> The problems appears to be with the put_Rate() call made in
> >>> > >> playerwindow.cpp
> >>> > >> when a negative rate is passed in as the argument.  It looks like
> >>> > >> the
> >>> > >> 0x80070057 code comes from E_INVALIDARGS being returned from
> >>> > >> somewhere.
>
> >>> > >> Do I need to override some virtual function now that I wouldn't
> >>> > >> need to
> >>> > >> in
> >>> > >>WinCE5.0?
>

> >>> > >> I'd appreciate any thoughts or ideas.  Thanks- Hide quoted text -
>
> - Show quoted text -

andy rock

unread,
Mar 30, 2012, 7:54:26 AM3/30/12
to
I have another issue related to this topic.actually i have audio video sync issue.
So i wanted to know how to modify or optimize the demux filter and whre to modify.
plz help.ASAP

> On Friday, March 21, 2008 1:31 PM Broofu wrote:

> I have custom Demuxes and Decoders that I've used on WinCE 5.0 with no
> problems, but upon moving to WinCE 6.0 Fast Rewind stopped working. Now if I
> press the fast rewind button a message box pops up with "An unknown error has
> occurred (0x80070057)". The video continues to play at normal play rate. I
> assume the issue is with the Demuxer because if I play WMV content with the
> ASF Parser supplied by Microsoft fast rewind works fine.
>
> The problems appears to be with the put_Rate() call made in playerwindow.cpp
> when a negative rate is passed in as the argument. It looks like the
> 0x80070057 code comes from E_INVALIDARGS being returned from somewhere.
>
> Do I need to override some virtual function now that I wouldn't need to in
> WinCE 5.0?
>
> I'd appreciate any thoughts or ideas. Thanks


>> On Friday, March 21, 2008 3:29 PM Broofu wrote:

>> I just wanted to update this. I put breakpoints at the point where the
>> CEPlayer issues the put_Rate() call and where the error message box is
>> displayed with all of the Debug Zones in quartz.dll enabled and these are the
>> only prints I got:
>>
>> 275153 PID:4c6000e TID:4c7000a CFGControl::CImplMediaSeeking::GetRate()
>> 275154 PID:4c6000e TID:4c7000a CFGControl::CImplMediaSeeking::SetRate()
>>
>> It doesn't look like a single call is issued to my demux, which makes me
>> believe the problem is in Microsoft code that perhaps needs to be
>> overwridden. I'm confused as to where this error is coming from or how to
>> debug this any further.
>>
>> Would appreciate any help.
>>
>> "Broofus" wrote:


>>> On Friday, March 21, 2008 8:23 PM Haitao Jiang \(MS\) wrote:

>>> Can you give more details about your playback pipeline? What is your media
>>> format? After you render the file, can you use
>>> IMediaSeeking::CheckCapabilities to see if AM_SEEKING_CanSeekBackwards is
>>> supported or not? If not, SetRate with negative rates will return invalid
>>> argument error. For details, check out
>>> http://msdn2.microsoft.com/en-us/library/aa921453.aspx.
>>>
>>> Thanks,
>>> --
>>> Haitao Jiang
>>> Software Design Engineer in Test
>>> Windows Device Core Multimedia
>>>
>>> This posting is provided "AS IS" with no warranties, and confers no rights.
>>> You assume all risk for your use.
>>>
>>> "Broofus" <Bro...@discussions.microsoft.com> wrote in message
>>> news:3308C70E-9184-4838...@microsoft.com...


>>>> On Monday, March 24, 2008 6:06 PM Broofu wrote:

>>>> Thanks for responding.
>>>>
>>>> I have the following custome decoders:
>>>> Mpeg1/2, Mpeg4, DivX, and WMV9
>>>>
>>>> and the following custom demuxers:
>>>> Mpeg1/2, Mpeg4, and AVI
>>>>
>>>>
>>>> If I try to use any of my demuxers I can not do fast rewind. But using the
>>>> MS demuxers everything works fine. So for instance WMV works because we use
>>>> the ASF splitter provided by MS, but if I play WMV in AVI container it
>>>> doesn't. Previously all of these filters worked fine in WinCE 5.0. Upon
>>>> testing them in WinCE 6.0 the fast rewind issue was encountered.
>>>>
>>>> I have done some more debugging and have found that in
>>>> CImplMediaSeeking::SetRate() there is some sort of check to see if the
>>>> desired rate is less than some number (this is assembly since I don't have
>>>> the sources, so I'm not sure exactly where this number comes from). That
>>>> returns TRUE and causes the E_INVALIDARG error message. If I change the
>>>> return value to FALSE the graph is then halted and the rate is changes.
>>>> Appears to be a check to see if the desired rate is smaller than the minimum
>>>> rate.
>>>>
>>>> This seems to indicate that I'm not reporting the ability to play backwards.
>>>> I would have thought that the capabilities would be determined in the
>>>> GetCapabilities() funtion. This is what I currently have and it doesn't work:
>>>>
>>>> class CBaseSeeking : public CUnknown, public IMediaSeeking, public
>>>> IAMExtendedSeeking
>>>>
>>>> CBaseSeeking::GetCapabilities()
>>>> {
>>>> *pCapabilities = AM_SEEKING_CanSeekAbsolute |
>>>> AM_SEEKING_CanSeekForwards |
>>>> AM_SEEKING_CanSeekBackwards |
>>>> AM_SEEKING_CanGetStopPos |
>>>> AM_SEEKING_CanPlayBackwards | AM_SEEKING_CanGetCurrentPos
>>>> AM_SEEKING_CanGetDuration;
>>>>
>>>> return S_OK
>>>> }
>>>>
>>>> "Haitao Jiang (MS)" wrote:


>>>>> On Tuesday, March 25, 2008 3:06 PM Broofu wrote:

>>>>> I've noticed that when playing WMV content that CImplMediaSeeking::SetRate()
>>>>> is not called, but instead CImplWMSeeking::SetRate(). If you step through
>>>>> this assembly there is only a check to see if the desired rate is equal to
>>>>> some number (I'm assuming the current rate) and if it's greater than some
>>>>> other number (Max speed?). There is no check to see if the desired rate is
>>>>> less than something as you find in the CImplMediaSeeking implementation.
>>>>>
>>>>> I don't understand how to override this function as is being done for WMV.
>>>>> For example in my AVI demux I have overridden SetRate() functions as follows:
>>>>>
>>>>> class CBaseDemuxFilter : public CBaseFilter
>>>>> HRESULT CBaseDemuxFilter::SetRate(double dRate)
>>>>>
>>>>> class CDemuxInputPin : public CBaseInputPin
>>>>> HRESULT CDemuxInputPin::SetRate(int nRate, BOOL bReStartPuller)
>>>>>
>>>>> class CAVIDemux : public CBaseDemux
>>>>> HRESULT CAVIDemux::SetRate(double dRate)
>>>>>
>>>>> class CBaseSeeking : public CUnknown, public IMediaSeeking, public
>>>>> IAMExtendedSeeking
>>>>> STDMETHODIMP CBaseSeeking::SetRate(double dRate)
>>>>>
>>>>> Am I missing something?
>>>>>
>>>>> Thanks...
>>>>>
>>>>> "Broofus" wrote:


>>>>>> On Friday, March 28, 2008 9:40 PM Haitao Jiang \(MS\) wrote:

>>>>>> The filter graph manager distributes IMediaSeeking calls to the filter in
>>>>>> the graph which has the implementation. Since the WM source filter reports
>>>>>> the right seeking capabilities, the filter graph manager knows it supports
>>>>>> rewinding and forwards calls to it. Somehow your demuxers were not exposing
>>>>>> the caps correctly, so the filter graph manager responded the seeking calls
>>>>>> with no actions because it didn't know your demuxer's capabilities.
>>>>>>
>>>>>> The check in the SetRate is to make sure you couldn't pass a negative rate
>>>>>> if the filters don't support it. But from your code, it did support
>>>>>> AM_SEEKING_CanPlayBackwards. A couple of things you can try is:
>>>>>>
>>>>>> 1. After the graph is built, use IMediaSeeking::GetCapabilities to see
>>>>>> if AM_SEEKING_CanPlayBackwards is supported.
>>>>>>
>>>>>> 2. If the result is not supported, check to see how many filters in
>>>>>> your pipeline support IMediaSeeking interface and make sure only one filter
>>>>>> exposing IMediaSeeking.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --
>>>>>> Haitao Jiang
>>>>>> Software Design Engineer in Test
>>>>>> Windows Device Core Multimedia
>>>>>>
>>>>>> This posting is provided "AS IS" with no warranties, and confers no rights.
>>>>>> You assume all risk for your use.
>>>>>>
>>>>>> "Broofus" <Bro...@discussions.microsoft.com> wrote in message
>>>>>> news:C5DD30FA-0028-4ED2...@microsoft.com...


>>>>>>> On Tuesday, April 01, 2008 2:52 PM Haitao Jiang \(MS\) wrote:

>>>>>>> It seems you implemented IMediaSeeking on the input pin. Can you try to
>>>>>>> implement it on the output pin of the demuxer? From the directx
>>>>>>> documentation, "The application queries the Filter Graph Manager for
>>>>>>> IMediaSeeking and uses it to issue seek commands. The Filter Graph Manager
>>>>>>> distributes each seek command to all of the renderer filters in the graph.
>>>>>>> Each renderer passes the command upstream, through the output pins of the
>>>>>>> upstream filters, until it reaches a filter that can execute the seek"
>>>>>>>
>>>>>>> Also please check out information at
>>>>>>> http://msdn2.microsoft.com/en-us/library/aa930719.aspx to see if you
>>>>>>> implemented the interface correctly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --
>>>>>>> Haitao Jiang
>>>>>>> Software Design Engineer in Test
>>>>>>> Windows Device Core Multimedia
>>>>>>>
>>>>>>> This posting is provided "AS IS" with no warranties, and confers no rights.
>>>>>>> You assume all risk for your use.
>>>>>>>
>>>>>>> "Haitao Jiang (MS)" <hai...@online.microsoft.com.noonlineemail> wrote in
>>>>>>> message news:OowIf3Tk...@TK2MSFTNGP06.phx.gbl...


>>>>>>>> On Thursday, April 03, 2008 9:56 PM embde wrote:

>>>>>>>> It would appear in WinCE 6 that the direct show framework was changed
>>>>>>>> and no longer matches the published documentation. A filter that
>>>>>>>> works on WinCE 5.0 and WinXP no longer is able to rewind on WinCE
>>>>>>>> 6.0. Also sample applications that can rewind on WinCE5.0 and WinXP
>>>>>>>> can no longer rewind either since the negative rates are not making it
>>>>>>>> through the directshow framework to the filters themselves.
>>>>>>>>
>>>>>>>> Their is a new check done for negative rates, that didn't exist
>>>>>>>> previously or the conditions for the check have changed. Could you
>>>>>>>> let us know why the check was added or what conditions have changed
>>>>>>>> that cause the check to happen now when it doesn't with WinCE 5.0
>>>>>>>> directshow framework or the WinXP Directshow framework?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>>
>>>>>>>> On Apr 1, 2:52=A0pm, "Haitao Jiang \(MS\)"
>>>>>>>> <hait...@online.microsoft.com.noonlineemail> wrote:
>>>>>>>> Seekingand uses it to issue seek commands. The Filter Graph Manager
>>>>>>>>
>>>>>>>> ry/aa930719.aspxto see if you
>>>>>>>> .
>>>>>>>> t
>>>>>>>> re
>>>>>>>> he
>>>>>>>> te
>>>>>>>> s to
>>>>>>>> ers in
>>>>>>>>
>>>>>>>> me
>>>>>>>> ate
>>>>>>>> .
>>>>>>>> ing
>>>>>>>> e we
>>>>>>>>
>>>>>>>>
>>>>>>>> the
>>>>>>>> .
>>>>>>>> he
>>>>>>>> sn't
>>>>>>>> |
>>>>>>>> s |
>>>>>>>>
>>>>>>>> tCurrentPos
>>>>>>>>
>>>>>>>>
>>>>>>>> s
>>>>>>>>
>>>>>>>> ere
>>>>>>>> x
>>>>>>>> or
>>>>>>>>
>>>>>>>>
>>>>>>>> wn
>>>>>>>> play
>>>>>>>> t
>>>>>>>> ke
>>>>>>>> -



0 new messages