Bug 111969 – mplayer-1.0_pre7-r1 plays the video in some mpeg files faster than the audio

• Product: Gentoo Linux
• Status: VERIFIED FIXED

[Description Alexandru Toma 2005-11-09 07:11:50 UTC]

mplayer seems to have some problems with some mpeg files (get either chin1.mpeg
or chin2.mpeg from the URL). It plays the video stream a lot faster than the
audio stream, which is played at normal speed. As a result the video and audio
get out of sync.

I have tried the following video codecs (with -vc) and all of them have this
problem:
mpeg12 (the default)
ffmpeg1
ffmpeg12

The strange thing is that ffplay (from ffmpeg) plays these video just fine even
if it plays them at double the resolution for some reason. The video and audio
never get out of sync though, which makes me think that this is a mplayer problem.

Please note that I have also tried plaympeg and gtv from media-libs/smpeg and
they also have problems playing those files but, as I said above, ffplay plays
them just fine.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.




[ebuild   R   ] media-video/mplayer-1.0_pre7-r1  -3dfx +3dnow +3dnowext +X +aac
+aalib +alsa (-altivec) -arts -bidi -bl -cdparanoia +cpudetection -custom-cflags
-debug -dga -directfb -doc +dts -dv -dvb +dvd +dvdread -edl +encode -esd -fbcon
-ggi +gif +gtk -i8x0 -ipv6 -jack -joystick +jpeg +libcaca -lirc -live +lzo +mad
+matroska -matrox +mmx +mmxext -mythtv -nas +nls -nvidia +opengl -oss +png +real
+rtc -samba +sdl +sse -sse2 -svga +tga +theora +truetype -v4l -v4l2 +vorbis
+win32codecs -xanim -xinerama +xmms +xv +xvid -xvmc 0 kB

[ebuild   R   ] media-video/ffmpeg-0.4.9_p20050906  +a52 +aac (-altivec) -debug
-doc +dts +encode -ieee1394 +imlib +mmx +network +ogg -oss +sdl -test +theora
-threads +truetype -v4l +vorbis +xvid +zlib 0 kB

Portage 2.0.51.22-r3 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2,
2.6.13-gentoo-r3 i686)
=================================================================
System uname: 2.6.13-gentoo-r3 i686 AMD Athlon(tm) XP 1800+
Gentoo Base System version 1.4.16
dev-lang/python:     2.3.4-r1, 2.4.2
sys-apps/sandbox:    1.2.10
sys-devel/autoconf:  2.13, 2.59-r6
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r1
sys-devel/binutils:  2.15.92.0.2-r10
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config
/usr/lib/X11/xkb /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-march=athlon-xp -O2 -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="ftp://ftp.roedu.net/pub/mirrors/gentoo.org http://gentoo.osuosl.org"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://rsync2.ro.gentoo.org/gentoo-portage"
USE="x86 3dnow 3dnowext X aalib alsa apm audiofile avi bitmap-fonts bzip2 cdr
crypt cups curl dts eds emboss encode exif expat fam ffmpeg flac foomaticdb
fortran gd geoip gif glut gphoto2 gpm gstreamer gtk2 guile idn imlib imlib2
jikes jpeg lcms libcaca libwww lua lzo mad matroska mhash mikmod mmx mmx2 mmxext
mng motif mp3 mpeg mysql ncurses network nls no_wxgtk1 ogg oggvorbis openal
opengl pam pcre png postgres python quicktime readline rtc ruby sdl slang spell
sse ssl tcpd tga theora tiff truetype truetype-fonts type1-fonts udev unicode
usb vorbis wmf xchatdccserver xml2 xmms xprint xv xvid zlib userland_GNU
kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, MAKEOPTS

[Comment 1 Luca Barbato 2005-11-09 12:35:48 UTC]

I think that those files are corrupted, I'll try to contact upstream about them

[Comment 2 Alexandru Toma 2005-11-09 13:48:02 UTC]

> I think that those files are corrupted, I'll try to contact upstream about them

Hmm... In that case why does ffmpeg (ffplay) play them well and mplayer (using
ffmpeg) doesn't?

By the way, I don't know if it's useful, but the files were created using
Honestech MPEG Encoder 2.0 - http://www.divx-digest.com/software/honestech.html
... you can see that by looking in the files, just after the header.

[Comment 3 Alexandru Toma 2005-11-09 14:34:20 UTC]

I've just played those files on Windows XP without problems. I used Media Player
Classic (which uses codecs) and VLC Media Player for Windows (which doesn't use
codecs but I don't know what library it uses for MPEG playback).

On both programs the playback was flawless so this looks more and more like a
mplayer bug to me. SMPEG also seems to have the same bug.

[Comment 4 Luca Barbato 2005-11-10 06:59:10 UTC]

Please report the bug in the mplayer-user ml, I'll check the files with the
upstream devs once I have the change.

[Comment 5 Alexandru Toma 2005-11-10 10:14:15 UTC]

http://mplayerhq.hu/pipermail/mplayer-users/2005-November/056552.html

From the email:

"After that I also tried Xine and it played chin1.mpeg extremely jerky and
chin2.mpeg a little jerky, but the important thing is that the video and
audio tracks stayed in sync. I haven't yet tried VLC on Linux for various
reasons but I suspect it would behave like the windows version."

So Xine, which also uses ffmpeg for playback, seems to be fine. I couldn't try
VLC because of bug #112086

> I'll check the files with the upstream devs once I have the change.
Did you mean _chance_ there? If not what exactly did you mean because I didn't
quite understand that?

[Comment 6 Alexandru Toma 2005-11-10 12:22:43 UTC]

http://mplayerhq.hu/pipermail/mplayer-users/2005-November/056554.html

Problem solved. Still, it is obvious that mplayer does some things differently
from other similar programs. That is not necessarily a bug though, so I'm
closing this.

[Comment 7 Luca Barbato 2005-11-10 18:24:55 UTC]

yes was "chance" and well, I still think that the problem is in the encoder.