DirectShow Thread Priority
gman
How can I set the thread priority for a DirectShow Graph? I am using VMR9
and I want the video stream I create to have the highest thready priortiy so
that the last thing to suffer is my video frame rate.
Anyone know how to do this?
Thanks,
gman
Tim Roberts
It already runs at an elevated priority. However, the renderer does not
operate in a vacuum. It doesn't matter how high the renderer's priority is
if the file source cannot feed frames, the compressor cannot decompress
them, or the color space converter cannot process them.
As a general rule, it is counterproductive to mess with the individual
thread priorities. A video graph is a relatively balanced process.
--
- Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc
Iain
I'm not persuaded that it does run at a higher priority. Certainly the
audio renderer does not.
There are two approaches. Quick and dirty simply raises the priority of
your whole app. This is fine if it is interference from 3rd party apps
that is the problem.
The other approach is to enumerate the threads in the process, pause / run
the graph, enumerate the threads again and raise the priority of the new
threads.
Iain
--
Iain Downs (DirectShow MVP)
Software Product Consultant
www.idcl.co.uk
Peter Duniho
news:1gq72hal9yibx.9...@40tude.net...
> I'm not persuaded that it does run at a higher priority. Certainly the
> audio renderer does not.
Even if so, I think Tim's main point still stands. It is hard to know which
threads are the important ones, even if you identify the ones that are new
after you run the graph.
Also, it's unlikely that a performance issue would be related to thread
priority anyway. Thread priority is only one factor with respect to which
thread gets CPU time when. Most threads will wind up yielding long before
their slice is up, usually because they wind up blocked on i/o or waiting
for another thread.
IMHO, the original poster's goal isn't reasonable. Assuming there are no
other CPU-intensive tasks going on during video rendering, the rendering
will take most of the CPU time anyway. That will happen naturally as the
thread (presumably) would be one of the few threads (or the only thread) on
the system actually using 100% of its time slice. If there ARE other
CPU-intensive tasks, then either they are important or they are not. If
they are, then starving them for video isn't reasonable. If they aren't,
then why are they running in the first place?
Messing with thread priority is almost always the wrong strategy. Almost
always, the existing priorities are set that way for a reason.
Just as an example: one video application (if I recall correctly, it's
TMPGEnc) sets its priority to a high setting while encoding, rather than the
default normal setting. The application doesn't get its encoding done any
faster; it just winds up making everything else on the system run like crap.
The CPU time it takes to handle mouse-clicks, or even running a solitaire
card game, is completely inconsequential compared to the CPU time required
by the encoder, and doing stuff like that won't result in any noticeable
difference in performance by the encoder.
If I were trying to run a 3D game, or another encoder, or something like
that while the application was encoding, then sure...the application would
suffer and not encode as quickly. But doing that would be dumb.
I realize the rendering example is a little different. But it's not much
different. The rendering WILL take the necessary CPU time as long as
nothing else needs the CPU that badly. And if there is something else that
needs the CPU that badly, either it's a bad idea to allow that something to
run, or it's a bad idea to allow the rendering to starve that something.
Either way, there's no reason to mess with the thread priority.
Pete
gman
You make some good points. I am going to describe my problem in more detail
and see if maybe you guys have some ideas on what I can do.
I have a list of videos in a CListCtrl that my users can choose from. When
the users clicks on a video in the list the application loads the video by
creating a graph and calling RenderFile. However, if there is a video
already playing and they click on a video in the list, creating the graph
and calling RenderFile interrupts the video playing and makes the video skip
and jump. Is there some way that when I load a video that I can prevent it
from interfering with my video that is playing?
Thanks,
gman
"Peter Duniho" <NpOeS...@NnOwSlPiAnMk.com> wrote in message
news:1154fme...@corp.supernews.com...
Peter Duniho
news:Zfv4e.111451$KI2.6072@clgrps12...
> [...]
> Is there some way that when I load a video that I can prevent it from
> interfering with my video that is playing?
It may be that you are running into contention on the disk, not the CPU. If
so, this is a good example of something changing a thread's priority just
isn't going to fix.
If you have a pre-populated list of videos, can you just create a graph and
call RenderFile for each of them, before you start actually playing any one
video? For that matter, do you really need to create a graph and call
RenderFile just because the user clicked on a video in your UI? To what end
are you doing those two things?
Pete
gman
Ya I don't really need to create a graph and call render file for when a
user clicks on a video in the list.
However when my users want to skip to the next track in the playlist, the
software has to create a graph and call renderfile to start playing the next
video in the playlist to preform the mix and when it does this the video
that is currently playing stutters. That is the real problem.
I need to find a way that I can create a new graph, and call render file
without it interfering with my video that is currently playing.
Any ideas?
Thanks,
gman
"Peter Duniho" <NpOeS...@NnOwSlPiAnMk.com> wrote in message
news:1155m6u...@corp.supernews.com...
Peter Duniho
> [...]
> I need to find a way that I can create a new graph, and call render file
> without it interfering with my video that is currently playing.
I already asked: is there some reason you can't create the necessary graph
prior to starting any video rendering?
Also, what "mix" are you trying to accomplish? Can you use DES to handle
that work? What actually is supposed to happen when the user jumps to the
next track? Can't you just stop the current playback before creating and
running the new graph? (That's assuming that, for some reason, you can't
pre-create the necessary graphs in the first place).
If you're going to halt the currently running video, I just can't see why
you would invest a lot of effort in trying to get it to continue to run
smoothly.
Pete
gman
I can create the graph the graph prior to starting the video rendering, but
in order to create the graph I have to call renderfile and when I do that we
get the stuttering happening on the video that is currently playing.
The reason I cant just stop playback of the video already playing when I
skip to the next track is because it is a "video mixer" which shows the
video that is playing sliding out, while the video they are skipping into is
sliding in. Therefor both videos have to play simultaneously for a breif
moment until the "mix" is complete, which could last anywhere from 1 second
to 30 seconds.
I only have two options. Create the graph when they press the skip button,
or create the graph when they add the track to the playlist and either way,
as soon I as try to create the graph (calling RenderFile) I get the
stuttering happening on the video that is playing?
Any ideas?
Thanks
gman
"Peter Duniho" <NpOeS...@NnOwSlPiAnMk.com> wrote in message
news:1155s7n...@corp.supernews.com...
Peter Duniho
>
> I can create the graph the graph prior to starting the video rendering,
> but in order to create the graph I have to call renderfile and when I do
> that we get the stuttering happening on the video that is currently
> playing.
I'm obviously not explaining myself very well.
> The reason I cant just stop playback of the video already playing when I
> skip to the next track is because it is a "video mixer" which shows the
> video that is playing sliding out, while the video they are skipping into
> is sliding in. Therefor both videos have to play simultaneously for a
> breif moment until the "mix" is complete, which could last anywhere from 1
> second to 30 seconds.
I've never used DES, but this sounds like a job for it. It already
understands the concept of having multiple video streams, and can even
handle transitions like what you're talking about. If I recall, it can
handle live rendering. I might be wrong. :)
> I only have two options. Create the graph when they press the skip button,
> or create the graph when they add the track to the playlist and either
> way, as soon I as try to create the graph (calling RenderFile) I get the
> stuttering happening on the video that is playing?
Well, the latter is what I was trying to suggest. I didn't realize that you
want your users to be able to add videos to the playlist while a video is
already playing. You never said anything about doing that.
I'm sure you have more than two options. However, I'm also sure that this
problem MAY be unsolveable, depending on why your rendering gets interrupted
when the user identifies a new video to be added to the playlist. At least,
not without possibly throwing more hardware at it (to solve whatever
contention issue exists).
Your first step is to figure out what the real bottleneck is. If you have a
reasonably fast computer, and all you're doing is rendering (not adding
special effects or anything like that), I really doubt you're dealing with a
CPU problem. I think disk contention is the most likely issue, or perhaps
some data bus problem (PCI, memory, for example). But whatever the problem
is, until you actually know what the problem is, it doesn't make sense to
make up solutions for it.
Pete
Iain
Sorry, guys, I've been away for a while.
The priority changing in this context is perfecttly reasonable. It's an
approach I've used (as have others) for low latency audio graphs which
otherwise stutter.
DES is probably not a useful approach as it is not intended to work in real
time scenarios.
An alternative is to look at a multi-graph approach based around Geraint's
GMFBridge sample (www.gdcl.co.uk), though that would likely suffer from the
same issues when a new track was initialised.
Try the priority up - it's easy to do. And whilst I agree that you
shouldn't mess with priorities will-he-nill-he, they were made user
accessible so you could change them if you need to