Информация об изменениях

Сообщение Re[4]: Учет ссылок на объекты COM в коде DirectShow от 26.08.2019 8:43

Изменено 26.08.2019 8:43 Videoman

Re[4]: Учет ссылок на объекты COM в коде DirectShow
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Выяснилось, что quartz.dll почему-то сперва освобождает последнюю ссылку на фильтр, а затем — на его пины. У меня учет был раздельный, поэтому и падало. Посмотрел в Base Classes — у них учет общий для фильтра и всех пинов. Сделал так же — падать перестало.


Здесь вот тонкий момент, нужно еще раз перепроверить вашу логику. Вообще, в идеологии COM, порядок освобождения должен быть не важен. Также, имея интерфейс IPin, всегда можно получить IBaseFilter и обратно. Т.е., по суди, это все один завуалированный объект, скажет такой большой "краб". Если счетчик один, то уже после первого AddRef мы не можем понять за что нас держат, за IPin или IBaseFilter и у нас нет выбора кроме как удалять все только когда ref_count == 0. Я в разных фильтраз делал и так и так и всегда все работало как и задумалось (без утечек). На основе подхода реализованного в базовых классах BaseClasses, возможен только вариант с общим счетчиком (советую делать также, т.к. удобнее для DirectShow).

ЕМ>Кстати, нет ли там (кроме Base Classes, конечно) какого-нибудь хелпера для управления Advise-списками? Чтобы реализовать в своем IReferenceClock только фактическое отслеживание времени, а остальную рутинную работу отдать типовому хелперу. Или каждый фильтр, реализующий часы, должен всю эту байду делать заново?


Еcть — класс CBaseReferenceClock. Но на моей долгой практике я ни разу не видел чтобы кто-то пользовался этим сервисом. Мне также было лень эту каку реализовывать и я всегда возвращаю E_NOTIMP Пока проблем не было (видимо лет 20 назад кто-то использовал из Visual Basic).
Re[4]: Учет ссылок на объекты COM в коде DirectShow
Здравствуйте, Евгений Музыченко, Вы писали:

ЕМ>Выяснилось, что quartz.dll почему-то сперва освобождает последнюю ссылку на фильтр, а затем — на его пины. У меня учет был раздельный, поэтому и падало. Посмотрел в Base Classes — у них учет общий для фильтра и всех пинов. Сделал так же — падать перестало.


Здесь вот тонкий момент, нужно еще раз перепроверить вашу логику. Вообще, в идеологии COM, порядок освобождения должен быть не важен. Также, имея интерфейс IPin, всегда можно получить IBaseFilter и обратно. Т.е., по суди, это все один завуалированный объект, скажем — такой большой "краб". Если счетчик один, то уже после первого AddRef мы не можем понять за что нас держат, за IPin или IBaseFilter и у нас нет выбора кроме как удалять все только когда ref_count == 0. Я в разных фильтраз делал и так и так и всегда все работало как и задумалось (без утечек). На основе подхода реализованного в базовых классах BaseClasses, возможен только вариант с общим счетчиком (советую делать также, т.к. удобнее для DirectShow).

ЕМ>Кстати, нет ли там (кроме Base Classes, конечно) какого-нибудь хелпера для управления Advise-списками? Чтобы реализовать в своем IReferenceClock только фактическое отслеживание времени, а остальную рутинную работу отдать типовому хелперу. Или каждый фильтр, реализующий часы, должен всю эту байду делать заново?


Еcть — класс CBaseReferenceClock. Но на моей долгой практике я ни разу не видел чтобы кто-то пользовался этим сервисом. Мне также было лень эту каку реализовывать и я всегда возвращаю E_NOTIMP Пока проблем не было (видимо лет 20 назад кто-то использовал из Visual Basic).