There's something wrong with mplayer

Army · 2010-07-03 17:08:37

Hi

Ionut Biru is the current packer of mplayer and he updates it very regularly, which is really great, because only a short while ago mplayer was terribly out of date. But unfortunately mplayer seems to have become really worse the past few weeks. I noticed it especially with 720p videos (encoded with h264), which use about half the power of my laptop, so they usually run fine (1080p videos are a bit too much though). And I use mplayer as my tv application, there are stuttering problems as well (yes even with these low resolutions).

What happens is, that these 720p videos don't run flawlessly anymore. It's not a dia show, but I get interruptions about every second. Taking a look at the cpu usage really disturbs me, because it's not even close to the maximum. So the problem MUST be mplayer. The revision I'm talking about is the current one, 31428. Fortunately I found an earlier version of mplayer, 31040, which I compiled with the very same configure options and now all videos run fine again. (I know I can get every revision via svn, but this 31040 source tree was used by Ionut in an earlier version, so I really wanted to compare to this one).
I didn't have the chance yet to test tv, but I guess this might be solved as well.

So my questions are, do other users have the same problems? And Ionut, how much testing do you do on those regularly updated packages? Do you also think that maybe these regular updates might be a bit to much? How about putting them in testing first, so everyone can check if there are problems? As said above, I really prefer such regular updates, but in case upstream breaks things, this might not be the right way.

Last edited by Army (2010-07-03 17:09:35)

Army · 2010-07-03 17:13:46

Almost forgot, even this earlier revision sucks with 720p videos compared to vlc :-( (I use vlc-nogui from AUR, because ... I don't need a gui)

karol · 2010-07-03 17:31:22

I think the packages should go through testing.
Army, do you have testing enabled? If so, did you post earlier about this regression?

Army · 2010-07-03 17:52:22

Yes I have testing enabled. But afair mplayer, ffmpeg etc don't go through testing (they are in [extra], so they don't have to).

I can't remember having posted about this before, no.

karol · 2010-07-03 18:12:10

So the only testing [extra] goes through is ... what? "Works for me" from the maintainer?
http://wiki.archlinux.org/index.php/Dev … ge_Testing

I don't know if you know, but you can use http://arm.kh.nu/search/ w/o compiling packages yourself.

W/o [testing] you need to ping-pong up- and down-grading the packages (as it was the case w/ mplayer and internet radio streams). [testing] would help only if there are many people using it. If not, you have to set up your own staging system and upgrade your main / production box only if you're sure everything works. You can set up your own little testing suite:
- do pdfs work: fonts rendering, continuous pages etc.
- movies: mp4, [other formats], low res, hi-res, fullHD etc.
...

litemotiv · 2010-07-03 18:21:58

Army wrote:

So my questions are, do other users have the same problems?

i can confirm the stuttering on a vdpau machine with 2-3% cpu load. file a flyspray report for this please..

wonder · 2010-07-03 18:52:26

i do use them one day before uploading in repos. most problems come from upstream and should be reported on their bugtracker or on mailing list.

in the latest version they changed demuxer for mkv and ogg to the internal ffmpeg and this seems to cause a lot of problems. they suggest to report this kind of problems and as a workaround to change back to mkv.

http://www.mplayerhq.hu/design7/news.html

personally i prefer bumping once a month x264/ffmpeg/mplayer to have the latest optimization and features.

Last edited by wonder (2010-07-03 18:55:08)

karol · 2010-07-03 19:19:51

> i do use them one day before uploading in repos.
Define "use". How do you test it?

wonder · 2010-07-03 19:22:56

karol wrote:

> i do use them one day before uploading in repos.
Define "use". How do you test it?

watching movies?

Army · 2010-07-03 19:30:59

But if there are problems with the up to date version, I think it would be better to wait with an update. Or does the current version of mplayer in the repos work flawlessly for you? If I understand this correctly, it doesn't really depend on the hardware (e.g. which graphic card you have) or which vo driver you use.

karol wrote:

I don't know if you know, but you can use http://arm.kh.nu/search/ w/o compiling packages yourself.

Yes I know that there's this possibility, but then I would have to downgrade the dependencies as well (e.g. libx264) which would all in all lead to a crappy system. Compiling mplayer doesn't take that long, so that's not really a problem.

karol · 2010-07-03 19:32:48

> watching movies?
So it's a "works for me" basis. Any plans to change that to a more comprehensive review (streaming, fullHD etc,?). I'm not demanding anything and I don't mind testing the apps I need myself, I'm just asking.

wonder · 2010-07-03 19:36:35

karol wrote:

> watching movies?
So it's a "works for me" basis. Any plans to change that to a more comprehensive review (streaming, fullHD etc,?). I'm not demanding anything and I don't mind testing the apps I need myself, I'm just asking.

the current mplayer works flawless for me using vdpau. i have some full hd 1080 videos that work perfectly.

if you have problems with this package, just use abs and get an older snapshot. all of them are available on ftp and i'm not going to delete them soon.

like i said earlier, problems should be reported upstream. nobody would fix problems if they aren't reported

Last edited by wonder (2010-07-03 19:38:46)

karol · 2010-07-03 19:43:35

> the current mplayer works flawless for me using vdpau
That's why a wider hardware base for testing would be welcome. Don't look at me - I have a 6yo box and I have to keep several IgnorePkgs, otherwise X freezes every 30 mins on avg.

If I have problems I report in the Arch bugtracker or directly upstream.

wonder · 2010-07-03 19:50:07

karol wrote:

> the current mplayer works flawless for me using vdpau
That's why a wider hardware base for testing would be welcome. Don't look at me - I have a 6yo box and I have to keep several IgnorePkgs, otherwise X freezes every 30 mins on avg.
If I have problems I report in the Arch bugtracker or directly upstream.

on the arch bugtracker and post the link to the upstream bug report to follow it

litemotiv · 2010-07-03 20:31:30

consider me jaded, but i don't think reporting bugs like this upstream should be the way to go. it takes quite some more time communicating on 2 different reports (arch + upstream), and software like mplayer is used so much that bugs like this will be reported very quickly upstream anyway. so instead we report here (flyspray), our maintainer has the opportunity to downgrade if he receives enough reports or +1's. if he doesn't want to downgrade that's his decision. for a package in extra i think this isn't too much asked, the alternative of reporting upstream means our end users will have to manually compile several upstream versions from source to see if the problem is fixed (upstream will require that obviously), then report back here so our own maintainer can rebuild it again once more. all in all we probably won't have a working binary version much sooner.

kudos to ionut and the other maintainers though, i know you have a busy agenda. but for large packages like mplayer+deps this is a bit too much diy in my opinion.

karol · 2010-07-03 20:45:45

litemotiv wrote:

kudos to ionut and the other maintainers though, i know you have a busy agenda. but for large packages like mplayer+deps this is a bit too much diy in my opinion.

If the package works, fine. If it doesn't, I report a bug and downgrade / compile my own. Arch makes it easy enough for me + there are -git versions from upstream, there's AUR w/ many prêt-à-porter PKGBUILDs and there's ARM.

I can wait for the latest features if it means smoother transition.

MreDD · 2010-07-24 03:12:31

are you using this in your config
heartbeat-cmd="xscreensaver-command -deactivate"
?
seems this is what causes my freezes.

https://bbs.archlinux.org/viewtopic.php?pid=511469
from that thread just changing it to
heartbeat-cmd="xscreensaver-command -deactivate &"
stops the freezes, and it worked for me

Last edited by MreDD (2010-07-24 03:30:56)

Army · 2010-07-27 22:14:21

I've been using mplayer-git from the AUR for a while now and it's really better! Does anyone of you guys use this? I have only one problem with it, playing an audio file with mplayer-git doesn't allow me to pause the playback with the space key, I can't scroll with the arrow keys etc. The only thing that works is quitting with enter. I tried it with the same compiling options as used in the official mplayer package, but still it doesn't work. Does it work for any of you guys who also use mplayer-git? If not, I'll contact the author.

R00KIE · 2010-07-27 23:23:56

I have also noticed that maybe the last 2 or 3 releases of mplayer do not work 100% with ssa subtitles embedded on mkv files, the subtitles show up at the correct time but do not go away until the next subtitle comes up, maybe the cause is the same.

jarda-wien · 2010-11-20 17:37:00

I have the same problems with mplayer. The video just stutters for a few seconds from time to time. The cpu usage is fairly low the whole time. It doesn't depend on the video driver either, as I have the same issues with xf86-video-ati and xf86-video-intel on another machine. The first being a laptop and the other one a very slow and low-ram sattelite receiver that I use to play films over lan on tv.

I'll just try to build mplayer-svn from AUR and see if it helps.

I am going to switch to vlc and wait until mplayer is fixed, as I am not very fond of keeping a special package version that is not broken.

I am just wondering why there are not more people reporting about this. The stuttering is not just barely noticeable, it is quite annoying!

jarda-wien · 2010-11-23 17:09:59

I have to confirm that mplayer-svn has exactly the same issues with a fluent video playback.

jarda-wien · 2010-11-23 18:37:12

I just found something else:
1, scrolling a page in chromium makes the video and audio playback of a mkv or even avi file in mplayer hang.
2, none of this happens in vlc (even though both have the same niceness).
3, scrolling a webpage in either midori/opera/seamonkey/firefox/firefox-beta doesn't affect playback.
4, running dmenu via a subtle (tiling-wm) hotkey does hang playback the same way scrolling in chromium does.
5, mplayer appears to have a higher cpu usage: vlc/mplayer usage on avi - 10%/15%, sdtv mkv - 20%/30% (both are set to use xvideo and no audio or video postprocessing whatsoever).

All test vere run on a Thinkpad T41, Pentium M 1.6GHz, 1.5GB RAM, Radeon 7500 using the radeon driver.

I am not sure what to do whith this info though. Some of it might be related to the problem in this thread, some not...

Army · 2010-11-23 21:48:36

Using mplayer-git really solved this problem for me, I like this fork far better. I threw out almost everything I don't need ("almost" because there are things left which can be thrown out, but I'll have to investigate a little further). Here's my PKGBUILD for inspiration

# Contributor: Laochailan <laochailan@web.de>
pkgname=mplayer-git
pkgver=20101120
pkgrel=1
pkgdesc="Mplayer from Uoti's git repository"
arch=(i686 x86_64)
url="http://repo.or.cz/w/mplayer.git"
license=('GPL')
depends=('freetype2' 'libdvdread' 'libxinerama' 'libxv' 'libxss' 'ffmpeg' 'faad2' 'libcdio')
makedepends=('git')
provides=(mplayer)
conflicts=(mplayer)
backup=('etc/mplayer/codecs.conf' 'etc/mplayer/input.conf')

_gitroot="git://repo.or.cz/mplayer.git"
_gitname="mplayer"

build() {
    cd "$srcdir"
    msg "Connecting to GIT server...."
    
    if [ -d $_gitname ] ; then
        cd $_gitname && git pull origin
        msg "The local files are updated."
    else
        git clone $_gitroot $_gitname
    fi
    
    msg "GIT checkout done or server timeout"
    msg "Starting make..."
    
    rm -rf "$srcdir/$_gitname-build"
    git clone "$srcdir/$_gitname" "$srcdir/$_gitname-build"
    cd "$srcdir/$_gitname-build"
    
    ./configure --prefix=/usr \
        --disable-runtime-cpudetection \
        --disable-termcap \
        --disable-smb \
        --disable-faad-internal \
        --disable-faac \
        --disable-aa \
        --disable-lirc \
        --disable-lircc \
        --disable-speex \
        --disable-jack \
        --disable-theora \
        --disable-libvorbis \
        --disable-pulse \
        --disable-vdpau \
        --disable-arts \
        --disable-liblzo \
        --disable-libdv \
        --disable-musepack \
        --disable-gif \
        --disable-liba52 \
        --disable-vm \
        --disable-xf86keysym \
        --disable-nas \
        --disable-live \
        --disable-nemesi \
        --disable-unrarexec \
        --disable-fribidi \
        --disable-enca \
        --disable-maemo \
        --disable-w32threads \
        --disable-directfb \
        --disable-ladspa \
        --disable-ossaudio \
        --disable-dga2 \
        --disable-vidix \
        --disable-xanim \
        --disable-esd \
        --disable-gl \
        --disable-gui \
        --disable-openal \
        --disable-mga \
        --disable-dvb \
        --disable-dvdread-internal \
        --disable-libdvdcss-internal \
        --disable-cdparanoia \
        --disable-cddb \
        --disable-fontconfig \
        --disable-ass \
        --disable-tremor-internal \
        --disable-png \
        --disable-mng \
        --disable-mad \
        --disable-win32dll \
        --disable-qtx \
        --disable-real \
        --disable-xvid \
        --disable-libnut \
        --disable-mp3lame \
        --disable-mpg123 \
        --yasm=yasm \
        --language=en \
        --confdir=/etc/mplayer

    [ "$CARCH" = "i686" ] &&  sed 's|-march=i486|-march=i686|g' -i config.mak
    
    make || return 1
    make -j1 DESTDIR="$pkgdir/" install
    
    install -Dm644 etc/{codecs.conf,input.conf,example.conf} ${pkgdir}/etc/mplayer/ || return 1
    install -dm755 ${pkgdir}/usr/share/mplayer/
    rm -rf ${pkgdir}/usr/share/mplayer/font
}

Arch Linux

#1 2010-07-03 17:08:37

There's something wrong with mplayer

#2 2010-07-03 17:13:46

Re: There's something wrong with mplayer

#3 2010-07-03 17:31:22

Re: There's something wrong with mplayer

#4 2010-07-03 17:52:22

Re: There's something wrong with mplayer

#5 2010-07-03 18:12:10

Re: There's something wrong with mplayer

#6 2010-07-03 18:21:58

Re: There's something wrong with mplayer

#7 2010-07-03 18:52:26

Re: There's something wrong with mplayer

#8 2010-07-03 19:19:51

Re: There's something wrong with mplayer

#9 2010-07-03 19:22:56

Re: There's something wrong with mplayer

#10 2010-07-03 19:30:59

Re: There's something wrong with mplayer

#11 2010-07-03 19:32:48

Re: There's something wrong with mplayer

#12 2010-07-03 19:36:35

Re: There's something wrong with mplayer

#13 2010-07-03 19:43:35

Re: There's something wrong with mplayer

#14 2010-07-03 19:50:07

Re: There's something wrong with mplayer

#15 2010-07-03 20:31:30

Re: There's something wrong with mplayer

#16 2010-07-03 20:45:45

Re: There's something wrong with mplayer

#17 2010-07-24 03:12:31

Re: There's something wrong with mplayer

#18 2010-07-27 22:14:21

Re: There's something wrong with mplayer

#19 2010-07-27 23:23:56

Re: There's something wrong with mplayer

#20 2010-11-20 17:37:00

Re: There's something wrong with mplayer

#21 2010-11-23 17:09:59

Re: There's something wrong with mplayer

#22 2010-11-23 18:37:12

Re: There's something wrong with mplayer

#23 2010-11-23 21:48:36

Re: There's something wrong with mplayer

Board footer