Bug#412080: please default to vo=x11
Package: mplayer Severity: normal Please default to vo=x11. Otherwise: - screenshots don't work - when rotating the screen using beryl, the mplayer screen is missplaced -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
tags wontfix 412080 close 412080 thanks On Fri, Feb 23, 2007 at 01:40:38PM +0100, Robert Millan [ackstorm] wrote: > > Please default to vo=x11. Otherwise: > > - screenshots don't work > - when rotating the screen using beryl, the mplayer screen is missplaced This is an insane request. It will turn off hardware scaling, which is necessary for fullscreen playback on >2GHz or so machines. Look at the screenshot filter, I think it will allow you to take screenshots even with the xv video output driver. As for Beryl, report the bug to them... Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Fri, Feb 23, 2007 at 01:40:38PM +0100, Robert Millan [ackstorm] wrote: > Package: mplayer > Severity: normal > > Please default to vo=x11. Otherwise: > > - screenshots don't work vo=x11 is quite slower than vo=xv , and there is no hw scaling, etc etc etc making that the default would be a bad choice you cannot balance "screenshots don't work" (which rarely people use) with all benefits of vo=xv or other hw accelerated vo > - when rotating the screen using beryl, the mplayer screen is missplaced this should be investigated better what about other players? what kind of video output is having this problem? a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Fri, Feb 23, 2007 at 02:46:58PM +0100, debdev wrote: > > - when rotating the screen using beryl, the mplayer screen is missplaced BTW: AFAICT beryl is not even packaged into Debian... so I hardly see this as a Debian bug a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
reopen 412080 thanks On Fri, Feb 23, 2007 at 02:17:51PM +0100, Diego Biurrun wrote: > tags wontfix 412080 > close 412080 > thanks Please don't close. Your refusal to fix it is already reflected by the wontfix tag; closing it is not necessary and is a bad thing since it'll hide the discussion (which at the least will be useful for reference). > > - screenshots don't work > > - when rotating the screen using beryl, the mplayer screen is missplaced > > This is an insane request. It will turn off hardware scaling, which is > necessary for fullscreen playback on >2GHz or so machines. It was my understanding that hardware scaling is necessary for _slow_ machines, not fast ones. But you seem to contradict that. Please can you explain? > Look at the screenshot filter, I think it will allow you to take > screenshots even with the xv video output driver. > > As for Beryl, report the bug to them... Sorry, I didn't explain well. I _can_ take screenshots, it's just that the video is displayed blue. This is not a Beryl bug, it'll happen to everything that captures the X display. See attached screenshots. In one of them, video appears to be completely blue, but in the real screen I see the video in 2D. I.e. as if after rotating the display the video was inserted only in the blue part (without rotation). -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Fri, Feb 23, 2007 at 02:46:58PM +0100, A Mennucc wrote: > On Fri, Feb 23, 2007 at 01:40:38PM +0100, Robert Millan [ackstorm] wrote: > > Package: mplayer > > Severity: normal > > > > Please default to vo=x11. Otherwise: > > > > - screenshots don't work > > vo=x11 is quite slower than vo=xv , and > there is no hw scaling, etc etc etc > > making that the default would be a bad choice > > you cannot balance "screenshots don't work" > (which rarely people use) with all benefits of > vo=xv or other hw accelerated vo What kind of computers would be in trouble because of no hardware scaling? In my experience, most slow (but recent) computers can cope with -vo x11 -zoom just fine. Also, can we consider rising the debconf priority of -vo question and/or improving the description to explain about these problems? > > - when rotating the screen using beryl, the mplayer screen is missplaced > > this should be investigated better See my other mail for more on that (with attached screenshots). > what about other players? They get the same problem when Xv is used. This is the case for Totem at least. > what kind of video output is having this problem? I haven't checked any other than x11 and xv. I expect that any video output that uses a "magic" interface to send the data instead of displaying it directly in the x11 window will have this problem. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 10:37:36AM +0100, Robert Millan [ackstorm] wrote: > > On Fri, Feb 23, 2007 at 02:17:51PM +0100, Diego Biurrun wrote: > > tags wontfix 412080 > > close 412080 > > thanks > > Please don't close. Your refusal to fix it is already reflected by the > wontfix tag; closing it is not necessary and is a bad thing since it'll > hide the discussion (which at the least will be useful for reference). So wontfix bugs will stay open forever? This does not make sense to me.. > > > - screenshots don't work > > > - when rotating the screen using beryl, the mplayer screen is missplaced > > > > This is an insane request. It will turn off hardware scaling, which is > > necessary for fullscreen playback on >2GHz or so machines. > > It was my understanding that hardware scaling is necessary for _slow_ > machines, not fast ones. But you seem to contradict that. Please can > you explain? Hardware scaling is not for slow machines. Hardware scaling is simply the faster way to scale. Not supporting hardware scaling amounts to not having fullscreen playback on moderately fast or slow machines that could otherwise perfectly handle the load and needlessly burning CPU cycles on fast ones. If your machine is fast enough, go ahead, add vo=x11 to your configuration file. But using this as a package default is going to do a lot of damage for almost everybody else. Not to mention that the -zoom option is necessary to get scaling at all then. > > Look at the screenshot filter, I think it will allow you to take > > screenshots even with the xv video output driver. > > > > As for Beryl, report the bug to them... > > Sorry, I didn't explain well. I _can_ take screenshots, it's just that > the video is displayed blue. This is not a Beryl bug, it'll happen to > everything that captures the X display. > > See attached screenshots. In one of them, video appears to be completely > blue, but in the real screen I see the video in 2D. I.e. as if after > rotating the display the video was inserted only in the blue part (without > rotation). I perfectly understood what you were referring to. I'm well familiar with this effect. This is because X does not handle the overlay video memory directly. Now why don't you try the screenshot filter as I suggested? Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Fri, Feb 23, 2007 at 06:47:42PM +0100, A Mennucc wrote: > On Fri, Feb 23, 2007 at 02:46:58PM +0100, debdev wrote: > > > - when rotating the screen using beryl, the mplayer screen is missplaced > > BTW: AFAICT beryl is not even packaged into Debian... so > I hardly see this as a Debian bug Our Social Contract has some words about software that is not part of Debian. Also, I'd like to remind you that mozilla-mplayer existed in Debian for a really long time despite the fact that mplayer did not. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
Hello, On Mon, Feb 26, 2007 at 10:43:29AM +0100, Robert Millan [ackstorm] wrote: > On Fri, Feb 23, 2007 at 02:46:58PM +0100, A Mennucc wrote: > > On Fri, Feb 23, 2007 at 01:40:38PM +0100, Robert Millan [ackstorm] wrote: > > > Package: mplayer > > > Severity: normal > > > > > > Please default to vo=x11. Otherwise: > > > > > > - screenshots don't work > > > > vo=x11 is quite slower than vo=xv , and > > there is no hw scaling, etc etc etc > > > > making that the default would be a bad choice > > > > you cannot balance "screenshots don't work" > > (which rarely people use) with all benefits of > > vo=xv or other hw accelerated vo > > What kind of computers would be in trouble because of no hardware scaling? > > In my experience, most slow (but recent) computers can cope with -vo x11 > -zoom just fine. I know quite a few PCs that can't play DVDs with just -vo x11 even without using -zoom but work just fine with -vo xv. In addition -vo x11 can not sync to vblank so you will see tearing. I also think you completely missed the videos that are not based on 10 year old technology like http://images.apple.com/movies/lionsgate/the_condemned/the_condemned-tlr_h720p.mov (that is one of those that actually need little CPU) and here -vo xv or -vo x11 easily makes the difference between playable or not even with a new PC. Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 11:39:14AM +0100, Robert Millan [ackstorm] wrote: > > On Mon, Feb 26, 2007 at 11:09:06AM +0100, Diego Biurrun wrote: > > > It was my understanding that hardware scaling is necessary for _slow_ > > > machines, not fast ones. But you seem to contradict that. Please can > > > you explain? > > > > Hardware scaling is not for slow machines. Hardware scaling is simply > > the faster way to scale. Not supporting hardware scaling amounts to not > > having fullscreen playback on moderately fast or slow machines that > > could otherwise perfectly handle the load and needlessly burning CPU > > cycles on fast ones. > > > > If your machine is fast enough, go ahead, add vo=x11 to your > > configuration file. But using this as a package default is going to do > > a lot of damage for almost everybody else. Not to mention that the -zoom > > option is necessary to get scaling at all then. > > Why a lot of damage? How many machines are too slow for software scaling? I would guess about 80% of all the machines out there. You know, not everybody has a machine fast enough to run Beryl or can afford one. All machines below 2GHz I would guess, this excludes every non-x86 right away. My last generation PowerBook is not fast enough, even for a video of moderate size. When the machine is too slow to scale the video, video and audio go out of sync and the movie becomes unwatchable. I would guess the number of people taking screenshots at all is in the low one-digit percent of the users of MPlayer. It's not unreasonable at all to expect them to take appropriate measures. The situation is the same for all other multimedia players, btw. Does this give you an idea how much damage such a change would do? > OTOH, the power user who is compiling things and running boinc will > have an idea how to tune up her mplayer. This power user should also have an idea how to read an FAQ or a man page. Taking screenshots is explained there. > > > Sorry, I didn't explain well. I _can_ take screenshots, it's just that > > > the video is displayed blue. This is not a Beryl bug, it'll happen to > > > everything that captures the X display. > > > > > > See attached screenshots. In one of them, video appears to be completely > > > blue, but in the real screen I see the video in 2D. I.e. as if after > > > rotating the display the video was inserted only in the blue part (without > > > rotation). > > > > I perfectly understood what you were referring to. I'm well familiar > > with this effect. This is because X does not handle the overlay video > > memory directly. Now why don't you try the screenshot filter as I > > suggested? > > That's a workaround. For plain screenshots it'd be enough to enable this > workaround by default. > > For Beryl, we would need another workaround, and presumably a more complicated > one. We shouldn't assume that is even possible to do that sanely. This is not a workaround, this is the only feasible solution. Now would you please try it? I feel extremely silly discussing this proposition at all. Broken distro packages defaulting to the x11 video output driver was the #1 source of complaints about MPlayer upstream. Needless to say, it was all blamed on us instead of on the packagers. I have single-handedly reviewed several distro packages and talked to the packagers to make them avoid this dreadful mistake. Now please stop insisting on this insanity, thank you very much. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
severity 412080 wishlist thanks On Mon, Feb 26, 2007 at 11:09:06AM +0100, Diego Biurrun wrote: > > Please don't close. Your refusal to fix it is already reflected by the > > wontfix tag; closing it is not necessary and is a bad thing since it'll > > hide the discussion (which at the least will be useful for reference). > > So wontfix bugs will stay open forever? This does not make sense to > me.. Yes. That's the point of archiving discussion, that it can be checked at any time. Bug reports should be closed when fixed. If you don't intend to fix it (as the wontfix tag shows), then it should not be closed. Though, I acknowledge that this is a wishlist item rather than a bug as-is. > > It was my understanding that hardware scaling is necessary for _slow_ > > machines, not fast ones. But you seem to contradict that. Please can > > you explain? > > Hardware scaling is not for slow machines. Hardware scaling is simply > the faster way to scale. Not supporting hardware scaling amounts to not > having fullscreen playback on moderately fast or slow machines that > could otherwise perfectly handle the load and needlessly burning CPU > cycles on fast ones. > > If your machine is fast enough, go ahead, add vo=x11 to your > configuration file. But using this as a package default is going to do > a lot of damage for almost everybody else. Not to mention that the -zoom > option is necessary to get scaling at all then. Why a lot of damage? How many machines are too slow for software scaling? Also, why is burning CPU cycles a big issue? The typical desktop user won't be doing anything else when displaying a video, specialy when scaling takes place and the video runs in full screen. OTOH, the power user who is compiling things and running boinc will have an idea how to tune up her mplayer. Also, we could take as a compromise solution to rise the template severity and make it clearer to the user what advantages and disadvantages do software and hardware scaling have. > > Sorry, I didn't explain well. I _can_ take screenshots, it's just that > > the video is displayed blue. This is not a Beryl bug, it'll happen to > > everything that captures the X display. > > > > See attached screenshots. In one of them, video appears to be completely > > blue, but in the real screen I see the video in 2D. I.e. as if after > > rotating the display the video was inserted only in the blue part (without > > rotation). > > I perfectly understood what you were referring to. I'm well familiar > with this effect. This is because X does not handle the overlay video > memory directly. Now why don't you try the screenshot filter as I > suggested? That's a workaround. For plain screenshots it'd be enough to enable this workaround by default. For Beryl, we would need another workaround, and presumably a more complicated one. We shouldn't assume that is even possible to do that sanely. Later, other programs might have similar problems, etc. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 11:51:13AM +0100, Reimar Döffinger wrote: > > > > What kind of computers would be in trouble because of no hardware scaling? > > > > In my experience, most slow (but recent) computers can cope with -vo x11 > > -zoom just fine. > > I know quite a few PCs that can't play DVDs with just -vo x11 even > without using -zoom but work just fine with -vo xv. > In addition -vo x11 can not sync to vblank so you will see tearing. > I also think you completely missed the videos that are not based on 10 > year old technology like > http://images.apple.com/movies/lionsgate/the_condemned/the_condemned-tlr_h720p.mov > (that is one of those that actually need little CPU) and here -vo xv or > -vo x11 easily makes the difference between playable or not even with a > new PC. I see what you mean... I wasn't aware that new codec implementations were so CPU hungry. Could we keep accelerated mode as default, but try to arrange it in a way that the novice user can easily choose x11 with software scaling if she wants that? I could send a patch to do this. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 12:03:00PM +0100, Diego Biurrun wrote: > > Why a lot of damage? How many machines are too slow for software scaling? > > I would guess about 80% of all the machines out there. You know, not > everybody has a machine fast enough to run Beryl or can afford one. > > All machines below 2GHz I would guess, this excludes every non-x86 right > away. My last generation PowerBook is not fast enough, even for a video > of moderate size. > > When the machine is too slow to scale the video, video and audio go out > of sync and the movie becomes unwatchable. > > I would guess the number of people taking screenshots at all is in the > low one-digit percent of the users of MPlayer. It's not unreasonable at > all to expect them to take appropriate measures. The situation is the > same for all other multimedia players, btw. > > Does this give you an idea how much damage such a change would do? Yes. I see your point here. Reimar also made a good one. I won't insist on having software scaling as default. But then again we could try to fit well for users of powerful machines as well. What do you think of my proposition of rearranging the template a bit (but still defaulting to accelerated mode) ? > > That's a workaround. For plain screenshots it'd be enough to enable this > > workaround by default. > > > > For Beryl, we would need another workaround, and presumably a more > > complicated > > one. We shouldn't assume that is even possible to do that sanely. > > This is not a workaround, this is the only feasible solution. Now would > you please try it? That's not necessary, I believe when you say it works. It doesn't work for Beryl though, or for $insert-new-weird-yet-to-be-found-stuff-here. > I feel extremely silly discussing this proposition at all. Broken > distro packages defaulting to the x11 video output driver was the #1 > source of complaints about MPlayer upstream. Needless to say, it was > all blamed on us instead of on the packagers. Ok. I understand you might have been quite annoyed about this. Sorry about that. Now if we can re-arrange the templates a bit, I would be quite happy with that. Can I proceed with this and send a proposed patch? -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 12:30:50PM +0100, Robert Millan [ackstorm] wrote: > On Mon, Feb 26, 2007 at 12:03:00PM +0100, Diego Biurrun wrote: > > > Why a lot of damage? How many machines are too slow for software scaling? > > > > I would guess about 80% of all the machines out there. You know, not > > everybody has a machine fast enough to run Beryl or can afford one. > > > > All machines below 2GHz I would guess, this excludes every non-x86 right > > away. My last generation PowerBook is not fast enough, even for a video > > of moderate size. > > > > When the machine is too slow to scale the video, video and audio go out > > of sync and the movie becomes unwatchable. > > > > I would guess the number of people taking screenshots at all is in the > > low one-digit percent of the users of MPlayer. It's not unreasonable at > > all to expect them to take appropriate measures. The situation is the > > same for all other multimedia players, btw. > > > > Does this give you an idea how much damage such a change would do? > > Yes. I see your point here. Reimar also made a good one. I won't insist > on having software scaling as default. :) > But then again we could try to fit well for users of powerful machines > as well. What do you think of my proposition of rearranging the template > a bit (but still defaulting to accelerated mode) ? I still think it's a bad idea. In fact I think this template is a bad idea to begin with. MPlayer has been carefully tuned to choose the best video output driver by default, setting a default vo overrides this. > > > That's a workaround. For plain screenshots it'd be enough to enable this > > > workaround by default. > > > > > > For Beryl, we would need another workaround, and presumably a more > > > complicated > > > one. We shouldn't assume that is even possible to do that sanely. > > > > This is not a workaround, this is the only feasible solution. Now would > > you please try it? > > That's not necessary, I believe when you say it works. It doesn't work for > Beryl though, or for $insert-new-weird-yet-to-be-found-stuff-here. I doubt this is related to Beryl, try the following mplayer -vo xv -vf screenshot Then press 's' a few times, you should get a message like sending VFCTRL_SCREENSHOT! *** screenshot 'shot0008.png' *** and a PNG file with the screenshot in the current directory. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
Package: mplayer Severity: wishlist # followup comes from #412080 On Mon, Feb 26, 2007 at 12:44:18PM +0100, Reimar Döffinger wrote: > Hello, > On Mon, Feb 26, 2007 at 12:24:09PM +0100, Robert Millan [ackstorm] wrote: > [...] > > Could we keep accelerated mode as default, but try to arrange it in a way > > that > > the novice user can easily choose x11 with software scaling if she wants > > that? > > Making things easier is never a fault, though 2 comments on your special > situation: > 1) Xgl at least solves both the positioning and screenshot problem by > emulating > XVideo via OpenGL, which is the only sane way to support xv-only applications > properly on a 3D desktop. It is not a real option on old hardware > though. > 2) If available, -vo gl or even better -vo gl:yuv=2 or even -vo > gl:yuv=2:lscale=1 is a much better choice than x11. > It can support vsync, hardware scaling and even hardware colorspace > conversion and in the last example even much higher-quality scaling, > given your hardware and drivers are good enough (which basically is the > main problem with it). Xgl is not in debian, and installing it in etch is a major headache (check the ITP). I don't think we should care about this now, since any user who spends several hours to install Xgl in etch can spare a few seconds to adjust mplayer. How about adding a "quick and easy" question that offers software mode for etch, and then figuring out an Xgl-aware layout for lenny ? Assuming you're ok with that, I'm using this mail to file a separate bug. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 01:16:39PM +0100, Diego Biurrun wrote: > > But then again we could try to fit well for users of powerful machines > > as well. What do you think of my proposition of rearranging the template > > a bit (but still defaulting to accelerated mode) ? > > I still think it's a bad idea. In fact I think this template is a bad > idea to begin with. MPlayer has been carefully tuned to choose the best > video output driver by default, setting a default vo overrides this. Sorry, I meant to say "defaulting to autodetection". Can we default to autodetection but first ask the user in a more friendly manner wether she wants to acceleration at all ? (explaining the drawbacks, etc) > > That's not necessary, I believe when you say it works. It doesn't work for > > Beryl though, or for $insert-new-weird-yet-to-be-found-stuff-here. > > I doubt this is related to Beryl, try the following > > mplayer -vo xv -vf screenshot > > Then press 's' a few times, you should get a message like > > sending VFCTRL_SCREENSHOT! > *** screenshot 'shot0008.png' *** Can't try this (see my other reply about mplayer crash), also if I press 's' while in Beryl cube mode, it won't be sent to my terminal. Anyway, AFAICT it's impossible that mplayer can figure out how Beryl is going to perform 3D rotation to its video display (see the screenshot I sent before), unless -vo x11 is used or some hack is added to Beryl. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
Package: mplayer Severity: normal On Mon, Feb 26, 2007 at 01:16:39PM +0100, Diego Biurrun wrote: > > I doubt this is related to Beryl, try the following > > mplayer -vo xv -vf screenshot Interestingly, this revealed a new bug (before doing anything with Beryl): [...] X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0 MPlayer interrupted by signal 6 in module: vo_check_events (with http://images.apple.com/movies/lionsgate/the_condemned/the_condemned-tlr_h720p.mov) -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 11:39:14AM +0100, Robert Millan [ackstorm] wrote: > Also, we could take as a compromise solution to rise the template severity > and make it clearer to the user what advantages and disadvantages do > software and hardware scaling have. I have no objections in raising the template severity (lets say, from low to normal ) as for changing the templates... there is only a problem: it would invalidate translations, and this we should not do in Etch freeze a. -- Andrea Mennucc "The EULA sounds like it was written by a team of lawyers who want to tell me what I can't do, and the GPL sounds like it was written by a human being who wants me to know what I can do." Anonymous,http://www.securityfocus.com/columnists/420 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
Hello, On Mon, Feb 26, 2007 at 01:07:59PM +0100, Robert Millan [ackstorm] wrote: > On Mon, Feb 26, 2007 at 12:44:18PM +0100, Reimar Döffinger wrote: > > On Mon, Feb 26, 2007 at 12:24:09PM +0100, Robert Millan [ackstorm] wrote: > > [...] > > > Could we keep accelerated mode as default, but try to arrange it in a way > > > that > > > the novice user can easily choose x11 with software scaling if she wants > > > that? > > > > Making things easier is never a fault, though 2 comments on your special > > situation: > > 1) Xgl at least solves both the positioning and screenshot problem by > > emulating > > XVideo via OpenGL, which is the only sane way to support xv-only > > applications > > properly on a 3D desktop. It is not a real option on old hardware > > though. > > 2) If available, -vo gl or even better -vo gl:yuv=2 or even -vo > > gl:yuv=2:lscale=1 is a much better choice than x11. > > It can support vsync, hardware scaling and even hardware colorspace > > conversion and in the last example even much higher-quality scaling, > > given your hardware and drivers are good enough (which basically is the > > main problem with it). > > Xgl is not in debian, and installing it in etch is a major headache (check > the ITP). I wasn't suggesting to use Xgl, I was just explaining what it does and stating that I think this is the only sane way to handle the XVideo problems with 3D Desktops at least in the long term. > I don't think we should care about this now, since any user who spends several > hours to install Xgl in etch can spare a few seconds to adjust mplayer. > > How about adding a "quick and easy" question that offers software mode for > etch, and then figuring out an Xgl-aware layout for lenny ? Huh?? I was basically saying that Xgl does not have any of these problems at all (it does create some problems with older 3D cards). And the second part was saying that for the 3D-Desktop case -vo gl should be a better choice than -vo x11 (whether Xgl or whatever else you use). Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
retitle 412080 please rise mplayer/voutput severity to 'high' thanks On Mon, Feb 26, 2007 at 02:21:45PM +0100, A Mennucc wrote: > On Mon, Feb 26, 2007 at 11:39:14AM +0100, Robert Millan [ackstorm] wrote: > > Also, we could take as a compromise solution to rise the template severity > > and make it clearer to the user what advantages and disadvantages do > > software and hardware scaling have. > > I have no objections in raising the template severity (lets say, > from low to normal ) That'd be from normal to high. If you can do that, I think it'd be an improvement. > as for changing the templates... > there is only a problem: it would invalidate translations, and > this we should not do in Etch freeze What a pity. Well, things are as they are. I'll think of writing something better post-etch. -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 02:37:27PM +0100, Reimar Döffinger wrote: > > Huh?? I was basically saying that Xgl does not have any of these > problems at all (it does create some problems with older 3D cards). > And the second part was saying that for the 3D-Desktop case -vo gl > should be a better choice than -vo x11 (whether Xgl or whatever else you use). Ah, ok. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Mon, Feb 26, 2007 at 01:31:21PM +0100, Robert Millan [ackstorm] wrote: > On Mon, Feb 26, 2007 at 01:16:39PM +0100, Diego Biurrun wrote: > > > But then again we could try to fit well for users of powerful machines > > > as well. What do you think of my proposition of rearranging the template > > > a bit (but still defaulting to accelerated mode) ? > > > > I still think it's a bad idea. In fact I think this template is a bad > > idea to begin with. MPlayer has been carefully tuned to choose the best > > video output driver by default, setting a default vo overrides this. > > Sorry, I meant to say "defaulting to autodetection". Can we default to > autodetection but first ask the user in a more friendly manner wether she > wants to acceleration at all ? (explaining the drawbacks, etc) I refuse to continue discussing this. You are the one-in-a-million special case asking to have his wishes accomodated. Ways to aquire screenshots already exist and are clearly documented. I cannot stop Andrea from doing this if he should decide so, but I consider it a very very bad idea. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Tue, Feb 27, 2007 at 11:36:04AM +0100, Diego Biurrun wrote: > On Mon, Feb 26, 2007 at 01:31:21PM +0100, Robert Millan [ackstorm] wrote: > > On Mon, Feb 26, 2007 at 01:16:39PM +0100, Diego Biurrun wrote: > > > > But then again we could try to fit well for users of powerful machines > > > > as well. What do you think of my proposition of rearranging the > > > > template > > > > a bit (but still defaulting to accelerated mode) ? > > > > > > I still think it's a bad idea. In fact I think this template is a bad > > > idea to begin with. MPlayer has been carefully tuned to choose the best > > > video output driver by default, setting a default vo overrides this. > > > > Sorry, I meant to say "defaulting to autodetection". Can we default to > > autodetection but first ask the user in a more friendly manner wether she > > wants to acceleration at all ? (explaining the drawbacks, etc) > > I refuse to continue discussing this. You are the one-in-a-million > special case asking to have his wishes accomodated. Ways to aquire > screenshots already exist and are clearly documented. I cannot stop > Andrea from doing this if he should decide so, but I consider it a very > very bad idea. Have you seen Andrea's last mail? We were discussing if we could just _rise the priority_ of the video output template. -- Robert Millan ACK STORM, S.L. - http://www.ackstorm.es/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Tue, Feb 27, 2007 at 11:40:07AM +0100, Robert Millan [ackstorm] wrote: > On Tue, Feb 27, 2007 at 11:36:04AM +0100, Diego Biurrun wrote: > > On Mon, Feb 26, 2007 at 01:31:21PM +0100, Robert Millan [ackstorm] wrote: > > > On Mon, Feb 26, 2007 at 01:16:39PM +0100, Diego Biurrun wrote: > > > > > But then again we could try to fit well for users of powerful machines > > > > > as well. What do you think of my proposition of rearranging the > > > > > template > > > > > a bit (but still defaulting to accelerated mode) ? > > > > > > > > I still think it's a bad idea. In fact I think this template is a bad > > > > idea to begin with. MPlayer has been carefully tuned to choose the best > > > > video output driver by default, setting a default vo overrides this. > > > > > > Sorry, I meant to say "defaulting to autodetection". Can we default to > > > autodetection but first ask the user in a more friendly manner wether she > > > wants to acceleration at all ? (explaining the drawbacks, etc) > > > > I refuse to continue discussing this. You are the one-in-a-million > > special case asking to have his wishes accomodated. Ways to aquire > > screenshots already exist and are clearly documented. I cannot stop > > Andrea from doing this if he should decide so, but I consider it a very > > very bad idea. > > Have you seen Andrea's last mail? We were discussing if we could just > _rise the priority_ of the video output template. Yes. I repeat (hopefully more clearly): I consider the video output template a very very bad idea. MPlayer has an elaborate system to work out the ideal video output driver on its own that this template overrides for no practical gain. I have personally removed a similar template from the upstream Debian packaging infrastructure and convinced Christian Marillat to do the same. Unfortunately I have been unsuccessful at convincing Andrea. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
Maybe we should take bug 412080 out of the CC, it's a different issue.. On Mon, Feb 26, 2007 at 01:25:13PM +0100, Robert Millan [ackstorm] wrote: > > On Mon, Feb 26, 2007 at 01:16:39PM +0100, Diego Biurrun wrote: > > > > I doubt this is related to Beryl, try the following > > > > mplayer -vo xv -vf screenshot > > Interestingly, this revealed a new bug (before doing anything with Beryl): > > [...] > X11 error: BadAlloc (insufficient resources for operation)?,?% 0 0 > > > MPlayer interrupted by signal 6 in module: vo_check_events > > (with > http://images.apple.com/movies/lionsgate/the_condemned/the_condemned-tlr_h720p.mov) We need verbose output to have a chance of debugging this, but I have a feeling a similar issue was fixed in Subversion HEAD. Robert, can you verify this problem still occurs with a fresh compile of a Subversion checkout? Reimar, can you have a look, this sounds like your area .. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Tue, Feb 27, 2007 at 12:49:36PM +0100, Diego Biurrun wrote: > > > > Have you seen Andrea's last mail? We were discussing if we could just > > _rise the priority_ of the video output template. > > Yes. I repeat (hopefully more clearly): I consider the video output > template a very very bad idea. MPlayer has an elaborate system to work > out the ideal video output driver on its own that this template > overrides for no practical gain. I have personally removed a similar > template from the upstream Debian packaging infrastructure and convinced > Christian Marillat to do the same. Unfortunately I have been > unsuccessful at convincing Andrea. FYI, a friend of mine got autodetected an accelerated driver that his system doesn't support, and gmplayer doesn't work for him. I have yet to receive the details from him to file a proper bug, but this exposes quite well the reasons for having this choice. (too bad gmplayer isn't affected by debconf setup, though) -- Robert Millan My spam trap is [EMAIL PROTECTED] Note: this address is only intended for spam harvesters. Writing to it will get you added to my black list. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
On Tue, Feb 27, 2007 at 08:58:44PM +0100, Robert Millan wrote: > On Tue, Feb 27, 2007 at 12:49:36PM +0100, Diego Biurrun wrote: > > > > > > Have you seen Andrea's last mail? We were discussing if we could just > > > _rise the priority_ of the video output template. > > > > Yes. I repeat (hopefully more clearly): I consider the video output > > template a very very bad idea. MPlayer has an elaborate system to work > > out the ideal video output driver on its own that this template > > overrides for no practical gain. I have personally removed a similar > > template from the upstream Debian packaging infrastructure and convinced > > Christian Marillat to do the same. Unfortunately I have been > > unsuccessful at convincing Andrea. > > FYI, a friend of mine got autodetected an accelerated driver that his system > doesn't support, and gmplayer doesn't work for him. I have yet to receive > the details from him to file a proper bug, but this exposes quite well the > reasons for having this choice. No, this just exposes that there may (or may not) be a bug. If you provide details we may try to fix it. It's not justification enough to call the whole autodetection into question. It has been working stable for years.. Diego -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412080: please default to vo=x11
Hello, On Tue, Feb 27, 2007 at 08:58:44PM +0100, Robert Millan wrote: > On Tue, Feb 27, 2007 at 12:49:36PM +0100, Diego Biurrun wrote: > > > Have you seen Andrea's last mail? We were discussing if we could just > > > _rise the priority_ of the video output template. > > > > Yes. I repeat (hopefully more clearly): I consider the video output > > template a very very bad idea. MPlayer has an elaborate system to work > > out the ideal video output driver on its own that this template > > overrides for no practical gain. I have personally removed a similar > > template from the upstream Debian packaging infrastructure and convinced > > Christian Marillat to do the same. Unfortunately I have been > > unsuccessful at convincing Andrea. > > FYI, a friend of mine got autodetected an accelerated driver that his system > doesn't support, and gmplayer doesn't work for him. I have yet to receive > the details from him to file a proper bug, but this exposes quite well the > reasons for having this choice. > > (too bad gmplayer isn't affected by debconf setup, though) Unfortunately, gmplayer is not "affected" by the autodetection either... So, gmplayer problems are a completely different thing. Greetings, Reimar Döffinger -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
