This forum is deprecated. Please visit https://github.com/smplayer-dev/smplayer/discussions

Is this Stones vid messed up or wrong SMP setting?

Problems, bugs, suggestions... anything related to SMPlayer.

Is this Stones vid messed up or wrong SMP setting?

Postby brittney24 » Mon Jun 24, 2013 2:20 am

Most music vids play fine. Not this one. Not sure if it's the file or incorrect settings. I made some adjustments, but didn't solve problem of stuttering / pausing.
Stones - Wild Horses http://www.youtube.com/watch?v=A--h9i3SwYM
Someone w/ fast enough connection & computer, who watches HQ steaming vids, could check it & see if it works. Or make suggestions.

I watch 1920 x 1080 HQ downloaded vids all the time - no issue. Seems to be problem w/ not caching enough on this one.
Increased cache to 8192 KB, as mplayer log suggested; then to 10,000 - still stutters a bit; stops & shows buffering. I consistently get ~ 2500 KiBi DSL d/l speed, so w/ a cache of 10 k KB, I'd think that's enough.

I'm using SMP 0.8.5r5473 x64 portable on Vista x64.
Nearly 5 GB RAM available.
Core 2 Q9400 2.66 GHz
Have a pretty decent 1GB GPU
SMP Performance priority set = high
enabled frame drop

Thanks.
Can't we all just get along? If a computer crashes when no one's around, does it make a sound?
brittney24
 
Posts: 148
Joined: Wed Jun 27, 2012 3:37 pm

Re: Is this Stones vid messed up or wrong SMP setting?

Postby brittney24 » Mon Jun 24, 2013 8:22 pm

I increased the cache to 20k KB, then played same vid, while watching the d/l volume. That helped a lot, but didn't completely solve issue of buffer running empty. Now, seems the d/l volume stays maxed out at my connection limit during play, after initial buffering.

So, apparently even starting w/ a 20 MB cache, for an HQ vid, is not enough of a head start, w/ my consistent DSL speed of ~ 2600 kbps (~ 313 KB/s).

Unless I'm completely wrong on this, appears w/ a connection like mine - for HQ vids, I'd have to set SMP cache to some huge # (40 - 60 - 100k KB), or just d/l the entire vid before playing.

I also used a different video output - gl3 (in mplayer2) - that may be a bit faster than default Direct3D.

The mplayer log errors of "Your system is too slow," "don't try to play big files on a slow CPU," "try setting cache to 8192" - are completely inaccurate. Nothing slow about my CPU / GPU & appears mplayer / mplayer2's log - suggested cache = 8192 isn't in the ball park to stop buffer from emptying. Mplayer has no way to see the connection d/l speed?, therefore no ability to suggest an accurate cache size to not run out of buffer.
Can't we all just get along? If a computer crashes when no one's around, does it make a sound?
brittney24
 
Posts: 148
Joined: Wed Jun 27, 2012 3:37 pm


Return to General

Who is online

Users browsing this forum: No registered users and 20 guests