Am Dienstag, den 30.08.2011, 23:29 +0200 schrieb Maarten Lankhorst: > > I think the question we should ask isn't if one driver or another needs > > something, but more if one or another behaviour is specific to an > > interface or not. So when an interface theoretically allows a behaviour > > (even if it's completely invalid like changing the picture structure in > > the middle of a frame) it is the job of the state tracker to come up > > with a proper solution to handle this behaviour. > Ah sure that makes sense. Do you think it's best to reject in that case? I thought about that for quite some time.
The first problem is when you detect this it's actually to late to send an error message to the application, because the data you just got is probably the first slice in the next valid frame. The second problem is that applications tend to not handle an error message at this point gracefully, because they think it's an out of memory condition, hardware problem or stuff like that. So it's probably the best to just end the last frame and move on with the next one. > >> Also I think it's safe to assume that the picture_structure won't change, > >> since the mpeg spec assumes its constant for the entire frame. > > I won't assume anything about the correctness of the stream. The mplayer > > guys have made quite a collection of streams which can crash the > > decoder: http://samples.mplayerhq.hu/MPEG2/ > > > > It's including stuff like changing the resolution of the picture in the > > middle of a stream, corrupt streams where an macroblock address is > > suddenly way out of the picture etc.. > > > > You should test that collection with your decoder and even if there is > > no way to correctly decode an invalid stream, it at least shouldn't > > crash, go into an endless loop... > > > Good idea, I should probably test that. I think it might hang > the gpu as it is now when macroblocks or motion vectors > go outside the picture, I've had it a few times on accident. For shaders a motion vector out of bounds isn't so bad (using textures just limits this nicely to the border color), but an invalid macroblock address lets the decoder write to what every memory currently is at this address....... The hard thing working with a gpu is mostly that you don't get a segfault (or valgrind complaining) if doing something stupid. I can't remember how many times I found myself sitting in front of a completely locked up system and wondering: Hey what the heck did you do wrong this time? Christian. _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
