I think we generally try to avoid introducing unused code, and if we have to, only as little as possible.
So I will suggest that instead of having the full featured generic decoder implemented at once, you implement it in a lock step with its client code (which I understand will be some winmm driver?), to show and validate how it's used and assert that it works. You can start by introducing the decoder with all method stubbed, and then implement the ones you need before or after calling them in the client.
Ideally I'd like to have tests for that as well, I don't know how hard it is to craft an indeo video stream, and test decoding it, do you think we could have that? I also understand from some past conversation that Windows doesn't support this anymore? Even so, maybe we could have the tests Wine-only, it will still let us catch potential regressions, and validate the implementation.
I also understand that the generic decoder is a rip-off of the H264, and although I would like to get the transforms factored together at some point, I think it's a bit too early for that and not the point of this anyway. So probably this generic decoder doesn't need most of the tiny details of the H264 decoder, and could be simplified and some methods kept as stubs.