New MPlayer release soon
Hi all. I'd like to do a new release of MPlayer, using the soon to be released FFmpeg 2.8. This will be the last FFmpeg release before a lot of old APIs are dropped; since the support in MPlayer for their replacement is very new it would be good to have a stable version in case of problems. Also some features will have to be removed in MPlayer after (eg. XvMC, lavfi ulnless it's rewritten), because of incompatibilities or deprecation. If you have anything that you want to get into the release please speak now and commit it; the same if you want to suggest that something is removed or dropped. Also reports about blocking issues are welcome. I will open some other threads about websites updates and such. Ciao, Roberto
Roberto Togni wrote on Sat, 29 Aug 2015 22:18:00 +0200:
If you have anything that you want to get into the release please speak now and commit it;
I'd like to add bin/cue support to the GUI (currently working on it). Ingo
I wrote on Sun, 30 Aug 2015 11:12:36 +0200:
Roberto Togni wrote on Sat, 29 Aug 2015 22:18:00 +0200:
If you have anything that you want to get into the release please speak now and commit it;
I'd like to add bin/cue support to the GUI (currently working on it).
I'm done. Ingo
On 8/29/15, Roberto Togni <rxt@rtogni.it> wrote:
Hi all.
I'd like to do a new release of MPlayer, using the soon to be released FFmpeg 2.8.
This will be the last FFmpeg release before a lot of old APIs are dropped; since the support in MPlayer for their replacement is very new it would be good to have a stable version in case of problems. Also some features will have to be removed in MPlayer after (eg. XvMC,
Why are you giving XvMC as example?
On Mon, 31 Aug 2015 11:17:15 +0300 Ivan Kalvachev <ikalvachev@gmail.com> wrote:
On 8/29/15, Roberto Togni <rxt@rtogni.it> wrote:
Hi all.
I'd like to do a new release of MPlayer, using the soon to be released FFmpeg 2.8.
This will be the last FFmpeg release before a lot of old APIs are dropped; since the support in MPlayer for their replacement is very new it would be good to have a stable version in case of problems. Also some features will have to be removed in MPlayer after (eg. XvMC,
Why are you giving XvMC as example?
No special reasons, it's just one thing that I remember having no replacement when it's dropped from FFmpeg. If you think it's important, I can mention in the release notes that this will be the last version that supports it. Ciao, Roberto
On 9/5/15, Roberto Togni <rxt@rtogni.it> wrote:
On Mon, 31 Aug 2015 11:17:15 +0300 Ivan Kalvachev <ikalvachev@gmail.com> wrote:
On 8/29/15, Roberto Togni <rxt@rtogni.it> wrote:
Hi all.
I'd like to do a new release of MPlayer, using the soon to be released FFmpeg 2.8.
This will be the last FFmpeg release before a lot of old APIs are dropped; since the support in MPlayer for their replacement is very new it would be good to have a stable version in case of problems. Also some features will have to be removed in MPlayer after (eg. XvMC,
Why are you giving XvMC as example?
No special reasons, it's just one thing that I remember having no replacement when it's dropped from FFmpeg.
If you think it's important, I can mention in the release notes that this will be the last version that supports it.
Why do you think FFmpeg is dropping it? FF_API_XVMC is not for removing XvMC, at least not in FFmpeg. I've converted it to hwaccel about year or two ago. Then I simplified the API that breaks the ABI, so I used the existing FF_API_XVMC to signal the API change. What I'm asking is if there is some breakage caused by the other API's that needs fixing in MPlayer. e.g. removing of get_buffer() interface.
On Sat, 19 Sep 2015 23:35:21 +0300 Ivan Kalvachev <ikalvachev@gmail.com> wrote:
On 9/5/15, Roberto Togni <rxt@rtogni.it> wrote:
On Mon, 31 Aug 2015 11:17:15 +0300 Ivan Kalvachev <ikalvachev@gmail.com> wrote:
On 8/29/15, Roberto Togni <rxt@rtogni.it> wrote:
Hi all.
I'd like to do a new release of MPlayer, using the soon to be released FFmpeg 2.8.
This will be the last FFmpeg release before a lot of old APIs are dropped; since the support in MPlayer for their replacement is very new it would be good to have a stable version in case of problems. Also some features will have to be removed in MPlayer after (eg. XvMC,
Why are you giving XvMC as example?
No special reasons, it's just one thing that I remember having no replacement when it's dropped from FFmpeg.
If you think it's important, I can mention in the release notes that this will be the last version that supports it.
Why do you think FFmpeg is dropping it? FF_API_XVMC is not for removing XvMC, at least not in FFmpeg.
I've converted it to hwaccel about year or two ago. Then I simplified the API that breaks the ABI, so I used the existing FF_API_XVMC to signal the API change.
What I'm asking is if there is some breakage caused by the other API's that needs fixing in MPlayer. e.g. removing of get_buffer() interface.
I misunderstood the meaning of FF_API_XVMC, I thought it was going to remove XvMC functionality. I have no idea XvMC works in MPlayer now, I never used it before (I never used hwaccel before I made the get_buffer patch). The get_buffer changes should be transparent, since I just reused the compatibility code from ffmpeg. At least plain sw decoders and vdpau works the same as before after the api change. If my card supports XvMC (sandybridge with internal GPU) I will test it. Ciao, Roberto
From 5f958b5b16034d3114ec8b756d08e50d474ebc36 Mon Sep 17 00:00:00 2001 From: ZhouXiaoyong <zhouxiaoyong@loongson.cn> Date: Thu, 20 Aug 2015 16:35:30 +0800 Subject: [PATCH 1/6] configure: add loongson series cpu support
Signed-off-by: ZhouXiaoyong <zhouxiaoyong@loongson.cn> --- configure | 28 +++++++++++++++++++++++++++- 1 file changed, 27 insertions(+), 1 deletion(-) diff --git a/configure b/configure index 4dbcdf5..50eb59a 100755 --- a/configure +++ b/configure @@ -2025,7 +2025,7 @@ def_local_aligned_8='#define HAVE_LOCAL_ALIGNED_8 0' def_local_aligned_16='#define HAVE_LOCAL_ALIGNED_16 0' def_local_aligned_32='#define HAVE_LOCAL_ALIGNED_32 0' arch_all='X86 IA64 SPARC ARM AVR32 SH4 PPC ALPHA MIPS PA_RISC S390 S390X VAX BFIN XTENSA TOMI GENERIC AARCH64' -subarch_all='X86_32 X86_64 PPC64' +subarch_all='X86_32 X86_64 PPC64 LOONGSON' case "$host_arch" in i[3-9]86|x86|x86pc|k5|k6|k6-2|k6-3|pentium*|athlon*|i586-i686) arch='x86' @@ -2620,6 +2620,32 @@ EOF arch='mips' iproc='mips' + if linux; then + echocheck "CPU type" + pname=$($_cpuinfo | grep 'model' | cut -d ':' -f 2 | head -n 1) + case $pname in + *Loongson-3*) + subarch='loongson' + def_fast_unaligned='#define HAVE_FAST_UNALIGNED 1' + def_av_fast_unaligned='#define AV_HAVE_FAST_UNALIGNED 1' + def_local_aligned_8='#define HAVE_LOCAL_ALIGNED_8 1' + def_local_aligned_16='#define HAVE_LOCAL_ALIGNED_16 1' + def_local_aligned_32='#define HAVE_LOCAL_ALIGNED_32 1' + def_fast_64bit='#define HAVE_FAST_64BIT 1' + _march='-march=loongson3a' + ;; + *Loongson-2*) + subarch='loongson' + _march='-march=mips3' + ;; + *Godson*) + subarch='loongson' + _march='-march=mips3' + ;; + esac + echores "$pname" + fi + if irix ; then echocheck "CPU type" proc=$(hinv -c processor | grep CPU | cut -d " " -f3) -- 2.1.4
On Sat, 29 Aug 2015 22:18:00 +0200 Roberto Togni <rxt@rtogni.it> wrote:
Hi all.
I'd like to do a new release of MPlayer, using the soon to be released FFmpeg 2.8.
This will be the last FFmpeg release before a lot of old APIs are dropped; since the support in MPlayer for their replacement is very new it would be good to have a stable version in case of problems. Also some features will have to be removed in MPlayer after (eg. XvMC, lavfi ulnless it's rewritten), because of incompatibilities or deprecation.
If you have anything that you want to get into the release please speak now and commit it; the same if you want to suggest that something is removed or dropped.
Also reports about blocking issues are welcome.
I will open some other threads about websites updates and such.
If no objections or last minute fixes, I plan to release MPlayer 1.2 tomorrow night. Ciao, Roberto
Roberto Togni wrote on Sun, 6 Sep 2015 23:20:51 +0200:
If no objections or last minute fixes, I plan to release MPlayer 1.2 tomorrow night.
It would be nice to have the missing Chinese translations in 1.2. Usually, jrash is very quick with these. Ingo
On Mon, 07 Sep 2015 09:29:18 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Roberto Togni wrote on Sun, 6 Sep 2015 23:20:51 +0200:
If no objections or last minute fixes, I plan to release MPlayer 1.2 tomorrow night.
It would be nice to have the missing Chinese translations in 1.2. Usually, jrash is very quick with these.
Ok, I'll wait for the update. I also found out that FFmpeg 2.8 is not officially released yet. Ciao, Roberto
Roberto Togni wrote on Mon, 7 Sep 2015 21:54:01 +0200:
On Mon, 07 Sep 2015 09:29:18 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
It would be nice to have the missing Chinese translations in 1.2. Usually, jrash is very quick with these.
Ok, I'll wait for the update.
It's in the 1.2 branch now. Unfortunately, nobody has cared about the missing updates of the DOCS, the homepage skin section and the skin tarballs for 1.2 yet. Ingo
On Sat, 12 Sep 2015 16:45:50 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Roberto Togni wrote on Mon, 7 Sep 2015 21:54:01 +0200:
On Mon, 07 Sep 2015 09:29:18 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
It would be nice to have the missing Chinese translations in 1.2. Usually, jrash is very quick with these.
Ok, I'll wait for the update.
It's in the 1.2 branch now.
Unfortunately, nobody has cared about the missing updates of the DOCS, the homepage skin section and the skin tarballs for 1.2 yet.
I'll try to do it tonight. For the skin files, iiuc I only have to make a tar.bz of every modified directory in the skins repo and name it $skindirectory-$version.tar.bz where $version is the content from VERSION file, right? There is still one crashing bug on screenshots reported by Josh on users list that I'd like to fix before the release, I'll see if I can reproduce it. Ciao, Roberto
Roberto Togni wrote on Sat, 12 Sep 2015 17:55:39 +0200:
On Sat, 12 Sep 2015 16:45:50 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Unfortunately, nobody has cared about the missing updates of the DOCS, the homepage skin section and the skin tarballs for 1.2 yet.
I'll try to do it tonight.
For the skin files, iiuc I only have to make a tar.bz of every modified directory in the skins repo and name it $skindirectory-$version.tar.bz where $version is the content from VERSION file, right?
A .tar.bz2 - basically, but yes. This all used to happen automatically. I was able (and allowed?) to change the homepage and every commit to the skin repository automatically created the tarball. The automatic update of the homepage DOCS is broken for a long time, but this also used to happen automatically once when committing something from the DOCS directory. I actually don't know what the issues are over and over again and I'm really tired to maintain the stuff under these conditions. Ingo
On Sat, 12 Sep 2015 18:42:27 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Roberto Togni wrote on Sat, 12 Sep 2015 17:55:39 +0200:
On Sat, 12 Sep 2015 16:45:50 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Unfortunately, nobody has cared about the missing updates of the DOCS, the homepage skin section and the skin tarballs for 1.2 yet.
I'll try to do it tonight.
For the skin files, iiuc I only have to make a tar.bz of every modified directory in the skins repo and name it $skindirectory-$version.tar.bz where $version is the content from VERSION file, right?
A .tar.bz2 - basically, but yes.
This all used to happen automatically. I was able (and allowed?) to change the homepage and every commit to the skin repository automatically created the tarball.
The automatic update of the homepage DOCS is broken for a long time, but this also used to happen automatically once when committing something from the DOCS directory.
I actually don't know what the issues are over and over again and I'm really tired to maintain the stuff under these conditions.
Docs and skins should be updated now. For the docs there is no posthook and no cron job, and probably (I haven't checked it yet) the package required to build the docs are not installed too. For the skins it seems to be a permission problem, the posthook is there and is correct. I think there are some serious permission problems on the new server; I used to be able to write to the various public directories (like skins and releases) as a user on the old mphq*, now I have to do it as root. This is probably also why the commit scripts are failing. I will try to have a look at it in the next days, but I know that there will be another server move in the near future. Sorry for the problems this is causing; now I have everything prepared to do it, so just ping me when you need to update something. Ciao, Roberto
Roberto Togni wrote on Sun, 13 Sep 2015 02:01:01 +0200:
Docs and skins should be updated now.
Confirmed. I forgot to update the skin version info on the homepage which I caught up on just now (and which immediately appeared online). As far as I'm concerned, ready for the new release. Ingo
On Mon, 14 Sep 2015 00:18:36 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Roberto Togni wrote on Sun, 13 Sep 2015 02:01:01 +0200:
Docs and skins should be updated now.
Confirmed. I forgot to update the skin version info on the homepage which I caught up on just now (and which immediately appeared online).
As far as I'm concerned, ready for the new release.
Finally released. Ciao, Roberto
On Sat, 3 Oct 2015 23:42:00 +0200 Roberto Togni <rxt@rtogni.it> wrote:
On Mon, 14 Sep 2015 00:18:36 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Roberto Togni wrote on Sun, 13 Sep 2015 02:01:01 +0200:
Docs and skins should be updated now.
Confirmed. I forgot to update the skin version info on the homepage which I caught up on just now (and which immediately appeared online).
As far as I'm concerned, ready for the new release.
Finally released.
wooooohooooooooo! -compn
Roberto Togni wrote on Sun, 6 Sep 2015 23:20:51 +0200:
If no objections or last minute fixes, I plan to release MPlayer [...]
I never thought I would add cue file playlist support to the GUI so fast, but now it would be great to have this already in the 1.2 release. I've tested it extensively. Is it OK to add this to the 1.2 branch? I currently don't know whether there is an easy way to apply all single patches from trunk, so - if not - is it OK to make everything one big change and apply it as a single patch? Ingo
On Tue, 08 Sep 2015 15:05:19 +0200 Ingo Brückl <ib@wupperonline.de> wrote:
Roberto Togni wrote on Sun, 6 Sep 2015 23:20:51 +0200:
If no objections or last minute fixes, I plan to release MPlayer [...]
I never thought I would add cue file playlist support to the GUI so fast, but now it would be great to have this already in the 1.2 release. I've tested it extensively.
Is it OK to add this to the 1.2 branch?
I have no problem with this.
I currently don't know whether there is an easy way to apply all single patches from trunk, so - if not - is it OK to make everything one big change and apply it as a single patch?
I'm not aware of a way to do it in a single step. You can merge the changes from trunk to the branch with svn merge ^/trunk -r startrev:endrev (you have to do it in a checkout of the branch). You can do it multiple times if the revisions are not consecutive. But when you will commit them, all the revisions will all appear as a single changeset. In my opinion you can push it in a single chunk, just add the list of the revisions to the commit message (we have the full history in trunk). Svn should record the merge operation anyway in the properties, but I think that having them in the commit message is more clear. Ciao, Roberto
participants (5)
-
compn -
Ingo Brückl -
Ivan Kalvachev -
Roberto Togni -
周晓勇