FFdshow image post processing so fast?

[lol_123]

Does anyone have idea why ffdshow's post-processing is so fast? i enabled several post processing filters (sharpness, resize, color), ffdshow still can playback 1280x720 content very smoothly, no frames drop. it seemed to me that
each of those post porcessing filters can run at least over
100 FPS @ 1280x720. but i dont think it is possible.

Anyone have ideas about it?

thanks in advance. L

[LoRd_MuldeR]

it seemed to me that
each of those post porcessing filters can run at least over
100 FPS @ 1280x720.
As longs as each filter in the chain can run at least at the framerate of your video, that should be enough for smooth playback...

but i dont think it is possible.
Why do you think so ???


BTW: Features like Queuing might help smooth playback!
When there is "free" CPU time, frames are decoded/filtered ahead and buffered until it's time to display them.
In times when too few CPU time is available, frames from the buffer can be displayed instead of skipping...

[Dark Shikari]

Its because most FFDShow filters are very heavily assembly optimized and are relatively simple (to ensure high speed).

[LoRd_MuldeR]

AFAIK various filters in ffdshow.ax are not assembler optimized.
Therefore the builds made with the Intel Compiler (ICL9/ICL10) should be "faster" in case you use a lot of filters.
For pure decoding performance the difference will be negligible, since the decoders are not in ffdshow.ax.

[lol_123]

[QUOTE=LoRd_MuldeR;1074482]As longs as each filter in the chain can run at least at the framerate of your video, that should be enough for smooth playback...

Thank you L_M, could you specify a little bit about the above statement?
for my understanding, those filters work in serial,
for example, filter A needs 30ms , filter B needs 30 ms, if you put them together, it requires 60ms, that means the frame rate drops to 15 frame per second.

Thanks L.

[LoRd_MuldeR]

Well, if you put 10 filters in a chain and watch a video at 25 fps, then each of the filters will still process only 25 frames per second.
Of course the required CPU power will increase with every filter you add, but as Dark Shikari said: The filters are highly optimized.
And as mentioned before: Frame drops caused by CPU usage peeks can be avoided with the Queuing feature.
Last but not least we have a lot of CPU today! So there should be enough CPU time left that can be wasted for filters.
The thing that really brings your CPU to it's limits is H.264 decoding of HD stuff ;)

[lol_123]

Thank for your quick response.
Actually, now i am developing the post processing filters,
like color, sharpness, de-blocking etc. All codes have optimaized by using SSE2 instructions.
What i can achieve is to make each of them run at 50 fps.
I think the bottle neck is at memory access ( store data) rather than computations. Also i looked into ffdshow codes,
i dont think their codes are 10 times faster than mine.
But the reality is they can make it run time, i can not.
I am not familiar with "Queuing", could you speicfy a little more?

Thanks L

[LoRd_MuldeR]

I'm not an expert, but from what I have understood so far it works like this:

Without a queue you simply decode/filter one frame, then display it, then decode/filter the next frame, display it and so on... When you have some CPU time left, you have to wait for the next frame. So the "free" CPU time will be unused/wasted.

Now the queue adds some kind of buffer in-between: A frame is decoded/filtered and then sent to the buffer, then the next frame is decoded/filtered and sent to the buffer. And so on... This way you don't need to wait until a frame has been displayed before you can decode/filter the next one. So you can decode/filter the frames even faster than they are displayed. The "free" CPU time can be used to decode/filter ahead. Each frame will be kept (queued) inside the buffer until it's time to display it. In case the CPU usage temporarily raises and you can't decode/filter the frames with the required speed any more, you can still display the frames that are queued in the buffer. Hence frame drops can be avoided, as long as the buffer doesn't underrun. Once the CPU usage peak is over, you start filling the buffer again...


// EDIT

Some more info:
http://ffdshow-tryout.sourceforge.net/html/en/queue.htm ;)

[lol_123]

thank you LM! i got your point, i will modify my codes to see what i can do with "Q". :-)