FFDShow versioning and governance

[shae]

1. Why are there builds for specific instruction sets (MMX/SSE/2/3/4)? Ideally you'd have handmade assembly code for tight loops for each of the variants, then use the right functions on the fly. Is it because ffdshow is composed of various separate projects which do not necessarily do the above?

If that is so, why not compile the needed modules with different settings, include them all, then again, branch according to a runtime detection?

2. What is the reason for the multiple builds (How many are there, 5-10?) Assuming there's no handmade optimization, wouldn't it be best to find out the best compiler for each part and assemble a single distribution? That would also mean only a single version is tested, so the efforts are concentrated.

3. Why aren't there comprehensible version numbers that can suggest more readily the extent of the changes between versions? The current mix of numbers and dates is difficult to follow, and there's no telling what is considered a good intermediate version to use rather than an experimental one.

As it is, deciding to upgrade ffdshow is a big undertaking :) which involves trying multiple versions and multiple builds, and with each, testing for multiple aspects (and even then one may encounter something that doesn't work after a while). And quite possibly, this testing is only good for a single instruction set.

[clsid]

1) ffdshow uses a lot of handmade assembly code.
2) There are several generic builds.
3) Compiling for specific instruction sets/cpus is pretty much pointless in terms of performance.
4) The InnoSetup installers are capable of runtime detection.
5) ffdshow does not have version numbers. It has revisions. Each time a change is commited to the source code repository, the revision number is incremented.

[shae]

1) ffdshow uses a lot of handmade assembly code.
2) There are several generic builds.
3) Compiling for specific instruction sets/cpus is pretty much pointless in terms of performance.
All this suggests there's no need for specific builds, yet there are MMX (I assume your generic ones are that), SSE and SSE2 ones, etc. If it's not needed, why is it done?

4) The InnoSetup installers are capable of runtime detection.I meant real runtime detection, not an installer that acts differently based on CPU (which would be a confusion potential).

5) ffdshow does not have version numbers. It has revisions. Each time a change is commited to the source code repository, the revision number is incremented.
Indeed, and these are completely cryptic without further research. Good for development, but not for end users. That could be accomplished by having a version number in addition to the build number.

[foxyshadis]

ffdshow is not in a state that could be considered "stable", bugs crop up and things change every week. When we reach a point where we're comfortable with changes done, we'll release an actual version; right now, the higher the rev the newer the stuff and that's the best we can say about it.

The only reason for the alternate builds is because while lavc and scaler are highly hand-optimized with full runtime detection, ffdshow (consisting of the directx code and all those filters you can turn on and off) is not. Unless you use those filters, especially the heavier ones, it's useless. Even then they're still much less useful than real optimization.

[shae]

Well, people have been using it for a few years now (3-4?), so it must have reached at least some stability. The versions I've been using seemed stable, at least after I've filtered numerous problematic versions/builds.

What should be defined as stable is the less experimental and more tested ones. If there are areas that require more attention, shouldn't they be solidified before moving on? Will the coder even remember what was going on after a few months, without having to relearn it?

Unlike (say) LAME, ffdshow doesn't have definite end goals -- new codecs are constantly being added, among other things -- so this ever evolving nature means there will never be a point where all the features are present and all that is left is to do is refine.

And why the conflict in opinions? clsid thinks specific instruction set complies do not contribute to performance.

[shae]

... the higher the rev the newer the stuff and that's the best we can say about it.
But if all you've been doing for a few revisions is tweak and fix, you know it's more likely to do fine than a revision that involves a complete rewrite of a big chunk, and THESE are the revisions that should be dubbed experimental or alpha.

[clsid]

I meant real runtime detection, not an installer that acts differently based on CPU (which would be a confusion potential).The assembly code also has runtime detection.
And why the conflict in opinions? clsid thinks specific instruction set complies do not contribute to performance.Several tests support this fact. However, there are still many people who want SSE2 builds because they think those are faster.
Well, people have been using it for a few years now (3-4?), so it must have reached at least some stability. The versions I've been using seemed stable, at least after I've filtered numerous problematic versions/builds.All the commonly used functionality of ffdshow is pretty much stable. But putting a version number on a product like ffdshow is pretty difficult. What should it be now? 1.0 or 2.0 or even higher? Alpha or beta or final? In many commercial products version numbers are more influenced by marketing than by actual (changes in) functionality. In my opinion a version number doesn't say much about the quality of a software product.

[LoRd_MuldeR]

All the commonly used functionality of ffdshow is pretty much stable. But putting a version number on a product like ffdshow is pretty difficult. What should it be now? 1.0 or 2.0 or even higher? Alpha or beta or final? In many commercial products version numbers are more influenced by marketing than by actual (changes in) functionality. In my opinion a version number doesn't say much about the quality of a software product.

I agree 100% and I know it's hard for a developer to make one "final build" with a certain Version number. But most people just don't think this way. I talk about people that just want to play their videos and don't care about software development. All those revision numbers and the variuous different builds you offer might be very confusing for "normal" users. Imagine you don't know what a "revision" or a "build" is and all you want is just downloading the program ^^ So IMO it would be a shame, if this is what prevents people from using ffdshow-tryouts. Wouldn't surprise me, if most people still use milan's latest "official build". So maybe it would be an advantage to tidy up the ffdshow projects page. Maybe people would feel more comfortable with a name like "ffdshow-Tryout v1.00 Beta-X" and maybe "... Final" one day.

[foxyshadis]

Several tests support this fact. However, there are still many people who want SSE2 builds because they think those are faster.
Decoding and resizing do not benefit, but deinterlacing and many ffdshow filters (blur, sharpen, levels, properties, and the goofier less common filters) can show a noticeable boost, along with the non-lavc decoders (like libfaad and libdts). Like I said, it only means anything if you use ffdshow filters, instead of straight decoding.

Maybe you're right about versioning. As long as it doesn't follow the biannual release cycle of the original, people shouldn't stick with outdated releases too long. Hmm, now that there's a site for releases, perhaps automated once-a-month update checking could be included at some point.

[Egh]

My opinion on ffdshow development is that:

1. for casual users, it would be probably good to release a stable build. Note that last build which was considered stable was released by Milan years ago :P

2. For that matter though, one would need branching. I.E. some of the SVN revision version should be considered "milestone". That revision code should be built, with various compilers, then all those builds should be properly tested and most stable build found.

3. Then those tested builds should be released as public 1.0beta version.

4. Bugs found in this version during testing should be fixed, but no new features added in this branch. ffdshow now decodes nearly all video and audio formats used in video files anyway. I don't think it's likely any new features would be added in the nearest future.

5. Then we would have 1.0 stable version :)

The question is whenever anybody is up to actually doing this proper software development cycle...

[haruhiko_yamagata]

My opinion on ffdshow development is that:

1. for casual users, it would be probably good to release a stable build. Note that last build which was considered stable was released by Milan years ago :P

2. For that matter though, one would need branching. I.E. some of the SVN revision version should be considered "milestone". That revision code should be built, with various compilers, then all those builds should be properly tested and most stable build found.

3. Then those tested builds should be released as public 1.0beta version.

4. Bugs found in this version during testing should be fixed, but no new features added in this branch. ffdshow now decodes nearly all video and audio formats used in video files anyway. I don't think it's likely any new features would be added in the nearest future.

5. Then we would have 1.0 stable version :)

The question is whenever anybody is up to actually doing this proper software development cycle...
Agreed. I can't say current ffdshow is more stable than milan's 20051115, but not too far. With a few more fixes, we'll reach milestone(branch base) version.

[clsid]

A feature freeze is a good idea. Imho there are already too many formats in ffdshow that are incomplete. First make it stable and then add new features one at a time.

How about this version numbering scheme:
stable: 1.0.0.revision beta
dev: 1.0.0.revision alpha

A list of known/reported problems:
* VC-1 does not work
* VMnc does not work
* VP5 does not work
* VP62 does not work
* The "perspective correction" filter makes ffdshow crash when interpolation-mode is set to "cubic". Happens only if horizontal video size is 768 or greater.
* SVQ3 crashes (splitter related?)
* kernel deinterlacer memory leak on NTSC Mpeg2 (720x480i) video (uncomfirmed)
* Output queue enabled + BSplayer = crash
* Output queue enabled + VMR9 renderless + RGB32 + specific video card + pause = blackout problem
* FFdshow is crashing when using subtitles stereoscopic

I probably missed a few.

[Egh]

I agree that a feature freeze is a good idea.

Btw, why beta for stable build?
I suggest
stable: 1.0.0.revision
dev: 1.0.0.revision alpha


Feature freeze should be only on 1.0.0.x versions. I'd suggest to name dev (alpha) versions as before, simply by svn revision. I think only stable versions should have version number. Of course, revision number will be different for those two.

If you have access to original ffdshow sf project page, then I'd recommend to do 1.0.0.x stable version there, and leave tryouts for developers and alpha builds. Some recently added and considered not reliable features can be removed for 1.0.0 (most die hard fans would use dev builds anyway :P)

[LoRd_MuldeR]

Can anybody provide a list of key-features added in ffdshow-tryouts, to compare with "official" branch?

:thanks:

[shae]

To summarize, as I understand it, base functionality (video decoding/encoding and some audio) is hand optimized and not affected by compiler specific targets, while some filters and some secondary libraries are affected.

What parts of ffdshow are considered "3rd party libraries"? I.e., which parts are the jurisdiction of the ffdshow dev team, and which aren't?

I assume the different compilers used are for their different generation of optimized code. Is the current consensus that some compilers create output that is faster for certain processors?

And about stability, besides experimental gccs, how can ICL or VC be unstable?

BTW: Why ffdshow-tryout and not just continue in the original ffdshow sf project?

...once-a-month update checking could be included...
You mean an online check for updates?

Versioning
I'd suggest to name dev (alpha) versions as before, simply by svn revision.
I think it'd be better if the dev versions could be easily related to the stable ones.

For version numbering I suggest major.feature.minor.rev.

major = Fundamental changes. E.g., changing from the current monolithic structure to plugin style, or reworking of a sizeable part of the code.

feature = Noticeable feature additions. E.g., addition of VC1 decoder, restructued GUI, 64-bit support.

minor = Minor features, or bugfixes. E.g., Addition of SSE2 optimization for DTS that gains 5%.

rev = Incremented from 0 (or 1) between stable versions.

Dev versions should be dubbed ALPHA. When there's a version that's destined to become stable, rename it BETA and keep that designation for the possible series of bugfix versions as people test. When all's good, dub it FINAL.

1.3.14.100 ALPHA -> 1.3.14.101 BETA, 102 BETA, 103 BETA -> 1.3.14.103 FINAL (or simply, 1.3.14).

While a version is transitioning from alpha to beta to final, the concurrent experimental dev versions should increment once the version (non-revision part), so while 1.3.14 is going thru the testing phases to FINAL, the concurrent alphas should be 1.3.15.x (or 1.4.0).

[Episode]

If this really is becoming a complete new fork of the original branch, you should start thinking about some other name than ffdshow-tryout, as it is really confusing for the casual users. They don't know the differences between this and the original ffdshow and label it as unstable and ignore it even if the code itself is pretty stable. A naming scheme that shae suggested sounds pretty good too and would be much more logical than just plain revision and/or build-date number.

[bond]

split

[QQ]

did this movement die? :)

[foxyshadis]

There is a stable beta 1 out at the moment, that doesn't include a few new unstable patches put in after it was made. So no, the movement hasn't died, but no one felt like discussing it, I suppose.

[fastplayer]

Rather than wasting time with these IMHO useless versioning peculiarities (just adds complexity where it's absolutely not needed), the devs should agree upon one build script instead of having 3 different builds for one and the same code. I got asked 3x in the past 10 days by friends (to whom I recommended the tryouts) which one of the builds to take. Funny thing, nobody dared trying the stable build, they were just looking at the rev numbers and went with the higher one...

[netwolf]

Hmm, I agree with you that 3 (or more) different build are a bit confusing for users who don't dare to follow the major thread about ffdshow here, are who don't know what the actual differences are etc. etc.
On the other hand, there are (AFAIK) still differences in the compilers or compiling options which are used by the various builders, and some people still prefer compiler X over Y, so why not give them what they want, after all it doesn't hurt :)

WRT versioning: first I also thought that this is not really important, but then after the latest ZoomPlayer release (5.00) I discovered a pretty nice tool called Install Center which is now bundled with ZP.
( http://forum.inmatrix.com/index.php?showtopic=5298&hl=install+center )

What it does is looking for missing (important) or old codecs/splitters you have on your system, and if it founds some, it provides an easy way to install/update/configure them.

So basically it's a very good tool IMO, espacially for not so experienced users, and also a good opportunity to spread ffdshow among users who didn't know it before.

To finally come to what I actually wanted to say: as there is no real versioning in ffdshow now, this tool can't really work as desired.
E.g. it tells me that there is a newer version of ffdshow than the one I use, which is wrong as I use the latest nightly build, but apparently the version number is lower...

So, to make a long story short, IMO proper versioning is a good thing and makes it much easier for external tools to cooperate with ffdshow.

[clsid]

ffdshow stores the revision number in the registry. External tools should use that. And as far as I know the ZP devs are already using that info, or are planning to use it.

[netwolf]

Ok, thank you, I see.

Hmm, so in this case I guess either the version numbers are not strictly incrementing (or haven't been in the past), or somthing is wrong with reading them from the registry (or elsewhere).
Are the revision numbers consistent throughout all the various builds?

[clsid]

Revisions are consistent.

The version number of ffdshow.ax does auto increment every time it is build, however the number differs between builders, so it is pretty much meaningless.

[foxyshadis]

It's reading it right out of the file properties, not the revision in the registry. Right now it's up to 1.0.2.20xx, it normally gets incremented each time someone compiles - but since those aren't committed, they can go out of sync. Let's dump that and see if we can synchronize it to the revision. 1.0.3.rev.

Blight didn't want to make a special exception for this, but he might if there's no way to embed the rev in the version resource.