DirectShow / DMO transform filter for custom video decoder with MKV splitter support

Develop DirectShow Filter/DMO with specified features for my custom codec in Matroska container and use some test codec to demonstrate its work. Windows XP/Vista/7; C++/C# ## Deliverables I have custom video codec (it's *decoder* only, but I will name it as "codec" in this text) which stores its frames inside mkv container video track with custom FOURCC. I need you to develop a DirectShow or DMO transform filter for my codec support in such way that it will use existing Matroska splitters (Haali's and GOMlab's) to extract frames data (by automatically linking with their source filters), and will output ARGB32 color output. Because my codec both NDA-protected and not yet finished/stable, to complete this project you must demonstrate that your filter works not on my codec, but on some another commonly available codec with same requirements (keyframe and seeking support, etc - see below) which you will interface via its native lib - like FFMpeg or ffdshow (not directshow filter, of course, but via native C functions). So basically you will be developing DirectShow or DMO carcass for my decoder and will demonstrate its work for some another simple publicly-available decoder. 1. You may write your code in C++ or C#. 2. Only decoder filter programming is required (only mkvstream -> argb32 conversion). 3. Your decoder must support automatic pin reconnection or some other mechanism that will allow to mix in one media mkv file several tracks with different video data. Basically I want to be able to mix my codec data at one interval with some standard video data at other (following or preceding) interval. And when user plays this video file, I want him to see both tracks in time order (providing they are not overlapping each other). 4. You may use LGPLed and MIT/BSD licensed libraries if you really need them for DirectShow/DMO programming (for base classes, for example). Basically any license will do, if it doesn't require me to open my code or pay to authors of lib. (But you anyway must notify me beforehand). 5. Same for license of your "test codec" that you will use to demonstrate the working of your filter. 6. Windows XP, Vista and 7 must be supported. 7. Both x86 and amd64 architectures must be supported (except for Windows XP 64bit OS - it doesn't need to). Vista/7 64bit must be supported. 8. You must use standard mkv splitter filters or precisely tell me why they cannot be used. 9. Your filter must work with standard DirectShow players: in first place - Windows Media Player, GOM Player, Media Player Classic. 10. You will complete project by completing only these requirements - working of your filter with my "real" codec will not matter. Only full-featured demonstration of your filter with some pre-specified "test" codec matters. Codec features that must be supported (and you must show me their support by using some example codec in your DirectShow filter / DMO): 1. My codec uses keyframes, which must be ignored during normal playback, but must be used during seeking. Each keyframe contains all required information (except for Resources - see below) to start playing file from keyframe position. 2. Other frames contain only incremental differences to last keyframe. So to output some frame F you must either play all frames from 1 to F, or play all frames from last keyframe K (including K) to F. 3. Your filter output must be in ARGB32 format. Do not use DirectShow color conversion filters for your "test codec" or use them very separately from main code, because my own codec outputs only in ARGB32 format. 4. Your decoder output must be in sync with audio tracks from the same MKV container. You cannot just drop frames - for each dropped frame you must call some custom function with frame data as argument (I will later write my own in place of it), because my codec needs to make special operations on dropped frames. 5. Your program architecture must clearly separate your directshow filter/dmo and usage of "test" codec. Namely in cases of seeking, dropping frame, drawing frame, changing resolution. 6. Your transform filter must be aware of change of renderer's resolution (or player client window resize) and call some function stub and change output pin resolution accordingly. Later I will use it to output video at different resolutions by my codec when player window size changes. 7. My codec uses Resource system: in each frame it stores several numeric links to "resources" which are unique across mkv file (resources are just blobs of binary data). Currently I'm planning to store them in MKV Attachments, but not sure how to access them via standard mkv spliters (Haali's, for example) or from DirectShow. You must propose a way to access MKV Attachments from your filter/DMO or propose another way to store global video file resources which can be references from frames. If needed, I will clarify these requirements basing on your questions and will ask do you accept clarified requirements before accepting any bid. * * *This broadcast message was sent to all bidders on Friday Mar 18, 2011 9:13:04 AM: Maximum bid amount set to $1700. * * *This broadcast message was sent to all bidders on Friday Mar 18, 2011 10:29:35 AM: Clarification on "stream mixing": I don't need "mixing" - only "chaining". Basically, I want my own stream (track) to be handled by my filter, and other tracks to be handled by standard filters from other vendors. I don't know do the players can automatically switch from one track to another of different format when first track ends and second track starts, but MKV format by its spec supports it. In other words, I want to make possible to play video files of following format: [0:00 some video xx:xx] [xx:xx my custom-encoded video yy:yy] [yy:yy some another standard-encoded video zz:zz]