[MPlayer-dev-eng] [PATCH]Add support for CoreAVC h264 codec

[Alan Nisota]

On 10/3/06, Gianluigi Tiesi wrote:
> Some stuff for the win32 loader seams to be nice, but some are
> unrelated, I think you must split a bit the patch.
Unrelated to what?  All of this code was needed to get the codec in
question to run.  But if you mean that it may be good to include the
wine portion without the rest, I'll be happy to split the patches up.

> I doubt anyway this will be included since corecodec is not
> free and so no so much ppl can test it.
I can understand this.  I wasn't expecting it to go in per se, even
though little, if anything, in this patch is strictly related to the
CoreAVC codec; they should all be bug-fixes/feature-enhancements.

> I disagree about hardcoding w/h values,
I agree that it is nasty, but if you actually look at the code, you'll
see that defaults are only set once all other attempts to find the
dimension have failed.  One of the problems I ran into is that mplayer
was trying to initialize the codec  without having a wxh specificed,
which caused it to crash.  After the codec is initialized, the correct
dimensions are detected, and the video is decoded properly regardless
of resolution.  So this just acts as a fall-though.  This may be an
artifact of the container I'm using rather than anything specifcially
related to CoreAVC itself.  I will see whether other samples show this
issue, and thus try to determine if it is container related, or
specific to the codec itself.

> also encodepointer would be nice to be implemented as:
> return value ^ getpid(), it's simple and does the right
> thing. Anyway is not a good thing that a binary codec
> calls encodepointer.
Ok.

I will split the patch into 3 pieces:
1) The wine section, which I believe should be mostly ok, though there
are a few places I need to remove '#ifdef WIN32_LOADER' to make the
code work, and I'm not sure that is correct.

2) the enhancement to codecs.conf to allow passing registry values in
through that mechanism.  This shouldn't be very controvertial, though
I don't know if there is any interest either

3) The changes to dshow, which I can very much understand your
reluctance to, even though, most if it is just filling out data
structures and bug fixes (the CoreAVC codec seems to be much more
rigorous about how it is initialized than most)

Again, I am just trying to help, and can fully understand why you
wouldn't include this code.  I've gotten numerous emails from people
trying to use this patch since I first posted it 6 months ago, and
thought I'd try to make it more easily available.