Reply to thread

Message: <blockquote data-quote="mm1352000" data-source="post: 1002469" data-attributes="member: 82144">I'm not sure, but I think our code here is pretty standard.I've been reading material like <a href="http://mathinfo.univ-reims.fr/image/mmVideo/cours/DirectShow3Annexe.pdf" target="_blank">this</a> trying to gain some knowledge and context on standard filter locking implementations.One thing which I think is a bit unusual in TsWriter is our locking with respect to Receive(). Stick with me here as this gets a bit curly... <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" /> If you check CMpTsFilterPin::Receive() you'll see we don't lock directly within that function. Use of the receive lock is commented out... which is interesting in itself.Having said that, CMpTsFilterPin implements CPacketSync.Samples Receive()'d are passed to CPacketSync::OnRawData(). If a complete TS packet is available in the buffer, that function invokes the virtual OnTsPacket() function which is overriden by CMpTsFilterPin. That OnTsPacket() override in turn calls AnalyzeTsPacket() on the main filter object.Now here's something that I think could be key: AnalyzeTsPacket() attempts to acquire the filter lock. Consider the scenario.Filter graph is running. Upstream filter is delivering samples. Everything honky dory.TV service decides its time to stop the graph for whatever reason.CMpTsFilter:<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite5" alt=":confused:" title="Confused    :confused:" loading="lazy" data-shortname=":confused:" />top() is invoked. While the lock is not yet acquired, samples continue to be delivered and nothing changes.When the lock is acquired, any sample that completes a TS packet in the CPacketSync buffer will block the streaming thread (because AnalyzeTsPacket() attempts to acquire the same lock held by Stop()).Having the streaming thread blocked could be very problematic depending on what CBaseFilter:<img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite5" alt=":confused:" title="Confused    :confused:" loading="lazy" data-shortname=":confused:" />top() does.I would presume that it in some way triggers the upstream filters to be stopped, and if any one of those filters tries to acquire an internal lock on its streaming thread (if it has one) the graph would immediately be in deadlock. Does that make any sense at all, or is it just nonsense?The other thing that is interesting to me is that we return S_FALSE for CMpTsFilterPin::ReceiveCanBlock(). I don't understand that considering the context of the above explanation that a lock is indeed acquired indirectly by the streaming thread. @<a href="https://forum.team-mediaportal.com/members/tourettes.10858/" target="_blank">tourettes</a> @<a href="https://forum.team-mediaportal.com/members/davidf.19484/" target="_blank">davidf</a> @<a href="https://forum.team-mediaportal.com/members/offbyone.73415/" target="_blank">offbyone</a> @<a href="https://forum.team-mediaportal.com/members/georgius.107951/" target="_blank">georgius</a> @<a href="https://forum.team-mediaportal.com/members/morpheus_xx.48495/" target="_blank">morpheus_xx</a> your thoughts would be most welcome! <img src="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" class="smilie smilie--sprite smilie--sprite1" alt=":)" title="Smile    :)" loading="lazy" data-shortname=":)" />Also ping to @[USERGROUP=39]Developers[/USERGROUP] in general. It is high time we figured this out!</blockquote>

Verification