ffdshow Modification Help

[daveoggy]

I've decided I like to make a slight modification to ffdshow. I pulled the source code from Subversion and opened the project in VS 2005 but then drew a blank from the sheer size of the thing.

I would like to add the option to display the frame number as timecode (i.e. HH:MM:SS:FF) to the OSD options.. My plan is to take the 'Current Frame' code and either copy it to create a new 'Display Timecode' option, or if that proves too difficult, modify the code so that 'Current Frame' option outputs a timecode string. After that I would want to add an option to offset the timecode from within ffdshow.

I have a class that takes an integer as the input and outputs the timecode as a string; I'm just searching for the right place to incorporate it. Can anyone point me towards the relevant section of the code?

Finally, how does my modification sit within the GPL, is there anything I have to do once I’ve made the modifications? I’d hate to upset anyone.

[foxyshadis]

All of this is in TimgFilterOSD.cpp, not one line of which is commented. Have fun. =D What you'll probably want to do is just change the output for IDFF_OSDtype_frameTimestamps into a formatted time (it's currently numeric). If you want to formally add a new option, you'll also need to look into some of the other OSD-related source files, they all have OSD in the name.

If you distribute a binary and anyone asks for the code, you have to provide a diff patch (or modified files or full source tree or whatever you feel like).

There's also a ton of patches on videomixer9's page that you'll want to apply if you're looking for the most current bugfixes and enhancements, the svn hasn't been updated since spring.

[daveoggy]

Thanks for the quick response foxy, it would have taken me forever to find that.

I have made some preliminary changes and hopefully these will give me what I want.

I am running into one big problem at the moment though. I can build ffdshow with no errors (but a fair few warnings :scared: ) and the filter automatically registers itself. Only problem is I can't add it to GraphEdit I just get the following warning:

No combination of intermediate filters could be found to make the connection (Return Code: 80040217)

This isn't when I try to render a pin, its actually when I tried to add the filter from the DirectShow filters list by double-clicking!

Any ideas what I'm doing wrong? Knowing me it will probably be something very n00b-esque...

*************************************************************************

Hmmmmmm, maybe I should try following the instructions before wasting anyones time. Like these ones here:
http://ffdshow.sourceforge.net/tikiwiki/tiki-index.php?page=From+sources

[daveoggy]

Regarding this line in the instructions:

"Intel C++ Compiler is unable to compile TomsMoComp_ff?. You have to use Microsoft C Compiler."

How do I specify what installer I want Visual Studio 2003 to use?

[videomixer9]

That info is wrong now. To use Intel Compiler you need to convert projects to Intel Projects via IDE integration.

[daveoggy]

Is it possible to use the MS C++ compiler to build all the componants? I don't have the Intel C++ compiler, I hadn't realised it was a seperate program!

[clsid]

The MS compiler should be able to build all components.

For libavcodec.dll and mplayer.dll it is recommended to use GCC to compile them, because for those libraries GCC will produce better performing (speedwise) binaries than the MS compiler.

[daveoggy]

I've now managed to get a working version using just the MS compiler.:thanks:

I will now try to compile the libavcodec.dll and mplayer.dll using GCC as suggested and see what happens.

If compatibility and stability are more important than speed for my purposes which compiler should I use?

[clsid]

The MS compiler is the most stable for most components. But you can safely use GCC for those other two libs. I recommend GCC 3.4.5 or 4.0.3

[Orion|69]

The MS compiler is the most stable for most components. But you can safely use GCC for those other two libs. I recommend GCC 3.4.5 or 4.0.3

I'd personally step it up on both branches and go for the latest versions.. 3.4.6 and 4.1.1 - both have been around since march without any major problems, so altho previous versions mentioned are safe and stable - these ones are as well imo.
All ffdshow components compile without too much trouble with these versions as well under windows.

As added "value" worth mentioning, but also kinda off topic -> If you are going to dabble around in existing opensource video-related sources with windows as platform, and you don't really do any other significant coding besides that for the windows platform in particular : go gcc. It's not only the compiler giving you -most of the times- the best performance, but 98% of the available projects were also initially created using gcc as main compiler, so you can rest assured that there will always be a flawless working make-file accompanying the project to build it.
Even if you are starting to learn C(++), this would be the compiler to beat, since
a) there is no other POPULAR compiler following the language rules more strict as gcc for as well ansi-c as c++
b) it's gpl'ed opensource so it doesn't require any initial cost to use it and still has all the potential you want from it (instead of the stripped microsoft bloated compilers e.g.)
c) it makes sure that, the moment you master to program a decent tool in ansi-c or c++ using gcc, it's really easy to port it to another OS (besides if you rely on the windows api too much to start with)
d) there's no better stepping stone to any other company's compiler the moment you chose for a more "enhanced" (read lazier and easier) IDE. Knowing gcc gives you the unlimited power to go for any platform, any compiler.

Conclusion : yes, it might be harder to start dabbling in C or C++ using gcc, but believe me: that's what you actually want - the basis of using any programming language and get skilled doing so, is actually knowing and comprehending what you are doing to begin with - relying from the start on a fancy IDE is the reason why the skilled programmer is a dying breed and shitty, buggy, bloated software seems to be booming business.

-end of rant- :)

[foxyshadis]

4.1 and 4.2 cause bugs here and there with heavy optimization. videomixer9 could probably give you the gory details, as he tries every combination looking for performance.

[Orion|69]

4.1 and 4.2 cause bugs here and there with heavy optimization. videomixer9 could probably give you the gory details, as he tries every combination looking for performance.

e) be prepared to be corrected from time to time and learn from it :D

In my defence: I never encountered bugs or weird behaviour myself sofar using the 4.1.1-stable, so I admit I just assumed it to be ok. However, a quick google-query turned up quite some hits regarding possible bugs, which basically proves me wrong, and therefor the the previously suggested versions of gcc, would probably be the safest choice. My apologies :)

I'm still 100% backing the rest of the post I made altho thats also the off-topic part of the post. Until proven wrong again ofcourse hehe :)

[daveoggy]

Thank you for your thoughts on the whys and wherefores of using GCC. I will certainly try to make the switch in the future. At the moment I'm wary of taking on more than I can chew and because I now have a way to compile and test, so I will stick with this for the time being. (The first time it compiled correctly I ran round the room like an idiot btw:p)

I'm also sorry because I have a new question. Foxy was dead right about the location of OSD code within ffdshow, but I didn't find exactly what I expected there. Let me explain: I grepped the whole svn folder for the string "Current frame:". This string showed up in various guises but one in particular caught my eye in TimgFilterOSD.cpp:

sprintf(sub.text[1],"Current frame: %i",deci->getParam2(IDFF_currentFrame));


This code makes a lot of sense to me, but the code is within a TimgFilterOSD.cpp file not associated with the ~\trunk\ffdshow version that I'm compiling. Its actually from an older version in the ~\ffdshow\tags\MY_IDCT_SELECT portion of the svn.

Seeing as the version I build has the Current Frame option and displays "Current frame: X" when enabled, I can't help but feel I'm missing something vital. I know I could probably still make my modifications without understanding this but I'd prefer not to.

[foxyshadis]

Check out Tinfo.cpp, where a lot of things are now defined. (Trickily, it's defined as "Current frame" with the colon added at runtime. :p) The default case in the switch leads to a couple of switches in Tinfo.cpp. (Notably GetVal and GetVal0.)

I usually find my way around by just hitting "Go to Definition" until it takes me somewhere useful.