Please Upgrade Mplayer

I notice on the Intrepid repo atleast, that dependencies are wrong with mplayer and gnome-mplayer. For some reason libx264-57 2007-12-74 is auto installed instead of the better later version which is named libx264-5920080408. I think it would be better to use one libx264 package so that when it is updated all the other packages that use it can also be automatically upgraded to the new revision.

Also there is atleast four unpatched security vulnerabilities resolved since rc2 was released back in 07/10/2007. Some details are found on http://www.mplayerhq.hu/design7/news.html but I suspect there is other security issues resolved in SVN.

I patched all of those in all releases months ago.

Not confirmed. I don't have any good reason to do this.

Sorry, but thats complete nonsense William and I'm flawed that you honestly consider that to be the case.

The development model of ffmpeg is that they do not "do" releases. What ffmpeg does is to continually update the code and refer any bug reports to "use the latest svn and see if it's still a problem". That is the standard response.

There has been *massive* changes in ffmpeg since Ubuntu last caught up with ffmpeg's SVN. Some of the highlights include:

* Fixing tracking theora / ogg movies so that the Ubuntu Experience ogg file supplied with mplayer has correct seeking
* Many, many improvements to the AVC / H.264 decoder which is seeing more and more prevelance as a common video standard
* Addition of new demuxers and decoders for greater format support

When it comes to mplayer, they in turn have problems doing releases due to their reliance on ffmpeg in mplayer. The last release candidate that mplayer "released" is ancient. Again, like ffmpeg, mplayer take the standard approach of forcing users to update to the latest svn.

There is also *many* fixes in mplayer svn that arent in the Ubuntu build.

Mplayer is the best video solution on Linux because:

* it supports the most formats
* it offers the best performance
* it is robust to video errors
* it is heavily supported in mplayer and in turn ffmpeg by developers around the world

William Grant:

If you are the maintainer, that is fair enough.

However, if this report has, in your view, no merit whatsoever, please don't keep the uninformed users hanging by reverting this to "New", giving any false hopes about mplayer in Ubuntu.

In other words, if you are not going to upgrade mplayer, please mark this report as "Invalid", so the users clearly know what's the deal, and know to rely on other options.

It's especially odd given that Ubuntu has, several times in the past, shipped with an item in main which hadn't officially been 'released' - and certainly wasn't stable. See NM back in... either breezy or dapper? Firefox in Hardy...

I'm unsure, given the development model of mplayer / ffmpeg and given that it is not a 'required' package from a default install, why it is kept a year old.

An explanation would be sufficient though.

William Grant:

This report should be either Confirmed or Invalid, because it definitely fulfills the criteria for Confirmed. As detailed in the Ubuntu wiki:
https://wiki.ubuntu.com/Bugs/Responses#Triage Successful
"Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!"

And:
https://wiki.ubuntu.com/BugWorkflow
"Confirmed: Contains enough information, presented well enough, for a developer to start fixing the bug."

That, this report definitely does contain - all that is asked for is a newer version. (Even justifications for the version upgrade request are provided, but technically that doesn't make a difference.)

Because of this, I am going to re-confirm this. Please do not revert the status to New, but instead either let it be or reject it properly: "Rejected: Either it is not a bug, or it is a bug that will not be fixed in this particular place."

FYI, the latter document also states the following:
"Current plans are to introduce a "Won't Fix" status, which would mean that the bug is valid but is not going to be fixed in that particular place." Before that, Rejected/Invalid is going to be used instead.

William,

As the developer of gnome-mplayer I get several bugs with regards to subtitles and other weirdness. Most of those issues are solved by getting a newer version of mplayer. By not upgrading this package to something more recent you are actually creating more problems for users and developers.

As stated above the mplayer team does not do releases and recommends using SVN. I know this causes more work for you as a packager, but even doing a monthly or quarterly release even with a package name of 'mplayer-svn' would be helpful. That way the people that want a 'stable' mplayer can use mplayer and those that want one that actually works, can track a newer package.

Thanks,

Kevin

Kevin DeKorte <email address hidden> writes:

> As stated above the mplayer team does not do releases and recommends
> using SVN. I know this causes more work for you as a packager, but even
> doing a monthly or quarterly release even with a package name of
> 'mplayer-svn' would be helpful. That way the people that want a 'stable'
> mplayer can use mplayer and those that want one that actually works, can
> track a newer package.

The documented procedure is to update the package first in the unstable
branch of ubuntu (currently jaunty) and then have it included in the
-backports repository.

Introducing mplayer-svn would introduce an inappropriate additional
maintenance overhead.

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

Reinhard, if the ffmpeg svn is allowed in the main repo, then mplayer svn should be allowed too.

Currently my mplayer gives the same error as described in this bug:
https://bugs.launchpad.net/ubuntu/+source/ffmpeg/+bug/318445

But since ffmpeg in jaunty is new, ffmpeg is actually fixed. But I still can't play the file in mplayer, because it's old and isn't linked against the new ffmpeg.

I realize linking against ffmpeg shared libs is problematic because they break API/ABI compatibility often. But having to convert the H264/AAC flv file to another container is quite ridiculous.

What's the reasoning behind not updating mplayer?
MPlayer 1.0rc2 may be the most recent actual release but the following page states that is isn't supported because it's outdated...
http://www.mplayerhq.hu/design7/dload.html
Surely ubuntu should be using supported versions of the software in the repos if one is available.

SMPlayer now complains about a too old MPlayer in Jaunty. Please downgrade SMPlayer or upgrade MPlayer.

For anyone who hasn't already discovered this there are packages of more recent MPlayer snapshots as well as SMPlayer and dependancy libraries in PPAs described here...

http://smplayer.berlios.de/forums/viewtopic.php?id=1139

This bug was fixed in the package mplayer - 2:1.0~rc3+svn20090426-1ubuntu1

---------------
mplayer (2:1.0~rc3+svn20090426-1ubuntu1) karmic; urgency=low

  * Switch to debian packaging for the mplayer package
  * New upstream release, LP: #336697, #260918, #246675, #243453, #74282
  * Fixes security issues: CVE-2008-5616, LP: #308939
  * many flv fixes LP: #73271, #347021
  * Build and install mencoder
  * Bump epoch

mplayer (1.0~rc3+svn20090426-1) unstable; urgency=low

  [ fabrice ]
  * Introduce the mplayer-nogui package, that does not depend on GTK+

  [ Reinhard Tartler ]
  * new upstream svn version based on the 1.0rc3 branch
  * various cleanups and refactoring in debian/rules
  * no longer remove mencoder.c: It does hardly contain any "dangerous"
    or patented code. Instead:
  * strip libavcodec similar to how its done in the ffmpeg package. This
    brings the patent policy of the mplayer and ffmpeg package in debian
    finally in sync. c.f. the comments and the "discussion" in #522373.
  * install upstream's version of binary_codecs.sh

mplayer (1.0~rc3+svn20090405-1) unstable; urgency=low

  * New upstream version. Track the 1.0rc3 release branch for now.
  * remove 50_r28803_segfault_print_int.patch, merged upstream.
  * no longer remove the TOOLS subdirectory from the upstream source.
  * make get-orig-source rule actually work.
  * disable musepack support. Closes: #476384
  * completely delegate handling of /etc/mplayer/mplayer.conf to
    dpkg. This change removes also all debconf templates and reduces
    package complexity.
  * move .gbp.conf to debian/gbp.conf
  * cleanups in debian/rules: prefer external debhelper helper files
  * enhance upstream Makefile to install gmplayer manpages
     - implement as quilt patch, submitted upstream
     - debian/rules: make use of the added rules
  * use dh_prep instead of dh_clean -k
  * bump Standards-Version to 3.8.1

mplayer (1.0~rc2+svn20090303-7) unstable; urgency=low

  * various cleanups in debian/rules.
  * as a side effect, DEB_BUILD_OPTIONS set to noopt no longer works. It
    really needs to be implemented in ./configure instead of weird hackery
    in debian/rules. patches welcome.
  * run 'make distclean' only of config.mak exists.
  * remove debian/control.mplayer* variants.
  * don't --enable-debug on mipsen. This hopfully fixes the FTBFS on mipsen.

mplayer (1.0~rc2+svn20090303-6) unstable; urgency=low

  [ A Mennucc1 ]

  * use ./configure flags to dynamically link FFmpeg,
    delete patch 30link-system-ffmpeg.patch

  [ Reinhard Tartler ]

  * cleanup debian/rules: use --enable-debug on all architectures but mips.
    in order to fix a FTBFS. This results in making the -dbg package on mips
    useless. If you are interested in having a usable mplayer-dbg package on
    mips, please try enabling that switch in debian/rules and send us your
    buildlog!
  * run 'make distclean' only of config.mak exists
  * cleanup debian/rules: remove unnecessary clean statements

mplayer (1.0~rc2+svn20090303-5) unstable; urgency=low

  * debian/control : move docbook-xml,docbook-xsl,xsltproc from
    Build-Depends-Indep to Build-Depends, since they are needed to run
    config...