On Wednesday 02 May 2007 12:47, Daniel Stone wrote: > > > X11 error: BadValue (integer parameter out of range for operation) > > > MPlayer interrupted by signal 6 in module: flip_page while gstreamer > > > did play them just fine. Also the Nokia_N800.avi and NokiaN93.avi died > > > in the same way. > > > > This X11 error on video playback start and also sometimes on switching > > fullscreen/windowed mode is a known problem [1] reported in this mailing > > list. > > > > If MPlayer dies on start, usually trying to start it again succeeds. So > > these 320x240 and 352x288 videos could be played as well if you were a > > bit more persistent :) > > Resizing is a bit tricky. Most video hardware lets you use the hardware > to clip, so if you move it beyond the edge of the screen, it just > happily ignores anything beyond the hardware's bounds. Unfortunately > for us, attempting to move a video surface off-screen (even by just a > few pixels) triggers a hardware lockup. > > Given that we can't display the frame at all, we send BadValue (there > are a couple of other conditions where this is possible, but this is the > main one). I don't see the point in returning Success when no video is > drawn at all. So, I guess you could hack mplayer's error handler to > just ignore BadValues from Xv(Shm)PutImage, unless you get more than > five or ten in a row, say.
Thanks for the hint, I'll try it. > Bear in mind that, as you've hinted at, the only part of the Xv code > which is custom is the _output_ code. We're using the standard X server > implementation (as used by tens of millions of people) for the protocol > decode and standard semantics, the standard KDrive layer for extended > stuff (as used by god-knows-how-many embedded and consumer devices), and > then the only part we have to play is taking frames and putting them on > the screen. > > Due to some restrictions (as above), we have to deliberately error out > on some operations. But errors like that tend to say 'you've hit a > hardware restriction, I can't do this', rather than 'you hit one of the > many random return BadValues we put in this weird code just to confuse > people'. That's the interesting information, thanks. > Also, bear in mind that a lot of the initial instability was due to the > DSP. The video was actually rather stable when you played without > sound, although now the situation is somewhat reversed with the DSP > being pretty steady now, and the new YUV420 code having complicated > semsnatics. Well, I was planning to raise this issuer later (after xserver/Xv things are clear), but looks like DSP still has some problems on N800. In MPlayer it can be triggered by a number of very fast sequential gstreamer pipeline start/stop operations which usually happen on seeking. Audio playback just hangs. Right now MPlayer artificially introduces 100ms pause to workaround this problem. I tried to reproduce the same issue on a small test program, but did not succeed yet. > > I have also submitted this patch to maemo bugzilla, hopefully it (or its > > modification) can get included into the next version of N800 firmware: > > https://maemo.org/bugzilla/show_bug.cgi?id=1278 > > I'll merge it with some changes. Thanks a lot. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
