[MPlayer-dev-eng] [PATCH] Implement DirectShow filter graph

[Steinar H. Gunderson]

On Sat, Mar 06, 2010 at 06:51:07PM +0100, Reimar Döffinger wrote:
>> All of this is copied from loader/dshow/allocator.c -- "modified" points to
>> the avifile library as a whole, but I can add a comment indicating the
>> original source is allocator.c?
> Definitely a good idea.

OK, done.

> Well, obviously you know it is used for reference counting, maybe you
> can even guess why reference counting is needed.
> Either of that would be a help.

OK, wrote a short comment.

>>>> +    p = (IFilterGraph*) FilterGraphCreate();
>>>> +    result = p->vt->QueryInterface((IUnknown*)p, iid, ppv);
>>>> +    p->vt->Release((IUnknown*)p);
>>> Wouldn't that make IUnknown the most appropriate type for p?
>> Again, copied from allocator.c. But I can change it if you'd like?
> Maybe change it in both places? :-)

OK, changed both places.

>> Can I use something like L"Filter" here, or would that be a problematic
>> gcc-ism?
> Never used it, but I think "L" indicates a wide character string, which on
> most Linux systems would be uint32_t, not uint16_t, not everyone had the
> skills of Microsoft to choose the absolutely most annoying unicode encoding
> possible...

FWIW, at the time Microsoft added Unicode support (a really long time ago!),
there was no talk at all about Unicode going beyond 16 bits. So I guess it
wasn't a conscious choice, just bad luck in being first :-)

Anyhow, I've changed it.

>>>>  	// enumerate pins
>>>>  	result = This->m_pFilter->vt->EnumPins(This->m_pFilter, &enum_pins);
>>>>  	if (result || !enum_pins)
>>> Mixed tabs and spaces.
>> You're talking about the break here, right, not the part you quoted?
> No, the part I quoted has 2 space and then a tab, which is the kind
> of indentation method I think really never is anything but a pain.

Hm. It really doesn't here. Perhaps I've fixed it since I sent the patch;
anyhow, it should be okay now.

>>> I assume there's no way this might break compiling on Windows?
>> It shouldn't be relevant for Windows at all; I'd assume it's not even included
>> in the compile?
> I don't know, we do use the same DirectShow loader code on Windows
> (of course we do not use the win32.c etc. stuff).
> We can still fix it afterwards, but it would be better to know beforehand
> if possible.

Well, it shouldn't really conflict with anything, but I can't guarantee it
then.

Updated patch attached.

/* Steinar */
-- 
Homepage: http://www.sesse.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dshow-filtergraph-v2.diff
Type: text/x-diff
Size: 12570 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20100306/2cee675f/attachment.diff>