Wow!! Having ffdshow included this starts getting *really* interesting! I did not imagine that it would be easy (was it?) to migrate native codecs to managed.
I will check this out as soon as I get home. It this works out good and more codecs follow, I could well imagine to integrate it into my player, so people would not have to download all those video codecs. This means I have to make it open source but I wanted to do it anyway sooner or later...
Perhaps I can help you coding a bit (don't have that much time though), I looked through the code and seen some areas where I think I could assist you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It wasn't really hard, but I had to decrypt the api first (never used vcm/acm directly before). The areas need help I think are code documenting, exceptions, and the audio renderer should be implemented a bit different. There was no open source audio renderer for directshow (ogo of reclock didn't reply to my email), so I had to come up with something on my own and it still has flaws, for example I don't know how to use the sound card's clock for the graph.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
One more thing, under remote desktop the dd7 renderer doesn't work, while in directshow the default renderer at least supports rgb565, but I cannot even create such a surface. I think I should use the tracker already :P
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After trying a few hd clips I had to realize that the constant sample memory reallocation is hurting a lot. So I made a class called MediaSamplePool which holds a fixed number pre-allocated byte[] arrays, similar to directshow allocators. The hard thing was that I couldn't just return these arrays when the sample was not used anymore, there is no reference counting here, or I should write it is not possible to query the actual reference count to a handle, and there are no predictible destructors either. The only thing I could do was to add IDisposable to ISample and make sure every end-user calls Dispose(). From now on this is going to be a general rule in the framework. Still, it's better than forgetting IUnknown::Release(), the GC might actually do the clean up some time later. The pool will just block when it runs out of free samples. Anyway, now even my test xvid at 1280x1080 uses only around 60% cpu with d3d9 (dd7 is much slower for some reason).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks to ffdshow, lots of video can be played now through vcm :)
btw, it is a c++ filter, it shows how to write mixed code :)
+acm decoder
This starts to smell reallyyyyyy good. :))
I've just played a 30 mins xvid avi and the perf counter "% time in GC" was around 15-20% on average.
Wow!! Having ffdshow included this starts getting *really* interesting! I did not imagine that it would be easy (was it?) to migrate native codecs to managed.
I will check this out as soon as I get home. It this works out good and more codecs follow, I could well imagine to integrate it into my player, so people would not have to download all those video codecs. This means I have to make it open source but I wanted to do it anyway sooner or later...
Perhaps I can help you coding a bit (don't have that much time though), I looked through the code and seen some areas where I think I could assist you.
It wasn't really hard, but I had to decrypt the api first (never used vcm/acm directly before). The areas need help I think are code documenting, exceptions, and the audio renderer should be implemented a bit different. There was no open source audio renderer for directshow (ogo of reclock didn't reply to my email), so I had to come up with something on my own and it still has flaws, for example I don't know how to use the sound card's clock for the graph.
One more thing, under remote desktop the dd7 renderer doesn't work, while in directshow the default renderer at least supports rgb565, but I cannot even create such a surface. I think I should use the tracker already :P
After trying a few hd clips I had to realize that the constant sample memory reallocation is hurting a lot. So I made a class called MediaSamplePool which holds a fixed number pre-allocated byte[] arrays, similar to directshow allocators. The hard thing was that I couldn't just return these arrays when the sample was not used anymore, there is no reference counting here, or I should write it is not possible to query the actual reference count to a handle, and there are no predictible destructors either. The only thing I could do was to add IDisposable to ISample and make sure every end-user calls Dispose(). From now on this is going to be a general rule in the framework. Still, it's better than forgetting IUnknown::Release(), the GC might actually do the clean up some time later. The pool will just block when it runs out of free samples. Anyway, now even my test xvid at 1280x1080 uses only around 60% cpu with d3d9 (dd7 is much slower for some reason).