Log in

View Full Version : DirectShowSource locks up or grey frames ASF source


systemloc
29th January 2009, 17:12
I've got some WMV 9 files that I'm re-encoding to AVC for playing on an iPhone, using MeGUI. I'm using DirectShowSource() to open the files. Occasionally, a file will lock up during video encoding, always at the same frame. I can add "timeout=x" to DirectShowSource() to get past the point with a grey frame inserted. Dragging the WMV file in question into graphedit and playing it causes graphedit to lock up at the same point. WMP 9 plays right through the point in the video without missing a beat, though!

What is WMP doing differently than GraphEdit and DirectShowSource() that it is able to play the frame? I thought GraphEdit should be identical to WMP.

To correct this, perhaps I could construct a graph manually that was equivelent to WMP's behavior and then load that into AVISynth?

Thanks for any input! :)

systemloc
29th January 2009, 17:55
Playing around a bit in GraphEdit, I found that GraphEdit seems to default to opening the file with "WM ASF Reader", which locks up. I built the graph manually with that to verify; it still locked up. I then tried opening the file with "Windows Media Source Filter". This required that I put in "ASF ICM Handler" and "ASF ACM Handler" before the video and audio decoders, respectively, however, it played without locking up!

I'm confused why GraphEdit defaults to "WM ASF Reader", whose merit is 00400000, instead of "Windows Media Source Filter", whose merit is 00600000. Perhaps because it requires the ICM and ACM Handlers?

I also found this MSDN page (http://msdn.microsoft.com/en-us/library/aa390680(VS.85).aspx), which explains that "WM ASF Reader" is newer, and used by default for WMV, ASF, and WMA files. I'm wondering how merit is overridden, and how to coerce AVISynth to use "Windows Media Source Filter" by default without having to manually make graphs for every file.

systemloc
29th January 2009, 18:09
Updating to WMP 11 fixed the problem. Kinda confusing, though, because qasf.dll, the "WM ASF Reader" was not modified. Oh well, the reason behind the problem is purely academic now, I suppose.