Infognition forum
August 01, 2010, 06:55:22 AM *
Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length
News: Last GraphEditPlus version: 1.4.0   Last Video Enhancer version: 1.9.3
 
   Home   Help Search Login Register  
Pages: [1]
  Print  
Author Topic: Frame rates inside of Graph Edit Plus graphs?  (Read 930 times)
JamieFaye
Newbie
*

Karma: +0/-0
Posts: 6


View Profile
« on: August 11, 2009, 11:00:44 PM »

Having hooked together many a filtergraph in my advancing years, I notice that the frame rates get slower as more graphs are run at once(In Graphedit, GraphEditPlus, and the other FG editors. . Is this something that GraphEditPlus manages, or are the policies related to bandwidth apportionment determined by the system?

It would be neat to be able to control this more closely. One project I am about to undertake involves frame rate conversion. (I know about IStreamConfig on capture pins, what I am after is to see the frame rate in the renderer quality prop-page to run at the speed I want it to).
« Last Edit: August 11, 2009, 11:03:32 PM by JamieFaye » Logged
Dee Mon
Administrator
Sr. Member
*****

Karma: +7/-0
Posts: 271



View Profile WWW
« Reply #1 on: August 12, 2009, 07:24:43 AM »

No, it's not controlled by GEP and other editors.
Sample times are set by parsers and capture devices independently of other graph members and other graphs, and if you play something then renderer uses those values to wait for a proper moment to show the sample. And if you don't render and just write to disk then nobody waits and data flows as fast as it can. When several graphs run at once their filters load CPU and may not work as fast as when only one graph is running. But probably I'm telling banalities you already know perfectly and you meant something else. In that case please explain what you mean.

In later versions of GEP where some animations were added, I recently noticed that it sometimes takes too much CPU just to display graph state. This will be fixed in next release.
Logged
JamieFaye
Newbie
*

Karma: +0/-0
Posts: 6


View Profile
« Reply #2 on: August 14, 2009, 06:51:55 AM »

I wrote that the other day when I was struggling to get a Filtergraph to go at 25fps and eventually did find the hard-wired frame rate that was buried in unexpected place.

Part of the frustration about DirectShow has to do with the opaque distribution of policy decisions amongst the filters and managers. You set a format and a timing and at some point it magically changes with little clue as to what you are doing wrong. GraphEditPlus does quite a bit to make this easier.

The next improvement I am craving is a facility for showing the time utilization of a GANT chart by filter component. A display showing for the last second or 4 of each invocation as a rectangle with filter# on the Y axis and Time on the X. This could show you where the big pigs are, if you are dropping frames and how often, who causes the jitter and judder, all at a glance with zero pre-configuration.

Implementation would of course, be challenging. Mostly simple API interception via hooks and v-table patching, and slogging past many a BSOD.
 I would buy an upgrade to get this -- Jamie F
Logged
Dee Mon
Administrator
Sr. Member
*****

Karma: +7/-0
Posts: 271



View Profile WWW
« Reply #3 on: August 14, 2009, 02:23:15 PM »

I understand your wish for such a profiling tool. However me and my employees don't have enough expertise to make it. Probably you can get some insights using Process Explorer from SysInternals. I think it could show what modules use what part of CPU.
Logged
JamieFaye
Newbie
*

Karma: +0/-0
Posts: 6


View Profile
« Reply #4 on: August 18, 2009, 05:24:36 AM »

There is a very good "API Hook Construction Set" out now, called EasyHook - It may turn this from a month-long project into a weekend project.

The curse (and blessing) of this project is the DirectShow Base Classes. Usually static linked, but stable for several years with minor changes.

The other angle is ETW - which I actually built-out a framework to test DirectShow with - the conclusion was that they had a few event logging taps here and there, but not nearly as many as you would want, nor in the right place.

Heck - my next project involves lots of filtergraphs running at once - and I have learned over the years that the only way to do a real-time multimedia project is to create a dynamic viusualization of execution at the same time you code the fundamentals Otherwise you spend all your time trying to explain how to do surgery to a blind man using a walkie talkie..
Logged
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.5 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!