So, first of all, this patch causes test failures. That's partly an effect of the mp3 tag data now changing, so you'll need to update the test to match.
Then it breaks the builtin quartz:filtergraph tests. While that makes sense given that we're no longer successfully parsing duration out of the file, it's not particularly ideal. And given that I've got some half-finished tests for seeking on parser filters locally, I'd kind of prefer that we can at least seek one file.
This caught my eye, though, because I recently submitted a patch to GStreamer for mpegaudioparse that improved its seeking logic, and yet even with that patch I was still getting a failure to query duration. After some time debugging I noticed some rather obvious problems with our duration queries. I'll send some patches which should make that test failure go away.
Anyway, this patch is a clear improvement, but what worries me is that it's not *enough*. One problem is that the larger the file, the longer we take to wait for EOS. I've seen a 45-minute mp3 file with no headers in the wild, and that makes connection take 3-5 seconds on my machine. I don't have a good solution for this, so I'm willing to accept the patch in the meantime. Possibly the best option is to also add a short timeout to the WaitForMultipleObjects() call.