Linux Mint Forums

I have a recent install of Mint 14 Cinnamon on workstation 2 listed in my signature. Playing a 720p h264 animation that is very busy as a test sequence, I have observed over the past few years continuous video rendering improvement under Ubuntu 10.04.1, particularly with SMPlayer, to the point where smooth, pixelation free playback was normal. Now having changed to Mint, there seems to be a subtle step backwards. SMplayer, Gnome-mplayer, and Videolan player all exhibit a video rendering behavior of about 3 seconds normal with a brief sub second pause. I do not see obvious dropped frames, although that could happen under the held frame. I have experimented with having the CPU cores run on-demand and full performance. Various combinations of cache increases up to many minutes worth of video have been tried, along with h264 rendering changes (mostly blind). Desktop effects have been turned off. None of these has had any effect on the hesitation with any of the three video players. There is no hesitation in the audio. The hesitation period and duration seems to my eye to be independent of the choice of player or anything I do.

I observe that with nothing visible calling for more processing power than maintaining the display of this window, the CPU cores randomly jump to 3.4 GHz (full speed) in the on-demand mode. However, these jumps do not seem to be periodic at the rate of video hesitation.

Suggestions to eliminate the hesitation are welcomed.

Thanks

kirby

I should add that streaming video from Cruchyroll using Firefox has the same issue. I'm uncertain what tool Firefox uses for video rendering in this case, but surely some Mint force majeur is interrupting the processing for these varied operations to show the same hesitation pattern.

{Edit] Totem does the same thing playing .flv video clips, and SMPlayer, even after caching 20% of the file, does the same playing YouTube videos.

It is hard to believe that I didn't notice this until today, which raises the question of whether one of the updates installed today are involved.

kirby

I recalled last night that under Ubuntu 10.04.1 I had solved some video issues that showed up after updating by reinstalling whichever player I was using, and decided to experiment with that approach today. It appears to still be needed.

Best results so far involve removing VLC, smplayer, and gnome-mplayer and reinstalling smplayer. (Note that this cannot be a controlled experiment because I cannot easily restore the initial conditions for various combinations of players and the post-update state.) Rebooting variously occurred during the period of the experiments, but was probably not needed. With just smplayer (and totem that I didn't mess with) residual hesitation is barely at the threshold of perception. This removal and reinstall also fixes totem hesitation (I have no idea why). If VLC is also reinstalled, it shows very slight hesitation after the install, whereas it was significant at the time of post 1. With both smplayer and VLC, the smplayer hesitation may be slightly greater than without VLC, but this judgement is too sensitive to error to treat at fact. Hesitation with VLC player alone seemed to be slightly more perceptable than with smplayer alone. Either, however, or the combination, is much, much better than before.

HTH

kirby

This approach is not always successful and doesn't remain successful when it works. However, I did find in nVidia settings a three-second parameter related to memory that I disabled. The clue was nVidia settings jumping into and out of existence in the system information processes list. Although disabling that 3-second activity had no immediate effect, uninstalling the video players, rebooting and reinstalling only one player (VLC this time) has reduced the effect to barely perceptible. It remains to determine if that condition lasts.

If the nVidia settings parameter is the issue, then it shoudn't matter how many players are installed. It is hard to believe, though, that nVidia sampling its memory use would have a material effect on play.

kirby

KirbySmith wrote:However, I did find in nVidia settings a three-second parameter related to memory that I disabled.

What was that parameter and how was it disabled?

Open 'NVIDIA X Server Settings,' reached via Menu/Administration. In the version provided with the 304.84 drivers, and I expect most other recent drivers, the last line should show 'nvidia-settings Confirguration.' (nVidia sotware writers aren't big on consistent capitalization.) Click on this item and a short list of toggle boxes and entries will appear, under which will bbe a section denoted 'Active Timers.' The top one is 'Memory Used (GPU 0)

I have an NVidea GT220, I unchecked Thermal Monitor and PowerMizer Monitor and the occasional hesitation in full screen flash video is now gone! Great thread! Thanks!

Edit: I did try extending the timers, it was better but unchecking them completely resolved the problem with the GT220.

Glad it helped.

I remain amazed that such an apparently trivial activity (relative to what a GPU can do) would cause a visible video pause.

kirby

exploder wrote:I have an NVidea GT220, I unchecked Thermal Monitor and PowerMizer Monitor and the occasional hesitation in full screen flash video is now gone! Great thread! Thanks!

Edit: I did try extending the timers, it was better but unchecking them completely resolved the problem with the GT220.

It won't stay that way. Read this. Quick and easy fix.

Nice research, catweazel. As it happens my configuration already includes an xorg.conf. The most recent driver set installation to mess with it was 304.51. (now running 304.84) In my case the problem is hesitation (probably including frame dropping during the hesitation), not tearing. However, your solution may be a good one for further solving that problem. I'll report when I have time to test it.

You wrote: "Most of nVidia's new cards now have what is called 'adaptive clocking'." As you can see in my sig, mine are not the latest and greatest, so I want to avoid confusing the driver if the parameters inserted into xorg.conf don't mean anything to it. (I don't recall seeing 'adaptive clocking' mentioned in any accompanying advertising when I bought the cards.)

So my question is: How far back in video card history is your comment valid? Or alternatively, do you know of somewhere at nVidia's site where this is tabulated?

Edit: Duh! If power mizer shows in the menu, as in your image, I suppose that answers my question (unless it shows independently of whether or not adaptive clocking is really present -- mine only shows level 0).

Thanks

kirby

OK, preliminary results are in; nothing worse happened after xorg.conf modification on my Mint/9800GT PC. I had a very minimal hesitation at the start of this experiment due to the other changes, and the hesitation is certainly no worse after the change. It would be hard without side by side comparison to determine whether it was better. The bigger question is how it holds up over a few weeks of software updates.

Since I already had an xorg.conf, I put the critical 'Option' string into the relevant device section. After rebooting, nVidia settings shows the same as before. There is only one performance setting, zero. My present guess is that the nVidia settings GUI provides the button for adaptive processing but for this card there isn't any actual adaptiveness. I will keep this critical information for use with any future video card.

Thanks again, catweazel

kirby

Problem status:

After upgrading to nVidia 304.88 last night, there was no significant hesitation so I didn't reinstall any movie players. The active timer states remained as they were last set. We'll see how long that lasts.

Desktop 2 now using Linux 3.5.0-27-generic (i686)

kirby

KirbySmith wrote:Desktop 2 now using Linux 3.5.0-27-generic (i686)

It might also be worth your testing with 3.5.0-27-lowlatency. I had major pausing in videos when any window was clicked. The low latency kernel stopped it in its tracks.

Ahhh! The catweazel strikes gold, methinks. I didn't know that that version existed. Normally (read: in all previous cases), I just install whatever shows up in the Update Manager hoping to discover some issue is fixed. I'll have to look up the details of manually installing alternative kernels. But first I'll need to find out what the scope of low latency is besides reacting to clicking on windows. My problem has been a repetitive hesitation lasting through a video played from a hard drive or played within Firefox (i.e., streamed video).

Thanks

kirby

KirbySmith wrote:I'll have to look up the details of manually installing alternative kernels.

The kernel can be installed directly from Synaptic. Just select the image and headers.

Indeed it is. Thanks for the clue. It seems selecting it also selects the headers and other stuff.

However, I will have to defer this experiment until next weekend as I won't have time before then to deal with any problems that might arise. Ideally, I should wait until the obvious hesitation comes back before going to the low latency build so I have a qualitative comparison. If the hesitation remains minimal as it is right now, then the low latency build will not show any improvement and I won't know that it fixed anything.

I was able to spend some time earlier today researching the limited information available, and my hope is that with the low-latency build, whatever process gags the video stream will not be able to hold up control of whatever it is controlling (cores are not the only thing the scheduler schedules; memory and bus traffic are also subject to variable latency). But if the offending process is part of the nVidia process that is also playing the video file, then I might not see an improvement.

Thanks again

kirby

Meheheheh! Definitely gold.

"Low-latency" kernel installed without difficulty and became the default after boot without any fuss. [I can't imagine what a pain changing an NT kernel would be; it sure wouldn't have taken me 10 minutes to a fully functional system.]

Testing of various sources, on-hand and on the web show essentially no hesitation. Only in the busiest high-resolution anime with many small objects in motion at once is there even a hint that something wants to take too much time at the 3-second periodic rate. And this is without re-installing smplayer, a ploy that sometimes temporarily works to minimize hesitation. A less exhaustive test with VLC shows similar good behavior. No obvious reductions in general performance are evident so far.

So, kudos to the catweazel!!!

kirby

KirbySmith wrote:So, kudos to the catweazel!!!

Cheers.

Just upgraded to the 3.5.0-28 lowlatency kernel. No apparent deficiencies. Hesitation remains barely perceptible when deliberately looked for, otherwise would not be noticeable.

kirby

A clue at last.

Just installed ksysguard (from a suggestion made to someone on the newbie forum) who noticed that gnome system monitor uses a lot of CPU. Observing via ksysguard the CPU history, all four cores may be seen to operate sinusoidally more or less in syncronism (a better description would be a cosine squared function) from near 10 percent (if Firefox is running, a few percent otherwise) to 20 to 40 percent. The rate of these fluctuations is approximately the rate that I have observed hesitation in video (became minimal with the low-latency kernel). The only process pulling enough core use to cause this is xorg, tending to show 8 - 9 percent in the process table. I assume that that value is an average. No processes with nVidia in the name are present other than briefly. I believe xorg is the culprit. But it may not be the source. Perhaps ksysguard itself induces this effect as it polls the processes. But the hesitation is back in smplayer, and is independent of whether ksysguard is running or not. So I guess it is time to reinstall smplayer. Aargggh!

kirby