Re: Does Video render in CE 6.0 use the Overlay surfaces (UYVY)?

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance



I am not sure what's going on here. 0x80040209 is VFW_E_NOT_CONNECTED, but I
am not sure what would cause that to be returned. I've passed the question
on to others who should know more, but I don't know when I'll hear back.

One other suggestion: Verify that the DDOVERLAYCAPS member is correctly
filled out (in halcaps.cpp, I believe), especially that DDOVERLAYCAPS_FLIP
is set (you can find the rest of the caps in ddraw.h).

--
Louis Clausen
Software Design Engineer in Test
Windows Devices Core Multimedia

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

"Danny" <Danny@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:5E60CBE8-C5CB-4D17-BA67-E5BF2EA3CB33@xxxxxxxxxxxxxxxx
Louis,

We are observing an almost identical problem in our efforts to port our CE
5.0 Overlay support to CE 6.0.

I am concerned about your statements about video memory differences
between
5.0 and 6.0. But it seems to me that these differences wouldn't stop the
application from running and calling UpdateOverlay. We are not seeing any
calls to Flip or UpdateOverlay, since the ceplayer application reverts to
GDI
somewhere behind the scenes before getting to this point. Would the video
memory differences possibly affect how ceplayer runs and whether it would
call Flip and UpdateOverlay? And, could you be more specific about where
in
the sample drivers this change can be seen in the code? I have compared
sample drivers between 5.0 and 6.0 and I have not seen any major
differences
in the video memory handling.

Not having either visibility into the private source or informative debug
messages is a severe hindrance to the debugging effort for this issue.
Could
you provide any indication as to what would precede the "!!! ERROR:
InputNewSegment(): DeliverNewSegment() returned 0x80040209" error
statement
in quartz.dll?

Thanks,
Danny

"BSP Developer" wrote:

Thankyou so much for the response Louis Clausen. Really appreciate any
help
extended.

I had taken a look at that post and confirmed that the mosquito sample
does
execute correctly in my setup. Although I had made minor changes to
eliminate
the color-keying in YUV Surface (my hardware does not support this
feature
for YUV Surfaces).

In this case, I have the Video render filter successfully creating the
UYVY
surface (using the DirectDraw AllocSurface) in video memory. However, it
refuses to use this surface for rendering the video. I am not able to get
the
reason for the same.

Any suggestion in getting past this hurdle would be greatly appreciated.

Thanking you in advance.
BD.

"Louis Clausen [MS]" wrote:

I am not sure if this is a similar issue, but here is a reply I gave
for a
different post:

It looks like there could be a problem with how your driver performs
flipping of overlay surfaces.Does the mosquito application display more
than
one frame as the overlay is moved?

If your display driver doesn't have the DDHAL)SURFCB32_FLIP flag set in
the
DDSurfaceCallbacks you will get the error you've listed. You'll also
get
that error if the HalFlip method in your driver does not return
DDHAL_DRIVER_HANDLED.

One other thing to be aware of: there have been changes to the way
video
memory is exposed to an application (due to changes in the kernel
virtual
memory architecture). You should be able to take a look at the changes
between the sample Mobile 5.0 drivers and the CE 6.0 driver to get a
better
idea. The main change is that unless all allocations are from the main
video
memory frame buffer the driver needs to copy the memory of new surfaces
into
the application's virtual memory space.


--
Louis Clausen
Software Design Engineer in Test
Windows Devices Core Multimedia

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

"BSP Developer" <BSPDeveloper@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:B8421F7D-BE47-4235-931B-20BBF48C8D23@xxxxxxxxxxxxxxxx



.



Relevant Pages

  • Re: Does Video render in CE 6.0 use the Overlay surfaces (UYVY)?
    ... Overlay support to CE 6.0. ... I am concerned about your statements about video memory differences between ... If your display driver doesn't have the DDHAL)SURFCB32_FLIP flag set in the ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Newbie memory management question
    ... True OpenGL is not GDI however "all Video ... The GDI uses the video driver to construct a drawing surface. ... How that's memory is arranged the GDI has no influence to, ...
    (comp.graphics.api.opengl)
  • Re: Does the default video rendor on CE 6 support Overlay surface?
    ... It seems ceplayer doesn't call any of ddraw function, ... If your display driver doesn't have the DDHAL)SURFCB32_FLIP flag set in the ... One other thing to be aware of: there have been changes to the way video ... memory architecture). ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Urgent! Need help. Cant boot into Windows!
    ... Francis, do you think the memory on his video card could be going out. ... > download the latest video driver from ATI, put it in a safe place for now ...
    (microsoft.public.windowsxp.general)
  • [PATCH] Integrating SEP Driver with RAR Driver
    ... RAR stands for Restricted Access Region; this is memory ... This is upstream revision 4 of the SEP driver. ... +This functions maps and allocates the shared area on the external ...
    (Linux-Kernel)