why would my directshow graph (with dynamic format) just hang?

0
votes

I have a custom "sink" filter. I create a BDA graph, and send the MPEG2VIDEO stream to it by calling IGraphBuilder2::RenderStream which also adds an intermediary "decode" filter. At this point, it notifies my filter that it will be passing it 704x480 YUY2 data.

When I call Run on the graph, the tuning occurs (I presume) and the format of the data apparently changes, as the upstream decoder calls ReceiveConnection on my filter's pin with a size of 1280x720. I accept it and return S_OK.

However, if I return S_OK, the graph basically hangs from that point on. If I return VFW_E_ALREADY_CONNECTED then it successfully feeds me 704x480 data. The odd part being that if I run the same type of graph in GraphEdit, but with a normal video renderer, it successfully renegotiates the format and uses it. One thing to note is my filter has no custom allocator. Any ideas?

The decoding filter in this case is PowerDVD 8's "mpeg2 video decoder" FWIW.

1
directshow
My only current theory is either I need to have an allocator, or something else is causing the calling thread to "segfault" (LAV filter for instance segfaults it seems). – rogerdpack
Probably unrelated, but I had a problem with powerdvd's mpeg2 decoder in the past. It caused a huge memory leak in my application. Uninstalling powerdvd and installing ffdshow(tryouts) fixed my problem. – wimh
I have only used BDA for live sources, so I could do the tuning even before adding the demux to the graph. Do you know/have elecard's spy.ax? You could insert the filter between two other filters to monitor the messages. That way you can check if the normal video renderer does something different. – wimh
@Wimmel yes this is live BDA. that spy.ax looks grand I wish there were a binary of it :) Anyway my current work around is to consume either the MPEG2VIDEO packets from the demux or to consume the TS stream heading into the demux, then at least I get the right resolutions from the get go. Still odd though...I might try running with a debug version of LAV filter installed as well. Thanks for the advice. – rogerdpack
If it hangs, it means that the crticial section locks has messed up. The simplest thing to do is use a debugger to pause the process and see where the thread(s) has deadlocked. Later on you can analyze the situation and find the cause of the deadlock. – Anton Angelov

1 Answers

0
votes

In the end I think this had to do with content renegotiation somehow...wasn't being handled right... my work around was to use different filters (lav filters vs. ffdshow) (which might have avoided a bug but then introduced more) so I ended up just passing the raw MPEG stream through (which wasn't easy...)