jerky flash in opera but not firefox, and only on nvidia cards
TimC
has picked up the 64 bit version 10 flash library (dated jul 18).
It's used by both opera (64 bit) and firefox (64 bit). The video card
is a nasta nvidia piece of crud using the closed drivers. An
identical installation with an intel video card works just fine.
Standalone video players work fine, as does firefox with the same
plugin. I had previously reported an issue with
http://lca2009.linux.org.au/ on this laptop using the nvidia drivers,
but I don't think the hangups there came down to the flash player
(they did seem to come down to it being an nvidia card though, again,
not affecting firefox)
But the flash player has *always* been slow and jerky when playing
videos under opera, including for old versions of both opera and the
flash plugin. I'm still on version 9.63 of opera because of various
bugs in 9.94 and 10, but this slow jerky behaviour still shows when I
tested 10.
Anyone else experience this? Andone know how to solve it, sort of
firing up firefox (and getting blasted with those damned youtube ads
that seem to have started popping up recently when using firefox)
everytime you want to watch youtube?
--
TimC
Kleeneness is next to Godelness.
Jens Schuessler
Same here, in 32-bit, but IMHO in 10 it's a bit less jerky.
I never thought that it has something to do with the
nvidia-driver, but as I only have an nvidia-card so I can't test it with
another one....
My feeling is that flash implementation from Adobe on Linux is always
a bit pain in the ass. In FF it works a little bit better, but it's slow
too and hangs often. I also use FF most times when i want to watch a yt-video
than Opera and I never saw any pop-ups. Maybe cause of AdBlockPlus.
Eirik Byrkjeflot Anonsen
> But the flash player has *always* been slow and jerky when playing
> videos under opera, including for old versions of both opera and the
> flash plugin. I'm still on version 9.63 of opera because of various
> bugs in 9.94 and 10, but this slow jerky behaviour still shows when I
> tested 10.
Maybe we still set low priority on plug-ins? Back in 2001 when I first
implemented the plug-in support on linux, flash would grab all the
resources it could, making opera really slow when a flash was running.
My solution back then was to lower the prority of the flash process.
I also added an environment variable that could be used to request a
different priority. If you set the environment variable
OPERA_PLUGINWRAPPER_DEBUG to above 6, I think opera will print out the
prority level it uses. Setting OPERAPLUGINWRAPPER_PRIORITY to 0 should
probably cause opera to use the "ordinary" priority level (the default
is most likely 19, which is the lowest possible).
eirik
Remco Lanting
The default on 9.64 is a nice value of 19 while on 10.00 it's 0. I pointed
the renice value out in May this year and it was changed in the build
released on 2009-05-27:
http://my.opera.com/desktopteam/blog/2009/05/27/snapshot-build-with-preview-of-the-new-skin
"[DSK-251573] Don't renice pluginwrapper to 19"
All that said, flash on linux sucks bigtime. Doing these things should
help:
- Make sure the video is the only flash player on the page (get rid of
flash ads for example)
- Wait for the video to download before starting playback
--
Remco Lanting
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
TimC
was almost, but not quite, entirely unlike tea:
> TimC <tcon...@no.spam.accepted.here-astro.swin.edu.au> writes:
>
>> But the flash player has *always* been slow and jerky when playing
>> videos under opera, including for old versions of both opera and the
>> flash plugin. I'm still on version 9.63 of opera because of various
>> bugs in 9.94 and 10, but this slow jerky behaviour still shows when I
>> tested 10.
>
> Maybe we still set low priority on plug-ins?
Ha. I've been frustrated by this for a couple of years. And yet I
never thought to see what nice level it was. 19 it is.
> Back in 2001 when I first
> implemented the plug-in support on linux, flash would grab all the
> resources it could, making opera really slow when a flash was running.
> My solution back then was to lower the prority of the flash process.
The linux scheduler was utter crap sometime soon after 2001. I
remember when a nice'd 19 process still got 20% of the time in favour
of a realtime process. The scheduler guru at the time said that it
was so prone to priority inversions, it wasn't safe to do anything
else.
Now of course, it'd be considered a rather big bug if a plugin was
able to steal all CPU time and cause a DoS to the browser.
> I also added an environment variable that could be used to request a
> different priority. If you set the environment variable
> OPERA_PLUGINWRAPPER_DEBUG to above 6, I think opera will print out the
> prority level it uses. Setting OPERAPLUGINWRAPPER_PRIORITY to 0 should
> probably cause opera to use the "ordinary" priority level (the default
> is most likely 19, which is the lowest possible).
At 0, I still get more audio stutters than I do under firefox.
It's a pain when I try to watch Geoffrey Gurrumul Yunupingu, so then I
just grab the HD flv file from ~/.opera/cache and play it in a
standalone player. It's OK, I bought his CD, so I'm allowed to pirate
his videos :)
--
TimC
Calm down, it's *only* ones and zeroes.
Tony
The better idea wil be renice Opera process itself.
Eirik Byrkjeflot Anonsen
> "Don't renice pluginwrapper to 19"
>
> The better idea wil be renice Opera process itself.
It's a matter of preference. When I did this (in 2001 or 2002), my
preference was to have choppy video in the few cases where it would end
up cpu-starved rather than a completely unresponsive opera whenever
there was a flash ad on a page. Things certainly have changed since
then, with the growth of flash video on the net.
eirik
ceed
As a non-technical Opera/Linux user I was wondering how to "renice" the
plugin-wrapper? Will it have to be done every time Opera runs, or can it
be set permanently. If so, how?
--
> <(((°> ceed <°)))><
Eirik Byrkjeflot Anonsen
The pluginwrapper renices itself when it starts up. Which it may do
many times during a single run of opera.
It used to be possible to set an environment variable to the niceness
value you wanted the pluginwrapper to use (in the range 0-19, I guess).
I've forgotten what that environment variable was called, though.
eirik
David W. Hodgins
> It used to be possible to set an environment variable to the niceness
> value you wanted the pluginwrapper to use (in the range 0-19, I guess).
> I've forgotten what that environment variable was called, though.
I think I got it from earlier in this thread ...
export OPERAPLUGINWRAPPER_PRIORITY=0
0=normal priorty, 19=low (default) priority.
Regards, Dave Hodgins
--
Change nomail.afraid.org to ody.ca to reply by email.
(nomail.afraid.org has been set up specifically for
use in usenet. Feel free to use it yourself.)
TimC
was almost, but not quite, entirely unlike tea:
>> As a non-technical Opera/Linux user I was wondering how to "renice"
>> the plugin-wrapper? Will it have to be done every time Opera runs, or
>> can it be set permanently. If so, how?
>
> The pluginwrapper renices itself when it starts up. Which it may do
> many times during a single run of opera.
>
> It used to be possible to set an environment variable to the niceness
> value you wanted the pluginwrapper to use (in the range 0-19, I guess).
> I've forgotten what that environment variable was called, though.
OPERAPLUGINWRAPPER_PRIORITY=0
If ceed can bring up the properties dialog for whatever starts opera
on their system, then you'd be able to get it to invoke
'env OPERAPLUGINWRAPPER_PRIORITY=0 opera'
instead of just 'opera' (keep any other parameters it might have on the
end of that)
--
TimC
A bug in the code is worth two in the documentation. --unknown
ceed
<tcon...@no.spam.accepted.here-astro.swin.edu.au> wrote:
> OPERAPLUGINWRAPPER_PRIORITY=0
> If ceed can bring up the properties dialog for whatever starts opera
> on their system, then you'd be able to get it to invoke
> 'env OPERAPLUGINWRAPPER_PRIORITY=0 opera'
> instead of just 'opera' (keep any other parameters it might have on the
> end of that)
The command invoking Opera on my system (Mint 7) is 'opera %u'. Should I
change it to: 'env OPERAPLUGINWRAPPER_PRIORITY=0 opera %u'?
--
> <(((°> ceed
TimC
was almost, but not quite, entirely unlike tea:
Yep, looks right. Give it a shot.
As Eirik said elsewhere, this is only for 9.*, and not 10.* as in the
latter case, someone said it appears to keep a priority of 0 already
(I haven't checked myself).
--
TimC
Yay! I have found the last bug bug bug bug bug bug bug
bug bug bug bug bug bug bug bug bug bug bug bug bug bug
bug bug bu%$@#$@#%$@# Error: Missing Carrier Signal
Tony
this case.
You have to renicre opera
PID!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
"sudo renice 19 xxxx" (where xxxx is your opera PID) and then it will
work. Sometimes theres two PIDs with opera and then you have to renice
both. Don't touch operapluginwrapper!!! It so simple. Trust me.
This problem was solved in Opera 10.
BTW, operapluginwrapper in Opera 9 doesn't show real CPU usage.
Eirik Byrkjeflot Anonsen
> Changing operapluginwrapper priority doesn't solve your problem in
> this case.
> You have to renicre opera
> PID!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
> "sudo renice 19 xxxx" (where xxxx is your opera PID) and then it will
> work. Sometimes theres two PIDs with opera and then you have to renice
> both. Don't touch operapluginwrapper!!! It so simple. Trust me.
That doesn't really make much sense to me. If you renice opera to have
a lower priority than the pluginwrapper and opera has high cpu usage, I
can see how this can work. Otherwise, I'd think that keeping the
pluginwrapper at default priority would be more effective than lowering
opera's priority to the same as the pluginwrapper.
> This problem was solved in Opera 10.
> BTW, operapluginwrapper in Opera 9 doesn't show real CPU usage.
???
Do you mean that the system tools for monitoring cpu usage does not show
the pluginwrapper using much cpu, but you believe the pluginwrapper
really does use quite a lot of cpu?
On a classic linux system it is certainly possible for a plug-in to do
this, but I would think it is unlikely to happen by accident and it
seems pointless to do it on purpose. And it should depend heavily on
which plug-in you are running. The pluginwrapper usually does very
little on its own. I would expect almost all the cpu time in the
pluginwrapper is spent by the plug-in.
eirik