Working around the mpegaudioparse problem does not seem unreasonable to me, but I don't think doing it from the frontend makes sense at all. I'd also really rather not have specific workarounds in the code until the actual problem is understood.
The problem resides in mpegvideoparse and the quartz tests, so having the workaround in the quartz mpeg decoder sounds resaonable. A bit more specifically, mpegvideoparse holds on some buffer we pass from the tests because it decides that it needs more data to tell whether they really are on frame boundaries or not, when it gets more and passes more data to ffmpeg the decoder in turn gets confused because it does not find the boundaries it expects. Splitting the frame data differently in the test makes the test pass. I think this is a non-issue anyway, the test comment suggests that native outputs buffer when EOS is seen anyway.
In that case I think we should just relax the quartz tests so that they accept whatever mpegvideoparse outputs.
Also:
And, like I said in 5255, I don't see how restricting the caps is necessary. What parser are you imagining would parse to the wrong format?