On Tue, May 01, 2007 at 08:49:20PM +0300, ext Siarhei Siamashka wrote: > On Tuesday 01 May 2007 17:49, Kalle Vahlman wrote: > > For testing, I fabricated some video with gstreamer: > > > > which resulted in [EMAIL PROTECTED] and [EMAIL PROTECTED] videos. For some > > reason 320x240 and 352x288 refused to play with: > > > > 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. > As Daniel replied in one of the followup messages, it is most likely some race > condition. The question is which code is a suspect. Is it MPlayer Xv video > output code that has been around for ages and worked fine on different systems > or relatively new Xv extension code from N800 xserver? In addition, a previous > revision of N800 firmware had a serious bug [2] related to video playback. It > should be noted, that MPlayer needed only about 1 minute to freeze on the > initial N800 firmware. So the problem could be identified much more easily > if MPlayer was included in the standard set of tests done by Nokia QA staff > before each new IT OS release. Surely, Nokia is only interested in a > properly working xvimagesink for the software included in IT OS by default. > But testing with more client applications can improve overall xserver quality. 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'. 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. > 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. Cheers, Daniel
signature.asc
Description: Digital signature
_______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
