Video Capture Performance with directshow

Just as a follow up, depending on your device the manufacturer may have put
in a third party video encoder, multiplexer, and file writer which are
compatible with the DirectShow video capture pipeline. Most of these are a
3GPP encoder for mms. You could try enumerating the filters available in the
system (or look in the registry), to see if you can find one. If there is
one available it will work exactly the same as the WMV encoder and ASF
multiplexer, it'll just have different GUID's and potentially there will be
an audio encoder also. As a starting point i'd recommend checking out the
pictures and video's registry keys for the Windows Mobile camera application
if the application that ships on the device supports a format other than
WMV.

Gary Daniels
Windows CE Multimedia and Graphics

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

"Gary Daniels [MS]" <garydan.DeleteThis@online.microsoft.com> wrote in message
news:466612e9$1@news.microsoft.com...
>I suspect you're using the WMV encoder?
>
> The memory usage spike you're seeing is the buffering filter storing up as
> much video as it can that's on it's way into the WMV encoder, once it runs
> out of ram it starts dropping samples. The app shouldn't stop running
> though, everything should continue to run (but probably very slowly). Once
> you stop the capture the samples will continue flow out of the buffering
> filter on the low priority thread which the video encoding happens on.
> Once encoding is completely finished (which may take many minutes
> depending on the resolution, how much was buffered, and how fast the CPU
> is) you'll receive the stream control stopped event. Don't stop the graph
> until you receive that event, otherwise the buffered video will be
> discarded.
>
> To fix the problem you'll need to decrease the resolution of the video
> you're trying to capture. The root of the problem is the WMV encoder just
> can't encode the video fast enough for the resolution and quality you've
> selected, so it tries it's best and ends up with a few second long
> slideshow. The WMV encoder provided in windows mobile is optimized for
> ARM, but WMV was primarily designed for the desktop and struggles to
> perform on low end devices. When it's running well, in my opinion the
> quality of the encoded video is better than MPEG at an equivalant
> resolution, however it has a much higher CPU utilization at that
> resolution which reduces its maximum resolution possible on mobile devices
> (well below what MPEG is capable of on the same CPU).
>
> Gary Daniels
> Windows CE Multimedia and Graphics
>
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> You assume all risk for your use.
>
> "SkyWaLKer" <shantanu.goel.DeleteThis@gmail.com> wrote in message
> news:1180796687.257341.166210@g37g2000prf.googlegroups.com...
>> Hi
>> I'm writing a directshow based solution for capturing window (target
>> is WM 5.0). Its in native code.
>> Now, I've been able to get it all together after reading through
>> sample code on msdn and bits of info scattered here and there. But my
>> problem is:
>> 1. When I run it on my Pocket PC, the available RAM (Program Memory)
>> diminshes rapidly irrespective of the time for which capturing is
>> done. It drops down to alarmingly low level (to around just 2 MB free
>> ram remaining) and then the app conks out. BTW, the output file size
>> is always a few KBs, so dont kjnow why so much ram is eaten.
>> 2. No matter how long I wait between starting and stopping the control
>> stream, the recorded video comes out to be juse a couple of seconds at
>> max.
>>
>> Basically what I'm doing in my code for starting stopping capture is:
>> ________________CODE________________
>> hResult=pFilterGraph->QueryInterface(&pMediaControl);
>> hResult =pMediaControl->Run();
>> OAFilterState state = State_Stopped;
>> while(state != State_Running)
>> pMediaControl->GetState(100, &state);
>>
>> LONGLONG dwStart = 0, dwEnd = 0;
>> WORD wStartCookie = 1, wEndCookie = 2;
>> dwEnd=MAXLONGLONG;
>> //start capturing
>> hResult=pCaptureGraphBuilder->ControlStream(
>> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
>> &dwStart, &dwEnd, 0, 0 );
>> Sleep(30000);
>> //Stop capturing
>> dwStart=0;
>> IMediaSeeking *pMediaSeeking;
>> hResult=pFilterGraph->QueryInterface(&pMediaSeeking );
>> hResult=pMediaSeeking->GetCurrentPosition( &dwEnd );
>> hResult= pCaptureGraphBuilder->ControlStream(
>> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
>> &dwStart, &dwEnd, wStartCookie, wEndCookie );
>> long leventCode, param1, param2;
>>
>> hResult =pFilterGraph->QueryInterface( IID_IMediaEventEx, (void**)
>> &pMediaEvent );
>> hResult = pMediaControl->Stop();
>> _________________CODE______________________
>>
>> So, please help me out as to :
>> 1. How to avoid the memory loss while recording?
>> 2. How to record for a longer length?
>>
>> Regards
>> Shantz
>>
>
>

On Jun 6, 6:58 am, "Gary Daniels [MS]" <gary... RemoveThis @online.microsoft.com>
wrote:
> Just as a follow up, depending on your device the manufacturer may have put
> in a third party video encoder, multiplexer, and file writer which are
> compatible with the DirectShow video capture pipeline. Most of these are a
> 3GPP encoder for mms. You could try enumerating the filters available in the
> system (or look in the registry), to see if you can find one. If there is
> one available it will work exactly the same as the WMV encoder and ASF
> multiplexer, it'll just have different GUID's and potentially there will be
> an audio encoder also. As a starting point i'd recommend checking out the
> pictures and video's registry keys for the Windows Mobile camera application
> if the application that ships on the device supports a format other than
> WMV.

Hi Gary
Thnx for the reply. I'm at office right now and will try enumerating
the available filters when I go back. However I looked through the
registry for the filters (using keywords like video, encoder, DMO,
filter etc) and found out a few interesting things:
1. Found that only WMV9 is registered as a DMO video encoder.
2. Also found a complete list of filters (subkeys within a subkey
called "filters"). It listed all the known filters (GUIds as subkeys
and name given in description) like WMV9 encoder, audio encoder,
MPEG-1 decoder, Audio Capture, Video Capture etc, but there was no
other "encoder" listed. HOWEVER, the thing is that this list also
contained 3-4 other keys (GUIDs) which didn't have any description
given. Can these be the encoder GUIDs used by the OEM camera app? But
these dont have any corresponding DMO entries in the registry.
3. I also had smthing else in mind. If we can make the graph in such a
way that it buffers some samples and then encodes them, then buffers
the next samples and then encodes them, and write these directly to
the disk, then maybe we can alleviate this problem of encoding
delay..Any thoughts on that?
Regards
Shantanu








>
> This posting is provided "AS IS" with no warranties, and confers no rights.
> You assume all risk for your use.
>
> "GaryDaniels[MS]" <gary... RemoveThis @online.microsoft.com> wrote in messagenews:466612e9$1@news.microsoft.com...
>
> >I suspect you're using the WMV encoder?
>
> > The memory usage spike you're seeing is the buffering filter storing up as
> > much video as it can that's on it's way into the WMV encoder, once it runs
> > out of ram it starts dropping samples. The app shouldn't stop running
> > though, everything should continue to run (but probably very slowly). Once
> > you stop the capture the samples will continue flow out of the buffering
> > filter on the low priority thread which the video encoding happens on.
> > Once encoding is completely finished (which may take many minutes
> > depending on the resolution, how much was buffered, and how fast the CPU
> > is) you'll receive the stream control stopped event. Don't stop the graph
> > until you receive that event, otherwise the buffered video will be
> > discarded.
>
> > To fix the problem you'll need to decrease the resolution of the video
> > you're trying to capture. The root of the problem is the WMV encoder just
> > can't encode the video fast enough for the resolution and quality you've
> > selected, so it tries it's best and ends up with a few second long
> > slideshow. The WMV encoder provided in windows mobile is optimized for
> > ARM, but WMV was primarily designed for the desktop and struggles to
> > perform on low end devices. When it's running well, in my opinion the
> > quality of the encoded video is better than MPEG at an equivalant
> > resolution, however it has a much higher CPU utilization at that
> > resolution which reduces its maximum resolution possible on mobile devices
> > (well below what MPEG is capable of on the same CPU).
>
> >GaryDaniels
> > Windows CE Multimedia and Graphics
>
> > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > You assume all risk for your use.
>
> > "SkyWaLKer" <shantanu.g... RemoveThis @gmail.com> wrote in message
> >news:1180796687.257341.166210@g37g2000prf.googlegroups.com...
> >> Hi
> >> I'm writing a directshow based solution for capturing window (target
> >> is WM 5.0). Its in native code.
> >> Now, I've been able to get it all together after reading through
> >> sample code on msdn and bits of info scattered here and there. But my
> >> problem is:
> >> 1. When I run it on my Pocket PC, the available RAM (Program Memory)
> >> diminshes rapidly irrespective of the time for which capturing is
> >> done. It drops down to alarmingly low level (to around just 2 MB free
> >> ram remaining) and then the app conks out. BTW, the output file size
> >> is always a few KBs, so dont kjnow why so much ram is eaten.
> >> 2. No matter how long I wait between starting and stopping the control
> >> stream, the recorded video comes out to be juse a couple of seconds at
> >> max.
>
> >> Basically what I'm doing in my code for starting stopping capture is:
> >> ________________CODE________________
> >> hResult=pFilterGraph->QueryInterface(&pMediaControl);
> >> hResult =pMediaControl->Run();
> >> OAFilterState state = State_Stopped;
> >> while(state != State_Running)
> >> pMediaControl->GetState(100, &state);
>
> >> LONGLONG dwStart = 0, dwEnd = 0;
> >> WORD wStartCookie = 1, wEndCookie = 2;
> >> dwEnd=MAXLONGLONG;
> >> //start capturing
> >> hResult=pCaptureGraphBuilder->ControlStream(
> >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
> >> &dwStart, &dwEnd, 0, 0 );
> >> Sleep(30000);
> >> //Stop capturing
> >> dwStart=0;
> >> IMediaSeeking *pMediaSeeking;
> >> hResult=pFilterGraph->QueryInterface(&pMediaSeeking );
> >> hResult=pMediaSeeking->GetCurrentPosition( &dwEnd );
> >> hResult= pCaptureGraphBuilder->ControlStream(
> >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
> >> &dwStart, &dwEnd, wStartCookie, wEndCookie );
> >> long leventCode, param1, param2;
>
> >> hResult =pFilterGraph->QueryInterface( IID_IMediaEventEx, (void**)
> >> &pMediaEvent );
> >> hResult = pMediaControl->Stop();
> >> _________________CODE______________________
>
> >> So, please help me out as to :
> >> 1. How to avoid the memory loss while recording?
> >> 2. How to record for a longer length?
>
> >> Regards
> >> Shantz

So I enumerated the filters present on my device (HTC Wizard/Qtek9100/
i-mate KJAM/T-Mobile MDA). Got 4 extra filters (i.e. not microsoft).
These filters were from HTC as the names suggested. 3 out of them were
for rendering video/audio and one mp3 decoder. The last one was named
"HTC DDR". Anyone knows what this does? Anyways, I tried to use the
CLSID of this filter in my IDMOWrapperFilter. A query interface on HTC
DDR for IDMOWrapperFilter return S_OK but when I tried to call the
Init method of IDMOWrapperFilter, it reurned E_NOINTERFACE. Any
suggestion??

On Jun 6, 3:31 pm, SkyWaLKer <shantanu.g....DeleteThis@gmail.com> wrote:
> On Jun 6, 6:58 am, "Gary Daniels [MS]" <gary....DeleteThis@online.microsoft.com>
> wrote:
>
> > Just as a follow up, depending on your device the manufacturer may have put
> > in a third party video encoder, multiplexer, and file writer which are
> > compatible with the DirectShow video capture pipeline. Most of these are a
> > 3GPP encoder for mms. You could try enumerating the filters available in the
> > system (or look in the registry), to see if you can find one. If there is
> > one available it will work exactly the same as the WMV encoder and ASF
> > multiplexer, it'll just have different GUID's and potentially there will be
> > an audio encoder also. As a starting point i'd recommend checking out the
> > pictures and video's registry keys for the Windows Mobile camera application
> > if the application that ships on the device supports a format other than
> > WMV.
>
> Hi Gary
> Thnx for the reply. I'm at office right now and will try enumerating
> the available filters when I go back. However I looked through the
> registry for the filters (using keywords like video, encoder, DMO,
> filter etc) and found out a few interesting things:
> 1. Found that only WMV9 is registered as a DMO video encoder.
> 2. Also found a complete list of filters (subkeys within a subkey
> called "filters"). It listed all the known filters (GUIds as subkeys
> and name given in description) like WMV9 encoder, audio encoder,
> MPEG-1 decoder, Audio Capture, Video Capture etc, but there was no
> other "encoder" listed. HOWEVER, the thing is that this list also
> contained 3-4 other keys (GUIDs) which didn't have any description
> given. Can these be the encoder GUIDs used by the OEM camera app? But
> these dont have any corresponding DMO entries in the registry.
> 3. I also had smthing else in mind. If we can make the graph in such a
> way that it buffers some samples and then encodes them, then buffers
> the next samples and then encodes them, and write these directly to
> the disk, then maybe we can alleviate this problem of encoding
> delay..Any thoughts on that?
> Regards
> Shantanu
>
>
>
> > This posting is provided "AS IS" with no warranties, and confers no rights.
> > You assume all risk for your use.
>
> > "GaryDaniels[MS]" <gary....DeleteThis@online.microsoft.com> wrote in messagenews:466612e9$1@news.microsoft.com...
>
> > >I suspect you're using the WMV encoder?
>
> > > The memory usage spike you're seeing is the buffering filter storing up as
> > > much video as it can that's on it's way into the WMV encoder, once it runs
> > > out of ram it starts dropping samples. The app shouldn't stop running
> > > though, everything should continue to run (but probably very slowly). Once
> > > you stop the capture the samples will continue flow out of the buffering
> > > filter on the low priority thread which the video encoding happens on.
> > > Once encoding is completely finished (which may take many minutes
> > > depending on the resolution, how much was buffered, and how fast the CPU
> > > is) you'll receive the stream control stopped event. Don't stop the graph
> > > until you receive that event, otherwise the buffered video will be
> > > discarded.
>
> > > To fix the problem you'll need to decrease the resolution of the video
> > > you're trying to capture. The root of the problem is the WMV encoder just
> > > can't encode the video fast enough for the resolution and quality you've
> > > selected, so it tries it's best and ends up with a few second long
> > > slideshow. The WMV encoder provided in windows mobile is optimized for
> > > ARM, but WMV was primarily designed for the desktop and struggles to
> > > perform on low end devices. When it's running well, in my opinion the
> > > quality of the encoded video is better than MPEG at an equivalant
> > > resolution, however it has a much higher CPU utilization at that
> > > resolution which reduces its maximum resolution possible on mobile devices
> > > (well below what MPEG is capable of on the same CPU).
>
> > >GaryDaniels
> > > Windows CE Multimedia and Graphics
>
> > > This posting is provided "AS IS" with no warranties, and confers no
> > > rights.
> > > You assume all risk for your use.
>
> > > "SkyWaLKer" <shantanu.g....DeleteThis@gmail.com> wrote in message
> > >news:1180796687.257341.166210@g37g2000prf.googlegroups.com...
> > >> Hi
> > >> I'm writing a directshow based solution for capturing window (target
> > >> is WM 5.0). Its in native code.
> > >> Now, I've been able to get it all together after reading through
> > >> sample code on msdn and bits of info scattered here and there. But my
> > >> problem is:
> > >> 1. When I run it on my Pocket PC, the available RAM (Program Memory)
> > >> diminshes rapidly irrespective of the time for which capturing is
> > >> done. It drops down to alarmingly low level (to around just 2 MB free
> > >> ram remaining) and then the app conks out. BTW, the output file size
> > >> is always a few KBs, so dont kjnow why so much ram is eaten.
> > >> 2. No matter how long I wait between starting and stopping the control
> > >> stream, the recorded video comes out to be juse a couple of seconds at
> > >> max.
>
> > >> Basically what I'm doing in my code for starting stopping capture is:
> > >> ________________CODE________________
> > >> hResult=pFilterGraph->QueryInterface(&pMediaControl);
> > >> hResult =pMediaControl->Run();
> > >> OAFilterState state = State_Stopped;
> > >> while(state != State_Running)
> > >> pMediaControl->GetState(100, &state);
>
> > >> LONGLONG dwStart = 0, dwEnd = 0;
> > >> WORD wStartCookie = 1, wEndCookie = 2;
> > >> dwEnd=MAXLONGLONG;
> > >> //start capturing
> > >> hResult=pCaptureGraphBuilder->ControlStream(
> > >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
> > >> &dwStart, &dwEnd, 0, 0 );
> > >> Sleep(30000);
> > >> //Stop capturing
> > >> dwStart=0;
> > >> IMediaSeeking *pMediaSeeking;
> > >> hResult=pFilterGraph->QueryInterface(&pMediaSeeking );
> > >> hResult=pMediaSeeking->GetCurrentPosition( &dwEnd );
> > >> hResult= pCaptureGraphBuilder->ControlStream(
> > >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
> > >> &dwStart, &dwEnd, wStartCookie, wEndCookie );
> > >> long leventCode, param1, param2;
>
> > >> hResult =pFilterGraph->QueryInterface( IID_IMediaEventEx, (void**)
> > >> &pMediaEvent );
> > >> hResult = pMediaControl->Stop();
> > >> _________________CODE______________________
>
> > >> So, please help me out as to :
> > >> 1. How to avoid the memory loss while recording?
> > >> 2. How to record for a longer length?
>
> > >> Regards
> > >> Shantz

Just found out that HTC devices ship with a filter named "HTC Source
Filter". Somewhere on directx.audio group I found out that someone had
delved into it a bit and found that it was a capture filter from HTC
(both audio and video). I checked in registry and that is true. So, it
must be some optimized filter that we can use for capture.
Now, I tried to enumerate the pins on this capture filter, for which I
have to first query for an IPersistPropertyBag interface on this
filter (used the clsid of the filter from the registry and
CoCreateInstance for it returns S_OK). But the QueryInterface returns
E_NOINTERFACE. Any opinions/suggestions here? Because the registry
clearyly shows that this is a capture filter. Is there any other way I
can use this filter?
---My Code---
HRESULT hResult = S_OK;
IGraphBuilder *pFilterGraph;
ICaptureGraphBuilder2 *pCaptureGraphBuilder;
htcDDR.Data1 = 0xA06DF275;
htcDDR.Data2 = 0xC4F3;
htcDDR.Data3 = 0x46C7;
htcDDR.Data4[0] = 0xB5;
htcDDR.Data4[1] = 0x20;
htcDDR.Data4[2] = 0x3A;
htcDDR.Data4[3] = 0x16;
htcDDR.Data4[4] = 0xB3;
htcDDR.Data4[5] = 0xD1;
htcDDR.Data4[6] = 0xB8;
htcDDR.Data4[7] = 0xC2;
hResult = CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC,
IID_IGraphBuilder,(void**)&pFilterGraph);
hResult = CoCreateInstance(CLSID_CaptureGraphBuilder, NULL,
CLSCTX_INPROC, IID_ICaptureGraphBuilder2,
(void**)& pCaptureGraphBuilder);

hResult = pCaptureGraphBuilder->SetFiltergraph( pFilterGraph );

IBaseFilter *pVideoCaptureFilter;
hResult=CoCreateInstance(htcDDR, NULL, CLSCTX_INPROC,
IID_IBaseFilter,
(void**)&pVideoCaptureFilter);

IPersistPropertyBag *pPropertyBag;

hResult=pVideoCaptureFilter->QueryInterface( IID_IPersistPropertyBag,
(void**) &pPropertyBag );
/* This is where I get the E_NOINTERFACE*/
---------------

Regards
Shantanu
On Jun 6, 10:11 pm, SkyWaLKer <shantanu.g... DeleteThis @gmail.com> wrote:
> So I enumerated the filters present on my device (HTC Wizard/Qtek9100/
> i-mate KJAM/T-Mobile MDA). Got 4 extra filters (i.e. not microsoft).
> These filters were from HTC as the names suggested. 3 out of them were
> for rendering video/audio and one mp3 decoder. The last one was named
> "HTC DDR". Anyone knows what this does? Anyways, I tried to use the
> CLSID of this filter in my IDMOWrapperFilter. A query interface on HTC
> DDR for IDMOWrapperFilter return S_OK but when I tried to call the
> Init method of IDMOWrapperFilter, it reurned E_NOINTERFACE. Any
> suggestion??
>
> On Jun 6, 3:31 pm, SkyWaLKer <shantanu.g... DeleteThis @gmail.com> wrote:
>
> > On Jun 6, 6:58 am, "Gary Daniels [MS]" <gary... DeleteThis @online.microsoft.com>
> > wrote:
>
> > > Just as a follow up, depending on your device the manufacturer may have put
> > > in a third party video encoder, multiplexer, and file writer which are
> > > compatible with the DirectShow video capture pipeline. Most of these are a
> > > 3GPP encoder for mms. You could try enumerating the filters available in the
> > > system (or look in the registry), to see if you can find one. If there is
> > > one available it will work exactly the same as the WMV encoder and ASF
> > > multiplexer, it'll just have different GUID's and potentially there will be
> > > an audio encoder also. As a starting point i'd recommend checking out the
> > > pictures and video's registry keys for the Windows Mobile camera application
> > > if the application that ships on the device supports a format other than
> > > WMV.
>
> > Hi Gary
> > Thnx for the reply. I'm at office right now and will try enumerating
> > the available filters when I go back. However I looked through the
> > registry for the filters (using keywords like video, encoder, DMO,
> > filter etc) and found out a few interesting things:
> > 1. Found that only WMV9 is registered as a DMO video encoder.
> > 2. Also found a complete list of filters (subkeys within a subkey
> > called "filters"). It listed all the known filters (GUIds as subkeys
> > and name given in description) like WMV9 encoder, audio encoder,
> > MPEG-1 decoder, Audio Capture, Video Capture etc, but there was no
> > other "encoder" listed. HOWEVER, the thing is that this list also
> > contained 3-4 other keys (GUIDs) which didn't have any description
> > given. Can these be the encoder GUIDs used by the OEM camera app? But
> > these dont have any corresponding DMO entries in the registry.
> > 3. I also had smthing else in mind. If we can make the graph in such a
> > way that it buffers some samples and then encodes them, then buffers
> > the next samples and then encodes them, and write these directly to
> > the disk, then maybe we can alleviate this problem of encoding
> > delay..Any thoughts on that?
> > Regards
> > Shantanu
>
> > > This posting is provided "AS IS" with no warranties, and confers no rights.
> > > You assume all risk for your use.
>
> > > "GaryDaniels[MS]" <gary... DeleteThis @online.microsoft.com> wrote in messagenews:466612e9$1@news.microsoft.com...
>
> > > >I suspect you're using the WMV encoder?
>
> > > > The memory usage spike you're seeing is the buffering filter storing up as
> > > > much video as it can that's on it's way into the WMV encoder, once it runs
> > > > out of ram it starts dropping samples. The app shouldn't stop running
> > > > though, everything should continue to run (but probably very slowly). Once
> > > > you stop the capture the samples will continue flow out of the buffering
> > > > filter on the low priority thread which the video encoding happens on.
> > > > Once encoding is completely finished (which may take many minutes
> > > > depending on the resolution, how much was buffered, and how fast the CPU
> > > > is) you'll receive the stream control stopped event. Don't stop the graph
> > > > until you receive that event, otherwise the buffered video will be
> > > > discarded.
>
> > > > To fix the problem you'll need to decrease the resolution of the video
> > > > you're trying to capture. The root of the problem is the WMV encoder just
> > > > can't encode the video fast enough for the resolution and quality you've
> > > > selected, so it tries it's best and ends up with a few second long
> > > > slideshow. The WMV encoder provided in windows mobile is optimized for
> > > > ARM, but WMV was primarily designed for the desktop and struggles to
> > > > perform on low end devices. When it's running well, in my opinion the
> > > > quality of the encoded video is better than MPEG at an equivalant
> > > > resolution, however it has a much higher CPU utilization at that
> > > > resolution which reduces its maximum resolution possible on mobile devices
> > > > (well below what MPEG is capable of on the same CPU).
>
> > > >GaryDaniels
> > > > Windows CE Multimedia and Graphics
>
> > > > This posting is provided "AS IS" with no warranties, and confers no
> > > > rights.
> > > > You assume all risk for your use.
>
> > > > "SkyWaLKer" <shantanu.g... DeleteThis @gmail.com> wrote in message
> > > >news:1180796687.257341.166210@g37g2000prf.googlegroups.com...
> > > >> Hi
> > > >> I'm writing a directshow based solution for capturing window (target
> > > >> is WM 5.0). Its in native code.
> > > >> Now, I've been able to get it all together after reading through
> > > >> sample code on msdn and bits of info scattered here and there. But my
> > > >> problem is:
> > > >> 1. When I run it on my Pocket PC, the available RAM (Program Memory)
> > > >> diminshes rapidly irrespective of the time for which capturing is
> > > >> done. It drops down to alarmingly low level (to around just 2 MB free
> > > >> ram remaining) and then the app conks out. BTW, the output file size
> > > >> is always a few KBs, so dont kjnow why so much ram is eaten.
> > > >> 2. No matter how long I wait between starting and stopping the control
> > > >> stream, the recorded video comes out to be juse a couple of seconds at
> > > >> max.
>
> > > >> Basically what I'm doing in my code for starting stopping capture is:
> > > >> ________________CODE________________
> > > >> hResult=pFilterGraph->QueryInterface(&pMediaControl);
> > > >> hResult =pMediaControl->Run();
> > > >> OAFilterState state = State_Stopped;
> > > >> while(state != State_Running)
> > > >> pMediaControl->GetState(100, &state);
>
> > > >> LONGLONG dwStart = 0, dwEnd = 0;
> > > >> WORD wStartCookie = 1, wEndCookie = 2;
> > > >> dwEnd=MAXLONGLONG;
> > > >> //start capturing
> > > >> hResult=pCaptureGraphBuilder->ControlStream(
> > > >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
> > > >> &dwStart, &dwEnd, 0, 0 );
> > > >> Sleep(30000);
> > > >> //Stop capturing
> > > >> dwStart=0;
> > > >> IMediaSeeking *pMediaSeeking;
> > > >> hResult=pFilterGraph->QueryInterface(&pMediaSeeking );
> > > >> hResult=pMediaSeeking->GetCurrentPosition( &dwEnd );
> > > >> hResult= pCaptureGraphBuilder->ControlStream(
> > > >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
> > > >> &dwStart, &dwEnd, wStartCookie, wEndCookie );
> > > >> long leventCode, param1, param2;
>
> > > >> hResult =pFilterGraph->QueryInterface( IID_IMediaEventEx, (void**)
> > > >> &pMediaEvent );
> > > >> hResult = pMediaControl->Stop();
> > > >> _________________CODE______________________
>
> > > >> So, please help me out as to :
> > > >> 1. How to avoid the memory loss while recording?
> > > >> 2. How to record for a longer length?
>
> > > >> Regards
> > > >> Shantz

I'm not familiar with any of the specific filters OEM's add to the devices,
sorry I can't be more help.

As for your question about video encoding, that is similar what we're doing
today. The "Buffering" filter is inserted just before the WMV encoder and
buffers up unencoded video into RAM. The output pin on the filter is running
at below normal priority, so it slowly feeds data into the WMV encoder as
CPU is available. When the filter runs out of RAM it drops the oldest sample
that hasn't been delivered to the encoder.

If you have an algorithm you'd like to use, it would be fairly simple to
replace the Microsoft buffering filter with your own implementation. Your
filter would have to have one input and one output. The input pin would need
to accept MEDIATYPE_Video/Audio, and the output pin would need to output
MEDIATYPE_VideoBuffered/AudioBuffered. When you go to build your capture
graph you'd cocreate two instances of the filter, one for video and one for
audio. When you render the encoding portion of the graph your buffering
filter would be automatically inserted instead of the Microsoft buffering
filter.

Gary Daniels
Windows CE Multimedia and Graphics

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

"SkyWaLKer" <shantanu.goel DeleteThis @gmail.com> wrote in message
news:1181242078.227759.317760@n15g2000prd.googlegroups.com...
> Just found out that HTC devices ship with a filter named "HTC Source
> Filter". Somewhere on directx.audio group I found out that someone had
> delved into it a bit and found that it was a capture filter from HTC
> (both audio and video). I checked in registry and that is true. So, it
> must be some optimized filter that we can use for capture.
> Now, I tried to enumerate the pins on this capture filter, for which I
> have to first query for an IPersistPropertyBag interface on this
> filter (used the clsid of the filter from the registry and
> CoCreateInstance for it returns S_OK). But the QueryInterface returns
> E_NOINTERFACE. Any opinions/suggestions here? Because the registry
> clearyly shows that this is a capture filter. Is there any other way I
> can use this filter?
> ---My Code---
> HRESULT hResult = S_OK;
> IGraphBuilder *pFilterGraph;
> ICaptureGraphBuilder2 *pCaptureGraphBuilder;
> htcDDR.Data1 = 0xA06DF275;
> htcDDR.Data2 = 0xC4F3;
> htcDDR.Data3 = 0x46C7;
> htcDDR.Data4[0] = 0xB5;
> htcDDR.Data4[1] = 0x20;
> htcDDR.Data4[2] = 0x3A;
> htcDDR.Data4[3] = 0x16;
> htcDDR.Data4[4] = 0xB3;
> htcDDR.Data4[5] = 0xD1;
> htcDDR.Data4[6] = 0xB8;
> htcDDR.Data4[7] = 0xC2;
> hResult = CoCreateInstance(CLSID_FilterGraph, NULL, CLSCTX_INPROC,
> IID_IGraphBuilder,(void**)&pFilterGraph);
> hResult = CoCreateInstance(CLSID_CaptureGraphBuilder, NULL,
> CLSCTX_INPROC, IID_ICaptureGraphBuilder2,
> (void**)& pCaptureGraphBuilder);
>
> hResult = pCaptureGraphBuilder->SetFiltergraph( pFilterGraph );
>
> IBaseFilter *pVideoCaptureFilter;
> hResult=CoCreateInstance(htcDDR, NULL, CLSCTX_INPROC,
> IID_IBaseFilter,
> (void**)&pVideoCaptureFilter);
>
> IPersistPropertyBag *pPropertyBag;
>
> hResult=pVideoCaptureFilter->QueryInterface( IID_IPersistPropertyBag,
> (void**) &pPropertyBag );
> /* This is where I get the E_NOINTERFACE*/
> ---------------
>
> Regards
> Shantanu
> On Jun 6, 10:11 pm, SkyWaLKer <shantanu.g... DeleteThis @gmail.com> wrote:
>> So I enumerated the filters present on my device (HTC Wizard/Qtek9100/
>> i-mate KJAM/T-Mobile MDA). Got 4 extra filters (i.e. not microsoft).
>> These filters were from HTC as the names suggested. 3 out of them were
>> for rendering video/audio and one mp3 decoder. The last one was named
>> "HTC DDR". Anyone knows what this does? Anyways, I tried to use the
>> CLSID of this filter in my IDMOWrapperFilter. A query interface on HTC
>> DDR for IDMOWrapperFilter return S_OK but when I tried to call the
>> Init method of IDMOWrapperFilter, it reurned E_NOINTERFACE. Any
>> suggestion??
>>
>> On Jun 6, 3:31 pm, SkyWaLKer <shantanu.g... DeleteThis @gmail.com> wrote:
>>
>> > On Jun 6, 6:58 am, "Gary Daniels [MS]" <gary... DeleteThis @online.microsoft.com>
>> > wrote:
>>
>> > > Just as a follow up, depending on your device the manufacturer may
>> > > have put
>> > > in a third party video encoder, multiplexer, and file writer which
>> > > are
>> > > compatible with the DirectShow video capture pipeline. Most of these
>> > > are a
>> > > 3GPP encoder for mms. You could try enumerating the filters available
>> > > in the
>> > > system (or look in the registry), to see if you can find one. If
>> > > there is
>> > > one available it will work exactly the same as the WMV encoder and
>> > > ASF
>> > > multiplexer, it'll just have different GUID's and potentially there
>> > > will be
>> > > an audio encoder also. As a starting point i'd recommend checking out
>> > > the
>> > > pictures and video's registry keys for the Windows Mobile camera
>> > > application
>> > > if the application that ships on the device supports a format other
>> > > than
>> > > WMV.
>>
>> > Hi Gary
>> > Thnx for the reply. I'm at office right now and will try enumerating
>> > the available filters when I go back. However I looked through the
>> > registry for the filters (using keywords like video, encoder, DMO,
>> > filter etc) and found out a few interesting things:
>> > 1. Found that only WMV9 is registered as a DMO video encoder.
>> > 2. Also found a complete list of filters (subkeys within a subkey
>> > called "filters"). It listed all the known filters (GUIds as subkeys
>> > and name given in description) like WMV9 encoder, audio encoder,
>> > MPEG-1 decoder, Audio Capture, Video Capture etc, but there was no
>> > other "encoder" listed. HOWEVER, the thing is that this list also
>> > contained 3-4 other keys (GUIDs) which didn't have any description
>> > given. Can these be the encoder GUIDs used by the OEM camera app? But
>> > these dont have any corresponding DMO entries in the registry.
>> > 3. I also had smthing else in mind. If we can make the graph in such a
>> > way that it buffers some samples and then encodes them, then buffers
>> > the next samples and then encodes them, and write these directly to
>> > the disk, then maybe we can alleviate this problem of encoding
>> > delay..Any thoughts on that?
>> > Regards
>> > Shantanu
>>
>> > > This posting is provided "AS IS" with no warranties, and confers no
>> > > rights.
>> > > You assume all risk for your use.
>>
>> > > "GaryDaniels[MS]" <gary... DeleteThis @online.microsoft.com> wrote in
>> > > messagenews:466612e9$1@news.microsoft.com...
>>
>> > > >I suspect you're using the WMV encoder?
>>
>> > > > The memory usage spike you're seeing is the buffering filter
>> > > > storing up as
>> > > > much video as it can that's on it's way into the WMV encoder, once
>> > > > it runs
>> > > > out of ram it starts dropping samples. The app shouldn't stop
>> > > > running
>> > > > though, everything should continue to run (but probably very
>> > > > slowly). Once
>> > > > you stop the capture the samples will continue flow out of the
>> > > > buffering
>> > > > filter on the low priority thread which the video encoding happens
>> > > > on.
>> > > > Once encoding is completely finished (which may take many minutes
>> > > > depending on the resolution, how much was buffered, and how fast
>> > > > the CPU
>> > > > is) you'll receive the stream control stopped event. Don't stop the
>> > > > graph
>> > > > until you receive that event, otherwise the buffered video will be
>> > > > discarded.
>>
>> > > > To fix the problem you'll need to decrease the resolution of the
>> > > > video
>> > > > you're trying to capture. The root of the problem is the WMV
>> > > > encoder just
>> > > > can't encode the video fast enough for the resolution and quality
>> > > > you've
>> > > > selected, so it tries it's best and ends up with a few second long
>> > > > slideshow. The WMV encoder provided in windows mobile is optimized
>> > > > for
>> > > > ARM, but WMV was primarily designed for the desktop and struggles
>> > > > to
>> > > > perform on low end devices. When it's running well, in my opinion
>> > > > the
>> > > > quality of the encoded video is better than MPEG at an equivalant
>> > > > resolution, however it has a much higher CPU utilization at that
>> > > > resolution which reduces its maximum resolution possible on mobile
>> > > > devices
>> > > > (well below what MPEG is capable of on the same CPU).
>>
>> > > >GaryDaniels
>> > > > Windows CE Multimedia and Graphics
>>
>> > > > This posting is provided "AS IS" with no warranties, and confers no
>> > > > rights.
>> > > > You assume all risk for your use.
>>
>> > > > "SkyWaLKer" <shantanu.g... DeleteThis @gmail.com> wrote in message
>> > > >news:1180796687.257341.166210@g37g2000prf.googlegroups.com...
>> > > >> Hi
>> > > >> I'm writing a directshow based solution for capturing window
>> > > >> (target
>> > > >> is WM 5.0). Its in native code.
>> > > >> Now, I've been able to get it all together after reading through
>> > > >> sample code on msdn and bits of info scattered here and there. But
>> > > >> my
>> > > >> problem is:
>> > > >> 1. When I run it on my Pocket PC, the available RAM (Program
>> > > >> Memory)
>> > > >> diminshes rapidly irrespective of the time for which capturing is
>> > > >> done. It drops down to alarmingly low level (to around just 2 MB
>> > > >> free
>> > > >> ram remaining) and then the app conks out. BTW, the output file
>> > > >> size
>> > > >> is always a few KBs, so dont kjnow why so much ram is eaten.
>> > > >> 2. No matter how long I wait between starting and stopping the
>> > > >> control
>> > > >> stream, the recorded video comes out to be juse a couple of
>> > > >> seconds at
>> > > >> max.
>>
>> > > >> Basically what I'm doing in my code for starting stopping capture
>> > > >> is:
>> > > >> ________________CODE________________
>> > > >> hResult=pFilterGraph->QueryInterface(&pMediaControl);
>> > > >> hResult =pMediaControl->Run();
>> > > >> OAFilterState state = State_Stopped;
>> > > >> while(state != State_Running)
>> > > >> pMediaControl->GetState(100, &state);
>>
>> > > >> LONGLONG dwStart = 0, dwEnd = 0;
>> > > >> WORD wStartCookie = 1, wEndCookie = 2;
>> > > >> dwEnd=MAXLONGLONG;
>> > > >> //start capturing
>> > > >> hResult=pCaptureGraphBuilder->ControlStream(
>> > > >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
>> > > >> &dwStart, &dwEnd, 0, 0 );
>> > > >> Sleep(30000);
>> > > >> //Stop capturing
>> > > >> dwStart=0;
>> > > >> IMediaSeeking *pMediaSeeking;
>> > > >> hResult=pFilterGraph->QueryInterface(&pMediaSeeking );
>> > > >> hResult=pMediaSeeking->GetCurrentPosition( &dwEnd );
>> > > >> hResult= pCaptureGraphBuilder->ControlStream(
>> > > >> &PIN_CATEGORY_CAPTURE, &MEDIATYPE_Video, pVideoCaptureFilter,
>> > > >> &dwStart, &dwEnd, wStartCookie, wEndCookie );
>> > > >> long leventCode, param1, param2;
>>
>> > > >> hResult =pFilterGraph->QueryInterface( IID_IMediaEventEx,
>> > > >> (void**)
>> > > >> &pMediaEvent );
>> > > >> hResult = pMediaControl->Stop();
>> > > >> _________________CODE______________________
>>
>> > > >> So, please help me out as to :
>> > > >> 1. How to avoid the memory loss while recording?
>> > > >> 2. How to record for a longer length?
>>
>> > > >> Regards
>> > > >> Shantz
>
>

Hi all,

I am working on developing a custom camera capture application for the HTC device.

I am trying to access the "HTC Source Filter" present already in the device. But I am running into the same problems decribed in this thread. I couldnt use any of the HTC filters.

Has anybody found a way to use those filters. If so can you please help me. I am stuck with this problem for a long time now.

Thanks,
Vidhya

EggHeadCafe - .NET Developer Portal of Choice
http://www.eggheadcafe.com

Vidhya S wrote:
> Hi all,
>
> I am working on developing a custom camera capture application for the HTC device.
>
> I am trying to access the "HTC Source Filter" present already in the device. But I am running into the same problems decribed in this thread. I couldnt use any of the HTC filters.
>
> Has anybody found a way to use those filters. If so can you please help me. I am stuck with this problem for a long time now.
>
> Thanks,
> Vidhya
>
> EggHeadCafe - .NET Developer Portal of Choice
> http://www.eggheadcafe.com

then U have revorked Camera_(API) .. Init, Begin, End, Done, ... and so on ?
from application perspective - can U share more info with us about other
functions eg. - GetProperty ?

Till now nobody has responed in this thread

mak

Hi I am trying to do the following with DirectShow

CameraFilter + DMO WMV9Encoder + CustomRTPFilter

I am having a hard time connecting my pins together. Everything works fine I remove the WMV9 Encoder from my graph.

I read up that a BufferFilter may be required before the encoder? Or that the media type needed to be set for the encoder ...

Does someone have information on to get something like this working?

Thanks,
Kris