home
products
contribute
download
documentation
forum
Home
Forums
New posts
Search forums
What's new
New posts
All posts
Latest activity
Members
Registered members
Current visitors
Donate
Log in
Register
What's new
Search
Search
Search titles only
By:
New posts
Search forums
Search titles only
By:
Menu
Log in
Register
Navigation
Install the app
Install
More options
Contact us
Close Menu
Forums
MediaPortal 1
Development
General Development (no feature request here!)
[Poll] Expose present surface object as in Framegrabber as event?
Contact us
RSS
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Reply to thread
Message
<blockquote data-quote="gemx" data-source="post: 561146" data-attributes="member: 26324"><p>Ok, i think i found the best possible solution to solve this.</p><p></p><p>See the attached patch (first post also updated)</p><p></p><p>It basically does:</p><p></p><p>1) extends VideoSurfaceToRGBSurface in DXUtil.dll to also pass the height and width since resizing is done here via StretchRect</p><p>2) Adds an overload to Framebuffer.GetCurrentImage() to be able to set the size of the bitmap. The overload is for backwards compatibility. So other plugins or routines who use this function don't have to be changed</p><p></p><p>This enables any plugin to use the already available FrameBuffer class and to also specify the dimensions of the target bitmap.</p><p></p><p>Just to make some things clear:</p><p></p><p>1) The frame you get with the FrameGrabber IS NOT a screenshot but only contains the video being played in the resolution this video has, regardless if it's shown in fullscreen or in a small window it has always the dimensions of the source video. Therefore HD material takes more time to copy than SD because the resolution is much higher. To get the whole desktop you have to use GUIGraphicsContext.DX9Device.GetBackBuffer() which always gets the whole screen and is very slow.</p><p></p><p>2) StretchRect is done completely in the GPU mem, therefore it hardly doesn't need CPU time < 1 ms (hardly measurable)</p><p></p><p>3) The only thing that takes CPU time is copying from GPU to CPU via SurfaceLoader.SaveToStream()</p><p></p><p>#3 is therefore the only problem which can be minimized by using this patch.</p><p>I did some tests with the following results (720p video):</p><p></p><p>FrameGrabber.GetCurrentImage(): ~ 110 ms per grab</p><p>FrameGrabber.GetCurrentImage(300x200): ~ 20 ms per grab</p><p></p><p>That is a huge different.</p><p></p><p>Please also note that setting the captureWidth and height in the GetCurrentImage(...) function doesn't interfere with other requests at the same time with different values since the function uses a lock</p><p></p><p>So what do you think about this patch?</p></blockquote><p></p>
[QUOTE="gemx, post: 561146, member: 26324"] Ok, i think i found the best possible solution to solve this. See the attached patch (first post also updated) It basically does: 1) extends VideoSurfaceToRGBSurface in DXUtil.dll to also pass the height and width since resizing is done here via StretchRect 2) Adds an overload to Framebuffer.GetCurrentImage() to be able to set the size of the bitmap. The overload is for backwards compatibility. So other plugins or routines who use this function don't have to be changed This enables any plugin to use the already available FrameBuffer class and to also specify the dimensions of the target bitmap. Just to make some things clear: 1) The frame you get with the FrameGrabber IS NOT a screenshot but only contains the video being played in the resolution this video has, regardless if it's shown in fullscreen or in a small window it has always the dimensions of the source video. Therefore HD material takes more time to copy than SD because the resolution is much higher. To get the whole desktop you have to use GUIGraphicsContext.DX9Device.GetBackBuffer() which always gets the whole screen and is very slow. 2) StretchRect is done completely in the GPU mem, therefore it hardly doesn't need CPU time < 1 ms (hardly measurable) 3) The only thing that takes CPU time is copying from GPU to CPU via SurfaceLoader.SaveToStream() #3 is therefore the only problem which can be minimized by using this patch. I did some tests with the following results (720p video): FrameGrabber.GetCurrentImage(): ~ 110 ms per grab FrameGrabber.GetCurrentImage(300x200): ~ 20 ms per grab That is a huge different. Please also note that setting the captureWidth and height in the GetCurrentImage(...) function doesn't interfere with other requests at the same time with different values since the function uses a lock So what do you think about this patch? [/QUOTE]
Insert quotes…
Verification
Post reply
Forums
MediaPortal 1
Development
General Development (no feature request here!)
[Poll] Expose present surface object as in Framegrabber as event?
Contact us
RSS
Top
Bottom