From Reimar.Doeffinger at gmx.de  Thu Sep  1 00:24:06 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 1 Sep 2011 00:24:06 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <4e5afefa.32b90f1e.bm000@wupperonline.de>
References: <20110828203122.32fa4506.tempn@twmi.rr.com>
	<4e5afefa.32b90f1e.bm000@wupperonline.de>
Message-ID: <20110831222406.GA3015@1und1.de>

On Mon, Aug 29, 2011 at 04:49:37AM +0200, Ingo Br?ckl wrote:
> compn wrote on Sun, 28 Aug 2011 20:31:22 -0400:
> 
> > On Mon, 29 Aug 2011 01:52:15 +0200, Ingo Br?ckl wrote:
> >>Seems to work just fine.
> 
> > have you tried it with an mp3 file and a fuzzer (like zzuf) to make
> > sure it doesnt crash or leak mem etc?
> 
> Currently it's just a feasibility study. I won't put work into it until I
> know that it will be accepted in principle.

However exactly that is exactly the problem.
After the last time such stuff was added it ended up with about
one major security hole per line (and lots of lines of code)
I am seriously doubting that it's a good idea.
It's possible to just prefer lavf demuxer for those files.
No idea if there's any reason not to.

From naoya.oyama at gmail.com  Thu Sep  1 18:53:10 2011
From: naoya.oyama at gmail.com (Naoya OYAMA)
Date: Fri, 2 Sep 2011 01:53:10 +0900
Subject: [MPlayer-dev-eng] [PATCH]SPDIF pass through decoder
In-Reply-To: <loom.20110818T161554-16@post.gmane.org>
References: <CAJz3U+WyC1FbN+yO3Rip=OkQVdwXyF6LXF8LgvrObtOiE0bH1w@mail.gmail.com>
	<20110811212406.GA17697@pool.informatik.RWTH-Aachen.DE>
	<CAJz3U+Ue=nau=C2mVf+0RmS+QoAQ8cA3yBKgA16fi6PCfT4n+w@mail.gmail.com>
	<loom.20110818T161554-16@post.gmane.org>
Message-ID: <CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>

Hi, patch updated.

> 2011/8/18, Carl Eugen Hoyos <cehoyos at ag.or.at>:
> Does your receiver support DTS-HD Master?
> I ask because all HD Master tracks are played as DTS (no HD Master) in my
> tests.
> I suspect something the muxing rate of the spdif muxer has to be set (and
> samplerate=192k and channels=8).

To decode DTS-HD the option dtshd_rate was required.
I test this patch works fine for DTS, DTS 96/24, DTS HiRes and DTS MA.
But it is very choppy(does not check DTS or DTS-HD).

And I write code for Dolby TrueHD.

<Patch Status>
Tested:
1. MPEG2 AAC
2. AC3
3. DTS
4. E-AC3
5. Dolby TrueHD
6. DTS-HD

Not tested:
1. MPEG4 AAC (my receiver does not supoprt)
2. MPEG audio(Layer1,2,3) (my receiver does not supoprt)

Not developed:
nothing

Thank you.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer_spdif3.path
Type: application/octet-stream
Size: 20801 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110902/f831731b/attachment-0001.obj>

From ib at wupperonline.de  Thu Sep  1 23:01:18 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 01 Sep 2011 23:01:18 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <20110831222406.GA3015@1und1.de>
Message-ID: <4e5ff2e6.519c3bb7.bm001@wupperonline.de>

Reimar D?ffinger wrote on Thu, 1 Sep 2011 00:24:06 +0200:

> On Mon, Aug 29, 2011 at 04:49:37AM +0200, Ingo Br?ckl wrote:
>> compn wrote on Sun, 28 Aug 2011 20:31:22 -0400:
>>
>> > On Mon, 29 Aug 2011 01:52:15 +0200, Ingo Br?ckl wrote:
>> >>Seems to work just fine.
>>
>> > have you tried it with an mp3 file and a fuzzer (like zzuf) to make
>> > sure it doesnt crash or leak mem etc?
>>
>> Currently it's just a feasibility study. I won't put work into it until I
>> know that it will be accepted in principle.

> However exactly that is exactly the problem.
> After the last time such stuff was added it ended up with about
> one major security hole per line (and lots of lines of code)

Hmm, what can possibly become a security hole? The worst thing that can
happen is that we get a wrong number of frames leading to a wrong value
for i_bps if a vbr header exists, which is exactly what we are having at
the moment.

> I am seriously doubting that it's a good idea.

Well, if it's unwanted ... I just thought it would be nice to have vbr
support...

> It's possible to just prefer lavf demuxer for those files.
> No idea if there's any reason not to.

Yes, it is possible, but because you don't know in advance you have to use
the lavf demuxer by default. (Which leads me to the question, why do we have
own demuxers and don't just use ffmepg's? Serious question.)

Ingo

From Reimar.Doeffinger at gmx.de  Thu Sep  1 23:16:39 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 1 Sep 2011 23:16:39 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <4e5ff2e6.519c3bb7.bm001@wupperonline.de>
References: <20110831222406.GA3015@1und1.de>
	<4e5ff2e6.519c3bb7.bm001@wupperonline.de>
Message-ID: <20110901211639.GA3946@1und1.de>

On Thu, Sep 01, 2011 at 11:01:18PM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Thu, 1 Sep 2011 00:24:06 +0200:
> 
> > On Mon, Aug 29, 2011 at 04:49:37AM +0200, Ingo Br?ckl wrote:
> >> compn wrote on Sun, 28 Aug 2011 20:31:22 -0400:
> >>
> >> > On Mon, 29 Aug 2011 01:52:15 +0200, Ingo Br?ckl wrote:
> >> >>Seems to work just fine.
> >>
> >> > have you tried it with an mp3 file and a fuzzer (like zzuf) to make
> >> > sure it doesnt crash or leak mem etc?
> >>
> >> Currently it's just a feasibility study. I won't put work into it until I
> >> know that it will be accepted in principle.
> 
> > However exactly that is exactly the problem.
> > After the last time such stuff was added it ended up with about
> > one major security hole per line (and lots of lines of code)
> 
> Hmm, what can possibly become a security hole? The worst thing that can
> happen is that we get a wrong number of frames leading to a wrong value
> for i_bps if a vbr header exists, which is exactly what we are having at
> the moment.

You might be reading in data incorrectly, the parsing might go wrong,
it might cause a division by 0, negative or 0 values for bitrate which
the code above might not be able to handle... The usually way security holes
happen when dealing with completely unfiltered user data.

> > I am seriously doubting that it's a good idea.
> 
> Well, if it's unwanted ... I just thought it would be nice to have vbr
> support...

If it's simple enough it would still be ok.
I guess your patch could probably be made simple enough by using the
appropriate stream_read_char/stream_read_dword functions, though it
still needs sanity checks and I think it won't handle stray Xing headers
which I think the FFmpeg demuxer can.
Though your patch only adds support for the Xing header, I am quite
sure there is at least one other VBR header.
I also think there was some bugzilla with a finished patch actually...

> > It's possible to just prefer lavf demuxer for those files.
> > No idea if there's any reason not to.
> 
> Yes, it is possible, but because you don't know in advance you have to use
> the lavf demuxer by default. (Which leads me to the question, why do we have
> own demuxers and don't just use ffmepg's? Serious question.)

Because there was no FFmpeg when MPlayer started.
And FFmpeg didn't have demuxers even longer.
And even longer FFmpeg didn't have actually reliably working demuxers.
E.g. it might be that in a streaming context the probing still takes too
long/needs too much data with the lavf demuxer even today - that is
one of the potential issues I could see.
So a bit after the motto "better a few small bugs than a large
regression" progress on moving to lavf is slow.

From ib at wupperonline.de  Fri Sep  2 10:16:53 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 02 Sep 2011 10:16:53 +0200
Subject: [MPlayer-dev-eng] [PATCH rev] windows gui about box
In-Reply-To: <loom.20110829T010928-834@post.gmane.org>
Message-ID: <4e60924d.612f25ee.bm002@wupperonline.de>

Stephen Sheldon wrote on Sun, 28 Aug 2011 23:32:07 +0000 (UTC):

> Here is another pass on the Windows GUI about box.

Would you mind a minor change? We should not drop the COPYRIGHT note and
that way it will look similar to the X11/GTK GUI message box to come.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: about.patch
Type: text/x-diff
Size: 3420 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110902/c579e6aa/attachment.bin>

From ib at wupperonline.de  Fri Sep  2 13:42:02 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 02 Sep 2011 13:42:02 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <20110901211639.GA3946@1und1.de>
Message-ID: <4e60c40f.595ad9d3.bm001@wupperonline.de>

Reimar D?ffinger wrote on Thu, 1 Sep 2011 23:16:39 +0200:

> On Thu, Sep 01, 2011 at 11:01:18PM +0200, Ingo Br?ckl wrote:
>> Reimar D?ffinger wrote on Thu, 1 Sep 2011 00:24:06 +0200:
>>
>> > On Mon, Aug 29, 2011 at 04:49:37AM +0200, Ingo Br?ckl wrote:
>> >> compn wrote on Sun, 28 Aug 2011 20:31:22 -0400:
>> >>
>> >> > On Mon, 29 Aug 2011 01:52:15 +0200, Ingo Br?ckl wrote:
>> >> >>Seems to work just fine.
>> >>
>> >> > have you tried it with an mp3 file and a fuzzer (like zzuf) to make
>> >> > sure it doesnt crash or leak mem etc?
>> >>
>> >> Currently it's just a feasibility study. I won't put work into it until I
>> >> know that it will be accepted in principle.
>>
>> > However exactly that is exactly the problem.
>> > After the last time such stuff was added it ended up with about
>> > one major security hole per line (and lots of lines of code)
>>
>> Hmm, what can possibly become a security hole? The worst thing that can
>> happen is that we get a wrong number of frames leading to a wrong value
>> for i_bps if a vbr header exists, which is exactly what we are having at
>> the moment.

> You might be reading in data incorrectly, the parsing might go wrong, it
> might cause a division by 0, negative or 0 values for bitrate which the
> code above might not be able to handle... The usually way security holes
> happen when dealing with completely unfiltered user data.

>> > I am seriously doubting that it's a good idea.
>>
>> Well, if it's unwanted ... I just thought it would be nice to have vbr
>> support...

> If it's simple enough it would still be ok.

So you're encouraging me?

> I guess your patch could probably be made simple enough by using the
> appropriate stream_read_char/stream_read_dword functions, though it
> still needs sanity checks and I think it won't handle stray Xing headers
> which I think the FFmpeg demuxer can.
> Though your patch only adds support for the Xing header, I am quite
> sure there is at least one other VBR header.

This is why I called it a "feasibility study". mp3_vbr_frames() is far from
being finished.

> I also think there was some bugzilla with a finished patch actually...

If you refer to #465, that won't help much (though it's nice to see the
runtime constantly making new guesses in the GUI).

Based on the bugzilla reports, don't you think it maybe *is* a good idea to
have vbr support?

I'm willing to put work into mp3_vbr_frames() to the best of my knowledge,
but not if you are seriously doubting that it's a good idea, which (to my
understanding) sounds like I'd waste my time.

Ingo

From sfsheldo at gmail.com  Fri Sep  2 17:47:10 2011
From: sfsheldo at gmail.com (Stephen Sheldon)
Date: Fri, 2 Sep 2011 15:47:10 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH rev] windows gui about box
References: <loom.20110829T010928-834@post.gmane.org>
	<4e60924d.612f25ee.bm002@wupperonline.de>
Message-ID: <loom.20110902T174613-524@post.gmane.org>

Ingo Br?ckl <ib <at> wupperonline.de> writes:

> 
> Stephen Sheldon wrote on Sun, 28 Aug 2011 23:32:07 +0000 (UTC):
> 
> > Here is another pass on the Windows GUI about box.
> 
> Would you mind a minor change? We should not drop the COPYRIGHT note and
> that way it will look similar to the X11/GTK GUI message box to come.
> 
This looks good.  Thank you.




From ib at wupperonline.de  Sat Sep  3 01:58:43 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sat, 03 Sep 2011 01:58:43 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
Message-ID: <4e616db5.5355276c.bm000@wupperonline.de>

To give the GUI control over the cursor (i.e. to avoid uncontrolled
appearances) I'd like to patch vo_x11_uninit().

The control could be achieved by either not showing the cursor if there
is a WinID (#1) or by a direct dependency on the GUI itself (#2).

#1 is more general and would pass control (and duty) to show the cursor to
the application owning WinID (which sounds reasonable at first), while #2
is the safest way, but maybe uglier.

Is one of them acceptable?

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_x11_uninit.1.patch
Type: text/x-diff
Size: 394 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110903/419d306b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_x11_uninit.2.patch
Type: text/x-diff
Size: 367 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110903/419d306b/attachment-0001.bin>

From Reimar.Doeffinger at gmx.de  Sat Sep  3 09:07:40 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 3 Sep 2011 09:07:40 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <4e60c40f.595ad9d3.bm001@wupperonline.de>
References: <20110901211639.GA3946@1und1.de>
	<4e60c40f.595ad9d3.bm001@wupperonline.de>
Message-ID: <20110903070740.GA9268@1und1.de>

On Fri, Sep 02, 2011 at 01:42:02PM +0200, Ingo Br?ckl wrote:
> >> > I am seriously doubting that it's a good idea.
> >>
> >> Well, if it's unwanted ... I just thought it would be nice to have vbr
> >> support...
> 
> > If it's simple enough it would still be ok.
> 
> So you're encouraging me?

Well, I'd prefer to switch to libavformat for mostly everything at least
in the long term, and I prefer time invested in that.
This is also because IIRC the Xing headers can cause some decoding
issues so lavf filters them out, but that I think is more complex than
why am willing to accept in MPlayer.
But if the patch you sent is mostly representative of the complexity
I think it would be fine to have in MPlayer's demuxer, too.

> Based on the bugzilla reports, don't you think it maybe *is* a good idea to
> have vbr support?

Yes.

> I'm willing to put work into mp3_vbr_frames() to the best of my knowledge,
> but not if you are seriously doubting that it's a good idea, which (to my
> understanding) sounds like I'd waste my time.

I am unsure if adding it to the MPlayer demuxer is the best way to get
the functionality though.

From tempn at twmi.rr.com  Sat Sep  3 13:42:05 2011
From: tempn at twmi.rr.com (compn)
Date: Sat, 3 Sep 2011 07:42:05 -0400
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <20110903070740.GA9268@1und1.de>
References: <20110901211639.GA3946@1und1.de>
	<4e60c40f.595ad9d3.bm001@wupperonline.de>
	<20110903070740.GA9268@1und1.de>
Message-ID: <20110903074205.ddd04da0.tempn@twmi.rr.com>

On Sat, 3 Sep 2011 09:07:40 +0200, Reimar D?ffinger wrote:
>On Fri, Sep 02, 2011 at 01:42:02PM +0200, Ingo Br?ckl wrote:

to summarize:
1. yes, having this feature in mplayer demuxer would be nice.
2. be sure to fuzz and valgrind test the code.
3. in the future we want to switch to libavformat to avoid maintaining
two sets of demuxers/wheels.

-compn

From ib at wupperonline.de  Sat Sep  3 17:52:30 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sat, 03 Sep 2011 17:52:30 +0200
Subject: [MPlayer-dev-eng] [PATCH rev] windows gui about box
In-Reply-To: <loom.20110902T174613-524@post.gmane.org>
Message-ID: <4e624d42.6576d737.bm000@wupperonline.de>

Stephen Sheldon wrote on Fri, 2 Sep 2011 15:47:10 +0000 (UTC):

> This looks good.  Thank you.

Applied.

Ingo

From ib at wupperonline.de  Sat Sep  3 18:52:31 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sat, 03 Sep 2011 18:52:31 +0200
Subject: [MPlayer-dev-eng] mp_msg vs. mp_dbg
Message-ID: <4e6262a2.580a5185.bm000@wupperonline.de>

While following the user list I increasingly got fond of the possibility to
use -v or  -v -v to track down problems.

When I started with the GUI I thought that using mp_dbg rather than mp_msg
for debug messages (level DBG2) is a good idea to save both unnecessary
execution and size of code. The disadvantage I'm aware of now is that in case
of real GUI problems (like: the GUI crashes, the main window doesn't show up
or looks weird) these debug messages could help, but only in the rare case
compilation has been carried out with --enable-debug; for MPlayer GUI
packages used for distributions very unlikely.

There seem to be more mp_dbg in the gui code than in all the other MPlayer
code. One reason might be, that you won't expect terminal output from a GUI,
so it does (almost) none. But MPlayer does, and I'm asking myself whether
mp_msg should be preferred over mp_dbg?

Is there a kind of policy?

Ingo

From Reimar.Doeffinger at gmx.de  Sun Sep  4 00:18:13 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 4 Sep 2011 00:18:13 +0200
Subject: [MPlayer-dev-eng] mp_msg vs. mp_dbg
In-Reply-To: <4e6262a2.580a5185.bm000@wupperonline.de>
References: <4e6262a2.580a5185.bm000@wupperonline.de>
Message-ID: <20110903221813.GA2075@1und1.de>

On Sat, Sep 03, 2011 at 06:52:31PM +0200, Ingo Br?ckl wrote:
> Is there a kind of policy?

No, do what you think makes most sense.
There are two obvious cases:
1) Stuff that users might reasonably be interested in should of course
not use mp_dbg
2) Stuff that would only print something useful for the case when you
are in the middle if modifying the code should be mp_dbg (no, I can't
really think of a specific example).

Anything in between is almost bikeshedding.

From jeremylawler at gmail.com  Sun Sep  4 07:46:49 2011
From: jeremylawler at gmail.com (Jeremy Lawler)
Date: Sun, 4 Sep 2011 00:46:49 -0500
Subject: [MPlayer-dev-eng] Found a bug in some slave mode code
Message-ID: <CACzHy3eU4d9sLASBOk4Zbi=i_Gq6oj1p4U0gMQbA4ZwG8qB6mA@mail.gmail.com>

I wrote some code that utilizes slave mode, and it has come to my attention
that "get_time_pos" has at least 1 bug.
The "get_time_pos" command  returns the value of sh_video->pts.
 Unfortunately, during DVD playback this is the position within the current
VOB file, not the total DVD stream.

I ended up using the demux->stream_pts to grab the info because the
demuxer_get_current_time function returns ints, not floats.  I assumed it
would be preferred to keep the current precision instead of using
get_current_time.

I joined the mailing list to post this and attempted to make sure my patch
is minimal/formatted correctly, so if there is anything wrong with the
patch/logic, apologies.


Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer_fix_get_time_pos.diff
Type: text/x-patch
Size: 601 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110904/621f55ca/attachment.bin>

From diego at biurrun.de  Sun Sep  4 15:15:46 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sun, 04 Sep 2011 15:15:46 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e616db5.5355276c.bm000@wupperonline.de>
References: <4e616db5.5355276c.bm000@wupperonline.de>
Message-ID: <20110904131546.GA3417@pool.informatik.RWTH-Aachen.DE>

On Sat, Sep 03, 2011 at 01:58:43AM +0200, Ingo Br?ckl wrote:
> To give the GUI control over the cursor (i.e. to avoid uncontrolled
> appearances) I'd like to patch vo_x11_uninit().
> 
> The control could be achieved by either not showing the cursor if there
> is a WinID (#1) or by a direct dependency on the GUI itself (#2).
> 
> #1 is more general and would pass control (and duty) to show the cursor to
> the application owning WinID (which sounds reasonable at first), while #2
> is the safest way, but maybe uglier.
> 
> Is one of them acceptable?

I'd hate to see another #ifdef GUI added to MPlayer.

Diego

From Reimar.Doeffinger at gmx.de  Sun Sep  4 15:22:49 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 4 Sep 2011 15:22:49 +0200
Subject: [MPlayer-dev-eng] Found a bug in some slave mode code
In-Reply-To: <CACzHy3eU4d9sLASBOk4Zbi=i_Gq6oj1p4U0gMQbA4ZwG8qB6mA@mail.gmail.com>
References: <CACzHy3eU4d9sLASBOk4Zbi=i_Gq6oj1p4U0gMQbA4ZwG8qB6mA@mail.gmail.com>
Message-ID: <20110904132249.GB2221@1und1.de>

On Sun, Sep 04, 2011 at 12:46:49AM -0500, Jeremy Lawler wrote:
> I wrote some code that utilizes slave mode, and it has come to my attention
> that "get_time_pos" has at least 1 bug.
> The "get_time_pos" command  returns the value of sh_video->pts.
>  Unfortunately, during DVD playback this is the position within the current
> VOB file, not the total DVD stream.
> 
> I ended up using the demux->stream_pts to grab the info because the
> demuxer_get_current_time function returns ints, not floats.  I assumed it
> would be preferred to keep the current precision instead of using
> get_current_time.
> 
> I joined the mailing list to post this and attempted to make sure my patch
> is minimal/formatted correctly, so if there is anything wrong with the
> patch/logic, apologies.

Well... Let me start with that I'm happy to come up with a better
solution if you dislike the current one, and that also documentation
improvements are highly welcome, but the current idea is:
1) You use get_property stream_time_pos, which returns stream_pts
2) If that returns an error you can optionally fall back to get_time_pos
(or the preferred newer syntax "get_property time_pos).

From Reimar.Doeffinger at gmx.de  Sun Sep  4 15:28:14 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 4 Sep 2011 15:28:14 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e616db5.5355276c.bm000@wupperonline.de>
References: <4e616db5.5355276c.bm000@wupperonline.de>
Message-ID: <20110904132814.GA2653@1und1.de>

On Sat, Sep 03, 2011 at 01:58:43AM +0200, Ingo Br?ckl wrote:
> To give the GUI control over the cursor (i.e. to avoid uncontrolled
> appearances) I'd like to patch vo_x11_uninit().
> 
> The control could be achieved by either not showing the cursor if there
> is a WinID (#1) or by a direct dependency on the GUI itself (#2).
> 
> #1 is more general and would pass control (and duty) to show the cursor to
> the application owning WinID (which sounds reasonable at first), while #2
> is the safest way, but maybe uglier.
> 
> Is one of them acceptable?
> 
> Ingo

> Index: libvo/x11_common.c
> ===================================================================
> --- libvo/x11_common.c	(revision 34051)
> +++ libvo/x11_common.c	(working copy)
> @@ -752,7 +752,7 @@
>  void vo_x11_uninit(void)
>  {
>      saver_on(mDisplay);
> -    if (vo_window != None)
> +    if (vo_window != None && vo_window != WinID)

I think that should be WinID > 0 or >= 0 to be consistent with the other
code.
I think that should be a good idea, however vo_hidecursor should then
also not be called by default, only disabling the showcursor but not
hidecursor seems like a really bad idea.

From eclipse7 at gmx.net  Sun Sep  4 17:02:25 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 4 Sep 2011 17:02:25 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110904132814.GA2653@1und1.de>
References: <4e616db5.5355276c.bm000@wupperonline.de>
	<20110904132814.GA2653@1und1.de>
Message-ID: <20110904150224.GA9555@tane>

Hi

Reimar D?ffinger wrote:
> On Sat, Sep 03, 2011 at 01:58:43AM +0200, Ingo Br?ckl wrote:
> > To give the GUI control over the cursor (i.e. to avoid uncontrolled
> > appearances) I'd like to patch vo_x11_uninit().
> > 
> > The control could be achieved by either not showing the cursor if there
> > is a WinID (#1) or by a direct dependency on the GUI itself (#2).
> > 
> > #1 is more general and would pass control (and duty) to show the cursor to
> > the application owning WinID (which sounds reasonable at first), while #2
> > is the safest way, but maybe uglier.
> > 
> > Is one of them acceptable?
> > 
> > Ingo
> 
> > Index: libvo/x11_common.c
> > ===================================================================
> > --- libvo/x11_common.c	(revision 34051)
> > +++ libvo/x11_common.c	(working copy)
> > @@ -752,7 +752,7 @@
> >  void vo_x11_uninit(void)
> >  {
> >      saver_on(mDisplay);
> > -    if (vo_window != None)
> > +    if (vo_window != None && vo_window != WinID)
> 
> I think that should be WinID > 0 or >= 0 to be consistent with the other
> code.
> I think that should be a good idea, however vo_hidecursor should then
> also not be called by default, only disabling the showcursor but not
> hidecursor seems like a really bad idea.

  I agree that this is a good idea and that hidecursor should be
disabled too. Maybe it is a more viable approach to disable them
from inside the vo_showcursor/vo_hidecursor routines themselves
and document them while at it.

  Also I could not find any of these called outside the x11_common
object module, so it may be a good idea to remove the prototypes
and make them private to x11_common.c by marking them static.

  Alexander

From ib at wupperonline.de  Sun Sep  4 18:49:33 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 04 Sep 2011 18:49:33 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110904150224.GA9555@tane>
Message-ID: <4e63ac1d.675dc4bc.bm001@wupperonline.de>

Alexander Strasser wrote on Sun, 4 Sep 2011 17:02:25 +0200:

> I agree that this is a good idea and that hidecursor should be disabled
> too.

vo_hidecursor() never gets called in case of WinID >= 0. The "goto final"
prevents that. This leads to an annoying "cursor visible bug" in the GUI.
(While making the cursor invisible is no problem, the GUI currently has no
control of it remaining invisible.)

As there is no hidecursor for WinIDs, we all seem to agree that there
shouldn't be a showcursor either.

> Maybe it is a more viable approach to disable them from inside the
> vo_showcursor/vo_hidecursor routines themselves and document them while at
> it.

I don't want to do that because this would prevent the useful autohide
feature.

> Also I could not find any of these called outside the x11_common object
> module, so it may be a good idea to remove the prototypes and make them
> private to x11_common.c by marking them static.

Good point, so I revised the patch.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_x11_uninit.3.patch
Type: text/x-diff
Size: 1317 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110904/d34f1a57/attachment.bin>

From ib at wupperonline.de  Sun Sep  4 18:42:45 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 04 Sep 2011 18:42:45 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110904132814.GA2653@1und1.de>
Message-ID: <4e63ac1d.506a60c1.bm000@wupperonline.de>

Reimar D?ffinger wrote on Sun, 4 Sep 2011 15:28:14 +0200:

> On Sat, Sep 03, 2011 at 01:58:43AM +0200, Ingo Br?ckl wrote:
>> To give the GUI control over the cursor (i.e. to avoid uncontrolled
>> appearances) I'd like to patch vo_x11_uninit().
>>
>> +    if (vo_window != None && vo_window != WinID)

> I think that should be WinID > 0 or >= 0 to be consistent with the other
> code.

Ok. I see what you mean and revised the patch.

> I think that should be a good idea, however vo_hidecursor should then
> also not be called by default, only disabling the showcursor but not
> hidecursor seems like a really bad idea.

Please see my answer to Alexander.

Ingo

From eclipse7 at gmx.net  Sun Sep  4 20:21:08 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 4 Sep 2011 20:21:08 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e63ac1d.675dc4bc.bm001@wupperonline.de>
References: <20110904150224.GA9555@tane>
	<4e63ac1d.675dc4bc.bm001@wupperonline.de>
Message-ID: <20110904182108.GB9555@tane>

Hi Ingo!

Ingo Br?ckl wrote:
> Alexander Strasser wrote on Sun, 4 Sep 2011 17:02:25 +0200:
> 
> > I agree that this is a good idea and that hidecursor should be disabled
> > too.
> 
> vo_hidecursor() never gets called in case of WinID >= 0. The "goto final"
> prevents that. This leads to an annoying "cursor visible bug" in the GUI.
> (While making the cursor invisible is no problem, the GUI currently has no
> control of it remaining invisible.)

  I looked at the code again, and now I think I know what you are after.

> As there is no hidecursor for WinIDs, we all seem to agree that there
> shouldn't be a showcursor either.

  Yes, we all agree in that point. But after re-reading your explanation
and the code I think you might be trying to fix the symptom but not the
problem. Wouldn't it be better to have the X11 VOs not interfere with
cursor management if an external WinID is used? In that case you would
would be in control of it remaining invisible and responsible for making
it visible.

> 
> > Maybe it is a more viable approach to disable them from inside the
> > vo_showcursor/vo_hidecursor routines themselves and document them while at
> > it.
> 
> I don't want to do that because this would prevent the useful autohide
> feature.

  I guess this is the reason you don't want to get into full control of
the cursor visibility.

  In case you want to keep this functionality, which depends on internal
VO state, then I would expect it to be better to make it just work out
without your interference. Maybe by doing the opposite change and letting
the VO code make it invisible.

> > Also I could not find any of these called outside the x11_common object
> > module, so it may be a good idea to remove the prototypes and make them
> > private to x11_common.c by marking them static.
> 
> Good point, so I revised the patch.

  Thanks for implementing it quickly, but stuffing this into a separate
commit would be much preferable. It could also get committed before your
show/hide cursor patch. But choose the order as you see fit in your work 
flow.

> Index: libvo/x11_common.c
> ===================================================================
> --- libvo/x11_common.c	(revision 34053)
> +++ libvo/x11_common.c	(working copy)
> @@ -178,7 +178,7 @@
>      }
>  }
>  
> -void vo_hidecursor(Display * disp, Window win)
> +static void vo_hidecursor(Display * disp, Window win)
>  {
>      Cursor no_ptr;
>      Pixmap bm_no;
> @@ -203,7 +203,7 @@
>      XFreeColors(disp,colormap,&black.pixel,1,0);
>  }
>  
> -void vo_showcursor(Display * disp, Window win)
> +static void vo_showcursor(Display * disp, Window win)
>  {
>      if (WinID == 0)
>          return;
> @@ -752,7 +752,7 @@
>  void vo_x11_uninit(void)
>  {
>      saver_on(mDisplay);
> -    if (vo_window != None)
> +    if (vo_window != None && WinID < 0)
>          vo_showcursor(mDisplay, vo_window);
>  
>      if (f_gc != None)
> Index: libvo/x11_common.h
> ===================================================================
> --- libvo/x11_common.h	(revision 34053)
> +++ libvo/x11_common.h	(working copy)
> @@ -63,8 +63,6 @@
>  
>  int vo_init( void );
>  void vo_uninit( void );
> -void vo_hidecursor ( Display* , Window );
> -void vo_showcursor( Display *disp, Window win );
>  void vo_x11_decoration( Display * vo_Display,Window w,int d );
>  void vo_x11_classhint( Display * display,Window window,const char *name );
>  void vo_x11_nofs_sizepos(int x, int y, int width, int height);

  Alexander

From ib at wupperonline.de  Mon Sep  5 12:05:28 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 05 Sep 2011 12:05:28 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110904182108.GB9555@tane>
Message-ID: <4e64b427.3f475271.bm000@wupperonline.de>

Alexander Strasser wrote on Sun, 4 Sep 2011 20:21:08 +0200:

> I looked at the code again, and now I think I know what you are after.

Maybe I shouldn't have said "full" cursor control. I was only looking for a
degree of control that eliminates the problems but retains the advantages.
(Let's call the change in vo_x11_uninit() solution #1.)

> Wouldn't it be better to have the X11 VOs not interfere with cursor
> management if an external WinID is used? In that case you would would be in
> control of it remaining invisible and responsible for making it visible.

You mean something like the attached patch and having a mouse_autohide code
in GUI's wm/ws.c? Yes, this would really give full cursor control to the
application owning the WinID and I'm perfectly fine with this (solution #2),
but I'm wondering whether this may affect other GUIs using MPlayer as backend
and depending on the current behavior.

>> > Maybe it is a more viable approach to disable them from inside the
>> > vo_showcursor/vo_hidecursor routines themselves and document them while at
>> > it.
>>
>> I don't want to do that because this would prevent the useful autohide
>> feature.

> I guess this is the reason you don't want to get into full control of the
> cursor visibility.

Yes.

> In case you want to keep this functionality, which depends on internal VO
> state, then I would expect it to be better to make it just work out without
> your interference. Maybe by doing the opposite change and letting the VO
> code make it invisible.

This would be solution #3, but letting the VO code make the cursor invisible
(and thus letting make it visible as well, i.e. leaving full control to the
VO code) has the disadvantage that the cursor will show up / flash shortly
between videos in a playlist which I dislike.

To summarize, I'm fine with #1 (small solution) and #2 (full control
solution), but not with #3.

Which one are you in favor of?

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x11_common.patch
Type: text/x-diff
Size: 848 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110905/6f91c5e5/attachment.bin>

From Reimar.Doeffinger at gmx.de  Mon Sep  5 16:55:19 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 5 Sep 2011 16:55:19 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e64b427.3f475271.bm000@wupperonline.de>
References: <20110904182108.GB9555@tane>
	<4e64b427.3f475271.bm000@wupperonline.de>
Message-ID: <20110905145519.GA6229@1und1.de>

On Mon, Sep 05, 2011 at 12:05:28PM +0200, Ingo Br?ckl wrote:
> Alexander Strasser wrote on Sun, 4 Sep 2011 20:21:08 +0200:
> > Wouldn't it be better to have the X11 VOs not interfere with cursor
> > management if an external WinID is used? In that case you would would be in
> > control of it remaining invisible and responsible for making it visible.
> 
> You mean something like the attached patch and having a mouse_autohide code
> in GUI's wm/ws.c? Yes, this would really give full cursor control to the
> application owning the WinID and I'm perfectly fine with this (solution #2),

Yes, I think this is a good way, though before you reimplement the
autohide or similar functionality in the GUI it might make sense to move the check
a bit so it's still possible to reuse the code if it makes sense.

> but I'm wondering whether this may affect other GUIs using MPlayer as backend
> and depending on the current behavior.

Well, it's a X11-only feature and thus hopefully most GUIs will be more
cross-platform than to rely on it.

From ib at wupperonline.de  Mon Sep  5 17:12:44 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 05 Sep 2011 17:12:44 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110905145519.GA6229@1und1.de>
Message-ID: <4e64e794.535c376f.bm000@wupperonline.de>

Reimar D?ffinger wrote on Mon, 5 Sep 2011 16:55:19 +0200:

> On Mon, Sep 05, 2011 at 12:05:28PM +0200, Ingo Br?ckl wrote:
>> Alexander Strasser wrote on Sun, 4 Sep 2011 20:21:08 +0200:
>> > Wouldn't it be better to have the X11 VOs not interfere with cursor
>> > management if an external WinID is used? In that case you would would be in
>> > control of it remaining invisible and responsible for making it visible.
>>
>> You mean something like the attached patch and having a mouse_autohide code
>> in GUI's wm/ws.c? Yes, this would really give full cursor control to the
>> application owning the WinID and I'm perfectly fine with this (solution #2),

> Yes, I think this is a good way, though before you reimplement the autohide
> or similar functionality in the GUI

I've already prepared and roughly checked this, it's only a few lines of
code.

> it might make sense to move the check a bit so it's still possible to reuse
> the code if it makes sense.

What do you mean by "move the check a bit", I don't get it. Which "check",
"move" where (or when)?

Ingo

From Reimar.Doeffinger at gmx.de  Mon Sep  5 19:32:24 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 5 Sep 2011 19:32:24 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e64e794.535c376f.bm000@wupperonline.de>
References: <20110905145519.GA6229@1und1.de>
	<4e64e794.535c376f.bm000@wupperonline.de>
Message-ID: <20110905173224.GA29004@1und1.de>

On Mon, Sep 05, 2011 at 05:12:44PM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Mon, 5 Sep 2011 16:55:19 +0200:
> 
> > On Mon, Sep 05, 2011 at 12:05:28PM +0200, Ingo Br?ckl wrote:
> >> Alexander Strasser wrote on Sun, 4 Sep 2011 20:21:08 +0200:
> >> > Wouldn't it be better to have the X11 VOs not interfere with cursor
> >> > management if an external WinID is used? In that case you would would be in
> >> > control of it remaining invisible and responsible for making it visible.
> >>
> >> You mean something like the attached patch and having a mouse_autohide code
> >> in GUI's wm/ws.c? Yes, this would really give full cursor control to the
> >> application owning the WinID and I'm perfectly fine with this (solution #2),
> 
> > Yes, I think this is a good way, though before you reimplement the autohide
> > or similar functionality in the GUI
> 
> I've already prepared and roughly checked this, it's only a few lines of
> code.
> 
> > it might make sense to move the check a bit so it's still possible to reuse
> > the code if it makes sense.
> 
> What do you mean by "move the check a bit", I don't get it. Which "check",
> "move" where (or when)?

Move the autohide timer check into a separate function, call that
function from GUI.
For that you'd have to move the WinID check into check_events instead
of having it in hidecursor.

From eclipse7 at gmx.net  Mon Sep  5 21:32:39 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Mon, 5 Sep 2011 21:32:39 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110905145519.GA6229@1und1.de>
References: <20110904182108.GB9555@tane>
	<4e64b427.3f475271.bm000@wupperonline.de>
	<20110905145519.GA6229@1und1.de>
Message-ID: <20110905193239.GA3358@tane>

Hi

Reimar D?ffinger wrote:
> On Mon, Sep 05, 2011 at 12:05:28PM +0200, Ingo Br?ckl wrote:
> > Alexander Strasser wrote on Sun, 4 Sep 2011 20:21:08 +0200:
> > > Wouldn't it be better to have the X11 VOs not interfere with cursor
> > > management if an external WinID is used? In that case you would would be in
> > > control of it remaining invisible and responsible for making it visible.
> > 
> > You mean something like the attached patch and having a mouse_autohide code
> > in GUI's wm/ws.c? Yes, this would really give full cursor control to the
> > application owning the WinID and I'm perfectly fine with this (solution #2),
> 
> Yes, I think this is a good way, though before you reimplement the
> autohide or similar functionality in the GUI it might make sense to move the check
> a bit so it's still possible to reuse the code if it makes sense.

  I agree to everything quoted so far.

> > but I'm wondering whether this may affect other GUIs using MPlayer as backend
> > and depending on the current behavior.
> 
> Well, it's a X11-only feature and thus hopefully most GUIs will be more
> cross-platform than to rely on it.

  I think many of the external GUI developers are listening on this list.
Also this change of behaviour should be mentioned in the Changelog file
and in the next release notes/news.
  
  Alexander

From Reimar.Doeffinger at gmx.de  Tue Sep  6 00:15:50 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 6 Sep 2011 00:15:50 +0200
Subject: [MPlayer-dev-eng] [PATCH] ignore "make clean" errors in ffmpeg/
Message-ID: <20110905221550.GA24232@1und1.de>

Hello,
if e.g. config.mak for example disappeared, the "make -C ffmpeg clean"
will fail and then none of the MPlayer binaries will be removed.
There is likely a better way, but attached patch would just ignore any
failures so that at least the MPlayer binaries will be removed no
matter what.
-------------- next part --------------
Index: Makefile
===================================================================
--- Makefile	(revision 34061)
+++ Makefile	(working copy)
@@ -918,12 +918,12 @@
 	rm -f $(foreach lang,$(MAN_LANGS),$(foreach man,mplayer.1 mencoder.1,$(MANDIR)/$(lang)/man1/$(man)))
 
 clean:
-	$(MAKE) -C ffmpeg $@
+	-$(MAKE) -C ffmpeg $@
 	-rm -f $(call ADD_ALL_DIRS,/*.o /*.a /*.ho /*~)
 	-rm -f $(call ADD_ALL_EXESUFS,mplayer mencoder)
 
 distclean: clean testsclean toolsclean driversclean dhahelperclean
-	$(MAKE) -C ffmpeg $@
+	-$(MAKE) -C ffmpeg $@
 	-rm -rf DOCS/tech/doxygen
 	-rm -f $(call ADD_ALL_DIRS,/*.d)
 	-rm -f config.* codecs.conf.h help_mp.h version.h TAGS tags

From ib at wupperonline.de  Tue Sep  6 12:44:55 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 06 Sep 2011 12:44:55 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen config file
Message-ID: <4e65f9a9.0aff9a3f.bm000@wupperonline.de>

This would allow commenting a group, like

  //@{
  /// Playing states
  #define GUI_STOP  0
  #define GUI_PLAY  1
  #define GUI_PAUSE 2
  //@}

instead of repeating the comment for every line.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doxyfile.patch
Type: text/x-lisp
Size: 546 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110906/670da6d5/attachment.bin>

From ib at wupperonline.de  Tue Sep  6 18:43:01 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 06 Sep 2011 18:43:01 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110905173224.GA29004@1und1.de>
Message-ID: <4e665347.243f6a2b.bm000@wupperonline.de>

Reimar D?ffinger wrote on Mon, 5 Sep 2011 19:32:24 +0200:

> On Mon, Sep 05, 2011 at 05:12:44PM +0200, Ingo Br?ckl wrote:
>> Reimar D?ffinger wrote on Mon, 5 Sep 2011 16:55:19 +0200:
>>
>> > On Mon, Sep 05, 2011 at 12:05:28PM +0200, Ingo Br?ckl wrote:
>> >> Alexander Strasser wrote on Sun, 4 Sep 2011 20:21:08 +0200:
>> >> > Wouldn't it be better to have the X11 VOs not interfere with cursor
>> >> > management if an external WinID is used? In that case you would would be in
>> >> > control of it remaining invisible and responsible for making it visible.
>> >>
>> >> You mean something like the attached patch and having a mouse_autohide code
>> >> in GUI's wm/ws.c? Yes, this would really give full cursor control to the
>> >> application owning the WinID and I'm perfectly fine with this (solution #2),
>>
>> > Yes, I think this is a good way, though before you reimplement the autohide
>> > or similar functionality in the GUI
>>
>> I've already prepared and roughly checked this, it's only a few lines of
>> code.
>>
>> > it might make sense to move the check a bit so it's still possible to reuse
>> > the code if it makes sense.
>>
>> What do you mean by "move the check a bit", I don't get it. Which "check",
>> "move" where (or when)?

> Move the autohide timer check into a separate function, call that
> function from GUI.
> For that you'd have to move the WinID check into check_events instead
> of having it in hidecursor.

Oh, I see.

If you prefer this solution, I'm fine with it, although it seems more
complicated. We'd need a 1.patch to move the autohide into a separate
function, 2.patch to block it for WinIDs and 3.patch for the GUI to
implement autohide.

On the other hand, we could simply have a.patch to block WinIDs and a
b.patch for the GUI to implement autohide.

It's your call. What would you like?

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 2842 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110906/25fcce56/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.patch
Type: text/x-diff
Size: 1641 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110906/25fcce56/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3.patch
Type: text/x-diff
Size: 798 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110906/25fcce56/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a.patch
Type: text/x-diff
Size: 848 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110906/25fcce56/attachment-0003.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: b.patch
Type: text/x-diff
Size: 1388 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110906/25fcce56/attachment-0004.bin>

From ted at tedpavlic.com  Tue Sep  6 19:37:34 2011
From: ted at tedpavlic.com (Ted Pavlic)
Date: Tue, 06 Sep 2011 13:37:34 -0400
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
Message-ID: <4E665A5E.7010409@tedpavlic.com>

Mplayer devs --

	I'm sorry if this question doesn't belong here, but this seems to be
something that most users are clueless about.

	I've noticed that when mplayer (and ffplay, actually) is running, my
monitors never turn off even though "xset q" shows that DPMS is enabled
and timeouts are set correctly. I've toyed with nostop-xscreensaver and
heartbeat-cmd, but they don't seem to have anything to do with it.

	The popular fractal flame distributed computing screensaver
electricsheep uses mplayer to display its AVI files on Linux.
Consequently, whenever electricsheep runs, my monitors fail to ever
standby, suspend, and turn off.

	I did notice that I can "xset force dpms off" and the monitors stay off
despite mplayer being up and running (forcing suspend or standby doesn't
work; they pop back on). So I've written an electricsheep wrapper script
that periodically turns the monitors off via DPMS at regular intervals.
This is an OK stopgap solution, but it's not perfect.

	If mplayer is disabling the DPMS timeouts, is there any way to prevent
that? Or was the design decision made that no one would ever want DPMS
timeouts to trigger while playing video through mplayer?

	Thanks --
	Ted

-- 
Ted Pavlic <ted at tedpavlic.com>

From diego at biurrun.de  Tue Sep  6 19:54:01 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Tue, 06 Sep 2011 19:54:01 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen config file
In-Reply-To: <4e65f9a9.0aff9a3f.bm000@wupperonline.de>
References: <4e65f9a9.0aff9a3f.bm000@wupperonline.de>
Message-ID: <20110906175401.GA16617@pool.informatik.rwth-aachen.de>

On Tue, Sep 06, 2011 at 12:44:55PM +0200, Ingo Br?ckl wrote:
> This would allow commenting a group, like
> 
>   //@{
>   /// Playing states
>   #define GUI_STOP  0
>   #define GUI_PLAY  1
>   #define GUI_PAUSE 2
>   //@}
> 
> instead of repeating the comment for every line.

OK with me.

Diego

From tempn at twmi.rr.com  Tue Sep  6 21:48:12 2011
From: tempn at twmi.rr.com (compn)
Date: Tue, 6 Sep 2011 15:48:12 -0400
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <4E665A5E.7010409@tedpavlic.com>
References: <4E665A5E.7010409@tedpavlic.com>
Message-ID: <20110906154812.be97dd62.tempn@twmi.rr.com>

On Tue, 06 Sep 2011 13:37:34 -0400, Ted Pavlic wrote:
>electricsheep uses mplayer to display its AVI files on Linux.

did you test with plain mplayer? just want to make sure electricsheep
isnt part of the problem.

what version of mplayer are you using? older versions of mplayer would
reset dpms because otherwise it would shut down the monitor while
mplayer was in the middle of a movie.

i dont know the current status.

-compn

From ted at tedpavlic.com  Tue Sep  6 21:50:35 2011
From: ted at tedpavlic.com (Ted Pavlic)
Date: Tue, 06 Sep 2011 15:50:35 -0400
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <20110906154812.be97dd62.tempn@twmi.rr.com>
References: <4E665A5E.7010409@tedpavlic.com>
	<20110906154812.be97dd62.tempn@twmi.rr.com>
Message-ID: <4E66798B.4090209@tedpavlic.com>

>> electricsheep uses mplayer to display its AVI files on Linux.
> 
> did you test with plain mplayer? just want to make sure electricsheep
> isnt part of the problem.

Yep. If I run mplayer on an AVI directly, my monitors will stay awake
forever. Once I quit mplayer, monitors turn off as usual.

It turns out on ffplay, this problem is related to SDL. In particular,
if I set the variable:

SDL_VIDEO_ALLOW_SCREENSAVER

to 1, the the problem disappears with ffplay. That doesn't fix the
problem with mplayer (even if I set -vo sdl).

> what version of mplayer are you using? older versions of mplayer would
> reset dpms because otherwise it would shut down the monitor while
> mplayer was in the middle of a movie.

I have the problem on two machines:

Fedora 15: mplayer SVN-r33251-4.6.0
Arch Linux: mplayer SVN-r34007-4.6.1

	Thanks --
	Ted

-- 
Ted Pavlic <ted at tedpavlic.com>

From Reimar.Doeffinger at gmx.de  Tue Sep  6 22:16:22 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 6 Sep 2011 22:16:22 +0200
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <4E665A5E.7010409@tedpavlic.com>
References: <4E665A5E.7010409@tedpavlic.com>
Message-ID: <20110906201622.GA3206@1und1.de>

On Tue, Sep 06, 2011 at 01:37:34PM -0400, Ted Pavlic wrote:
> I've toyed with nostop-xscreensaver and

I think that option accidentally had no effect, can you try attached patch?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: screensave.diff
Type: text/x-diff
Size: 362 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110906/d7b08123/attachment.bin>

From ted at tedpavlic.com  Tue Sep  6 22:31:57 2011
From: ted at tedpavlic.com (Ted Pavlic)
Date: Tue, 06 Sep 2011 16:31:57 -0400
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <20110906201622.GA3206@1und1.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
Message-ID: <4E66833D.5050208@tedpavlic.com>

> On Tue, Sep 06, 2011 at 01:37:34PM -0400, Ted Pavlic wrote:
>> I've toyed with nostop-xscreensaver and
> 
> I think that option accidentally had no effect, can you try attached patch?

The patch works!

mplayer
mplayer -nostop-xscreensaver

both allow DPMS timeouts to be hit. If I add:

mplayer -stop-xscreensaver

then mplayer keeps the monitors on.

So the patch restores the expected behavior.

	Thanks --
	Ted

-- 
Ted Pavlic <ted at tedpavlic.com>

From auerswal at unix-ag.uni-kl.de  Wed Sep  7 10:30:01 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Wed, 7 Sep 2011 10:30:01 +0200
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable	DPMS
	timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <4E66833D.5050208@tedpavlic.com>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
Message-ID: <20110907083001.GA32239@sushi.unix-ag.uni-kl.de>

Hi,

On Tue, Sep 06, 2011 at 04:31:57PM -0400, Ted Pavlic wrote:
> > On Tue, Sep 06, 2011 at 01:37:34PM -0400, Ted Pavlic wrote:
> >> I've toyed with nostop-xscreensaver and
> > 
> > I think that option accidentally had no effect, can you try attached patch?
> 
> The patch works!
> 
> mplayer
> mplayer -nostop-xscreensaver
> 
> both allow DPMS timeouts to be hit. If I add:

That sounds like a bug (a regression; at least an undocumented change in
behaviour). Current mplayer (as of this weekend) and older versions as long
as I can remember stop the screensaver and DPMS from blanking the
monitor while watching a movie.

If some program calling mplayer to play some movies does wish to play a
movie that cannot be seen (because the monitor is turned off), that program
should specify the -nostop-xscreensaver option.

> mplayer -stop-xscreensaver

Do I need to add yet another option to my mplayer config to keep mplayer
working the way it should?

> then mplayer keeps the monitors on.

That was the long-standing default behaviour.

> So the patch restores the expected behavior.

No, it introduces a regression. This would not be the first such change of
behaviour to the worse (-nosub is needed for DVDs now-a-days, which was
not needed back-in-the-day).

Thanks,
Erik
-- 
Conventional Li-Ion batteries have been known to catch fire and explode.
                        -- Iddo Genuth

From nicolas.george at normalesup.org  Wed Sep  7 12:47:23 2011
From: nicolas.george at normalesup.org (Nicolas George)
Date: Wed, 7 Sep 2011 12:47:23 +0200
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
Message-ID: <20110907104723.GA9561@phare.normalesup.org>

Le primidi 21 fructidor, an CCXIX, Erik Auerswald a ?crit?:
> That sounds like a bug (a regression; at least an undocumented change in
> behaviour). Current mplayer (as of this weekend) and older versions as long
> as I can remember stop the screensaver and DPMS from blanking the
> monitor while watching a movie.
> 
> If some program calling mplayer to play some movies does wish to play a
> movie that cannot be seen (because the monitor is turned off), that program
> should specify the -nostop-xscreensaver option.

I tend to agree: -stop-screensaver should be the default.

Changing:

int stop_xscreensaver = 0;

to ... = 1 in libvo/x11_common.c should be enough.

> No, it introduces a regression. This would not be the first such change of
> behaviour to the worse (-nosub is needed for DVDs now-a-days, which was
> not needed back-in-the-day).

People who need subtitles would think it is a change for the best.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110907/1a5057e9/attachment.asc>

From Reimar.Doeffinger at gmx.de  Wed Sep  7 15:38:16 2011
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Wed, 7 Sep 2011 15:38:16 +0200
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
	timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <20110907104723.GA9561@phare.normalesup.org>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
Message-ID: <92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>

On 7 Sep 2011, at 12:47, Nicolas George <nicolas.george at normalesup.org> wrote:
> Le primidi 21 fructidor, an CCXIX, Erik Auerswald a ?crit :
>> That sounds like a bug (a regression; at least an undocumented change in
>> behaviour). Current mplayer (as of this weekend) and older versions as long
>> as I can remember stop the screensaver and DPMS from blanking the
>> monitor while watching a movie.
>> 
>> If some program calling mplayer to play some movies does wish to play a
>> movie that cannot be seen (because the monitor is turned off), that program
>> should specify the -nostop-xscreensaver option.
> 
> I tend to agree: -stop-screensaver should be the default.
> 
> Changing:
> 
> int stop_xscreensaver = 0;
> 
> to ... = 1 in libvo/x11_common.c should be enough.

I have no objections, I just didn't get around to it.

> 
>> No, it introduces a regression. This would not be the first such change of
>> behaviour to the worse (-nosub is needed for DVDs now-a-days, which was
>> not needed back-in-the-day).
> 
> People who need subtitles would think it is a change for the best.

It should be a similarly easy thing to change the default for that too.
Never considered it relevant enough to bother though.
Well, it might be a bit more involved, since I think it needs also a change to allow -sid -1 otherwise the current behaviour becomes completely unaccessible.

From ted at tedpavlic.com  Wed Sep  7 17:47:47 2011
From: ted at tedpavlic.com (Ted Pavlic)
Date: Wed, 07 Sep 2011 11:47:47 -0400
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
Message-ID: <4E679223.7060601@tedpavlic.com>

>> I tend to agree: -stop-screensaver should be the default.
>>
>> Changing:
>>
>> int stop_xscreensaver = 0;
>>
>> to ... = 1 in libvo/x11_common.c should be enough.
> 
> I have no objections, I just didn't get around to it.

FYI, so long as

-nostop-xscreensaver

works as documented, I think this is a good fix. Existing screensavers
that use mplayer (including electricsheep) have been using the
nostop-xscreensaver option. It's just nice that it works again.

Thanks.
--Ted

-- 
Ted Pavlic <ted at tedpavlic.com>

From Reimar.Doeffinger at gmx.de  Wed Sep  7 18:11:43 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 7 Sep 2011 18:11:43 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e665347.243f6a2b.bm000@wupperonline.de>
References: <20110905173224.GA29004@1und1.de>
	<4e665347.243f6a2b.bm000@wupperonline.de>
Message-ID: <20110907161143.GA8880@1und1.de>

On Tue, Sep 06, 2011 at 06:43:01PM +0200, Ingo Br?ckl wrote:
> On the other hand, we could simply have a.patch to block WinIDs and a
> b.patch for the GUI to implement autohide.

For that one the GUI code seems broken, if mouse_time is 0 by pure
chance the mouse pointer seems to get stuck on.

> +void vo_x11_show_autohide_cursor(Display * mydisplay, int start)

"start" seems like a bad name, rather "show", "movement", "reset" or something
like that would fit better IMO.
And "show" is a bit confusing as well, maybe "handle" or such instead?

> +  if (start) {
> +      vo_showcursor(mydisplay, vo_window);
> +      mouse_waiting_hide = 1;
> +      mouse_timer = GetTimerMS();
> +  }
> +  else if (mouse_waiting_hide && (GetTimerMS() - mouse_timer >= 1000)) {
> +      vo_hidecursor(mydisplay, vo_window);
> +      mouse_waiting_hide = 0;

Since I think they are no more used anywhere else,
mouse_waiting_hide and mouse_timer variables should be moved into
this function.

> +        vo_x11_show_autohide_cursor(mydisplay, VO_FALSE);

Just 0/1 is better than VO_TRUE/VO_FALSE, especially for code that will
be used from the GUI.
Otherwise that seems like a fine solution to me...

From diego at biurrun.de  Wed Sep  7 19:56:40 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Wed, 07 Sep 2011 19:56:40 +0200
Subject: [MPlayer-dev-eng] [PATCH] ignore "make clean" errors in ffmpeg/
In-Reply-To: <20110905221550.GA24232@1und1.de>
References: <20110905221550.GA24232@1und1.de>
Message-ID: <20110907175640.GA24476@pool.informatik.rwth-aachen.de>

On Tue, Sep 06, 2011 at 12:15:50AM +0200, Reimar D?ffinger wrote:
> if e.g. config.mak for example disappeared, the "make -C ffmpeg clean"
> will fail and then none of the MPlayer binaries will be removed.
> There is likely a better way, but attached patch would just ignore any
> failures so that at least the MPlayer binaries will be removed no
> matter what.

OK

Diego

From ib at wupperonline.de  Wed Sep  7 17:44:13 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 07 Sep 2011 17:44:13 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen config file
In-Reply-To: <20110906175401.GA16617@pool.informatik.rwth-aachen.de>
Message-ID: <4e67914e.621b85e0.bm000@wupperonline.de>

Diego Biurrun wrote on Tue, 06 Sep 2011 19:54:01 +0200:

> On Tue, Sep 06, 2011 at 12:44:55PM +0200, Ingo Br?ckl wrote:
>> This would allow commenting a group, like
>>
>>   //@{
>>   /// Playing states
>>   #define GUI_STOP  0
>>   #define GUI_PLAY  1
>>   #define GUI_PAUSE 2
>>   //@}
>>
>> instead of repeating the comment for every line.

> OK with me.

Thanks, applied.

Ingo

From ib at wupperonline.de  Thu Sep  8 01:09:28 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 08 Sep 2011 01:09:28 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110907161143.GA8880@1und1.de>
Message-ID: <4e67fa39.6e7c104f.bm000@wupperonline.de>

Reimar D?ffinger wrote on Wed, 7 Sep 2011 18:11:43 +0200:

> On Tue, Sep 06, 2011 at 06:43:01PM +0200, Ingo Br?ckl wrote:
>> b.patch for the GUI to implement autohide.

> For that one the GUI code seems broken, if mouse_time is 0 by pure
> chance the mouse pointer seems to get stuck on.

As you prefer the other solution, it may no longer be important by I'm
curious. What do you mean by "0 by pure chance"? If it gets 0 somewhere
else than at @@ -614,6 +618,11 @@? That would be a programming error.
GetTimerMS() returning 0?

>> +void vo_x11_show_autohide_cursor(Display * mydisplay, int start)

> [...]
> Otherwise that seems like a fine solution to me...

I revised it and post it again for final approval.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 3080 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110908/97f08c34/attachment.bin>

From Reimar.Doeffinger at gmx.de  Thu Sep  8 10:53:01 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 8 Sep 2011 10:53:01 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e67fa39.6e7c104f.bm000@wupperonline.de>
References: <20110907161143.GA8880@1und1.de>
	<4e67fa39.6e7c104f.bm000@wupperonline.de>
Message-ID: <20110908085301.GB2182@1und1.de>

On Thu, Sep 08, 2011 at 01:09:28AM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Wed, 7 Sep 2011 18:11:43 +0200:
> 
> > On Tue, Sep 06, 2011 at 06:43:01PM +0200, Ingo Br?ckl wrote:
> >> b.patch for the GUI to implement autohide.
> 
> > For that one the GUI code seems broken, if mouse_time is 0 by pure
> > chance the mouse pointer seems to get stuck on.
> 
> As you prefer the other solution, it may no longer be important by I'm
> curious. What do you mean by "0 by pure chance"? If it gets 0 somewhere
> else than at @@ -614,6 +618,11 @@? That would be a programming error.
> GetTimerMS() returning 0?

Yes. GetTimerMS overflows every 48 days, also it currently (somewhat
incorrectly) uses a non-monotonous timer, so it also can become
0/overflow/whatever due to a NTP time change.

> +  }
> +  else if (mouse_waiting_hide && (GetTimerMS() - mouse_timer >= 1000)) {

Cosmetic nit: put them on a single line, I think that should be more
consistent with other code.
Otherwise I like it, I think the code now is better than it was before.

From Reimar.Doeffinger at gmx.de  Thu Sep  8 10:54:01 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 8 Sep 2011 10:54:01 +0200
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
Message-ID: <20110908085401.GC2182@1und1.de>

On Wed, Sep 07, 2011 at 03:38:16PM +0200, Reimar D?ffinger wrote:
> On 7 Sep 2011, at 12:47, Nicolas George <nicolas.george at normalesup.org> wrote:
> > Le primidi 21 fructidor, an CCXIX, Erik Auerswald a ?crit :
> >> That sounds like a bug (a regression; at least an undocumented change in
> >> behaviour). Current mplayer (as of this weekend) and older versions as long
> >> as I can remember stop the screensaver and DPMS from blanking the
> >> monitor while watching a movie.
> >> 
> >> If some program calling mplayer to play some movies does wish to play a
> >> movie that cannot be seen (because the monitor is turned off), that program
> >> should specify the -nostop-xscreensaver option.
> > 
> > I tend to agree: -stop-screensaver should be the default.
> > 
> > Changing:
> > 
> > int stop_xscreensaver = 0;
> > 
> > to ... = 1 in libvo/x11_common.c should be enough.
> 
> I have no objections, I just didn't get around to it.

I changed it, everyone please complain if you don't like something
about how it works now.

From ikalvachev at gmail.com  Thu Sep  8 13:23:28 2011
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Thu, 8 Sep 2011 14:23:28 +0300
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <20110908085401.GC2182@1und1.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
	<20110908085401.GC2182@1und1.de>
Message-ID: <CABA=pqeJjoEKYG8UirNwrbmSAxRRJknj7uZkNHW_Q4=+=4hYCg@mail.gmail.com>

On 9/8/11, Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:
> On Wed, Sep 07, 2011 at 03:38:16PM +0200, Reimar D?ffinger wrote:
>> On 7 Sep 2011, at 12:47, Nicolas George <nicolas.george at normalesup.org>
>> wrote:
>> > Le primidi 21 fructidor, an CCXIX, Erik Auerswald a ?crit :
>> >> That sounds like a bug (a regression; at least an undocumented change
>> >> in
>> >> behaviour). Current mplayer (as of this weekend) and older versions as
>> >> long
>> >> as I can remember stop the screensaver and DPMS from blanking the
>> >> monitor while watching a movie.
>> >>
>> >> If some program calling mplayer to play some movies does wish to play a
>> >> movie that cannot be seen (because the monitor is turned off), that
>> >> program
>> >> should specify the -nostop-xscreensaver option.
>> >
>> > I tend to agree: -stop-screensaver should be the default.
>> >
>> > Changing:
>> >
>> > int stop_xscreensaver = 0;
>> >
>> > to ... = 1 in libvo/x11_common.c should be enough.
>>
>> I have no objections, I just didn't get around to it.
>
> I changed it, everyone please complain if you don't like something
> about how it works now.

Just to be clear.
I think that DPMS should have its own option.

There are many buggy (intel) drivers that e.g. turn off the backlight
when dpms is turned off. When workarounding such bug you'd want to be
able to disable dpms and still stop the screensaver from jumping over
your movie.

(There is also a feature request, to have a mode where pausing a movie
restores dpms & screensaver).

From eclipse7 at gmx.net  Thu Sep  8 19:25:53 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Thu, 8 Sep 2011 19:25:53 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e67fa39.6e7c104f.bm000@wupperonline.de>
References: <20110907161143.GA8880@1und1.de>
	<4e67fa39.6e7c104f.bm000@wupperonline.de>
Message-ID: <20110908172553.GA3954@tane>

Hi

Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Wed, 7 Sep 2011 18:11:43 +0200:
[...]
> > Otherwise that seems like a fine solution to me...
> 
> I revised it and post it again for final approval.

> Index: libvo/x11_common.c
> ===================================================================
> --- libvo/x11_common.c	(revision 34077)
> +++ libvo/x11_common.c	(working copy)
> @@ -790,9 +790,6 @@
>      }
>  }
>  
> -static unsigned int mouse_timer;
> -static int mouse_waiting_hide;
> -
>  static int check_resize(void)
>  {
>      int old_w = vo_dwidth, old_h = vo_dheight;
> @@ -806,6 +803,22 @@
>      return rc;
>  }
>  
> +void vo_x11_handle_autohide_cursor(Display * mydisplay, int show)
> +{
> +  static unsigned int mouse_timer;
> +  static int mouse_waiting_hide;
> +
> +  if (show) {
> +      vo_showcursor(mydisplay, vo_window);
> +      mouse_waiting_hide = 1;
> +      mouse_timer = GetTimerMS();
> +  }
> +  else if (mouse_waiting_hide && (GetTimerMS() - mouse_timer >= 1000)) {
> +      vo_hidecursor(mydisplay, vo_window);
> +      mouse_waiting_hide = 0;
> +  }
> +}

  It could probably be made to not actually hide/show the cursor and
instead leave that to the calling code. But if you don't need that
level of control I am in favor of this solution.

[...]
> +void vo_x11_handle_autohide_cursor(Display * mydisplay, int show);

  Small nit: I generally don't like parameter names like mysomething,
so if you could name it dpy I would be thankful.

  The patch looks good otherwise.

[...]

Greetings,
  Alexander

From auerswal at unix-ag.uni-kl.de  Thu Sep  8 22:15:16 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Thu, 8 Sep 2011 22:15:16 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility off
	(was Re:	 Question for dev's: Does mplayer disable
	DPMS	timeouts? "xset q" looks good, but timeouts never trigger)
In-Reply-To: <92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
Message-ID: <20110908201516.GB21744@sushi.unix-ag.uni-kl.de>

Hi,

On Wed, Sep 07, 2011 at 03:38:16PM +0200, Reimar D?ffinger wrote:
> On 7 Sep 2011, at 12:47, Nicolas George <nicolas.george at normalesup.org> wrote:
> > Le primidi 21 fructidor, an CCXIX, Erik Auerswald a ?crit :
> [...]
> >> No, it introduces a regression. This would not be the first such change of
> >> behaviour to the worse (-nosub is needed for DVDs now-a-days, which was
> >> not needed back-in-the-day).
> > 
> > People who need subtitles would think it is a change for the best.
> 
> It should be a similarly easy thing to change the default for that too.
> Never considered it relevant enough to bother though.
> Well, it might be a bit more involved, since I think it needs also
> a change to allow -sid -1 otherwise the current behaviour becomes
> completely unaccessible.

My goal is to see no subtitles unless explicitly specifying some. Having a
default subtitle language set should not count as specifying a subtitle. It
should just provide a useful default selection for switching on subtitle
visibility interactively.

I took a first look at the code and came up with the untested idea in the
attached patch. Since I currently have no DVDs handy I can't even test if
this does what I want it to. Comments welcome. :-)

Handle with care, the patch is completely untested and might drink all
your beer. ;-)

Thanks,
Erik
-- 
Once is happenstance. Twice is coincidence. Three times is enemy action.
                        -- Auric Goldfinger
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-subtitle-visibility.RFC.patch
Type: text/x-diff
Size: 835 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110908/86b6e581/attachment.bin>

From Dan.Oscarsson at tieto.com  Fri Sep  9 07:59:14 2011
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Fri, 09 Sep 2011 07:59:14 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility
 off (was Re:	 Question for dev's: Does mplayer disable DPMS	timeouts? "xset
 q" looks good, but timeouts never trigger)
In-Reply-To: <20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
References: <4E665A5E.7010409@tedpavlic.com>
	<20110906201622.GA3206@1und1.de> <4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
Message-ID: <1315547954.15632.67.camel@valinor.malmo.kicore.net>

tor 2011-09-08 klockan 22:15 +0200 skrev Erik Auerswald:

> 
> My goal is to see no subtitles unless explicitly specifying some. Having a
> default subtitle language set should not count as specifying a subtitle. It
> should just provide a useful default selection for switching on subtitle
> visibility interactively.

For me, who understands Swedish or English, the preferred way would be
for a video player to, by default, show the Swedish or English subtitle
if audio is in some other language. I have not looked at the code to see
if something like that is possible, and language information in media is
not always correct, so it may not be easy to implement.

   Dan


From ib at wupperonline.de  Fri Sep  9 11:52:16 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 09 Sep 2011 11:52:16 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110908172553.GA3954@tane>
Message-ID: <4e69e945.5416bf3c.bm000@wupperonline.de>

Alexander Strasser wrote on Thu, 8 Sep 2011 19:25:53 +0200:

> Ingo Br?ckl wrote:
>>
>> +void vo_x11_handle_autohide_cursor(Display * mydisplay, int show)

> It could probably be made to not actually hide/show the cursor and instead
> leave that to the calling code. But if you don't need that level of control
> I am in favor of this solution.

That is an interesting idea and I'll keep that in mind, but the hide/show
will do me fine.

>> +void vo_x11_handle_autohide_cursor(Display * mydisplay, int show);

> Small nit: I generally don't like parameter names like mysomething, so if
> you could name it dpy I would be thankful.

Sure.

Ingo

From ib at wupperonline.de  Fri Sep  9 17:09:24 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 09 Sep 2011 17:09:24 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <4e577c98.7dd86f12.bm000@wupperonline.de>
Message-ID: <4e6a34dc.71737836.bm000@wupperonline.de>

After reworking the GUI fullscreen code, there are two vo_x11 functions left
which I'd like to use, but currently can't.

vo_x11_setlayer() is blocked by WinID >= 0, vo_x11.1.patch could unblock it.

(If accepted, we probably should likewise patch vo_x11_border()
[vo_x11.2.patch], although I don't need that, because I'm using an own
GUI decoration function.)

vo_x11_sizehint() uses global mDisplay and vo_window and I'd need these as
parameters as in vo_x11.3.patch. (But I could use own sizehint code which is
in the GUI function that creates a window just as well. This code could be
extracted into an own function and called then, which may be the better
solution.)

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_x11.1.patch
Type: text/x-diff
Size: 989 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110909/650a503d/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_x11.2.patch
Type: text/x-diff
Size: 408 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110909/650a503d/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vo_x11.3.patch
Type: text/x-diff
Size: 1996 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110909/650a503d/attachment-0002.bin>

From nicolas.george at normalesup.org  Fri Sep  9 20:33:30 2011
From: nicolas.george at normalesup.org (Nicolas George)
Date: Fri, 9 Sep 2011 20:33:30 +0200
Subject: [MPlayer-dev-eng] Question for dev's: Does mplayer disable DPMS
 timeouts? "xset q" looks good, but timeouts never trigger
In-Reply-To: <CABA=pqeJjoEKYG8UirNwrbmSAxRRJknj7uZkNHW_Q4=+=4hYCg@mail.gmail.com>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
	<20110908085401.GC2182@1und1.de>
	<CABA=pqeJjoEKYG8UirNwrbmSAxRRJknj7uZkNHW_Q4=+=4hYCg@mail.gmail.com>
Message-ID: <20110909183330.GD23214@phare.normalesup.org>

Le duodi 22 fructidor, an CCXIX, Ivan Kalvachev a ?crit?:
> I think that DPMS should have its own option.
> 
> There are many buggy (intel) drivers that e.g. turn off the backlight
> when dpms is turned off. When workarounding such bug you'd want to be
> able to disable dpms and still stop the screensaver from jumping over
> your movie.

I was not aware of that problem (yet, I have several boxes with Intel
drivers and sometimes disabled DPMS), but it is indeed clearly an issue.

An additional option for DPMS would be pretty easy.

Is it possible to identify reliably the faulty drivers?

> (There is also a feature request, to have a mode where pausing a movie
> restores dpms & screensaver).

This should be pretty easy too, in fact. Currently, mplayer has two ways of
preventing the screen saver from obscuring the video:

- suspend it with XScreenSaverSuspend (which is the correct way to do it, as
  its effect is reset when the client exits), see xss_suspend in x11_common.

- reset the inactivity timer with XResetScreenSaver (potentially at each
  frame, but it is limited to only once each 30 seconds), see
  xscreensaver_heartbeat in x11_common.

Both are controlled by the same option, and, unless I am mistaken, both
should be enough to prevent non-bogus screen savers from obscuring a video.

Having only the second one should give you the feature you want.

The hard part is to decide of a way for the user to specify the mode he
wants. Having a zillion options is probably not the best way. Some kind of
flag mask may be the way to go.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110909/4fba6eef/attachment.asc>

From auerswal at unix-ag.uni-kl.de  Fri Sep  9 21:54:02 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Fri, 09 Sep 2011 21:54:02 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility
 off	(was Re:	 Question for dev's: Does mplayer disable	DPMS	timeouts? "xset
 q" looks good, but timeouts never trigger)
In-Reply-To: <20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
References: <4E665A5E.7010409@tedpavlic.com>
	<20110906201622.GA3206@1und1.de>	<4E66833D.5050208@tedpavlic.com>	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>	<20110907104723.GA9561@phare.normalesup.org>	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
Message-ID: <4E6A6EDA.8080200@unix-ag.uni-kl.de>

Hi,

On 09/08/2011 10:15 PM, Erik Auerswald wrote:
> On Wed, Sep 07, 2011 at 03:38:16PM +0200, Reimar D?ffinger wrote:
>> On 7 Sep 2011, at 12:47, Nicolas George<nicolas.george at normalesup.org>  wrote:
>>> Le primidi 21 fructidor, an CCXIX, Erik Auerswald a ?crit :
>> [...]
>>>> No, it introduces a regression. This would not be the first such change of
>>>> behaviour to the worse (-nosub is needed for DVDs now-a-days, which was
>>>> not needed back-in-the-day).
>>>
>>> People who need subtitles would think it is a change for the best.
>>
>> It should be a similarly easy thing to change the default for that too.
>> Never considered it relevant enough to bother though.
>> Well, it might be a bit more involved, since I think it needs also
>> a change to allow -sid -1 otherwise the current behaviour becomes
>> completely unaccessible.
>
> My goal is to see no subtitles unless explicitly specifying some. Having a
> default subtitle language set should not count as specifying a subtitle. It
> should just provide a useful default selection for switching on subtitle
> visibility interactively.
>
> I took a first look at the code and came up with the untested idea in the
> attached patch. Since I currently have no DVDs handy I can't even test if
> this does what I want it to. Comments welcome. :-)

Well, that patch did not even compile...

The attached patch (actually tested) is a definite improvement for me. 
When specifying -slang XX or having a suitably named .srt file lying 
near a movie, subtitles are displayed. But the mere presence of 
subtitles on a DVD does not result in displaying them automatically.

Pleas consider applying.

Thanks,
Erik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer-sub-visibility.patch
Type: text/x-diff
Size: 752 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110909/48c297a6/attachment.bin>

From ib at wupperonline.de  Sat Sep 10 14:05:02 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sat, 10 Sep 2011 14:05:02 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110908085301.GB2182@1und1.de>
Message-ID: <4e6b5321.66007e40.bm000@wupperonline.de>

Reimar D?ffinger wrote on Thu, 8 Sep 2011 10:53:01 +0200:

> Otherwise I like it, I think the code now is better than it was before.

I was just preparing the patch series for GUI's full cursor control and
running the final tests when I noticed that I'd need a Window parameter
in the new vo_x11_handle_autohide_cursor() (revised patch attached).

The reason for these parameters in vo_x11 functions I call from the GUI is
that they must handle the sub window (the video window) of the GUI even
before/without a video driver being loaded (i.e. without vo_window already
being set).

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1.patch
Type: text/x-diff
Size: 3117 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110910/d2727b82/attachment.bin>

From eclipse7 at gmx.net  Sat Sep 10 15:33:52 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 10 Sep 2011 15:33:52 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <4e6a34dc.71737836.bm000@wupperonline.de>
References: <4e577c98.7dd86f12.bm000@wupperonline.de>
	<4e6a34dc.71737836.bm000@wupperonline.de>
Message-ID: <20110910133351.GA3929@tane>

Hi Ingo,

Ingo Br?ckl wrote:
> After reworking the GUI fullscreen code, there are two vo_x11 functions left
> which I'd like to use, but currently can't.
> 
> vo_x11_setlayer() is blocked by WinID >= 0, vo_x11.1.patch could unblock it.

  OK

> (If accepted, we probably should likewise patch vo_x11_border()
> [vo_x11.2.patch], although I don't need that, because I'm using an own
> GUI decoration function.)

  OK

> vo_x11_sizehint() uses global mDisplay and vo_window and I'd need these as
> parameters as in vo_x11.3.patch. (But I could use own sizehint code which is
> in the GUI function that creates a window just as well. This code could be
> extracted into an own function and called then, which may be the better
> solution.)

  I think it is OK doing it this way.

  In general I am a bit concerned about the WinID handling inside
the x11_common and the x11 based vo drivers. But I think it is not
worse with the patches.

  Maybe wait a day or two for additional comments from Reimar.

  Nice work!

> Index: libvo/x11_common.c
> ===================================================================
> --- libvo/x11_common.c	(revision 34097)
> +++ libvo/x11_common.c	(working copy)
> @@ -1206,7 +1206,7 @@
>  
>  void vo_x11_setlayer(Display * mDisplay, Window vo_window, int layer)
>  {
> -    if (WinID >= 0)
> +    if (!WinID)
>          return;
>  
>      if (vo_fs_type & vo_wm_LAYER)
> @@ -1431,7 +1431,7 @@
>  {
>      vo_ontop = (!(vo_ontop));
>  
> -    vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
> +    if (WinID < 0) vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
>  }
>  
>  void vo_x11_border(void)
> Index: libvo/vo_dxr2.c
> ===================================================================
> --- libvo/vo_dxr2.c	(revision 34097)
> +++ libvo/vo_dxr2.c	(working copy)
> @@ -719,7 +719,7 @@
>      break;
>    }
>  
> -  if (vo_ontop) vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
> +  if (vo_ontop && WinID < 0) vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
>  
>    // start playing
>    if(ioctl(dxr2_fd, DXR2_IOC_PLAY, NULL) == 0) {

> Index: libvo/x11_common.c
> ===================================================================
> --- libvo/x11_common.c	(revision 34097)
> +++ libvo/x11_common.c	(working copy)
> @@ -1437,7 +1437,7 @@
>  void vo_x11_border(void)
>  {
>      vo_border = !vo_border;
> -    vo_x11_decoration(mDisplay, vo_window, vo_border && !vo_fs);
> +    if (WinID < 0) vo_x11_decoration(mDisplay, vo_window, vo_border && !vo_fs);
>  }
>  
>  /*

> Index: libvo/x11_common.c
> ===================================================================
> --- libvo/x11_common.c	(revision 34097)
> +++ libvo/x11_common.c	(working copy)
> @@ -942,7 +942,7 @@
>   */
>  void vo_x11_nofs_sizepos(int x, int y, int width, int height)
>  {
> -  vo_x11_sizehint(x, y, width, height, 0);
> +  vo_x11_sizehint(mDisplay, vo_window, x, y, width, height, 0);
>    if (vo_fs) {
>      vo_old_x = x;
>      vo_old_y = y;
> @@ -957,7 +957,7 @@
>    }
>  }
>  
> -void vo_x11_sizehint(int x, int y, int width, int height, int max)
> +void vo_x11_sizehint(Display * dpy, Window win, int x, int y, int width, int height, int max)
>  {
>      vo_hint.flags = 0;
>      if (vo_keepaspect)
> @@ -999,7 +999,7 @@
>  
>      vo_hint.flags |= PWinGravity;
>      vo_hint.win_gravity = StaticGravity;
> -    XSetWMNormalHints(mDisplay, vo_window, &vo_hint);
> +    XSetWMNormalHints(dpy, win, &vo_hint);
>  }
>  
>  static int vo_x11_get_gnome_layer(Display * mDisplay, Window win)
> @@ -1410,7 +1410,7 @@
>      if ( ! (vo_fs_type & vo_wm_FULLSCREEN) ) // not needed with EWMH fs
>      {
>          vo_x11_decoration(mDisplay, vo_window, vo_border && !vo_fs);
> -        vo_x11_sizehint(x, y, w, h, 0);
> +        vo_x11_sizehint(mDisplay, vo_window, x, y, w, h, 0);
>          vo_x11_setlayer(mDisplay, vo_window, vo_fs);
>  
>  
> Index: libvo/x11_common.h
> ===================================================================
> --- libvo/x11_common.h	(revision 34097)
> +++ libvo/x11_common.h	(working copy)
> @@ -66,7 +66,7 @@
>  void vo_x11_decoration( Display * vo_Display,Window w,int d );
>  void vo_x11_classhint( Display * display,Window window,const char *name );
>  void vo_x11_nofs_sizepos(int x, int y, int width, int height);
> -void vo_x11_sizehint( int x, int y, int width, int height, int max );
> +void vo_x11_sizehint( Display * dpy, Window win, int x, int y, int width, int height, int max );
>  int vo_x11_check_events(Display *mydisplay);
>  void vo_x11_selectinput_witherr(Display *display, Window w, long event_mask);
>  int vo_x11_update_geometry(void);


  Alexander

From eclipse7 at gmx.net  Sat Sep 10 15:34:33 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 10 Sep 2011 15:34:33 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e6b5321.66007e40.bm000@wupperonline.de>
References: <20110908085301.GB2182@1und1.de>
	<4e6b5321.66007e40.bm000@wupperonline.de>
Message-ID: <20110910133433.GB3929@tane>

Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Thu, 8 Sep 2011 10:53:01 +0200:
> 
> > Otherwise I like it, I think the code now is better than it was before.
> 
> I was just preparing the patch series for GUI's full cursor control and
> running the final tests when I noticed that I'd need a Window parameter
> in the new vo_x11_handle_autohide_cursor() (revised patch attached).
> 
> The reason for these parameters in vo_x11 functions I call from the GUI is
> that they must handle the sub window (the video window) of the GUI even
> before/without a video driver being loaded (i.e. without vo_window already
> being set).

  Looks good to me.

  Alexander

From Reimar.Doeffinger at gmx.de  Sun Sep 11 11:29:05 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 11 Sep 2011 11:29:05 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <4e6a34dc.71737836.bm000@wupperonline.de>
References: <4e577c98.7dd86f12.bm000@wupperonline.de>
	<4e6a34dc.71737836.bm000@wupperonline.de>
Message-ID: <20110911092905.GA3205@1und1.de>

On Fri, Sep 09, 2011 at 05:09:24PM +0200, Ingo Br?ckl wrote:
> Index: libvo/x11_common.c
> ===================================================================
> --- libvo/x11_common.c	(revision 34097)
> +++ libvo/x11_common.c	(working copy)
> @@ -1206,7 +1206,7 @@
>  
>  void vo_x11_setlayer(Display * mDisplay, Window vo_window, int layer)
>  {
> -    if (WinID >= 0)
> +    if (!WinID)
>          return;
>  
>      if (vo_fs_type & vo_wm_LAYER)
> @@ -1431,7 +1431,7 @@
>  {
>      vo_ontop = (!(vo_ontop));
>  
> -    vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
> +    if (WinID < 0) vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
>  }

I very much dislike having half the WinID check in the function and the
other half outside.
I don't mind removing it completely, but IMO leaving the !WinID there is
confusing.
Even more so since it possibly should really check the vo_window
parameter instead of WinID.

From Reimar.Doeffinger at gmx.de  Sun Sep 11 11:31:29 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 11 Sep 2011 11:31:29 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e6b5321.66007e40.bm000@wupperonline.de>
References: <20110908085301.GB2182@1und1.de>
	<4e6b5321.66007e40.bm000@wupperonline.de>
Message-ID: <20110911093129.GB3205@1und1.de>

On Sat, Sep 10, 2011 at 02:05:02PM +0200, Ingo Br?ckl wrote:
>  
> +void vo_x11_handle_autohide_cursor(Display * dpy, Window win, int show)
> +{
> +  static unsigned int mouse_timer;
> +  static int mouse_waiting_hide;
> +
> +  if (show) {
> +      vo_showcursor(dpy, win);
> +      mouse_waiting_hide = 1;
> +      mouse_timer = GetTimerMS();
> +  } else if (mouse_waiting_hide && (GetTimerMS() - mouse_timer >= 1000)) {
> +      vo_hidecursor(dpy, win);
> +      mouse_waiting_hide = 0;
> +  }
> +}

Could you please add a bit of doxygen documentation?
Because the function signature might actually look like it would
work properly for multiple windows, but due to the mouse_timer/
mouse_waiting_hide variables being shared it will actually break
quite badly if someone ever tried to use it on multiple windows
at the same time.

From diego at biurrun.de  Sun Sep 11 19:36:00 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sun, 11 Sep 2011 19:36:00 +0200
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new libbluray API
Message-ID: <1315762560-16131-1-git-send-email-diego@biurrun.de>

From: Rico Tzschichholz <ricotz at ubuntu.com>

Switch to new libbluray API with three parameters to bd_get_title_info().
libbluray versions using the old API are no longer supported.

Signed-off-by: Diego Biurrun <diego at biurrun.de>
---
 configure              |    2 +-
 stream/stream_bluray.c |   14 +++++++-------
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index cbc5702..8ca5fbf 100755
--- a/configure
+++ b/configure
@@ -5738,7 +5738,7 @@ echores "$_vcd"
 echocheck "Blu-ray support"
 if test "$_bluray" = auto ; then
   _bluray=no
-  statement_check libbluray/bluray.h 'bd_get_title_info(0, 0)' -lbluray && _bluray=yes
+  statement_check libbluray/bluray.h 'bd_get_title_info(0, 0, 0)' -lbluray && _bluray=yes
 fi
 if test "$_bluray" = yes ; then
   def_bluray='#define CONFIG_LIBBLURAY 1'
diff --git a/stream/stream_bluray.c b/stream/stream_bluray.c
index 2ce6255..f46ea69 100644
--- a/stream/stream_bluray.c
+++ b/stream/stream_bluray.c
@@ -116,7 +116,7 @@ static int bluray_stream_control(stream_t *s, int cmd, void *arg)
     case STREAM_CTRL_GET_NUM_CHAPTERS: {
         BLURAY_TITLE_INFO *ti;
 
-        ti = bd_get_title_info(b->bd, b->current_title);
+        ti = bd_get_title_info(b->bd, b->current_title, b->current_angle);
         if (!ti)
             return STREAM_UNSUPPORTED;
 
@@ -137,7 +137,7 @@ static int bluray_stream_control(stream_t *s, int cmd, void *arg)
         int64_t pos;
         int r;
 
-        ti = bd_get_title_info(b->bd, b->current_title);
+        ti = bd_get_title_info(b->bd, b->current_title, b->current_angle);
         if (!ti)
             return STREAM_UNSUPPORTED;
 
@@ -156,7 +156,7 @@ static int bluray_stream_control(stream_t *s, int cmd, void *arg)
     case STREAM_CTRL_GET_NUM_ANGLES: {
         BLURAY_TITLE_INFO *ti;
 
-        ti = bd_get_title_info(b->bd, b->current_title);
+        ti = bd_get_title_info(b->bd, b->current_title, b->current_angle);
         if (!ti)
             return STREAM_UNSUPPORTED;
 
@@ -175,7 +175,7 @@ static int bluray_stream_control(stream_t *s, int cmd, void *arg)
         BLURAY_TITLE_INFO *ti;
         int angle = *((int *) arg);
 
-        ti = bd_get_title_info(b->bd, b->current_title);
+        ti = bd_get_title_info(b->bd, b->current_title, b->current_angle);
         if (!ti)
             return STREAM_UNSUPPORTED;
 
@@ -236,7 +236,7 @@ static int bluray_stream_open(stream_t *s, int mode,
     }
 
     /* check for available titles on disc */
-    title_count = bd_get_titles(bd, TITLES_RELEVANT);
+    title_count = bd_get_titles(bd, TITLES_RELEVANT, angle);
     mp_msg(MSGT_IDENTIFY, MSGL_INFO, "ID_BLURAY_TITLES=%d\n", title_count);
     if (!title_count) {
         mp_msg(MSGT_OPEN, MSGL_ERR, MSGTR_BlurayNoTitles);
@@ -250,7 +250,7 @@ static int bluray_stream_open(stream_t *s, int mode,
         BLURAY_TITLE_INFO *ti;
         int sec, msec;
 
-        ti = bd_get_title_info(bd, i);
+        ti = bd_get_title_info(bd, i, angle);
         if (!ti)
             continue;
 
@@ -284,7 +284,7 @@ static int bluray_stream_open(stream_t *s, int mode,
            "ID_BLURAY_CURRENT_TITLE=%d\n", title + 1);
 
     /* Get current title information */
-    info = bd_get_title_info(bd, title);
+    info = bd_get_title_info(bd, title, angle);
     if (!info)
         goto err_no_info;
 
-- 
1.7.1


From dominik at greysector.net  Sun Sep 11 20:19:30 2011
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Sun, 11 Sep 2011 20:19:30 +0200
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new
 libbluray API
In-Reply-To: <1315762560-16131-1-git-send-email-diego@biurrun.de>
References: <1315762560-16131-1-git-send-email-diego@biurrun.de>
Message-ID: <20110911180827.GA15557@ryvius.greysector.net>

Hi,

On Sunday, 11 September 2011 at 19:36, Diego Biurrun wrote:
> From: Rico Tzschichholz <ricotz at ubuntu.com>
> 
> Switch to new libbluray API with three parameters to bd_get_title_info().
> libbluray versions using the old API are no longer supported.

Which version has the new API?

Regards,
Dominik

-- 
MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan

From diego at biurrun.de  Mon Sep 12 10:45:23 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 12 Sep 2011 10:45:23 +0200
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new
 libbluray API
In-Reply-To: <20110911180827.GA15557@ryvius.greysector.net>
References: <1315762560-16131-1-git-send-email-diego@biurrun.de>
	<20110911180827.GA15557@ryvius.greysector.net>
Message-ID: <20110912084523.GA14263@pool.informatik.rwth-aachen.de>

On Sun, Sep 11, 2011 at 08:19:30PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> 
> On Sunday, 11 September 2011 at 19:36, Diego Biurrun wrote:
> > From: Rico Tzschichholz <ricotz at ubuntu.com>
> > 
> > Switch to new libbluray API with three parameters to bd_get_title_info().
> > libbluray versions using the old API are no longer supported.
> 
> Which version has the new API?

libbluray has not had formal releases yet and I expect there is no promise
of API stability.  The following two commits extend the API:

commit 80779fae8dbcf38a269e5d86e6acd75617f65ab4
Author: hpi1 <hpi1 at anonymous.org>
Date:   Tue May 10 15:21:08 2011 +0300

commit 17896a40e6ddbe12473db77549ff0207ef748a64
Author: hpi1 <hpi1 at anonymous.org>
Date:   Mon Jun 13 20:36:16 2011 +0300

I have not checked if further commits introduce API changes as well.
Ubuntu has packaged two snapshots named git20110213.20739ed and
git20110717.3477b65.  They have different major numbers.

Diego

From marcin.slusarz at gmail.com  Sat Sep 10 23:58:33 2011
From: marcin.slusarz at gmail.com (Marcin Slusarz)
Date: Sat, 10 Sep 2011 23:58:33 +0200
Subject: [MPlayer-dev-eng] [PATCH] xvmc: handle shm xvimage allocation error
Message-ID: <20110910215833.GA30222@joi.lan>

- handle xvimage/shm allocation failure and fallback to non-shm xv
- assert xvimage->data_size!=0 because 0 size will lead to memory corruptions
  (I hit it because of bug in Nouveau's early xvmc implementation)

Index: libvo/vo_xvmc.c
===================================================================
--- libvo/vo_xvmc.c	(wersja 34098)
+++ libvo/vo_xvmc.c	(kopia robocza)
@@ -181,6 +181,15 @@
     return cur_render->state || (cur_render->mpi && cur_render->mpi->usage_count);
 }
 
+static void allocate_xvimage_non_shm(int xvimage_width, int xvimage_height, int xv_format)
+{
+    xvimage = (XvImage *) XvCreateImage(mDisplay, xv_port, xv_format, NULL,
+                                        xvimage_width, xvimage_height);
+    assert(xvimage->data_size);
+    xvimage->data = malloc(xvimage->data_size);
+    XSync(mDisplay,False);
+}
+
 static void allocate_xvimage(int xvimage_width,int xvimage_height,int xv_format)
 {
  /*
@@ -188,7 +197,8 @@
   * mit-shm this will bomb... trzing to fix ::atmos
   */
 #ifdef HAVE_SHM
-    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) ) Shmem_Flag = 1;
+    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) )
+        Shmem_Flag = 0;
     else
     {
         Shmem_Flag = 0;
@@ -198,25 +208,41 @@
     {
         xvimage = (XvImage *) XvShmCreateImage(mDisplay, xv_port, xv_format,
                              NULL, xvimage_width, xvimage_height, &Shminfo);
+        if (!xvimage)
+            goto noshmimage;
 
+        assert(xvimage->data_size);
         Shminfo.shmid    = shmget(IPC_PRIVATE, xvimage->data_size, IPC_CREAT | 0777);
+        if (Shminfo.shmid == -1)
+            goto shmgetfail;
+
         Shminfo.shmaddr  = (char *) shmat(Shminfo.shmid, 0, 0);
+        if ((long)Shminfo.shmaddr == -1)
+            goto shmatfail;
+
         Shminfo.readOnly = False;
 
         xvimage->data = Shminfo.shmaddr;
-        XShmAttach(mDisplay, &Shminfo);
+        if (!XShmAttach(mDisplay, &Shminfo))
+            goto shmattachfail;
+
         XSync(mDisplay, False);
         shmctl(Shminfo.shmid, IPC_RMID, 0);
     }
     else
 #endif
-    {
-        xvimage = (XvImage *) XvCreateImage(mDisplay, xv_port, xv_format, NULL, xvimage_width, xvimage_height);
-        xvimage->data = malloc(xvimage->data_size);
-        XSync(mDisplay,False);
-    }
-// memset(xvimage->data,128,xvimage->data_size);
+    allocate_xvimage_non_shm(xvimage_width, xvimage_height, xv_format);
     return;
+
+shmattachfail:
+    shmdt(Shminfo.shmaddr);
+shmatfail:
+    shmctl(Shminfo.shmid, IPC_RMID, 0);
+shmgetfail:
+    XFree(xvimage);
+noshmimage:
+    Shmem_Flag = 0;
+    allocate_xvimage_non_shm(xvimage_width, xvimage_height, xv_format);
 }
 
 static void deallocate_xvimage(void)


From tempn at twmi.rr.com  Mon Sep 12 13:33:06 2011
From: tempn at twmi.rr.com (compn)
Date: Mon, 12 Sep 2011 07:33:06 -0400
Subject: [MPlayer-dev-eng] [PATCH]SPDIF pass through decoder
In-Reply-To: <CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>
References: <CAJz3U+WyC1FbN+yO3Rip=OkQVdwXyF6LXF8LgvrObtOiE0bH1w@mail.gmail.com>
	<20110811212406.GA17697@pool.informatik.RWTH-Aachen.DE>
	<CAJz3U+Ue=nau=C2mVf+0RmS+QoAQ8cA3yBKgA16fi6PCfT4n+w@mail.gmail.com>
	<loom.20110818T161554-16@post.gmane.org>
	<CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>
Message-ID: <20110912073306.5733189b.tempn@twmi.rr.com>

On Fri, 2 Sep 2011 01:53:10 +0900, Naoya OYAMA wrote:
>Hi, patch updated.

carl, are you going to apply this ? :)

-compn

From tempn at twmi.rr.com  Mon Sep 12 13:36:24 2011
From: tempn at twmi.rr.com (compn)
Date: Mon, 12 Sep 2011 07:36:24 -0400
Subject: [MPlayer-dev-eng] [patch] fix SPDIF output on Mac
In-Reply-To: <loom.20110822T054102-115@post.gmane.org>
References: <loom.20110822T054102-115@post.gmane.org>
Message-ID: <20110912073624.c3092e71.tempn@twmi.rr.com>

On Mon, 22 Aug 2011 03:49:47 +0000 (UTC), Zongyao Qu wrote:
>https://www.gitorious.org/mplayer-for-mplayerx/
>mplayer/commit/b41d5d28fe2b2087e94e2facd035efb79dc0e93b

i have attached the patch, from this url:
https://www.gitorious.org/mplayer-for-mplayerx/mplayer/commit/b41d5d28fe2b2087e94e2facd035efb79dc0e93b?format=patch

(sorry, i didnt check mplayer-dev-eng moderation queue in a while)

-compn
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patch.txt
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110912/5ffc04d5/attachment.txt>

From ib at wupperonline.de  Mon Sep 12 16:13:55 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 12 Sep 2011 16:13:55 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <20110911092905.GA3205@1und1.de>
Message-ID: <4e6e18b9.5b4b1e52.bm001@wupperonline.de>

Reimar D?ffinger wrote on Sun, 11 Sep 2011 11:29:05 +0200:

> On Fri, Sep 09, 2011 at 05:09:24PM +0200, Ingo Br?ckl wrote:
>> Index: libvo/x11_common.c
>> ===================================================================
>> --- libvo/x11_common.c        (revision 34097)
>> +++ libvo/x11_common.c        (working copy)
>> @@ -1206,7 +1206,7 @@
>>
>>  void vo_x11_setlayer(Display * mDisplay, Window vo_window, int layer)
>>  {
>> -    if (WinID >= 0)
>> +    if (!WinID)
>>          return;
>>
>>      if (vo_fs_type & vo_wm_LAYER)
>> @@ -1431,7 +1431,7 @@
>>  {
>>      vo_ontop = (!(vo_ontop));
>>
>> -    vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
>> +    if (WinID < 0) vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
>>  }

> I very much dislike having half the WinID check in the function and the
> other half outside.

The inside check has a different meaning.

> I don't mind removing it completely, but IMO leaving the !WinID there is
> confusing.
> Even more so since it possibly should really check the vo_window parameter
> instead of WinID.

Actually, it is checked whether vo_window is the root window (although
indirectly, because vo_window is the root window if WinID is 0). The same
check is done in vo_x11_decoration().

Alexander Strasser wrote on Sat, 10 Sep 2011 15:33:52 +0200:

> In general I am a bit concerned about the WinID handling inside the
> x11_common and the x11 based vo drivers.

Me too.

After reconsidering the patches, I've come to the conclusion that we don't
need the various WinID < 0 conditions - in fact shouldn't have them.
vo_x11_ontop() and vo_x11_border() are only called via control/VOCTRL which
should be allowed. Patching vo_dxr2 would retain its current behavior, but
I'd say it currently has the same ontop bug as the GUI (ontop doesn't work)
and not patching vo_dxr2 would enable ontop now.

So the only remaining patch is:

Index: libvo/x11_common.c
===================================================================
--- libvo/x11_common.c	(revision 34097)
+++ libvo/x11_common.c	(working copy)
@@ -1206,7 +1206,7 @@

 void vo_x11_setlayer(Display * mDisplay, Window vo_window, int layer)
 {
-    if (WinID >= 0)
+    if (!WinID)
         return;

     if (vo_fs_type & vo_wm_LAYER)

and - maybe - the vo_x11_sizehint() patch to add parameters (but I'll check
whether I can do this with existing GUI code first.)

Other WinID conditions could be prevented by the simple vo_hidecursor() and
vo_showcursor() patch (see the "GUI cursor control" topic).

Ingo

From ib at wupperonline.de  Mon Sep 12 12:58:58 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 12 Sep 2011 12:58:58 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <20110911093129.GB3205@1und1.de>
Message-ID: <4e6e18b9.5c2756e6.bm000@wupperonline.de>

Reimar D?ffinger wrote on Sun, 11 Sep 2011 11:31:29 +0200:

> On Sat, Sep 10, 2011 at 02:05:02PM +0200, Ingo Br?ckl wrote:
>>
>> +void vo_x11_handle_autohide_cursor(Display * dpy, Window win, int show)

> Could you please add a bit of doxygen documentation?
> Because the function signature might actually look like it would
> work properly for multiple windows,

Something like this (or is the \syntax - used throughout x11_common -
preferred)?

/**
 * @brief Handle appearance and automatic hiding of the cursor.
 *
 * @param dpy display
 * @param win window
 * @param show flag indicating whether to show the cursor (anything but 0)
 *        or whether to hide it if display time has elapsed (0)
 *
 * @note Only one window will be handled at a time, i.e. after a cursor has
 *       been shown on a window it only can be hidden from the window if
 *       display time has elapsed, but not be shown on a second one.
 */

> due to the mouse_timer/mouse_waiting_hide variables being shared it will
> actually break quite badly if someone ever tried to use it on multiple
> windows at the same time.

We could prevent this, but it would blow up the code (untested, but should
work):

 void vo_x11_handle_autohide_cursor(Display * dpy, Window win, int show)
 {
   static unsigned int mouse_timer;
   static int mouse_waiting_hide;
+  static Window mouse_win = None;

-  if (show) {
+  if (show && (mouse_win == None)) {
       vo_showcursor(dpy, win);
+      mouse_win = win;
       mouse_waiting_hide = 1;
       mouse_timer = GetTimerMS();
-  } else if (mouse_waiting_hide && (GetTimerMS() - mouse_timer >= 1000)) {
+  } else if (mouse_waiting_hide && (win == mouse_win) && (GetTimerMS() - mouse_timer >= 1000)) {
       vo_hidecursor(dpy, win);
+      mouse_win = None;
       mouse_waiting_hide = 0;
   }
 }

Considering everything discussed so far, wouldn't it be better to just patch
vo_hidecursor() and vo_showcursor() (and copy the few autohide lines - as
they currently are, not as separate function - to the GUI code):

Index: libvo/x11_common.c
===================================================================
--- libvo/x11_common.c	(revision 34097)
+++ libvo/x11_common.c	(working copy)
@@ -186,7 +186,7 @@
     Colormap colormap;
     static char bm_no_data[] = { 0, 0, 0, 0, 0, 0, 0, 0 };

-    if (WinID == 0)
+    if (WinID >= 0)
         return;                 // do not hide if playing on the root window

     colormap = DefaultColormap(disp, DefaultScreen(disp));
@@ -205,7 +205,7 @@

 static void vo_showcursor(Display * disp, Window win)
 {
-    if (WinID == 0)
+    if (WinID >= 0)
         return;
     XDefineCursor(disp, win, 0);
 }

We won't do (cursor-wise) with a given window then what we don't do with the
root window. Seems far less complex to me.

Ingo

From Reimar.Doeffinger at gmx.de  Mon Sep 12 18:12:41 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 12 Sep 2011 18:12:41 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in trunk/libass:
 ass.c ass.h ass_bitmap.c ass_bitmap.h ass_cache.c ass_cache.h ass_drawing.c
 ass_font.c ass_font.h ass_fontconfig.c ass_fontconfig.h ass_library.c
 ass_library.h ass_parse.c...
In-Reply-To: <20110912085049.GB14263@pool.informatik.rwth-aachen.de>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
Message-ID: <20110912161241.GB3165@1und1.de>

On Mon, Sep 12, 2011 at 10:50:49AM +0200, Diego Biurrun wrote:
> On Sun, Sep 11, 2011 at 10:34:17PM +0200, Alexander Strasser wrote:
> > Diego Biurrun wrote:
> > > On Sun, Sep 11, 2011 at 02:05:20PM +0200, Reimar D?ffinger wrote:
> > > > On Sun, Sep 11, 2011 at 01:47:57PM +0200, Diego Biurrun wrote:
> > > > > On Sun, Sep 11, 2011 at 12:33:14PM +0200, reimar wrote:
> > > > > > 
> > > > > > Log:
> > > > > > Update included libass copy to 0.9.13 release.
> > > > > 
> > > > > What's the point of continuing to carry this lib around?  AFAIR it is now
> > > > > widely available in distributions, so IMO we should just check at configure
> > > > > time and use the system library.
> > > > 
> > > > Neither Windows nor OSX include it.
> > > 
> > > And who of these people compiles from source?  Those that do can compile
> > > libass, what's the problem?  Do we bundle libc?

I am one of those people occasionally and I haven't tested whether I can
compile libass.
So far keeping the copy and updating it seems the minimal effort method.

> > > > And to my knowledge e.g. Gentoo is still defaulting to a setup that ends
> > > > up combining the crashing library versions.
> > > 
> > > There will always be some combination of distro and lib version that is
> > > buggy.  Report bugs, get them fixed, don't accumulate local workarounds.
> > 
> >   Please keep up the flames. This exactly the wrong way and IMHO the
> > wrong mailing list to start such a discussion.
> 
> If you wish to move the discussion to dev-eng, go right ahead.  However,
> everybody is subscribed here, so it's as good a place as any to discuss.
> 
> Reimar and I have talked about this in the past, the last time the decision
> was to postpone a decision about libass because it was not yet widely
> available in distros.  This is no longer the case.

Actually it was rather "a properly working version available in
distros", which as I mentioned is still problematic.
There's also other things like it using autotools without the generated
scripts being checked in, which I still see as big advertisement of
"you won't manage to get it to build on half of your systems".
Yes, at some point we should get rid of included libs.
However I don't see a good cost/benefit ratio here.
If we want to remove things: Does anyone remember a reason to keep
mp3lib? Because that one is high-cost in comparison.
We have some custom changes there, but they seem like they start to
become a negative value, mpg123 and mad both seem to be better, and
ffmp3 is the included alternative.

From Reimar.Doeffinger at gmx.de  Mon Sep 12 18:26:27 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 12 Sep 2011 18:26:27 +0200
Subject: [MPlayer-dev-eng] [PATCH] xvmc: handle shm xvimage allocation
 error
In-Reply-To: <20110910215833.GA30222@joi.lan>
References: <20110910215833.GA30222@joi.lan>
Message-ID: <20110912162627.GC3165@1und1.de>

On Sat, Sep 10, 2011 at 11:58:33PM +0200, Marcin Slusarz wrote:
> - assert xvimage->data_size!=0 because 0 size will lead to memory corruptions
>   (I hit it because of bug in Nouveau's early xvmc implementation)

An assert is not really that much better.
Failing is fine. So is checking data_size at the appropriate place.
But an assert isn't a good enough solution to be worth it IMO.

> -    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) ) Shmem_Flag = 1;
> +    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) )
> +        Shmem_Flag = 0;
>      else
>      {
>          Shmem_Flag = 0;

That is rather pointless if you set it to 0 in both cases.
And the warning about not using Shm will no longer really
correspond to reality after this change.
Lastly, this change causes deallocate_xvimage to always use free
instead of XShmDetach when it should.

> @@ -198,25 +208,41 @@
>      {
>          xvimage = (XvImage *) XvShmCreateImage(mDisplay, xv_port, xv_format,
>                               NULL, xvimage_width, xvimage_height, &Shminfo);
> +        if (!xvimage)
> +            goto noshmimage;
>  
> +        assert(xvimage->data_size);
>          Shminfo.shmid    = shmget(IPC_PRIVATE, xvimage->data_size, IPC_CREAT | 0777);
> +        if (Shminfo.shmid == -1)
> +            goto shmgetfail;
> +
>          Shminfo.shmaddr  = (char *) shmat(Shminfo.shmid, 0, 0);
> +        if ((long)Shminfo.shmaddr == -1)

Documentation says it returns (void *)-1, so you should check for
equality with that really.

> +shmattachfail:
> +    shmdt(Shminfo.shmaddr);
> +shmatfail:
> +    shmctl(Shminfo.shmid, IPC_RMID, 0);
> +shmgetfail:
> +    XFree(xvimage);

This would be much nicer (i.e. require only a single goto)
if initializing shmaddr/shmid/xvimage to appropriate invalid
values, adding a shm_deallocate function that frees those
that have a valid value and then reusing that in deallocate_xvimage
should also get rid of the need for Shmem_Flag.

From Reimar.Doeffinger at gmx.de  Mon Sep 12 18:28:52 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 12 Sep 2011 18:28:52 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <4e6e18b9.5b4b1e52.bm001@wupperonline.de>
References: <20110911092905.GA3205@1und1.de>
	<4e6e18b9.5b4b1e52.bm001@wupperonline.de>
Message-ID: <20110912162852.GD3165@1und1.de>

On Mon, Sep 12, 2011 at 04:13:55PM +0200, Ingo Br?ckl wrote:
> need the various WinID < 0 conditions - in fact shouldn't have them.
> vo_x11_ontop() and vo_x11_border() are only called via control/VOCTRL which
> should be allowed.

I disagree. A frontend does not necessarily have its own key handling
but might instead just pass things on to MPlayer.
It shouldn't have to risk that MPlayer completely messes up its window
just because of that.

From ib at wupperonline.de  Mon Sep 12 20:27:47 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 12 Sep 2011 20:27:47 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <20110912162852.GD3165@1und1.de>
Message-ID: <4e6e5470.7cef1baf.bm000@wupperonline.de>

Reimar D?ffinger wrote on Mon, 12 Sep 2011 18:28:52 +0200:

> On Mon, Sep 12, 2011 at 04:13:55PM +0200, Ingo Br?ckl wrote:
>> need the various WinID < 0 conditions - in fact shouldn't have them.
>> vo_x11_ontop() and vo_x11_border() are only called via control/VOCTRL
>> which should be allowed.

> I disagree. A frontend does not necessarily have its own key handling
> but might instead just pass things on to MPlayer.
> It shouldn't have to risk that MPlayer completely messes up its window
> just because of that.

Sorry, but I don't get it.

If we block vo_x11_ontop() by a WinID < 0 condition a control() VOCTRL_ONTOP
call won't do anything. If we don't do that (and patch vo_x11_setlayer()) the
call will work as expected and I can't see any mess-up. (VOCTRL_BORDER is
already working the same way.)

Ingo

From diego at biurrun.de  Mon Sep 12 23:08:29 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 12 Sep 2011 23:08:29 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e6e18b9.5c2756e6.bm000@wupperonline.de>
References: <20110911093129.GB3205@1und1.de>
	<4e6e18b9.5c2756e6.bm000@wupperonline.de>
Message-ID: <20110912210827.GA4549@pool.informatik.rwth-aachen.de>

On Mon, Sep 12, 2011 at 12:58:58PM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Sun, 11 Sep 2011 11:31:29 +0200:
> 
> > On Sat, Sep 10, 2011 at 02:05:02PM +0200, Ingo Br?ckl wrote:
> >>
> >> +void vo_x11_handle_autohide_cursor(Display * dpy, Window win, int show)
> 
> > Could you please add a bit of doxygen documentation?
> > Because the function signature might actually look like it would
> > work properly for multiple windows,
> 
> Something like this (or is the \syntax - used throughout x11_common -
> preferred)?

@ syntax is preferred.

Diego

From cehoyos at ag.or.at  Mon Sep 12 23:32:26 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Mon, 12 Sep 2011 21:32:26 +0000 (UTC)
Subject: [MPlayer-dev-eng]
	=?utf-8?q?=5BMPlayer-cvslog=5D_r34099_-_in_trun?=
	=?utf-8?q?k/libass=3A_ass=2Ec_ass=2Eh_ass=5Fbitmap=2Ecass=5Fbitmap?=
	=?utf-8?b?Lmhhc3NfY2FjaGUuY2Fzc19jYWNoZS5oYXNzX2RyYXdpbmcuY2Fzc19m?=
	=?utf-8?q?ont=2Ecass=5Ffont=2Ehass=5Ffontconfig=2Ecass=5Ffontconfi?=
	=?utf-8?b?Zy5oYXNzX2xpYnJhcnkuY2Fzc19saWJyYXJ5Lmhhc3NfcGFyc2UuYy4u?=
	=?utf-8?q?=2E?=
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
Message-ID: <loom.20110912T232801-702@post.gmane.org>

Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:

> If we want to remove things: Does anyone remember a reason to keep
> mp3lib?

I can add that it is still faster on the only systems where it matters, MMX and
SSE (watching HDTV means audio takes ~50% of the CPU).
(But I did not test external mp3lib.)

Carl Eugen


From Reimar.Doeffinger at gmx.de  Mon Sep 12 23:39:58 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 12 Sep 2011 23:39:58 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <4e6e5470.7cef1baf.bm000@wupperonline.de>
References: <20110912162852.GD3165@1und1.de>
	<4e6e5470.7cef1baf.bm000@wupperonline.de>
Message-ID: <20110912213958.GD2950@1und1.de>

On Mon, Sep 12, 2011 at 08:27:47PM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Mon, 12 Sep 2011 18:28:52 +0200:
> 
> > On Mon, Sep 12, 2011 at 04:13:55PM +0200, Ingo Br?ckl wrote:
> >> need the various WinID < 0 conditions - in fact shouldn't have them.
> >> vo_x11_ontop() and vo_x11_border() are only called via control/VOCTRL
> >> which should be allowed.
> 
> > I disagree. A frontend does not necessarily have its own key handling
> > but might instead just pass things on to MPlayer.
> > It shouldn't have to risk that MPlayer completely messes up its window
> > just because of that.
> 
> Sorry, but I don't get it.
> 
> If we block vo_x11_ontop() by a WinID < 0 condition a control() VOCTRL_ONTOP
> call won't do anything. If we don't do that (and patch vo_x11_setlayer()) the
> call will work as expected and I can't see any mess-up. (VOCTRL_BORDER is
> already working the same way.)

The messup I see is in modifying the state of a window we did not create or
manage in any way.
If VOCTRL_BORDER actually modifies the window for WinID > 0 I'd consider
that a bug/left over from older code.

From diego at biurrun.de  Mon Sep 12 23:45:56 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 12 Sep 2011 23:45:56 +0200
Subject: [MPlayer-dev-eng] [patch] fix SPDIF output on Mac
In-Reply-To: <loom.20110822T054102-115@post.gmane.org>
References: <loom.20110822T054102-115@post.gmane.org>
Message-ID: <20110912214554.GB4549@pool.informatik.rwth-aachen.de>

On Mon, Aug 22, 2011 at 03:49:47AM +0000, Zongyao Qu wrote:
> 
> Recently, I made a fix for Mac users on Mac OS X 10.7.
> 
> I didn't test it myself, 
> but my users told me that this fixed the SPDIF output problem.
> 
> I think I should share it, so other Mac mplayer users will be 
> happy with it.
> 
> I was told the line width is limited to 80 chars.
> so please refer to the link below to review the patch.
> 
> https://www.gitorious.org/mplayer-for-mplayerx/
> mplayer/commit/b41d5d28fe2b2087e94e2facd035efb79dc0e93b

Please eliminate the tabs and just send your patch here.
git-send-email will do, as will attaching the patch to an email.

I was told at videolan dev days that this indeed fix problems
for some people, so the patch is desirable.  Would be great if
somebody could test it.  Do you know if it keeps older systems
in working order?

> Any suggestion welcomed,
> since I know little about the coding rules in mplayer project.

I was also told at VDD that people could not find source code for
MPlayerX even though they looked hard for it.  Please make some
links available directly from your homepage and don't distribute
MPlayerX versions without also distributing sources.

Diego

From Reimar.Doeffinger at gmx.de  Mon Sep 12 23:51:25 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 12 Sep 2011 23:51:25 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in trunk/libass:
 ass.c ass.h
 ass_bitmap.cass_bitmap.hass_cache.cass_cache.hass_drawing.cass_font.cass_font.hass_fontconfig.cass_fontconfig.hass_library.cass_library.hass_parse.c...
In-Reply-To: <loom.20110912T232801-702@post.gmane.org>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<loom.20110912T232801-702@post.gmane.org>
Message-ID: <20110912215125.GB3320@1und1.de>

On Mon, Sep 12, 2011 at 09:32:26PM +0000, Carl Eugen Hoyos wrote:
> Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
> 
> > If we want to remove things: Does anyone remember a reason to keep
> > mp3lib?
> 
> I can add that it is still faster on the only systems where it matters, MMX and
> SSE (watching HDTV means audio takes ~50% of the CPU).

You mean systems without SSE2? (shouldn't matter I'd think since SSE2 is
for integer, and lavc codec uses float by default now).
Do you have any guess why?

From eclipse7 at gmx.net  Mon Sep 12 23:51:14 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Mon, 12 Sep 2011 23:51:14 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <4e6e18b9.5b4b1e52.bm001@wupperonline.de>
References: <20110911092905.GA3205@1und1.de>
	<4e6e18b9.5b4b1e52.bm001@wupperonline.de>
Message-ID: <20110912215114.GC4595@tane>

Hi,

Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Sun, 11 Sep 2011 11:29:05 +0200:
> > On Fri, Sep 09, 2011 at 05:09:24PM +0200, Ingo Br?ckl wrote:
> >> Index: libvo/x11_common.c
> >> ===================================================================
> >> --- libvo/x11_common.c        (revision 34097)
> >> +++ libvo/x11_common.c        (working copy)
> >> @@ -1206,7 +1206,7 @@
> >>
> >>  void vo_x11_setlayer(Display * mDisplay, Window vo_window, int layer)
> >>  {
> >> -    if (WinID >= 0)
> >> +    if (!WinID)
> >>          return;
> >>
> >>      if (vo_fs_type & vo_wm_LAYER)
> >> @@ -1431,7 +1431,7 @@
> >>  {
> >>      vo_ontop = (!(vo_ontop));
> >>
> >> -    vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
> >> +    if (WinID < 0) vo_x11_setlayer(mDisplay, vo_window, vo_ontop);
> >>  }
> 
> > I very much dislike having half the WinID check in the function and the
> > other half outside.
> 
> The inside check has a different meaning.
> 
> > I don't mind removing it completely, but IMO leaving the !WinID there is
> > confusing.
> > Even more so since it possibly should really check the vo_window parameter
> > instead of WinID.
> 
> Actually, it is checked whether vo_window is the root window (although
> indirectly, because vo_window is the root window if WinID is 0). The same
> check is done in vo_x11_decoration().

  I believe Ingo is right on this one. But I also do find the code
misleading and confusing.

> Alexander Strasser wrote on Sat, 10 Sep 2011 15:33:52 +0200:
> 
> > In general I am a bit concerned about the WinID handling inside the
> > x11_common and the x11 based vo drivers.
> 
> Me too.

  As I see it, we are trying to tackle to many issues at once. It should
be possible to break this down into smaller self contained changes.

  This is my first attempt to do it:

  1. Generalize some functions a bit, so they could be used from the GUI
  2. Don't automatically handle cursor auto hide feature when an external
     window ID is specified).
  3. Clean up/improve the code handling around the WinID variable.

  Point 3 isn't yet worked out. Point 1 and 2 should be possible right
now with Ingo's patches iff Reimar changed his mind about the confusing
WinID usage.

  The other alternative I currently see is: reorder priorities and do
point 3 before 1 and 2. After point 3 is done, the objections should
no longer hold but the patches would need to get updated to the future
version of x11_common code.

[...]

  Alexander

From diego at biurrun.de  Mon Sep 12 23:52:39 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 12 Sep 2011 23:52:39 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in trunk/libass:
 ass.c ass.h
 ass_bitmap.cass_bitmap.hass_cache.cass_cache.hass_drawing.cass_font.cass_font.hass_fontconfig.cass_fontconfig.hass_library.cass_library.hass_parse.c...
In-Reply-To: <loom.20110912T232801-702@post.gmane.org>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<loom.20110912T232801-702@post.gmane.org>
Message-ID: <20110912215238.GC4549@pool.informatik.rwth-aachen.de>

On Mon, Sep 12, 2011 at 09:32:26PM +0000, Carl Eugen Hoyos wrote:
> Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
> 
> > If we want to remove things: Does anyone remember a reason to keep
> > mp3lib?
> 
> I can add that it is still faster on the only systems where it matters, MMX and
> SSE (watching HDTV means audio takes ~50% of the CPU).
> (But I did not test external mp3lib.)

What system could possibly take 50% CPU to decode MP3?  Any Pentium should
do and any MMX CPU should be plenty, but none of these systems can dream
of dealing with HDTV...

Diego

From Reimar.Doeffinger at gmx.de  Mon Sep 12 23:55:42 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 12 Sep 2011 23:55:42 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in trunk/libass:
 ass.c ass.h
 ass_bitmap.cass_bitmap.hass_cache.cass_cache.hass_drawing.cass_font.cass_font.hass_fontconfig.cass_fontconfig.hass_library.cass_library.hass_parse.c...
In-Reply-To: <20110912215238.GC4549@pool.informatik.rwth-aachen.de>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<loom.20110912T232801-702@post.gmane.org>
	<20110912215238.GC4549@pool.informatik.rwth-aachen.de>
Message-ID: <20110912215542.GA3565@1und1.de>

On Mon, Sep 12, 2011 at 11:52:39PM +0200, Diego Biurrun wrote:
> On Mon, Sep 12, 2011 at 09:32:26PM +0000, Carl Eugen Hoyos wrote:
> > Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
> > 
> > > If we want to remove things: Does anyone remember a reason to keep
> > > mp3lib?
> > 
> > I can add that it is still faster on the only systems where it matters, MMX and
> > SSE (watching HDTV means audio takes ~50% of the CPU).
> > (But I did not test external mp3lib.)
> 
> What system could possibly take 50% CPU to decode MP3?  Any Pentium should
> do and any MMX CPU should be plenty, but none of these systems can dream
> of dealing with HDTV...

50% of the overall CPU usage I guess, playing with VDPAU probably.
But yes some details would probably be a good idea.

From cehoyos at ag.or.at  Tue Sep 13 00:10:39 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Mon, 12 Sep 2011 22:10:39 +0000 (UTC)
Subject: [MPlayer-dev-eng]
	=?utf-8?q?=5BMPlayer-cvslog=5D_r34099_-_in_trun?=
	=?utf-8?q?k/libass=3A_ass=2Ec_ass=2Eh_ass=5Fbitmap=2Ecass=5Fbitmap?=
	=?utf-8?b?Lmhhc3NfY2FjaGUuY2Fzc19jYWNoZS5oYXNzX2RyYXdpbmcuY2Fzc19m?=
	=?utf-8?q?ont=2Ecass=5Ffont=2Ehass=5Ffontconfig=2Ecass=5Ffontconfi?=
	=?utf-8?b?Zy5oYXNzX2xpYnJhcnkuY2Fzc19saWJyYXJ5Lmhhc3NfcGFyc2UuYy4u?=
	=?utf-8?q?=2E?=
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<loom.20110912T232801-702@post.gmane.org>
	<20110912215125.GB3320@1und1.de>
Message-ID: <loom.20110913T000729-789@post.gmane.org>

Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:

> > > If we want to remove things: Does anyone remember a reason to keep
> > > mp3lib?
> > 
> > I can add that it is still faster on the only systems where it matters, MMX
> > and SSE (watching HDTV means audio takes ~50% of the CPU).
> 
> You mean systems without SSE2?

Yes (and yes, with VDPAU).

> (shouldn't matter I'd think since SSE2 is
> for integer, and lavc codec uses float by default now).
> Do you have any guess why?

Vitor asked me the same question and I can only repeat that mp3lib has MMX code
that makes its (floating point?) decoding faster than ffmp3float on SSE.
(When I tested some time ago after FFmpeg received optimisations.)

Carl Eugen


From marcin.slusarz at gmail.com  Tue Sep 13 02:40:13 2011
From: marcin.slusarz at gmail.com (Marcin Slusarz)
Date: Tue, 13 Sep 2011 02:40:13 +0200
Subject: [MPlayer-dev-eng] [PATCH] xvmc: handle shm xvimage allocation
 error
In-Reply-To: <20110912162627.GC3165@1und1.de>
References: <20110912162627.GC3165@1und1.de>
Message-ID: <20110913004013.GA2158@joi.lan>

Please Cc me on replies. I'm not subscribed.

On Mon, Sep 12, 2011 at 06:26:27PM +0200, =?ISO-8859-1?Q?Reimar_D=F6ffinger_ wrote:
> On Sat, Sep 10, 2011 at 11:58:33PM +0200, Marcin Slusarz wrote:
> > - assert xvimage->data_size!=0 because 0 size will lead to memory corruptions
> >   (I hit it because of bug in Nouveau's early xvmc implementation)
> 
> An assert is not really that much better.
> Failing is fine. So is checking data_size at the appropriate place.
> But an assert isn't a good enough solution to be worth it IMO.

Ok. But it means we need to disable OSD as a fallback.

> > -    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) ) Shmem_Flag = 1;
> > +    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) )
> > +        Shmem_Flag = 0;
> >      else
> >      {
> >          Shmem_Flag = 0;
> 
> That is rather pointless if you set it to 0 in both cases.

It was a leftover from testing...

> And the warning about not using Shm will no longer really
> correspond to reality after this change.
> Lastly, this change causes deallocate_xvimage to always use free
> instead of XShmDetach when it should.
> 
> > @@ -198,25 +208,41 @@
> >      {
> >          xvimage = (XvImage *) XvShmCreateImage(mDisplay, xv_port, xv_format,
> >                               NULL, xvimage_width, xvimage_height, &Shminfo);
> > +        if (!xvimage)
> > +            goto noshmimage;
> >  
> > +        assert(xvimage->data_size);
> >          Shminfo.shmid    = shmget(IPC_PRIVATE, xvimage->data_size, IPC_CREAT | 0777);
> > +        if (Shminfo.shmid == -1)
> > +            goto shmgetfail;
> > +
> >          Shminfo.shmaddr  = (char *) shmat(Shminfo.shmid, 0, 0);
> > +        if ((long)Shminfo.shmaddr == -1)
> 
> Documentation says it returns (void *)-1, so you should check for
> equality with that really.

Heh, localized shmat man page omitted this detail...
Fixed.

> > +shmattachfail:
> > +    shmdt(Shminfo.shmaddr);
> > +shmatfail:
> > +    shmctl(Shminfo.shmid, IPC_RMID, 0);
> > +shmgetfail:
> > +    XFree(xvimage);
> 
> This would be much nicer (i.e. require only a single goto)
> if initializing shmaddr/shmid/xvimage to appropriate invalid
> values, adding a shm_deallocate function that frees those
> that have a valid value and then reusing that in deallocate_xvimage
> should also get rid of the need for Shmem_Flag.
> 

Half done. I think it's clearer the way I've done it, because shm_deallocate
could not share too much with deallocate_xvimage and need additional state
(did XShmAttach succeed?). If you feel stronly about it I can change this.

---
xvmc: handle osd xvimage allocation error

- handle xvimage/shm allocation failure and fallback to non-shm xv
- if non-shm xv still fails - disable OSD
- detect bug in xvmc implementation (xvimage->data_size==0) and disable OSD

Index: libvo/vo_xvmc.c
===================================================================
--- libvo/vo_xvmc.c	(wersja 34098)
+++ libvo/vo_xvmc.c	(kopia robocza)
@@ -148,7 +148,6 @@
 //shm stuff from vo_xv
 #ifdef HAVE_SHM
 static XShmSegmentInfo Shminfo;
-static int Shmem_Flag;
 #endif
 static XvImage * xvimage;
 
@@ -181,48 +180,105 @@
     return cur_render->state || (cur_render->mpi && cur_render->mpi->usage_count);
 }
 
-static void allocate_xvimage(int xvimage_width,int xvimage_height,int xv_format)
+static int allocate_xvimage_normal(int xvimage_width, int xvimage_height, int xv_format)
 {
- /*
-  * allocate XvImages.  FIXME: no error checking, without
-  * mit-shm this will bomb... trzing to fix ::atmos
-  */
+    xvimage = (XvImage *) XvCreateImage(mDisplay, xv_port, xv_format, NULL,
+                                        xvimage_width, xvimage_height);
+    if (!xvimage->data_size)
+    {
+        mp_msg(MSGT_VO, MSGL_WARN,
+                "XServer's XvCreateImage implementation is buggy (returned 0-sized image)\n" );
+        XFree(xvimage);
+        xvimage = NULL;
+        return -1;
+    }
+    xvimage->data = malloc(xvimage->data_size);
+    XSync(mDisplay,False);
+
+    return 0;
+}
+
 #ifdef HAVE_SHM
-    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) ) Shmem_Flag = 1;
-    else
+
+static int allocate_xvimage(int xvimage_width,int xvimage_height,int xv_format)
+{
+    int use_shm = mLocalDisplay && XShmQueryExtension( mDisplay );
+
+    Shminfo.shmid = -1;
+    Shminfo.shmaddr = (void *)-1;
+
+    if (!use_shm)
     {
-        Shmem_Flag = 0;
-        mp_msg(MSGT_VO,MSGL_WARN, "Shared memory not supported\nReverting to normal Xv\n" );
+        mp_msg(MSGT_VO, MSGL_WARN, "Shared memory not supported\nReverting to normal Xv\n" );
+        return allocate_xvimage_normal(xvimage_width, xvimage_height, xv_format);
     }
-    if ( Shmem_Flag )
+
+    xvimage = (XvImage *) XvShmCreateImage(mDisplay, xv_port, xv_format,
+                         NULL, xvimage_width, xvimage_height, &Shminfo);
+    if (!xvimage)
+        goto shmfail;
+
+    if (!xvimage->data_size)
     {
-        xvimage = (XvImage *) XvShmCreateImage(mDisplay, xv_port, xv_format,
-                             NULL, xvimage_width, xvimage_height, &Shminfo);
+        mp_msg(MSGT_VO, MSGL_WARN,
+                "XServer's XvShmCreateImage implementation is buggy (returned 0-sized image)\n" );
+        goto shmfail;
+    }
 
-        Shminfo.shmid    = shmget(IPC_PRIVATE, xvimage->data_size, IPC_CREAT | 0777);
-        Shminfo.shmaddr  = (char *) shmat(Shminfo.shmid, 0, 0);
-        Shminfo.readOnly = False;
+    Shminfo.shmid    = shmget(IPC_PRIVATE, xvimage->data_size, IPC_CREAT | 0777);
+    if (Shminfo.shmid == -1)
+        goto shmfail;
 
-        xvimage->data = Shminfo.shmaddr;
-        XShmAttach(mDisplay, &Shminfo);
-        XSync(mDisplay, False);
+    Shminfo.shmaddr  = (char *) shmat(Shminfo.shmid, 0, 0);
+    if (Shminfo.shmaddr == (void *)-1)
+        goto shmfail;
+
+    Shminfo.readOnly = False;
+
+    xvimage->data = Shminfo.shmaddr;
+    if (!XShmAttach(mDisplay, &Shminfo))
+        goto shmfail;
+
+    XSync(mDisplay, False);
+    shmctl(Shminfo.shmid, IPC_RMID, 0);
+
+    return 0;
+
+shmfail:
+    mp_msg(MSGT_VO, MSGL_WARN, "Failure in setting up shared memory Xv\nReverting to normal Xv\n" );
+    if (Shminfo.shmaddr != (void *)-1)
+    {
+        shmdt(Shminfo.shmaddr);
+        Shminfo.shmaddr = (void *)-1;
+    }
+    if (Shminfo.shmid != -1)
+    {
         shmctl(Shminfo.shmid, IPC_RMID, 0);
+        Shminfo.shmid = -1;
     }
-    else
-#endif
+    if (xvimage)
     {
-        xvimage = (XvImage *) XvCreateImage(mDisplay, xv_port, xv_format, NULL, xvimage_width, xvimage_height);
-        xvimage->data = malloc(xvimage->data_size);
-        XSync(mDisplay,False);
+        XFree(xvimage);
+        xvimage = NULL;
     }
-// memset(xvimage->data,128,xvimage->data_size);
-    return;
+
+    return allocate_xvimage_normal(xvimage_width, xvimage_height, xv_format);
 }
 
+#else
+
+static void allocate_xvimage(int xvimage_width,int xvimage_height,int xv_format)
+{
+    return allocate_xvimage_normal(xvimage_width, xvimage_height, xv_format);
+}
+
+#endif
+
+
 static void deallocate_xvimage(void)
 {
 #ifdef HAVE_SHM
-    if ( Shmem_Flag )
+    if (Shminfo.shmaddr != (void *)-1)
     {
         XShmDetach( mDisplay,&Shminfo );
         shmdt( Shminfo.shmaddr );
@@ -812,7 +868,13 @@
     mp_msg(MSGT_VO,MSGL_DBG4,"vo_xvmc: clearing subpicture\n");
     clear_osd_fnc(0, 0, subpicture.width, subpicture.height);
 
-    allocate_xvimage(subpicture.width, subpicture.height, subpicture_info.id);
+    if (allocate_xvimage(subpicture.width, subpicture.height, subpicture_info.id))
+    {
+        subpicture_mode = NO_SUBPICTURE;
+        mp_msg(MSGT_VO,MSGL_WARN, "vo_xvmc: OSD disabled\n");
+        return;
+    }
+
     subpicture_alloc = 1;
 }
 

From ib at wupperonline.de  Tue Sep 13 02:41:16 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 13 Sep 2011 02:41:16 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <20110912213958.GD2950@1und1.de>
Message-ID: <4e6ea734.02bc81c8.bm000@wupperonline.de>

Reimar D?ffinger wrote on Mon, 12 Sep 2011 23:39:58 +0200:

> The messup I see is in modifying the state of a window we did not create
> or manage in any way.

Ok, I get this, but doesn't that contradict the idea of reusing the vo_x11
code? Isn't the driver supposed to manage windows (-wid) it didn't create?
Why not allowing an application owning a WinID to use the decoration code
for its window if it is safe to do so?

Take vo_x11_ewmh_fullscreen() for example. It probably shouldn't be called
if the driver deals with the root window, so there should be a "if (!WinID)
return;". If "modifying the state of a window we did not create or manage in
any way" is mandatory, then there should be even a "if (WinID >= 0) return;"
and the function could not be reused. Currently vo_x11_ewmh_fullscreen() is
completely "open" and WinID >= 0 is assured in vo_x11_fullscreen() from where
it is called.

So the question is: Where should be the WinID check? Inside the function
to protect it (no reusability), or there from where the function gets
called (lots of WinID conditions)?
And, shall we use WinID == 0 (actual meaning: vo_window == mRootWin),
WinID < 0 (actual meaning: vo_window != WinID) and WinID > 0 (actual
meaning: vo_window == WinID), or rather the actual meanings?

It may be a good idea to follow Alexander's suggestion to clean up/improve
the code handling around the WinID variable first.

We can either block the functions by a condition inside or leave it as open
as possible to enable reusage (either directly by the GUI or via VOCTRL
calls).

Ingo

From auerswal at unix-ag.uni-kl.de  Tue Sep 13 09:09:49 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Tue, 13 Sep 2011 09:09:49 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
	trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h
	ass_cache.c ass_cache.h	ass_drawing.c ass_font.c ass_font.h
	ass_fontconfig.c	ass_fontconfig.h ass_library.c ass_library.h
	ass_parse.c...
In-Reply-To: <20110912161241.GB3165@1und1.de>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
Message-ID: <20110913070949.GA11243@sushi.unix-ag.uni-kl.de>

Hi,

On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
> [...]
> If we want to remove things: Does anyone remember a reason to keep
> mp3lib? Because that one is high-cost in comparison.

I currently need mp3lib because the default mpg123 crashes on every mp3
file I have.

> We have some custom changes there, but they seem like they start to
> become a negative value, mpg123 and mad both seem to be better, and
> ffmp3 is the included alternative.

OK, so I have to test something like -afm mad and -afm ffmp3 works on my
setup...

Thanks,
Erik
-- 
The real requirement is to be able to get answers and solve problems;
to perform the necessary research.
                        -- Henry Grebler

From skizzhg at gmx.com  Tue Sep 13 09:32:25 2011
From: skizzhg at gmx.com (skizzhg)
Date: Tue, 13 Sep 2011 09:32:25 +0200
Subject: [MPlayer-dev-eng] [PATCH] manpage - italian update
Message-ID: <20110913073224.GL771@jackinthebox>

Hi,
another update of the italian translation of mplayer.1, the patch is
zipped due previous issues with the encoding.

Ciao
skizzhg
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: manpage-it_2.patch.gz
Type: application/octet-stream
Size: 17412 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110913/53caeedb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110913/53caeedb/attachment.asc>

From ib at wupperonline.de  Tue Sep 13 12:34:48 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 13 Sep 2011 12:34:48 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <20110912215114.GC4595@tane>
Message-ID: <4e6f3390.7fa2540f.bm000@wupperonline.de>

Alexander Strasser wrote on Mon, 12 Sep 2011 23:51:14 +0200:

> As I see it, we are trying to tackle to many issues at once. It should be
> possible to break this down into smaller self contained changes.

>   This is my first attempt to do it:

>   1. Generalize some functions a bit, so they could be used from the GUI

This would be 1a.patch.

1b.patch maybe, but there is already code in the GUI that probably can be
made an appropriate GUI function and called, so I assume 1b isn't necessary.

>   2. Don't automatically handle cursor auto hide feature when an external
>      window ID is specified).

This would be 2.patch (together with autohide code in the GUI).

>   3. Clean up/improve the code handling around the WinID variable.

With these 2 (or 3) patches, we won't change much with current WinID
handling. We only would abandon a reusable autohide function in vo_x11
(and copy the few lines to the GUI) and allow VOCTRL_ONTOP (which Reimar
would consider a bug).

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1a.patch
Type: text/x-diff
Size: 362 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110913/eff70de0/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1b.patch
Type: text/x-diff
Size: 1994 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110913/eff70de0/attachment-0001.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2.patch
Type: text/x-diff
Size: 855 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110913/eff70de0/attachment-0002.bin>

From diego at biurrun.de  Tue Sep 13 13:37:59 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Tue, 13 Sep 2011 13:37:59 +0200
Subject: [MPlayer-dev-eng] [PATCH] manpage - italian update
In-Reply-To: <20110913073224.GL771@jackinthebox>
References: <20110913073224.GL771@jackinthebox>
Message-ID: <20110913113759.GB6665@pool.informatik.rwth-aachen.de>

On Tue, Sep 13, 2011 at 09:32:25AM +0200, skizzhg wrote:
> another update of the italian translation of mplayer.1, the patch is
> zipped due previous issues with the encoding.

Thanks, applied.

Diego

From diego at biurrun.de  Tue Sep 13 13:51:45 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Tue, 13 Sep 2011 13:51:45 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
 trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h	ass_cache.c
 ass_cache.h	ass_drawing.c ass_font.c ass_font.h	ass_fontconfig.c
 ass_fontconfig.h ass_library.c ass_library.h	ass_parse.c...
In-Reply-To: <20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
Message-ID: <20110913115145.GC6665@pool.informatik.rwth-aachen.de>

On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
> 
> On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
> > [...]
> > If we want to remove things: Does anyone remember a reason to keep
> > mp3lib? Because that one is high-cost in comparison.
> 
> I currently need mp3lib because the default mpg123 crashes on every mp3
> file I have.

What do you mean by "default mpg123"?

Diego

From auerswal at unix-ag.uni-kl.de  Tue Sep 13 14:39:19 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Tue, 13 Sep 2011 14:39:19 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
	trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h
	ass_cache.c ass_cache.h	ass_drawing.c ass_font.c ass_font.h
	ass_fontconfig.c	ass_fontconfig.h ass_library.c ass_library.h
	ass_parse.c...
In-Reply-To: <20110913115145.GC6665@pool.informatik.rwth-aachen.de>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>
Message-ID: <20110913123919.GA31656@sushi.unix-ag.uni-kl.de>

Hi,

On Tue, Sep 13, 2011 at 01:51:45PM +0200, Diego Biurrun wrote:
> On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
> > 
> > On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
> > > [...]
> > > If we want to remove things: Does anyone remember a reason to keep
> > > mp3lib? Because that one is high-cost in comparison.
> > 
> > I currently need mp3lib because the default mpg123 crashes on every mp3
> > file I have.
> 
> What do you mean by "default mpg123"?

That MPlayer decides to use the mpg123 (based?) code by default.

Erik
-- 
But heck, system administration is hard, what's a little more rope?
Here, hold this gun while I position your foot...
                        -- Valerie Aurora

From diego at biurrun.de  Tue Sep 13 15:58:56 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Tue, 13 Sep 2011 15:58:56 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
 trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h	ass_cache.c
 ass_cache.h	ass_drawing.c ass_font.c ass_font.h	ass_fontconfig.c
 ass_fontconfig.h ass_library.c ass_library.h	ass_parse.c...
In-Reply-To: <20110913123919.GA31656@sushi.unix-ag.uni-kl.de>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>
	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>
Message-ID: <20110913135856.GD6665@pool.informatik.rwth-aachen.de>

On Tue, Sep 13, 2011 at 02:39:19PM +0200, Erik Auerswald wrote:
> 
> On Tue, Sep 13, 2011 at 01:51:45PM +0200, Diego Biurrun wrote:
> > On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
> > > 
> > > On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
> > > > [...]
> > > > If we want to remove things: Does anyone remember a reason to keep
> > > > mp3lib? Because that one is high-cost in comparison.
> > > 
> > > I currently need mp3lib because the default mpg123 crashes on every mp3
> > > file I have.
> > 
> > What do you mean by "default mpg123"?
> 
> That MPlayer decides to use the mpg123 (based?) code by default.

I'm still not following.  Is "default mpg123"

a) what MPlayer carries along in the mp3lib/ directory or
b) the upstream libmpg123 from mpg123.de (which version)?

Diego

From auerswal at unix-ag.uni-kl.de  Tue Sep 13 16:31:27 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Tue, 13 Sep 2011 16:31:27 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
	trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h
	ass_cache.c ass_cache.h	ass_drawing.c ass_font.c ass_font.h
	ass_fontconfig.c	ass_fontconfig.h ass_library.c ass_library.h
	ass_parse.c...
In-Reply-To: <20110913135856.GD6665@pool.informatik.rwth-aachen.de>
References: <20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>
	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>
	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>
Message-ID: <20110913143127.GA5063@sushi.unix-ag.uni-kl.de>

Hi,

On Tue, Sep 13, 2011 at 03:58:56PM +0200, Diego Biurrun wrote:
> On Tue, Sep 13, 2011 at 02:39:19PM +0200, Erik Auerswald wrote:
> > On Tue, Sep 13, 2011 at 01:51:45PM +0200, Diego Biurrun wrote:
> > > On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
> > > > 
> > > > On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
> > > > > [...]
> > > > > If we want to remove things: Does anyone remember a reason to keep
> > > > > mp3lib? Because that one is high-cost in comparison.
> > > > 
> > > > I currently need mp3lib because the default mpg123 crashes on every mp3
> > > > file I have.
> > > 
> > > What do you mean by "default mpg123"?
> > 
> > That MPlayer decides to use the mpg123 (based?) code by default.
> 
> I'm still not following.  Is "default mpg123"
> 
> a) what MPlayer carries along in the mp3lib/ directory or
> b) the upstream libmpg123 from mpg123.de (which version)?

I'll check when I'm back at my home system (not before Friday). I suppose
configure output and existing system librarys should be enough to decide
this. If system libs are used, they are from Debian/Sid, last updated
Sunday.

Anyway, If I specify "-afm mp3lib" I can play mp3 files and videos with
included mp3 audio. If I don't specify -afm ..., mplayer crashes when
trying to play an mp3.

What I am trying to say is that I need mp3lib support. I don't currently
know if the version included in mplayer is used or some system lib. I
assumed that the included code is used without even checking for a system
wide replacement; I don't specify anything mp3 related when calling
configure. But I don't know for sure and cannot check at the moment.

Thanks,
Erik
-- 
Recoil effect upon the shooter is about 85 percent mental.
                        -- Jeff Cooper

From diego at biurrun.de  Tue Sep 13 17:25:17 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Tue, 13 Sep 2011 17:25:17 +0200
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new
 libbluray API
In-Reply-To: <1315762560-16131-1-git-send-email-diego@biurrun.de>
References: <1315762560-16131-1-git-send-email-diego@biurrun.de>
Message-ID: <20110913152517.GE6665@pool.informatik.rwth-aachen.de>

On Sun, Sep 11, 2011 at 07:36:00PM +0200, Diego Biurrun wrote:
> From: Rico Tzschichholz <ricotz at ubuntu.com>
> 
> Switch to new libbluray API with three parameters to bd_get_title_info().
> libbluray versions using the old API are no longer supported.
> 
> Signed-off-by: Diego Biurrun <diego at biurrun.de>

No opinions?  Then I'll push this by Friday or so.

Diego

From tempn at twmi.rr.com  Tue Sep 13 20:42:38 2011
From: tempn at twmi.rr.com (compn)
Date: Tue, 13 Sep 2011 14:42:38 -0400
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new
 libbluray API
In-Reply-To: <20110913152517.GE6665@pool.informatik.rwth-aachen.de>
References: <1315762560-16131-1-git-send-email-diego@biurrun.de>
	<20110913152517.GE6665@pool.informatik.rwth-aachen.de>
Message-ID: <20110913144238.824dd2aa.tempn@twmi.rr.com>

On Tue, 13 Sep 2011 17:25:17 +0200, Diego Biurrun wrote:
>On Sun, Sep 11, 2011 at 07:36:00PM +0200, Diego Biurrun wrote:
>> From: Rico Tzschichholz <ricotz at ubuntu.com>
>> 
>> Switch to new libbluray API with three parameters to bd_get_title_info().
>> libbluray versions using the old API are no longer supported.
>> 
>> Signed-off-by: Diego Biurrun <diego at biurrun.de>
>
>No opinions?  Then I'll push this by Friday or so.

the number of mplayer devels with bluray + with unencrypted bluray
samples is pretty small. whats going on with libaacskeys or whatever is
required for encrypted disc playback?

werent we going to host a list of keys too?

-compn

From ikalvachev at gmail.com  Wed Sep 14 01:01:02 2011
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Wed, 14 Sep 2011 02:01:02 +0300
Subject: [MPlayer-dev-eng] [PATCH] xvmc: handle shm xvimage allocation
	error
In-Reply-To: <20110912162627.GC3165@1und1.de>
References: <20110910215833.GA30222@joi.lan> <20110912162627.GC3165@1und1.de>
Message-ID: <CABA=pqfGFg6OPcVq4CsQd7pyscYh4Dt3Z19CYvEjku5q6Tq6Kg@mail.gmail.com>

On 9/12/11, Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:
> On Sat, Sep 10, 2011 at 11:58:33PM +0200, Marcin Slusarz wrote:
>> - assert xvimage->data_size!=0 because 0 size will lead to memory
>> corruptions
>>   (I hit it because of bug in Nouveau's early xvmc implementation)
>
> An assert is not really that much better.
> Failing is fine. So is checking data_size at the appropriate place.
> But an assert isn't a good enough solution to be worth it IMO.
>
>> -    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) ) Shmem_Flag =
>> 1;
>> +    if ( mLocalDisplay && XShmQueryExtension( mDisplay ) )
>> +        Shmem_Flag = 0;
>>      else
>>      {
>>          Shmem_Flag = 0;
>
> That is rather pointless if you set it to 0 in both cases.
> And the warning about not using Shm will no longer really
> correspond to reality after this change.
> Lastly, this change causes deallocate_xvimage to always use free
> instead of XShmDetach when it should.
>
>> @@ -198,25 +208,41 @@
>>      {
>>          xvimage = (XvImage *) XvShmCreateImage(mDisplay, xv_port,
>> xv_format,
>>                               NULL, xvimage_width, xvimage_height,
>> &Shminfo);
>> +        if (!xvimage)
>> +            goto noshmimage;
>>
>> +        assert(xvimage->data_size);
>>          Shminfo.shmid    = shmget(IPC_PRIVATE, xvimage->data_size,
>> IPC_CREAT | 0777);
>> +        if (Shminfo.shmid == -1)
>> +            goto shmgetfail;
>> +
>>          Shminfo.shmaddr  = (char *) shmat(Shminfo.shmid, 0, 0);
>> +        if ((long)Shminfo.shmaddr == -1)
>
> Documentation says it returns (void *)-1, so you should check for
> equality with that really.
>
>> +shmattachfail:
>> +    shmdt(Shminfo.shmaddr);
>> +shmatfail:
>> +    shmctl(Shminfo.shmid, IPC_RMID, 0);
>> +shmgetfail:
>> +    XFree(xvimage);
>
> This would be much nicer (i.e. require only a single goto)
> if initializing shmaddr/shmid/xvimage to appropriate invalid
> values, adding a shm_deallocate function that frees those
> that have a valid value and then reusing that in deallocate_xvimage
> should also get rid of the need for Shmem_Flag.

imho, I prefer the goto approach more.
It is indeed worse in language cleanness, but the generated code is
more optimal (not that it is speed critical:), because you won't check
for same thing twice.
I also find it more readable, (aka use the goto only in case of exact
error, otherwise it becomes mess with special values).


I'd just like to assert something. (not directly related to this patch).

Few months ago I investigated a user problem with Xv that turned out
to be caused by too small memory size for shm. So the xvimage
allocation is problem that have to be fixed in vo_xv.c too and we have
multiple xvimage buffers there.

So there are basically 2 solutions:
1. In case of Shm allocation fails, free all existing Shm images and
clear the flag, aka stop using Shm at all.
2. Make individual flag for each buffer and query that flag at each
use... IMHO this is overkill.

Moving the code to x11_common.c would be great, I had an attempt but I
didn't like it (i didn't like sharing the Shmem_Flag) , that's why I
haven't posted it .

P.S.
Good work on the patch, by the way.

From rhswdev at gmail.com  Thu Sep 15 13:43:19 2011
From: rhswdev at gmail.com (Karoly Horvath)
Date: Thu, 15 Sep 2011 12:43:19 +0100
Subject: [MPlayer-dev-eng] getting frame rate
Message-ID: <CA+o_KfvD-uPKBEK2zU7wCcL4Uk4Ga-wsWbh_3tZFY8o7d=As4g@mail.gmail.com>

Hi!

I developed a couple of audio and video plugins (af_.., vf_..) for
monitoring purposes and everything is working fine, but currently the
plugins are sample and frame based and I would like to configure them based
on time intervals. For example I would like to set to generate an alert when
the sound is below a specific threshold for a x seconds or the video freezed
for more than y second.

How can I retrieve the video frame-rate and audio sample-rate for a stream?
Where does mplayer store this info?

Thx.

--
Karoly Horvath

From ib at wupperonline.de  Thu Sep 15 16:06:23 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 15 Sep 2011 16:06:23 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <20110903074205.ddd04da0.tempn@twmi.rr.com>
Message-ID: <4e7209e4.1b0a0978.bm001@wupperonline.de>

compn wrote on Sat, 3 Sep 2011 07:42:05 -0400:

> to summarize:
> 1. yes, having this feature in mplayer demuxer would be nice.
> 2. be sure to fuzz and valgrind test the code.

Here we go.

All tests I did worked fine. The zzuf'ed mp3s played as strange as they do
without mp3_vbr_frames() and with wrong cbr runtime then - as expected.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp3.vbr.patch
Type: text/x-diff
Size: 3303 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110915/9bf7e4a4/attachment.bin>

From ib at wupperonline.de  Thu Sep 15 11:30:19 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 15 Sep 2011 11:30:19 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation
Message-ID: <4e7209e4.1177514b.bm000@wupperonline.de>

There are some conditional declarations within the GUI (and in MPlayer as
well, see X11_FULLSCREEN in libvo/x11_common.c) that currently won't appear
in the doxygen documentation, i.e. the generated documentation is rather one
according to the personal settings than a general one. This could be changed
by using the PREDEFINED tag.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: doxygen.patch
Type: text/x-diff
Size: 1279 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110915/54f98fc5/attachment.bin>

From dominik at greysector.net  Thu Sep 15 20:49:41 2011
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Thu, 15 Sep 2011 20:49:41 +0200
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new
 libbluray API
In-Reply-To: <20110913152517.GE6665@pool.informatik.rwth-aachen.de>
References: <1315762560-16131-1-git-send-email-diego@biurrun.de>
	<20110913152517.GE6665@pool.informatik.rwth-aachen.de>
Message-ID: <20110915184941.GA3118@ryvius.greysector.net>

Hi,

On Tuesday, 13 September 2011 at 17:25, Diego Biurrun wrote:
> On Sun, Sep 11, 2011 at 07:36:00PM +0200, Diego Biurrun wrote:
> > From: Rico Tzschichholz <ricotz at ubuntu.com>
> > 
> > Switch to new libbluray API with three parameters to bd_get_title_info().
> > libbluray versions using the old API are no longer supported.
> > 
> > Signed-off-by: Diego Biurrun <diego at biurrun.de>
> 
> No opinions?  Then I'll push this by Friday or so.

Please mention those commit hashes (maybe with a date) from
libbluray upstream in the commit message so that people can
find out why their local libbluray version is not detected.

Regards,
-- 
MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan

From cehoyos at ag.or.at  Thu Sep 15 21:34:29 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Thu, 15 Sep 2011 21:34:29 +0200
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
	available / was disabled
Message-ID: <201109152134.29391.cehoyos@ag.or.at>

Hi!

I will apply attached if nobody has better ideas, Carl Eugen
-------------- next part --------------
Index: configure
===================================================================
--- configure	(revision 34105)
+++ configure	(working copy)
@@ -6867,6 +6867,15 @@
 fi
 echores "$_libopencore_amrwb"
 
+
+if test "$_libopencore_amrnb" = no && test "$_libopencore_amrwb" = no ; then
+  libavdecoders="$libavdecoders PRORES_DECODER"
+  def_ffmpeg_license='#define FFMPEG_LICENSE "GPL version 2"'
+else
+  def_ffmpeg_license='#define FFMPEG_LICENSE "GPL version 2 or later"'
+fi
+
+
 echocheck "libdv-0.9.5+"
 if test "$_libdv" = auto ; then
   _libdv=no
@@ -8603,7 +8612,7 @@
 #endif
 
 #define FFMPEG_CONFIGURATION "--enable-gpl --enable-postproc"
-#define FFMPEG_LICENSE "GPL version 2 or later"
+$def_ffmpeg_license
 
 #define LIBAV_CONFIGURATION FFMPEG_CONFIGURATION
 #define LIBAV_LICENSE FFMPEG_LICENSE

From lobo at lobs.sytes.net  Thu Sep 15 22:37:27 2011
From: lobo at lobs.sytes.net (Lobster)
Date: Fri, 16 Sep 2011 08:37:27 +1200
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
 available / was disabled
In-Reply-To: <201109152134.29391.cehoyos@ag.or.at>
References: <201109152134.29391.cehoyos@ag.or.at>
Message-ID: <4E726207.3040507@lobs.sytes.net>

On 16/09/2011 7:34 a.m., Carl Eugen Hoyos wrote:
> Hi!
>
> I will apply attached if nobody has better ideas, Carl Eugen

Why does ProRes depend on libopencore in the first place?
As far as I know any real ProRes video/audio files wont use any codecs 
provided
by libopencore.


From cehoyos at ag.or.at  Thu Sep 15 22:45:27 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Thu, 15 Sep 2011 20:45:27 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
	available / was disabled
References: <201109152134.29391.cehoyos@ag.or.at>
	<4E726207.3040507@lobs.sytes.net>
Message-ID: <loom.20110915T224436-240@post.gmane.org>

Lobster <lobo <at> lobs.sytes.net> writes:

> On 16/09/2011 7:34 a.m., Carl Eugen Hoyos wrote:
> > Hi!
> >
> > I will apply attached if nobody has better ideas, Carl Eugen
> 
> Why does ProRes depend on libopencore in the first place?
> As far as I know any real ProRes video/audio files wont use any codecs 
> provided
> by libopencore.

libopencore's software license is not compatible with GPL v2 (but v3), FFmpeg's
ProRes decoder is GPL v2 (only).

Carl Eugen


From auerswal at unix-ag.uni-kl.de  Thu Sep 15 23:22:47 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Thu, 15 Sep 2011 23:22:47 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
	trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h
	ass_cache.c ass_cache.h	ass_drawing.c ass_font.c ass_font.h
	ass_fontconfig.c	ass_fontconfig.h ass_library.c ass_library.h
	ass_parse.c...
In-Reply-To: <20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
References: <20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>
	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>
	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>
	<20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
Message-ID: <20110915212247.GA12722@sushi.unix-ag.uni-kl.de>

Hi,

On Tue, Sep 13, 2011 at 04:31:27PM +0200, Erik Auerswald wrote:
> On Tue, Sep 13, 2011 at 03:58:56PM +0200, Diego Biurrun wrote:
> > On Tue, Sep 13, 2011 at 02:39:19PM +0200, Erik Auerswald wrote:
> > > On Tue, Sep 13, 2011 at 01:51:45PM +0200, Diego Biurrun wrote:
> > > > On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
> > > > > 
> > > > > On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
> > > > > > [...]
> > > > > > If we want to remove things: Does anyone remember a reason to keep
> > > > > > mp3lib? Because that one is high-cost in comparison.
> > > > > 
> > > > > I currently need mp3lib because the default mpg123 crashes on every mp3
> > > > > file I have.
> > > > 
> > > > What do you mean by "default mpg123"?
> > > 
> > > That MPlayer decides to use the mpg123 (based?) code by default.
> > 
> > I'm still not following.  Is "default mpg123"
> > 
> > a) what MPlayer carries along in the mp3lib/ directory or
> > b) the upstream libmpg123 from mpg123.de (which version)?

My MPlayer is linked against the system's libmpg123 (version libmpg123-0
(= 1.12.1-3.2) packaged by Debian).

The mp3lib code comes from the MPLayer repo (included version).

The latter works for me, the former does not.

I know that this is no proper bug report (which would be off topic
anyway ;), I just argue for keeping mp3lib/.

Thanks,
Erik
-- 
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it.
                        -- Brian W. Kernighan

From lobo at lobs.sytes.net  Thu Sep 15 23:31:45 2011
From: lobo at lobs.sytes.net (Lobster)
Date: Fri, 16 Sep 2011 09:31:45 +1200
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
 available / was disabled
In-Reply-To: <loom.20110915T224436-240@post.gmane.org>
References: <201109152134.29391.cehoyos@ag.or.at>
	<4E726207.3040507@lobs.sytes.net>
	<loom.20110915T224436-240@post.gmane.org>
Message-ID: <4E726EC1.5030604@lobs.sytes.net>

On 16/09/2011 8:45 a.m., Carl Eugen Hoyos wrote:
> Why does ProRes depend on libopencore in the first place? As far as I 
> know any real ProRes video/audio files wont use any codecs provided by 
> libopencore.
> libopencore's software license is not compatible with GPL v2 (but v3), FFmpeg's
> ProRes decoder is GPL v2 (only).

I still fail to see why libopencore is an issue with ProRes, as I said
any real ProRes file shouldn't need or use anything provided by
libopencore anyway.


From tempn at twmi.rr.com  Fri Sep 16 02:20:27 2011
From: tempn at twmi.rr.com (compn)
Date: Thu, 15 Sep 2011 20:20:27 -0400
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
 available / was disabled
In-Reply-To: <4E726EC1.5030604@lobs.sytes.net>
References: <201109152134.29391.cehoyos@ag.or.at>
	<4E726207.3040507@lobs.sytes.net>
	<loom.20110915T224436-240@post.gmane.org>
	<4E726EC1.5030604@lobs.sytes.net>
Message-ID: <20110915202027.5f303905.tempn@twmi.rr.com>

On Fri, 16 Sep 2011 09:31:45 +1200, Lobster wrote:
>On 16/09/2011 8:45 a.m., Carl Eugen Hoyos wrote:
>> Why does ProRes depend on libopencore in the first place? As far as I 
>> know any real ProRes video/audio files wont use any codecs provided by 
>> libopencore.
>> libopencore's software license is not compatible with GPL v2 (but v3), FFmpeg's
>> ProRes decoder is GPL v2 (only).
>
>I still fail to see why libopencore is an issue with ProRes, as I said
>any real ProRes file shouldn't need or use anything provided by
>libopencore anyway.

prores doesnt use anything from libopencore.

just it maybe confusing (or goes against gpl?) to have one library
gplv2only and another library gplv3 in the same binary program.

we'd need to find some kind of license expert to tell us the proper way
i guess.

-compn

From yumkam at mail.ru  Fri Sep 16 07:20:20 2011
From: yumkam at mail.ru (Yuriy Kaminskiy)
Date: Fri, 16 Sep 2011 09:20:20 +0400
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in trunk/libass:
 ass.c ass.h ass_bitmap.c ass_bitmap.h ass_cache.c ass_cache.h ass_drawing.c
 ass_font.c ass_font.h ass_fontconfig.c ass_fontconfig.h ass_library.c
 ass_library.h ass_parse.c...
In-Reply-To: <20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
References: <20110911114757.GA27939@pool.informatik.rwth-aachen.de>	<20110911120520.GA4469@1und1.de>	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>	<20110911203416.GA4736@tane>	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>	<20110912161241.GB3165@1und1.de>	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>
	<20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
Message-ID: <j4umak$r2s$1@dough.gmane.org>

Erik Auerswald wrote:
> Hi,
> 
> On Tue, Sep 13, 2011 at 03:58:56PM +0200, Diego Biurrun wrote:
>> On Tue, Sep 13, 2011 at 02:39:19PM +0200, Erik Auerswald wrote:
>>> On Tue, Sep 13, 2011 at 01:51:45PM +0200, Diego Biurrun wrote:
>>>> On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
>>>>> On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
>>>>>> [...]
>>>>>> If we want to remove things: Does anyone remember a reason to keep
>>>>>> mp3lib? Because that one is high-cost in comparison.
>>>>> I currently need mp3lib because the default mpg123 crashes on every mp3
>>>>> file I have.
>>>> What do you mean by "default mpg123"?
>>> That MPlayer decides to use the mpg123 (based?) code by default.
>> I'm still not following.  Is "default mpg123"
>>
>> a) what MPlayer carries along in the mp3lib/ directory or
>> b) the upstream libmpg123 from mpg123.de (which version)?
> 
> I'll check when I'm back at my home system (not before Friday). I suppose
> configure output and existing system librarys should be enough to decide
> this. If system libs are used, they are from Debian/Sid, last updated
> Sunday.

libmpg123 package 1.12.1-3.2 on debian/sid is broken (it fails to hide internal
symbols, they overridden by symbols from MPlayer/mp3lib [with different ABI],
resulting in crash).
As package from squeeze (same upstream version) is *not* broken in same way, and
changes in packaging looks minor and unrelated, have no idea why it is broken.
Likely ./configure --disable-mp3lib also will fix this crash :-)

> Anyway, If I specify "-afm mp3lib" I can play mp3 files and videos with
> included mp3 audio. If I don't specify -afm ..., mplayer crashes when
> trying to play an mp3.
> 
> What I am trying to say is that I need mp3lib support. I don't currently
> know if the version included in mplayer is used or some system lib. I
> assumed that the included code is used without even checking for a system
> wide replacement; I don't specify anything mp3 related when calling
> configure. But I don't know for sure and cannot check at the moment.
> 
> Thanks,
> Erik


From alex at roalter.it  Fri Sep 16 10:56:40 2011
From: alex at roalter.it (Alexander Roalter)
Date: Fri, 16 Sep 2011 10:56:40 +0200
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new
 libbluray API
In-Reply-To: <20110913144238.824dd2aa.tempn@twmi.rr.com>
References: <1315762560-16131-1-git-send-email-diego@biurrun.de>
	<20110913152517.GE6665@pool.informatik.rwth-aachen.de>
	<20110913144238.824dd2aa.tempn@twmi.rr.com>
Message-ID: <4E730F48.5000106@roalter.it>

Am 13.09.2011 20:42, schrieb compn:
> On Tue, 13 Sep 2011 17:25:17 +0200, Diego Biurrun wrote:
>> On Sun, Sep 11, 2011 at 07:36:00PM +0200, Diego Biurrun wrote:
>>> From: Rico Tzschichholz<ricotz at ubuntu.com>
>>>
>>> Switch to new libbluray API with three parameters to bd_get_title_info().
>>> libbluray versions using the old API are no longer supported.
>>>
>>> Signed-off-by: Diego Biurrun<diego at biurrun.de>
>>
>> No opinions?  Then I'll push this by Friday or so.
>
> the number of mplayer devels with bluray + with unencrypted bluray
> samples is pretty small. whats going on with libaacskeys or whatever is
> required for encrypted disc playback?

At least now processing keys for Media Key Blocks up until version 23 
(should be brand new) are available, so libaacskeys can currently 
decrypt any BD out there. At least that's the theory. More on that issue 
on doom9.org. So I can currently playback the dozen or so BDs I have 
without problem (if it weren't for those BD+ protected Fox discs).

So unencrypted bluray samples should again be easy to get a hand on... 
If they weren's so large and slow to upload...

-- 
cheers,
Alex

From Reimar.Doeffinger at gmx.de  Sat Sep 17 16:14:02 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 17 Sep 2011 16:14:02 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation
In-Reply-To: <4e7209e4.1177514b.bm000@wupperonline.de>
References: <4e7209e4.1177514b.bm000@wupperonline.de>
Message-ID: <20110917141402.GD6990@1und1.de>

On Thu, Sep 15, 2011 at 11:30:19AM +0200, Ingo Br?ckl wrote:
> There are some conditional declarations within the GUI (and in MPlayer as
> well, see X11_FULLSCREEN in libvo/x11_common.c)

I don't think they have any reason to be conditional, and the
X11_FULLSCREEN one seems completely undesirable and probably also
broken to me.
Doesn't mean it's necessarily a bad idea, but there's a good chance
you're just working around broken code :-)

From Reimar.Doeffinger at gmx.de  Sat Sep 17 16:22:24 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 17 Sep 2011 16:22:24 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in trunk/libass:
 ass.c ass.h
 ass_bitmap.cass_bitmap.hass_cache.cass_cache.hass_drawing.cass_font.cass_font.hass_fontconfig.cass_fontconfig.hass_library.cass_library.hass_parse.c...
In-Reply-To: <loom.20110913T000729-789@post.gmane.org>
References: <20110911103314.720C6106677@avserver.banki.hu>
	<20110911114757.GA27939@pool.informatik.rwth-aachen.de>
	<20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<loom.20110912T232801-702@post.gmane.org>
	<20110912215125.GB3320@1und1.de>
	<loom.20110913T000729-789@post.gmane.org>
Message-ID: <20110917142224.GG6990@1und1.de>

On Mon, Sep 12, 2011 at 10:10:39PM +0000, Carl Eugen Hoyos wrote:
> > (shouldn't matter I'd think since SSE2 is
> > for integer, and lavc codec uses float by default now).
> > Do you have any guess why?
> 
> Vitor asked me the same question and I can only repeat that mp3lib has MMX code
> that makes its (floating point?) decoding faster than ffmp3float on SSE.
> (When I tested some time ago after FFmpeg received optimisations.)

Could you test with -ao null or something like that which accepts float
output?
I suspect that the af_format conversion from float to int16 might be
what causes the issue.
If so, making an MMX/SSE version of it might be worthwhile.

From Reimar.Doeffinger at gmx.de  Sat Sep 17 16:25:16 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 17 Sep 2011 16:25:16 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
	trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h
	ass_cache.c ass_cache.h	ass_drawing.c ass_font.c ass_font.h
	ass_fontconfig.c	ass_fontconfig.h ass_library.c ass_library.h
	ass_parse.c...
In-Reply-To: <20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
References: <20110911120520.GA4469@1und1.de>
	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>
	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>
	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>
	<20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
Message-ID: <20110917142516.GH6990@1und1.de>

On Tue, Sep 13, 2011 at 04:31:27PM +0200, Erik Auerswald wrote:
> Hi,
> 
> On Tue, Sep 13, 2011 at 03:58:56PM +0200, Diego Biurrun wrote:
> > On Tue, Sep 13, 2011 at 02:39:19PM +0200, Erik Auerswald wrote:
> > > On Tue, Sep 13, 2011 at 01:51:45PM +0200, Diego Biurrun wrote:
> > > > On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
> > > > > 
> > > > > On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
> > > > > > [...]
> > > > > > If we want to remove things: Does anyone remember a reason to keep
> > > > > > mp3lib? Because that one is high-cost in comparison.
> > > > > 
> > > > > I currently need mp3lib because the default mpg123 crashes on every mp3
> > > > > file I have.
> > > > 
> > > > What do you mean by "default mpg123"?
> > > 
> > > That MPlayer decides to use the mpg123 (based?) code by default.
> > 
> > I'm still not following.  Is "default mpg123"
> > 
> > a) what MPlayer carries along in the mp3lib/ directory or
> > b) the upstream libmpg123 from mpg123.de (which version)?
> 
> I'll check when I'm back at my home system (not before Friday). I suppose
> configure output and existing system librarys should be enough to decide
> this. If system libs are used, they are from Debian/Sid, last updated
> Sunday.
> 
> Anyway, If I specify "-afm mp3lib" I can play mp3 files and videos with
> included mp3 audio. If I don't specify -afm ..., mplayer crashes when
> trying to play an mp3.
> 
> What I am trying to say is that I need mp3lib support. I don't currently
> know if the version included in mplayer is used or some system lib. I
> assumed that the included code is used without even checking for a system
> wide replacement; I don't specify anything mp3 related when calling
> configure. But I don't know for sure and cannot check at the moment.

You are aware of ffmp3?
mp3lib is marked as broken in codecs.conf, so nobody is using that
nowadays unless they compiled FFmpeg without mp3 support.
Which also means that compiling without mpg123 support would
"fix" your issue.
My concern now is mostly about making sure that no significant
optimizations are lost when removing our heavily modified mp3lib.

From Reimar.Doeffinger at gmx.de  Sat Sep 17 17:01:34 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 17 Sep 2011 17:01:34 +0200
Subject: [MPlayer-dev-eng] [PATCH] Remove some useless ifdefs in x11_common.h
Message-ID: <20110917150134.GA13294@1und1.de>

Hello,
See attached, just wanted to double-check I did not miss anything.
And btw. does anyone see any issues with completely removing all
X11_FULLSCREEN conditionals?
It seems it is only ever undefined when building only vo_dxr3 or
something and probably will fail to build in that case anyway...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: x11_ifdef.diff
Type: text/x-diff
Size: 956 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110917/ec5068b2/attachment.bin>

From ib at wupperonline.de  Sat Sep 17 17:09:23 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sat, 17 Sep 2011 17:09:23 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation
In-Reply-To: <4e7209e4.1177514b.bm000@wupperonline.de>
Message-ID: <4e74b825.3ebf6bf2.bm000@wupperonline.de>

I wrote on Thu, 15 Sep 2011 11:30:19 +0200:

> There are some conditional declarations [...]

s/declaration/definition/

Ingo

From deron at pagestream.org  Sat Sep 17 18:49:04 2011
From: deron at pagestream.org (Deron Kazmaier)
Date: Sat, 17 Sep 2011 10:49:04 -0600
Subject: [MPlayer-dev-eng] DeckLink driver
Message-ID: <4E74CF80.9050002@pagestream.org>


I'm trying to resurrect a patch made 2 years ago by Georg Lippitsch and 
posted on this list that added support for the Blackmagic Decklink 
HD-SDI output cards.

I've updated the code to compile (well, one niggly that I don't fully 
understand but it is with a Delete which hopefully will at worst just 
leave memory unfreed at the end) but I couldn't get it too link. The 
error messages certainly made me believe that the problem is simply that 
the C++ libraries are not linked in. Just using g++ instead of gcc seems 
to fix it (I copy/pasted the link line, replacing gcc with g++), but 
what would be the proper way to handle this in the config? Obviously the 
average user would not enable/compile the decklink drivers and so it 
would be crazy to use g++ all the time to link it.

I'm trying to get a friend who is a broadcaster to use Linux for his 
video servers and video processing instead of his Macs, and this is the 
last big piece to make a functional setup that he can start playing 
with. I hope that Georg will be enticed to help me refine this driver 
and I hope we can get it accepted into the main trunk.

Thanks,

Deron


From Reimar.Doeffinger at gmx.de  Sat Sep 17 18:58:30 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 17 Sep 2011 18:58:30 +0200
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <4E74CF80.9050002@pagestream.org>
References: <4E74CF80.9050002@pagestream.org>
Message-ID: <20110917165830.GA24894@1und1.de>

On Sat, Sep 17, 2011 at 10:49:04AM -0600, Deron Kazmaier wrote:
> I've updated the code to compile (well, one niggly that I don't
> fully understand but it is with a Delete which hopefully will at
> worst just leave memory unfreed at the end) but I couldn't get it
> too link. The error messages certainly made me believe that the
> problem is simply that the C++ libraries are not linked in. Just
> using g++ instead of gcc seems to fix it (I copy/pasted the link
> line, replacing gcc with g++), but what would be the proper way to
> handle this in the config? Obviously the average user would not
> enable/compile the decklink drivers and so it would be crazy to use
> g++ all the time to link it.

Well, you are really very vague and don't give us any relevant
information at all.
But usually that would be because you're missing -lstdc++

From tempn at twmi.rr.com  Sat Sep 17 19:24:42 2011
From: tempn at twmi.rr.com (compn)
Date: Sat, 17 Sep 2011 13:24:42 -0400
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
 available / was disabled
In-Reply-To: <201109152134.29391.cehoyos@ag.or.at>
References: <201109152134.29391.cehoyos@ag.or.at>
Message-ID: <20110917132442.9d28e6f5.tempn@twmi.rr.com>

On Thu, 15 Sep 2011 21:34:29 +0200, Carl Eugen Hoyos wrote:
>Hi!
>
>I will apply attached if nobody has better ideas, Carl Eugen
>

i have no better ideas. aside from asking some gpl guru about mixing
gpl versions in one binary

-compn

From tempn at twmi.rr.com  Sat Sep 17 19:25:28 2011
From: tempn at twmi.rr.com (compn)
Date: Sat, 17 Sep 2011 13:25:28 -0400
Subject: [MPlayer-dev-eng] [PATCH]SPDIF pass through decoder
In-Reply-To: <CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>
References: <CAJz3U+WyC1FbN+yO3Rip=OkQVdwXyF6LXF8LgvrObtOiE0bH1w@mail.gmail.com>
	<20110811212406.GA17697@pool.informatik.RWTH-Aachen.DE>
	<CAJz3U+Ue=nau=C2mVf+0RmS+QoAQ8cA3yBKgA16fi6PCfT4n+w@mail.gmail.com>
	<loom.20110818T161554-16@post.gmane.org>
	<CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>
Message-ID: <20110917132528.0c8f8f8b.tempn@twmi.rr.com>

On Fri, 2 Sep 2011 01:53:10 +0900, Naoya OYAMA wrote:
>Hi, patch updated.

ping.
anyone going to apply this ?

From deron at pagestream.org  Sat Sep 17 19:56:47 2011
From: deron at pagestream.org (Deron Kazmaier)
Date: Sat, 17 Sep 2011 11:56:47 -0600
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <20110917165830.GA24894@1und1.de>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
Message-ID: <4E74DF5F.1060106@pagestream.org>

On 9/17/11 10:58 AM, Reimar D?ffinger wrote:
> On Sat, Sep 17, 2011 at 10:49:04AM -0600, Deron Kazmaier wrote:
>> I've updated the code to compile (well, one niggly that I don't
>> fully understand but it is with a Delete which hopefully will at
>> worst just leave memory unfreed at the end) but I couldn't get it
>> too link. The error messages certainly made me believe that the
>> problem is simply that the C++ libraries are not linked in. Just
>> using g++ instead of gcc seems to fix it (I copy/pasted the link
>> line, replacing gcc with g++), but what would be the proper way to
>> handle this in the config? Obviously the average user would not
>> enable/compile the decklink drivers and so it would be crazy to use
>> g++ all the time to link it.
> Well, you are really very vague and don't give us any relevant
> information at all.
> But usually that would be because you're missing -lstdc++
> _______________________________________________


Sorry, I may have given too much info.

Everything linked when I simply changed gcc to g++.

So the question is, what is the proper changes to config that would 
cause g++ to be used instead of gcc, when and only when the decklink 
drivers are enabled?

Or is simply using -lstdc++ enough? (I've always been lead to believe 
there is more too it, but I'm not c++ export. I hate it, but that is 
just me).

Now I'm trying to figure out what it won't find the decklink card 
itself. I'm guessing the decklink 64bit kernel module is not compatible, 
in which case am I screwed?...

Deron


From diego at biurrun.de  Sat Sep 17 23:03:03 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sat, 17 Sep 2011 23:03:03 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in
 trunk/libass:	ass.c ass.h ass_bitmap.c ass_bitmap.h	ass_cache.c
 ass_cache.h	ass_drawing.c ass_font.c ass_font.h	ass_fontconfig.c
 ass_fontconfig.h ass_library.c ass_library.h	ass_parse.c...
In-Reply-To: <20110917142516.GH6990@1und1.de>
References: <20110911163059.GA9321@pool.informatik.rwth-aachen.de>
	<20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>
	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>
	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>
	<20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
	<20110917142516.GH6990@1und1.de>
Message-ID: <20110917210302.GB1043@pool.informatik.rwth-aachen.de>

On Sat, Sep 17, 2011 at 04:25:16PM +0200, Reimar D?ffinger wrote:
> My concern now is mostly about making sure that no significant
> optimizations are lost when removing our heavily modified mp3lib.

Didn't the new maintainer port all of that over?

Diego

From diego at biurrun.de  Sat Sep 17 23:05:52 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sat, 17 Sep 2011 23:05:52 +0200
Subject: [MPlayer-dev-eng] [PATCH] Remove some useless ifdefs in
 x11_common.h
In-Reply-To: <20110917150134.GA13294@1und1.de>
References: <20110917150134.GA13294@1und1.de>
Message-ID: <20110917210552.GC1043@pool.informatik.rwth-aachen.de>

On Sat, Sep 17, 2011 at 05:01:34PM +0200, Reimar D?ffinger wrote:
> See attached, just wanted to double-check I did not miss anything.

Patch looks good to me, I just wonder about all those empty lines
you add.

Diego

From diego at biurrun.de  Sat Sep 17 23:08:31 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sat, 17 Sep 2011 23:08:31 +0200
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <4E74DF5F.1060106@pagestream.org>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
	<4E74DF5F.1060106@pagestream.org>
Message-ID: <20110917210830.GD1043@pool.informatik.rwth-aachen.de>

On Sat, Sep 17, 2011 at 11:56:47AM -0600, Deron Kazmaier wrote:
> On 9/17/11 10:58 AM, Reimar D?ffinger wrote:
> >On Sat, Sep 17, 2011 at 10:49:04AM -0600, Deron Kazmaier wrote:
> >>I've updated the code to compile (well, one niggly that I don't
> >>fully understand but it is with a Delete which hopefully will at
> >>worst just leave memory unfreed at the end) but I couldn't get it
> >>too link. The error messages certainly made me believe that the
> >>problem is simply that the C++ libraries are not linked in. Just
> >>using g++ instead of gcc seems to fix it (I copy/pasted the link
> >>line, replacing gcc with g++), but what would be the proper way to
> >>handle this in the config? Obviously the average user would not
> >>enable/compile the decklink drivers and so it would be crazy to use
> >>g++ all the time to link it.
> >Well, you are really very vague and don't give us any relevant
> >information at all.
> >But usually that would be because you're missing -lstdc++
> 
> Sorry, I may have given too much info.

No, you have given too little.  Please send the patch and show us
the error message.

Diego

From diego at biurrun.de  Sat Sep 17 23:12:29 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sat, 17 Sep 2011 23:12:29 +0200
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
 available / was disabled
In-Reply-To: <20110915202027.5f303905.tempn@twmi.rr.com>
References: <201109152134.29391.cehoyos@ag.or.at>
	<4E726207.3040507@lobs.sytes.net>
	<loom.20110915T224436-240@post.gmane.org>
	<4E726EC1.5030604@lobs.sytes.net>
	<20110915202027.5f303905.tempn@twmi.rr.com>
Message-ID: <20110917211228.GE1043@pool.informatik.rwth-aachen.de>

On Thu, Sep 15, 2011 at 08:20:27PM -0400, compn wrote:
> On Fri, 16 Sep 2011 09:31:45 +1200, Lobster wrote:
> >On 16/09/2011 8:45 a.m., Carl Eugen Hoyos wrote:
> >> Why does ProRes depend on libopencore in the first place? As far as I 
> >> know any real ProRes video/audio files wont use any codecs provided by 
> >> libopencore.
> >> libopencore's software license is not compatible with GPL v2 (but v3), FFmpeg's
> >> ProRes decoder is GPL v2 (only).
> >
> >I still fail to see why libopencore is an issue with ProRes, as I said
> >any real ProRes file shouldn't need or use anything provided by
> >libopencore anyway.
> 
> prores doesnt use anything from libopencore.
> 
> just it maybe confusing (or goes against gpl?) to have one library
> gplv2only and another library gplv3 in the same binary program.
> 
> we'd need to find some kind of license expert to tell us the proper way
> i guess.

No big expertise necessary.  Different copyleft licenses are by definition
incompatible with each other, since including a copylefted part in some
work requires releasing the whole work under that copyleft license.  GPLv2
and GPLv3 are different copyleft licenses, thus incompatible.

Diego

From marathon96 at gmail.com  Sat Sep 17 23:14:46 2011
From: marathon96 at gmail.com (Grant Erickson)
Date: Sat, 17 Sep 2011 14:14:46 -0700
Subject: [MPlayer-dev-eng] [PATCH] OMAPFB FBDev Workaround for Tearing
	during Playback
In-Reply-To: <B445C6F5-2A80-48DF-A899-E67E7F4A1A1F@gmail.com>
References: <B445C6F5-2A80-48DF-A899-E67E7F4A1A1F@gmail.com>
Message-ID: <CANf5k1xDg1eLUBk-=92A_uXJz+sws0jcS4k=Yc+4mfU+TCA7GQ@mail.gmail.com>

The attached patch works around tearing issues during playback in the
mplayer vo_fbdev.c wrapper for the TI OMAPFB fbdev driver. See

? ? ? ?http://processors.wiki.ti.com/index.php/OMAP35x_Linux_-_DSS_FAQ
? ? ? ?http://www.spinics.net/lists/linux-omap/msg40710.html

for more information.

Best,

Grant Erickson

----
--- a/configure	2011-09-15 16:36:13.487956217 -0700
+++ b/configure	2011-09-15 16:22:45.003976019 -0700
@@ -482,6 +482,7 @@
   --enable-xshape          enable XShape support [autodetect]
   --disable-xss            disable screensaver support via xss [autodetect]
   --enable-fbdev           enable FBDev video output [autodetect]
+  --enable-omapfb          enable TI OMAP video output [autodetect]
   --enable-mlib            enable mediaLib video output (Solaris) [disable]
   --enable-3dfx            enable obsolete /dev/3dfx video output [disable]
   --enable-tdfxfb          enable tdfxfb video output [disable]
@@ -683,6 +684,7 @@
 _svga=auto
 _vesa=auto
 _fbdev=auto
+_omapfb=auto
 _dvb=auto
 _dxr2=auto
 _dxr3=auto
@@ -1047,6 +1049,8 @@
   --disable-vesa)       _vesa=no        ;;
   --enable-fbdev)       _fbdev=yes      ;;
   --disable-fbdev)      _fbdev=no       ;;
+  --enable-omapfb)      _omapfb=yes     ;;
+  --disable-omapfb)     _omapfb=no      ;;
   --enable-dvb)         _dvb=yes        ;;
   --disable-dvb)        _dvb=no         ;;
   --enable-dxr2)        _dxr2=yes       ;;
@@ -4686,7 +4690,23 @@
 fi
 echores "$_fbdev"

-
+echocheck "OMAPFB"
+if test "$_omapfb" = auto ; then
+  _omapfb=no
+  cat > $TMPC <<EOF
+#include <unistd.h>
+#include <sys/ioctl.h>
+#include <linux/omapfb.h>
+int main(void) { ioctl(0, OMAPFB_WAITFORGO, 0); return 0; }
+EOF
+  cc_check && _omapfb=yes
+fi
+if test "$_omapfb" = yes ; then
+  def_omapfb='#define CONFIG_OMAPFB 1'
+else
+  def_omapfb='#undef CONFIG_OMAPFB'
+fi
+echores "$_omapfb"

 echocheck "DVB"
 if test "$_dvb" = auto ; then
@@ -7952,6 +7972,7 @@
 FAAD = $_faad
 FASTMEMCPY = $_fastmemcpy
 FBDEV = $_fbdev
+OMAPFB = $_omapfb
 FREETYPE = $_freetype
 FTP = $_ftp
 GIF = $_gif
@@ -8490,6 +8511,7 @@
 $def_dxr2
 $def_dxr3
 $def_fbdev
+$def_omapfb
 $def_ggi
 $def_ggiwmh
 $def_gif
diff -aruN a/libvo/vo_fbdev.c b/libvo/vo_fbdev.c
--- a/libvo/vo_fbdev.c	2011-05-07 03:59:11.000000000 -0700
+++ b/libvo/vo_fbdev.c	2011-09-15 16:25:04.740695666 -0700
@@ -47,6 +47,10 @@
 #include "libavutil/common.h"
 #include "vo_fbdev.h"

+#if CONFIG_OMAPFB
+#include <linux/omapfb.h>
+#endif
+
 static const vo_info_t info = {
     "Framebuffer Device",
     "fbdev",
@@ -1071,6 +1075,10 @@
     fb_vinfo.yoffset = fb_page * fb_yres;
     ioctl(fb_dev_fd, FBIOPAN_DISPLAY, &fb_vinfo);

+#if CONFIG_OMAPFB
+    ioctl(fb_dev_fd, OMAPFB_WAITFORGO, 0);
+#endif
+
     center += page_delta * fb_yres * fb_line_len;
     fb_page = next_page;
 }
----
1.7.6

From alex at roalter.it  Sat Sep 17 23:42:21 2011
From: alex at roalter.it (Alexander Roalter)
Date: Sat, 17 Sep 2011 23:42:21 +0200
Subject: [MPlayer-dev-eng] dvdread fix
Message-ID: <4E75143D.3010702@roalter.it>

Doesn't fall into the dvdnav field, but is needed for playback of newest 
copy protection scheme employed by Paramount for their Thor DVD.

It basically uses a technique apparently targeted at player software 
that erroneously implements their own UDF reader, delivering a different 
VIDEO_TS.IFO to libdvdread than viewed in the normal file system.

The filenames in UDF are stored as follows: (I don't know what the 8 
does here)

08 56 49 44 45 4F 5F 54 53 2E 49 46 4F     VIDEO_TS.IFO

But look here, there's another video_ts.bup, but with a DIFFERENT name:

10 01 76 01 69 01 64 01 65 01 6F 01 5F 01 74 01 73 01 2E 01 69 01 66 01 
6F       v i d e o _ t s . i f o

As you can see, every character is preceeded by a 01. I reckon the 10 is 
somewhat of a charmap specified or whatever.

The following patch was found at
http://ubuntuforums.org/showthread.php?p=11254706

and should go into libdvdread4.

At least on my computer it now plays Thor (previously, it bailed out at
libdvdread,ifoOpenVMGI(): Invalid main menu IFO (VIDEO_TS.IFO).
libdvdnav: vm: failed to read VIDEO_TS.IFO)



-- 
Cheers,
Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: thor.diff
Type: text/x-patch
Size: 887 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110917/0e2b5174/attachment.bin>

From Reimar.Doeffinger at gmx.de  Sat Sep 17 23:46:17 2011
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Sat, 17 Sep 2011 23:46:17 +0200
Subject: [MPlayer-dev-eng] [PATCH] Remove some useless ifdefs in
	x11_common.h
In-Reply-To: <20110917210552.GC1043@pool.informatik.rwth-aachen.de>
References: <20110917150134.GA13294@1und1.de>
	<20110917210552.GC1043@pool.informatik.rwth-aachen.de>
Message-ID: <E972EC80-E193-43F4-8E32-FA4C4E163767@gmx.de>

On 17 Sep 2011, at 23:05, Diego Biurrun <diego at biurrun.de> wrote:
> On Sat, Sep 17, 2011 at 05:01:34PM +0200, Reimar D?ffinger wrote:
>> See attached, just wanted to double-check I did not miss anything.
> 
> Patch looks good to me, I just wonder about all those empty lines
> you add.

An attempt to keep the functions grouped by functionality as the ifdef did before.

From tempn at twmi.rr.com  Sat Sep 17 23:49:23 2011
From: tempn at twmi.rr.com (compn)
Date: Sat, 17 Sep 2011 17:49:23 -0400
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <4E75143D.3010702@roalter.it>
References: <4E75143D.3010702@roalter.it>
Message-ID: <20110917174923.93a7f81c.tempn@twmi.rr.com>

On Sat, 17 Sep 2011 23:42:21 +0200, Alexander Roalter wrote:
>Doesn't fall into the dvdnav field, but is needed for playback of newest 
>copy protection scheme employed by Paramount for their Thor DVD.

technically its not a 'dvd' if it doesnt have the dvd logo...

note for future me: mplayer is never going to be able to keep up with
idiot fake dvd protection schemes. we need to band together with other
projects to stay on top.

-compn

From alexander at roalter.it  Sat Sep 17 23:56:36 2011
From: alexander at roalter.it (Alexander Roalter)
Date: Sat, 17 Sep 2011 23:56:36 +0200
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <20110917174923.93a7f81c.tempn@twmi.rr.com>
References: <4E75143D.3010702@roalter.it>
	<20110917174923.93a7f81c.tempn@twmi.rr.com>
Message-ID: <4E751794.7030109@roalter.it>

On 09/17/2011 11:49 PM, compn wrote:
> On Sat, 17 Sep 2011 23:42:21 +0200, Alexander Roalter wrote:
>> Doesn't fall into the dvdnav field, but is needed for playback of newest
>> copy protection scheme employed by Paramount for their Thor DVD.
>
> technically its not a 'dvd' if it doesnt have the dvd logo...
>
> note for future me: mplayer is never going to be able to keep up with
> idiot fake dvd protection schemes. we need to band together with other
> projects to stay on top.
>
> -compn
well, it came with the Thor blu-ray, so...

projects using the libdvdread library should be ok with this patch.

I simply cannot understand what these guys at Sony, Paramount and Disney 
(these are the studios I know of) still believe implementing stupid copy 
protections on a DVD will keep anyone from getting to the content. If a 
player can play it (and I mean a player that could do it ten years ago), 
then software will always be able to play it.

I just can imagine these guys fiddling out how to trick the known player 
software into NOT playing the disc anymore. And then high-fiving 
themselves once they found a way, so the bosses can run to the studio 
once again and babble something about 'unbreakable solution' and $$$.


-- 
Cheers,
Alex

From Reimar.Doeffinger at gmx.de  Sun Sep 18 02:38:48 2011
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Sun, 18 Sep 2011 02:38:48 +0200
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <4E75143D.3010702@roalter.it>
References: <4E75143D.3010702@roalter.it>
Message-ID: <1613573B-8124-4468-818B-187749323DF9@gmx.de>

On 17 Sep 2011, at 23:42, Alexander Roalter <alex at roalter.it> wrote:
> Doesn't fall into the dvdnav field, but is needed for playback of newest copy protection scheme employed by Paramount for their Thor DVD.
> 
> It basically uses a technique apparently targeted at player software that erroneously implements their own UDF reader, delivering a different VIDEO_TS.IFO to libdvdread than viewed in the normal file system.
> 
> The filenames in UDF are stored as follows: (I don't know what the 8 does here)
> 
> 08 56 49 44 45 4F 5F 54 53 2E 49 46 4F     VIDEO_TS.IFO
> 
> But look here, there's another video_ts.bup, but with a DIFFERENT name:
> 
> 10 01 76 01 69 01 64 01 65 01 6F 01 5F 01 74 01 73 01 2E 01 69 01 66 01 6F       v i d e o _ t s . i f o
> 
> As you can see, every character is preceeded by a 01. I reckon the 10 is somewhat of a charmap specified or whatever.
> 
> The following patch was found at
> http://ubuntuforums.org/showthread.php?p=11254706
> 
> and should go into libdvdread4.

There is a separate mailing list for dvdread development though, and it should rather be posted there.
And probably the better solution is to allow the decode function to return an error, and make it do so if it contains anything outside the ASCII range.
> 

From alex at roalter.it  Sun Sep 18 10:21:11 2011
From: alex at roalter.it (Alexander Roalter)
Date: Sun, 18 Sep 2011 10:21:11 +0200
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <1613573B-8124-4468-818B-187749323DF9@gmx.de>
References: <4E75143D.3010702@roalter.it>
	<1613573B-8124-4468-818B-187749323DF9@gmx.de>
Message-ID: <4E75A9F7.8010403@roalter.it>

On 09/18/2011 02:38 AM, Reimar D?ffinger wrote:
> On 17 Sep 2011, at 23:42, Alexander Roalter<alex at roalter.it>  wrote:
>> The following patch was found at
>> http://ubuntuforums.org/showthread.php?p=11254706
>>
>> and should go into libdvdread4.
>
> There is a separate mailing list for dvdread development though, and[...]
Not to sound obnoxious, but where?
googling for it doesn't turn up anything working or (still) active.

-- 
Cheers,
Alex

From diego at biurrun.de  Sun Sep 18 12:01:51 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sun, 18 Sep 2011 12:01:51 +0200
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <4E75A9F7.8010403@roalter.it>
References: <4E75143D.3010702@roalter.it>
	<1613573B-8124-4468-818B-187749323DF9@gmx.de>
	<4E75A9F7.8010403@roalter.it>
Message-ID: <20110918100151.GA21053@pool.informatik.rwth-aachen.de>

On Sun, Sep 18, 2011 at 10:21:11AM +0200, Alexander Roalter wrote:
> On 09/18/2011 02:38 AM, Reimar D?ffinger wrote:
> >On 17 Sep 2011, at 23:42, Alexander Roalter<alex at roalter.it>  wrote:
> >>The following patch was found at
> >>http://ubuntuforums.org/showthread.php?p=11254706
> >>
> >>and should go into libdvdread4.
> >
> >There is a separate mailing list for dvdread development though, and[...]
> Not to sound obnoxious, but where?
> googling for it doesn't turn up anything working or (still) active.

http://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss

Diego

From alexander at roalter.it  Sun Sep 18 12:05:19 2011
From: alexander at roalter.it (Alexander Roalter)
Date: Sun, 18 Sep 2011 12:05:19 +0200
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <20110918100151.GA21053@pool.informatik.rwth-aachen.de>
References: <4E75143D.3010702@roalter.it>	<1613573B-8124-4468-818B-187749323DF9@gmx.de>	<4E75A9F7.8010403@roalter.it>
	<20110918100151.GA21053@pool.informatik.rwth-aachen.de>
Message-ID: <4E75C25F.7050809@roalter.it>

On 09/18/2011 12:01 PM, Diego Biurrun wrote:
> On Sun, Sep 18, 2011 at 10:21:11AM +0200, Alexander Roalter wrote:
>> On 09/18/2011 02:38 AM, Reimar D?ffinger wrote:
>>> On 17 Sep 2011, at 23:42, Alexander Roalter<alex at roalter.it>   wrote:
>>>> The following patch was found at
>>>> http://ubuntuforums.org/showthread.php?p=11254706
>>>>
>>>> and should go into libdvdread4.
>>>
>>> There is a separate mailing list for dvdread development though, and[...]
>> Not to sound obnoxious, but where?
>> googling for it doesn't turn up anything working or (still) active.
>
> http://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
>
> Diego
Also libdvdREAD? I've subscribed to libdvdnav a long time ago, but I 
wasn't aware it was for dvdread, too.

-- 
Cheers,
Alex

From diego at biurrun.de  Sun Sep 18 14:03:38 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Sun, 18 Sep 2011 14:03:38 +0200
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <4E75C25F.7050809@roalter.it>
References: <4E75143D.3010702@roalter.it>
	<1613573B-8124-4468-818B-187749323DF9@gmx.de>
	<4E75A9F7.8010403@roalter.it>
	<20110918100151.GA21053@pool.informatik.rwth-aachen.de>
	<4E75C25F.7050809@roalter.it>
Message-ID: <20110918120338.GB21053@pool.informatik.rwth-aachen.de>

On Sun, Sep 18, 2011 at 12:05:19PM +0200, Alexander Roalter wrote:
> On 09/18/2011 12:01 PM, Diego Biurrun wrote:
> >On Sun, Sep 18, 2011 at 10:21:11AM +0200, Alexander Roalter wrote:
> >>On 09/18/2011 02:38 AM, Reimar D?ffinger wrote:
> >>>On 17 Sep 2011, at 23:42, Alexander Roalter<alex at roalter.it>   wrote:
> >>>>The following patch was found at
> >>>>http://ubuntuforums.org/showthread.php?p=11254706
> >>>>
> >>>>and should go into libdvdread4.
> >>>
> >>>There is a separate mailing list for dvdread development though, and[...]
> >>Not to sound obnoxious, but where?
> >>googling for it doesn't turn up anything working or (still) active.
> >
> >http://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
> >
> Also libdvdREAD? I've subscribed to libdvdnav a long time ago, but I
> wasn't aware it was for dvdread, too.

Yes.

Diego

From auerswal at unix-ag.uni-kl.de  Sun Sep 18 14:41:00 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sun, 18 Sep 2011 14:41:00 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in	trunk/libass:
 ass.c ass.h ass_bitmap.c ass_bitmap.h	ass_cache.c ass_cache.h	ass_drawing.c
 ass_font.c ass_font.h	ass_fontconfig.c	ass_fontconfig.h ass_library.c
 ass_library.h ass_parse.c...
In-Reply-To: <20110917142516.GH6990@1und1.de>
References: <20110911120520.GA4469@1und1.de>	<20110911163059.GA9321@pool.informatik.rwth-aachen.de>	<20110911203416.GA4736@tane>	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>	<20110912161241.GB3165@1und1.de>	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>	<20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
	<20110917142516.GH6990@1und1.de>
Message-ID: <4E75E6DC.6090300@unix-ag.uni-kl.de>

Hi,

On 09/17/2011 04:25 PM, Reimar D?ffinger wrote:
> On Tue, Sep 13, 2011 at 04:31:27PM +0200, Erik Auerswald wrote:
>> On Tue, Sep 13, 2011 at 03:58:56PM +0200, Diego Biurrun wrote:
>>> On Tue, Sep 13, 2011 at 02:39:19PM +0200, Erik Auerswald wrote:
>>>> On Tue, Sep 13, 2011 at 01:51:45PM +0200, Diego Biurrun wrote:
>>>>> On Tue, Sep 13, 2011 at 09:09:49AM +0200, Erik Auerswald wrote:
>>>>>>
>>>>>> On Mon, Sep 12, 2011 at 06:12:41PM +0200, Reimar D?ffinger wrote:
>>>>>>> [...]
>>>>>>> If we want to remove things: Does anyone remember a reason to keep
>>>>>>> mp3lib? Because that one is high-cost in comparison.
>>>>>>
>>>>>> I currently need mp3lib because the default mpg123 crashes on every mp3
>>>>>> file I have.
>>>>>
>>>>> What do you mean by "default mpg123"?
>>>>
>>>> That MPlayer decides to use the mpg123 (based?) code by default.
>>>
>>> I'm still not following.  Is "default mpg123"
>>>
>>> a) what MPlayer carries along in the mp3lib/ directory or
>>> b) the upstream libmpg123 from mpg123.de (which version)?
>>
>> I'll check when I'm back at my home system (not before Friday). I suppose
>> configure output and existing system librarys should be enough to decide
>> this. If system libs are used, they are from Debian/Sid, last updated
>> Sunday.
>>
>> Anyway, If I specify "-afm mp3lib" I can play mp3 files and videos with
>> included mp3 audio. If I don't specify -afm ..., mplayer crashes when
>> trying to play an mp3.
>>
>> What I am trying to say is that I need mp3lib support. I don't currently
>> know if the version included in mplayer is used or some system lib. I
>> assumed that the included code is used without even checking for a system
>> wide replacement; I don't specify anything mp3 related when calling
>> configure. But I don't know for sure and cannot check at the moment.
>
> You are aware of ffmp3?
> mp3lib is marked as broken in codecs.conf, so nobody is using that
> nowadays unless they compiled FFmpeg without mp3 support.

I am now... didn't really care as long as everything worked. When the 
problems with mp3 files started, I discovered mp3lib first and stopped 
there.

After compiling without libmpg123 support, -afm ffmpeg was used, which 
works as well.

> Which also means that compiling without mpg123 support would
> "fix" your issue.

There are several ways to "fix" (i.e. work around) my issue:

1) using -afm ffmpeg or -afm mp3lib for files with mp3 audio
2) configuring with --disable-mp3lib
3) configuring with --disable-mpg123
4) removing the libmpg123 development headers from the system

I went with 4) since I had them installed for MPlayer only and libmpg123 
is supposedly broken on Debian/Sid currently.

> My concern now is mostly about making sure that no significant
> optimizations are lost when removing our heavily modified mp3lib.

ffmp3float seems to be faster on my system:

==========================================================================
Requested audio codec family [mpg123] (afm=mpg123) not available.
Enable it at compilation.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 24000->352800)
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
==========================================================================
AO: [null] 44100Hz 2ch floatle (4 bytes per sample)
Video: no video
Starting playback...
A: 271.7 (04:31.6) of 358.0 (05:58.0)  0.9% 0%
Audio output truncated at end.
A: 271.7 (04:31.6) of 358.0 (05:58.0)  0.9% 0%


BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.433s Sys: 276.795s =  279.228s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  0.8712% Sys: 99.1288% = 100.0000%

==========================================================================
Trying to force audio codec driver family mp3lib...
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [null] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 271.6 (04:31.6) of 538.0 (08:58.0)  1.1% 0%
Audio output truncated at end.
A: 271.6 (04:31.6) of 538.0 (08:58.0)  1.1% 0%


BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.998s Sys: 276.480s =  279.478s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  1.0728% Sys: 98.9272% = 100.0000%

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 28
model name      : AMD Sempron(tm) Processor 3000+
stepping        : 0
cpu MHz         : 1000.000
cache size      : 128 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge 
mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext fxsr_opt 
3dnowext 3dnow up lahf_lm
bogomips        : 2009.83
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 32 bits virtual
power management: ts fid vid ttp

[CPU clock stays at 1GHz while playing mp3, will go to 1.8GHz if needed. 
;-)]

Hm, just noticed the different reported bitrates (192kbps for ffmpeg, 
128kbps for mp3lib). mpg123 (the standalone player) reports "MPEG 1.0 
layer III, VBR, 44100 Hz stereo" for the used file.

Anyway, I don't need mp3lib any more, feel free to remove it. Or perhaps 
just disable it in configure by default.

Thanks,
Erik

From auerswal at unix-ag.uni-kl.de  Sun Sep 18 14:51:29 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sun, 18 Sep 2011 14:51:29 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility
 off	(was Re:	 Question for dev's: Does mplayer disable	DPMS	timeouts? "xset
 q" looks good, but timeouts never trigger)
In-Reply-To: <4E6A6EDA.8080200@unix-ag.uni-kl.de>
References: <4E665A5E.7010409@tedpavlic.com>	<20110906201622.GA3206@1und1.de>	<4E66833D.5050208@tedpavlic.com>	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>	<20110907104723.GA9561@phare.normalesup.org>	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
	<4E6A6EDA.8080200@unix-ag.uni-kl.de>
Message-ID: <4E75E951.8000800@unix-ag.uni-kl.de>

Hi,

no comments regarding the small patch that hides subtitles unless the 
subtitle selection code actually selects a subtitle stream?

On 09/09/2011 09:54 PM, Erik Auerswald wrote:
> [...]
> The attached patch (actually tested) is a definite improvement for me.
> When specifying -slang XX or having a suitably named .srt file lying
> near a movie, subtitles are displayed. But the mere presence of
> subtitles on a DVD does not result in displaying them automatically.
>
> Pleas consider applying.

The patch still applies cleanly.

Thanks,
Erik

From auerswal at unix-ag.uni-kl.de  Sun Sep 18 15:20:10 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sun, 18 Sep 2011 15:20:10 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility
 off (was Re:	 Question for dev's: Does mplayer disable DPMS	timeouts? "xset
 q" looks good, but timeouts never trigger)
In-Reply-To: <1315547954.15632.67.camel@valinor.malmo.kicore.net>
References: <4E665A5E.7010409@tedpavlic.com>	<20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>	<20110907104723.GA9561@phare.normalesup.org>	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
	<1315547954.15632.67.camel@valinor.malmo.kicore.net>
Message-ID: <4E75F00A.4000804@unix-ag.uni-kl.de>

Hi Dan,

On 09/09/2011 07:59 AM, Dan Oscarsson wrote:
> tor 2011-09-08 klockan 22:15 +0200 skrev Erik Auerswald:
>>
>> My goal is to see no subtitles unless explicitly specifying some. Having a
>> default subtitle language set should not count as specifying a subtitle. It
>> should just provide a useful default selection for switching on subtitle
>> visibility interactively.
>
> For me, who understands Swedish or English, the preferred way would be
> for a video player to, by default, show the Swedish or English subtitle
> if audio is in some other language. I have not looked at the code to see
> if something like that is possible, and language information in media is
> not always correct, so it may not be easy to implement.

That would be nice. E.g. adding a new option/config file token for 
preferred languages and then checking for audio tracks with this 
language first, and subtitles later, if no matching audio is found.

This cannot work all the time. E.g. my "Vengeance" DVD has two audio 
tracks, "de" and "en", but "en" is a mix of Chinese (probably 
Cantonese), French and English. I prefer to watch it using the "en" 
audio track, but with German subtitles ("de", only subs on disc) enabled.

But most of the time, looking for preferred languages would do The Right 
Thing?.

Some table specifying the equivalence of two- and three-letter language 
codes (e.g. en == eng) would help usability.

Don't hold your breath waiting for me to come up with a patch... ;-)

Thanks,
Erik

From Reimar.Doeffinger at gmx.de  Sun Sep 18 18:06:11 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 18 Sep 2011 18:06:11 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in	trunk/libass:
 ass.c ass.h ass_bitmap.c ass_bitmap.h	ass_cache.c ass_cache.h	ass_drawing.c
 ass_font.c ass_font.h	ass_fontconfig.c	ass_fontconfig.h ass_library.c
 ass_library.h ass_parse.c...
In-Reply-To: <4E75E6DC.6090300@unix-ag.uni-kl.de>
References: <20110911203416.GA4736@tane>
	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>
	<20110912161241.GB3165@1und1.de>
	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>
	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>
	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>
	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>
	<20110913143127.GA5063@sushi.unix-ag.uni-kl.de>
	<20110917142516.GH6990@1und1.de>
	<4E75E6DC.6090300@unix-ag.uni-kl.de>
Message-ID: <20110918160611.GA3365@1und1.de>

On Sun, Sep 18, 2011 at 02:41:00PM +0200, Erik Auerswald wrote:
> >My concern now is mostly about making sure that no significant
> >optimizations are lost when removing our heavily modified mp3lib.
> 
> ffmp3float seems to be faster on my system:
> 
> ==========================================================================
> Requested audio codec family [mpg123] (afm=mpg123) not available.
> Enable it at compilation.
> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
> AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 24000->352800)
> Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
> ==========================================================================
> AO: [null] 44100Hz 2ch floatle (4 bytes per sample)
> Video: no video
> Starting playback...
> A: 271.7 (04:31.6) of 358.0 (05:58.0)  0.9% 0%
> Audio output truncated at end.
> A: 271.7 (04:31.6) of 358.0 (05:58.0)  0.9% 0%
> 
> 
> BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.433s Sys: 276.795s =  279.228s
> BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  0.8712% Sys: 99.1288% = 100.0000%
> 
> ==========================================================================
> Trying to force audio codec driver family mp3lib...
> Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
> AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
> Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
> ==========================================================================
> AO: [null] 44100Hz 2ch s16le (2 bytes per sample)
> Video: no video
> Starting playback...
> A: 271.6 (04:31.6) of 538.0 (08:58.0)  1.1% 0%
> Audio output truncated at end.
> A: 271.6 (04:31.6) of 538.0 (08:58.0)  1.1% 0%

Yes, but they are outputting to different formats.
I guess where Carl sees the performance loss is when you need s16le in
the end, e.g. if you add -af format=s16le (or something like that, do
not know the exact syntax).

From auerswal at unix-ag.uni-kl.de  Sun Sep 18 18:51:04 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Sun, 18 Sep 2011 18:51:04 +0200
Subject: [MPlayer-dev-eng] [MPlayer-cvslog] r34099 - in	trunk/libass:
 ass.c ass.h ass_bitmap.c ass_bitmap.h	ass_cache.c ass_cache.h	ass_drawing.c
 ass_font.c ass_font.h	ass_fontconfig.c	ass_fontconfig.h ass_library.c
 ass_library.h ass_parse.c...
In-Reply-To: <20110918160611.GA3365@1und1.de>
References: <20110911203416.GA4736@tane>	<20110912085049.GB14263@pool.informatik.rwth-aachen.de>	<20110912161241.GB3165@1und1.de>	<20110913070949.GA11243@sushi.unix-ag.uni-kl.de>	<20110913115145.GC6665@pool.informatik.rwth-aachen.de>	<20110913123919.GA31656@sushi.unix-ag.uni-kl.de>	<20110913135856.GD6665@pool.informatik.rwth-aachen.de>	<20110913143127.GA5063@sushi.unix-ag.uni-kl.de>	<20110917142516.GH6990@1und1.de>	<4E75E6DC.6090300@unix-ag.uni-kl.de>
	<20110918160611.GA3365@1und1.de>
Message-ID: <4E762178.3030804@unix-ag.uni-kl.de>

Hi,

On 09/18/2011 06:06 PM, Reimar D?ffinger wrote:
> On Sun, Sep 18, 2011 at 02:41:00PM +0200, Erik Auerswald wrote:
>>> My concern now is mostly about making sure that no significant
>>> optimizations are lost when removing our heavily modified mp3lib.
>>
>> ffmp3float seems to be faster on my system:
>>
>> ==========================================================================
>> Requested audio codec family [mpg123] (afm=mpg123) not available.
>> Enable it at compilation.
>> Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
>> AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 24000->352800)
>> Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
>> ==========================================================================
>> AO: [null] 44100Hz 2ch floatle (4 bytes per sample)
>> Video: no video
>> Starting playback...
>> A: 271.7 (04:31.6) of 358.0 (05:58.0)  0.9% 0%
>> Audio output truncated at end.
>> A: 271.7 (04:31.6) of 358.0 (05:58.0)  0.9% 0%
>>
>>
>> BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.433s Sys: 276.795s =  279.228s
>> BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  0.8712% Sys: 99.1288% = 100.0000%
>>
>> ==========================================================================
>> Trying to force audio codec driver family mp3lib...
>> Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
>> AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
>> Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
>> ==========================================================================
>> AO: [null] 44100Hz 2ch s16le (2 bytes per sample)
>> Video: no video
>> Starting playback...
>> A: 271.6 (04:31.6) of 538.0 (08:58.0)  1.1% 0%
>> Audio output truncated at end.
>> A: 271.6 (04:31.6) of 538.0 (08:58.0)  1.1% 0%

You omitted the -benchmark output, I re-added it for reference:

BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.998s Sys: 276.480s =  279.478s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  1.0728% Sys: 98.9272% = 100.0000%

> Yes, but they are outputting to different formats.
> I guess where Carl sees the performance loss is when you need s16le in
> the end, e.g. if you add -af format=s16le (or something like that, do
> not know the exact syntax).

Using -format s16le (or -af format=s16le) is a bit slower than foatle, 
but still faster than mp3lib:

==========================================================================
Requested audio codec family [mpg123] (afm=mpg123) not available.
Enable it at compilation.
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, floatle, 192.0 kbit/6.80% (ratio: 24000->352800)
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
==========================================================================
AO: [null] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 271.7 (04:31.6) of 358.0 (05:58.0)  1.0% 0%
Audio output truncated at end.
A: 271.7 (04:31.6) of 358.0 (05:58.0)  1.0% 0%


BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.627s Sys: 276.665s =  279.292s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  0.9407% Sys: 99.0593% = 100.0000%


Hm, -ac ffmp3 results in s16le output and is a lot slower:

==========================================================================
Forced audio codec: ffmp3
Opening audio decoder: [ffmpeg] FFmpeg/libavcodec audio decoders
AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [ffmp3] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
==========================================================================
AO: [null] 44100Hz 2ch s16le (2 bytes per sample)
Video: no video
Starting playback...
A: 271.6 (04:31.6) of 358.0 (05:58.0)  1.9% 0%
Audio output truncated at end.
A: 271.7 (04:31.6) of 358.0 (05:58.0)  1.9% 0%


BENCHMARKs: VC:   0.000s VO:   0.000s A:   5.171s Sys: 280.325s =  285.496s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  1.8114% Sys: 98.1886% = 100.0000%


Erik

From cehoyos at ag.or.at  Sun Sep 18 18:52:21 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Sun, 18 Sep 2011 16:52:21 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH]Support ProRes if libopencore is not
	available / was disabled
References: <201109152134.29391.cehoyos@ag.or.at>
Message-ID: <loom.20110918T185156-735@post.gmane.org>

Carl Eugen Hoyos <cehoyos <at> ag.or.at> writes:

> I will apply attached if nobody has better ideas, Carl Eugen

Patch applied, Carl Eugen


From eclipse7 at gmx.net  Sun Sep 18 19:46:56 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 18 Sep 2011 19:46:56 +0200
Subject: [MPlayer-dev-eng] [PATCH] Remove some useless ifdefs in
 x11_common.h
In-Reply-To: <E972EC80-E193-43F4-8E32-FA4C4E163767@gmx.de>
References: <20110917150134.GA13294@1und1.de>
	<20110917210552.GC1043@pool.informatik.rwth-aachen.de>
	<E972EC80-E193-43F4-8E32-FA4C4E163767@gmx.de>
Message-ID: <20110918174656.GA3755@tane>

Reimar D?ffinger wrote:
> On 17 Sep 2011, at 23:05, Diego Biurrun <diego at biurrun.de> wrote:
> > On Sat, Sep 17, 2011 at 05:01:34PM +0200, Reimar D?ffinger wrote:
> >> See attached, just wanted to double-check I did not miss anything.
> > 
> > Patch looks good to me, I just wonder about all those empty lines
> > you add.
> 
> An attempt to keep the functions grouped by functionality as the ifdef did before.

  Looks good to me too. I also like the empty lines.

  Alexander

From cehoyos at ag.or.at  Sun Sep 18 20:10:01 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Sun, 18 Sep 2011 20:10:01 +0200
Subject: [MPlayer-dev-eng] [PATCH]Disable libopencore* by default
Message-ID: <201109182010.01478.cehoyos@ag.or.at>

Hi!

It could be argued that ProRes decoding is more important than decoding AMR 
through libopencore.

Please comment, Carl Eugen
-------------- next part --------------
Index: configure
===================================================================
--- configure	(revision 34111)
+++ configure	(working copy)
@@ -426,8 +426,8 @@
   --disable-libmpeg2        disable libmpeg2 [autodetect]
   --disable-libmpeg2-internal disable builtin libmpeg2 [autodetect]
   --enable-musepack         enable libmpcdec support (deprecated in favour of libavcodec) [disabled]
-  --disable-libopencore_amrnb disable libopencore_amr narrowband [autodetect]
-  --disable-libopencore_amrwb disable libopencore_amr wideband [autodetect]
+  --enable-libopencore_amrnb autodetect libopencore_amr narrowband [disabled]
+  --enable-libopencore_amrwb autodetect libopencore_amr wideband [disabled]
   --disable-libopenjpeg     disable OpenJPEG (JPEG 2000) input/output support [autodetect]
   --disable-crystalhd       disable CrystalHD support [autodetect]
   --disable-decoder=DECODER disable specified FFmpeg decoder
@@ -630,8 +630,8 @@
 ffmpeg_a=auto
 ffmpeg_so=auto
 _libavcodec_mpegaudio_hp=yes
-_libopencore_amrnb=auto
-_libopencore_amrwb=auto
+_libopencore_amrnb=no
+_libopencore_amrwb=no
 libopenjpeg=auto
 libavdecoders_all=$(sed -n 's/^[^#]*DEC.*(.*, *\(.*\)).*/\1_decoder/p' ffmpeg/libavcodec/allcodecs.c | tr '[a-z]' '[A-Z]')
 libavdecoders=$(echo $libavdecoders_all | sed -e 's/ LIB[A-Z0-9_]*_DECODER//g' -e s/PRORES_DECODER//)
@@ -1236,9 +1236,9 @@
   --disable-libvpx-lavc)  _libvpx_lavc=no   ;;
   --enable-libnut)      _libnut=yes     ;;
   --disable-libnut)     _libnut=no      ;;
-  --enable-libopencore_amrnb)   _libopencore_amrnb=yes  ;;
+  --enable-libopencore_amrnb)   _libopencore_amrnb=auto ;;
   --disable-libopencore_amrnb)  _libopencore_amrnb=no   ;;
-  --enable-libopencore_amrwb)   _libopencore_amrwb=yes  ;;
+  --enable-libopencore_amrwb)   _libopencore_amrwb=auto ;;
   --disable-libopencore_amrwb)  _libopencore_amrwb=no   ;;
   --enable-decoder=*)  libavdecoders="$libavdecoders $(echo $ac_option | cut -d '=' -f 2 | tr '[a-z]' '[A-Z]')" ;;
   --disable-decoder=*) libavdecoders=$(echo $libavdecoders | sed "s/$(echo $ac_option | cut -d '=' -f 2 | tr '[a-z]' '[A-Z]')//g") ;;

From ib at wupperonline.de  Sun Sep 18 20:48:50 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 18 Sep 2011 20:48:50 +0200
Subject: [MPlayer-dev-eng] GUI and vo_x11 functions
In-Reply-To: <4e6f3390.7fa2540f.bm000@wupperonline.de>
Message-ID: <4e763d12.27e5a992.bm001@wupperonline.de>

I wrote on Tue, 13 Sep 2011 12:34:48 +0200:

> We only would [...] allow VOCTRL_ONTOP [...]

Ping?

It's probably best (and easiest) to copy the vo_x11_setlayer() code to the
GUI.

If there are no further contributions I'll do so within the next few days.

Ingo

From ib at wupperonline.de  Sun Sep 18 20:42:18 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 18 Sep 2011 20:42:18 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e6e18b9.5c2756e6.bm000@wupperonline.de>
Message-ID: <4e763d12.2f5922c9.bm000@wupperonline.de>

I wrote on Mon, 12 Sep 2011 12:58:58 +0200:

> [...] wouldn't it be better to just patch vo_hidecursor() and
> vo_showcursor() (and copy the few autohide lines - as they
> currently are, not as separate function - to the GUI code)

Ping?

Are there objections? If not, I'd like to commit and finish this topic.

Ingo

From eclipse7 at gmx.net  Sun Sep 18 20:51:30 2011
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 18 Sep 2011 20:51:30 +0200
Subject: [MPlayer-dev-eng] [PATCH] Remove some useless ifdefs in
 x11_common.h
In-Reply-To: <20110917150134.GA13294@1und1.de>
References: <20110917150134.GA13294@1und1.de>
Message-ID: <20110918185130.GB3755@tane>

Hi Reimar!

Reimar D?ffinger wrote:
[...]
> And btw. does anyone see any issues with completely removing all
> X11_FULLSCREEN conditionals?
> It seems it is only ever undefined when building only vo_dxr3 or
> something and probably will fail to build in that case anyway...

  I don't know why X11_FULLSCREEN was introduced but I don't think
it adds much value (if at all) today.

  Alexander

From diego at biurrun.de  Mon Sep 19 11:57:20 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 19 Sep 2011 11:57:20 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation
In-Reply-To: <4e7209e4.1177514b.bm000@wupperonline.de>
References: <4e7209e4.1177514b.bm000@wupperonline.de>
Message-ID: <20110919095720.GA28145@pool.informatik.rwth-aachen.de>

On Thu, Sep 15, 2011 at 11:30:19AM +0200, Ingo Br?ckl wrote:
> There are some conditional declarations within the GUI (and in MPlayer as
> well, see X11_FULLSCREEN in libvo/x11_common.c) that currently won't appear
> in the doxygen documentation, i.e. the generated documentation is rather one
> according to the personal settings than a general one. This could be changed
> by using the PREDEFINED tag.

I must say this has a smell of workaround to it.  What problem are you
trying to fix exactly?

> --- DOCS/tech/Doxyfile	(revision 34103)
> +++ DOCS/tech/Doxyfile	(working copy)
> @@ -1144,7 +1144,7 @@
>  # then the macro expansion is limited to the macros specified with the
>  # PREDEFINED and EXPAND_AS_DEFINED tags.
>  
> -EXPAND_ONLY_PREDEF     = NO
> +EXPAND_ONLY_PREDEF     = YES

What about setting MACRO_EXPANSION to "yes" instead?

Diego

From Reimar.Doeffinger at gmx.de  Mon Sep 19 20:14:09 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 19 Sep 2011 20:14:09 +0200
Subject: [MPlayer-dev-eng] [PATCH] GUI cursor control
In-Reply-To: <4e763d12.2f5922c9.bm000@wupperonline.de>
References: <4e6e18b9.5c2756e6.bm000@wupperonline.de>
	<4e763d12.2f5922c9.bm000@wupperonline.de>
Message-ID: <20110919181409.GA2779@1und1.de>

On Sun, Sep 18, 2011 at 08:42:18PM +0200, Ingo Br?ckl wrote:
> I wrote on Mon, 12 Sep 2011 12:58:58 +0200:
> 
> > [...] wouldn't it be better to just patch vo_hidecursor() and
> > vo_showcursor() (and copy the few autohide lines - as they
> > currently are, not as separate function - to the GUI code)
> 
> Ping?
> 
> Are there objections? If not, I'd like to commit and finish this topic.

Fine, it's not the perfect solution but the perfect solution probably
involves some significant code cleanup.
Also since it looks like also some differences in behaviour remain
between w32_common and x11_common behaviour (I'll ignore the OSX code,
before I feel the urge to go berserk ;-) ).

From deron at pagestream.org  Mon Sep 19 21:20:43 2011
From: deron at pagestream.org (Deron Kazmaier)
Date: Mon, 19 Sep 2011 13:20:43 -0600
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <20110917210830.GD1043@pool.informatik.rwth-aachen.de>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
	<4E74DF5F.1060106@pagestream.org>
	<20110917210830.GD1043@pool.informatik.rwth-aachen.de>
Message-ID: <4E77960B.20907@pagestream.org>

On 9/17/11 3:08 PM, Diego Biurrun wrote:
> On Sat, Sep 17, 2011 at 11:56:47AM -0600, Deron Kazmaier wrote:
>> On 9/17/11 10:58 AM, Reimar D?ffinger wrote:
>>> On Sat, Sep 17, 2011 at 10:49:04AM -0600, Deron Kazmaier wrote:
>>>> I've updated the code to compile (well, one niggly that I don't
>>>> fully understand but it is with a Delete which hopefully will at
>>>> worst just leave memory unfreed at the end) but I couldn't get it
>>>> too link. The error messages certainly made me believe that the
>>>> problem is simply that the C++ libraries are not linked in. Just
>>>> using g++ instead of gcc seems to fix it (I copy/pasted the link
>>>> line, replacing gcc with g++), but what would be the proper way to
>>>> handle this in the config? Obviously the average user would not
>>>> enable/compile the decklink drivers and so it would be crazy to use
>>>> g++ all the time to link it.
>>> Well, you are really very vague and don't give us any relevant
>>> information at all.
>>> But usually that would be because you're missing -lstdc++
>> Sorry, I may have given too much info.
> No, you have given too little.  Please send the patch and show us
> the error message.
>
> Diego

Sorry. I was talking about the background. I never know how much to 
write before eyes start glazing over and people reach for the delete key :-)

I have this compiling and linking and running by hand (I simply 
copy/paste the final mplayer link line, replacing cc with g++), but it 
would be nice if configure could take care of it. The actual DeckLink 
driver patch was posted on this list and can be seen here:

http://mplayerhq.hu/pipermail/mplayer-dev-eng/2009-August/062097.html

patch url 
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090817/0a55034d/attachment.diff.

Here is the original errors when it tried to link with cc instead of g++:

libvo/vo_decklink.o: In function `config':
vo_decklink.cpp:(.text+0x50b): undefined reference to `operator 
new[](unsigned long)'
libvo/vo_decklink.o: In function `preinit':
vo_decklink.cpp:(.text+0x7a7): undefined reference to `operator 
new(unsigned long)'
libvo/vo_decklink.o: In function 
`DeckLinkVideoOutputCallback::~DeckLinkVideoOutputCallback()':
vo_decklink.cpp:(.text._ZN27DeckLinkVideoOutputCallbackD0Ev[_ZN27DeckLinkVideoOutputCallbackD5Ev]+0x8): 
undefined reference to `operator delete(void*)'
libvo/vo_decklink.o: In function 
`IDeckLinkVideoOutputCallback::~IDeckLinkVideoOutputCallback()':
vo_decklink.cpp:(.text._ZN28IDeckLinkVideoOutputCallbackD0Ev[_ZN28IDeckLinkVideoOutputCallbackD5Ev]+0x8): 
undefined reference to `operator delete(void*)'
libvo/vo_decklink.o:(.rodata._ZTV28IDeckLinkVideoOutputCallback[vtable 
for IDeckLinkVideoOutputCallback]+0x10): undefined reference to 
`__cxa_pure_virtual'
libvo/vo_decklink.o:(.rodata._ZTV28IDeckLinkVideoOutputCallback[vtable 
for IDeckLinkVideoOutputCallback]+0x18): undefined reference to 
`__cxa_pure_virtual'
libvo/vo_decklink.o:(.rodata._ZTV28IDeckLinkVideoOutputCallback[vtable 
for IDeckLinkVideoOutputCallback]+0x20): undefined reference to 
`__cxa_pure_virtual'
libvo/vo_decklink.o:(.rodata._ZTV28IDeckLinkVideoOutputCallback[vtable 
for IDeckLinkVideoOutputCallback]+0x28): undefined reference to 
`__cxa_pure_virtual'
libvo/vo_decklink.o:(.rodata._ZTV28IDeckLinkVideoOutputCallback[vtable 
for IDeckLinkVideoOutputCallback]+0x30): undefined reference to 
`__cxa_pure_virtual'
libvo/vo_decklink.o:(.rodata._ZTV8IUnknown[vtable for IUnknown]+0x10): 
more undefined references to `__cxa_pure_virtual' follow
libvo/vo_decklink.o:(.rodata._ZTI27DeckLinkVideoOutputCallback[typeinfo 
for DeckLinkVideoOutputCallback]+0x0): undefined reference to `vtable 
for __cxxabiv1::__si_class_type_info'
libvo/vo_decklink.o:(.rodata._ZTI28IDeckLinkVideoOutputCallback[typeinfo 
for IDeckLinkVideoOutputCallback]+0x0): undefined reference to `vtable 
for __cxxabiv1::__si_class_type_info'
libvo/vo_decklink.o:(.rodata._ZTI8IUnknown[typeinfo for IUnknown]+0x0): 
undefined reference to `vtable for __cxxabiv1::__class_type_info'
collect2: ld returned 1 exit status



Thanks,

Deron


From deron at pagestream.org  Mon Sep 19 21:23:37 2011
From: deron at pagestream.org (Deron Kazmaier)
Date: Mon, 19 Sep 2011 13:23:37 -0600
Subject: [MPlayer-dev-eng] Passing parameters to video/audio output drivers
Message-ID: <4E7796B9.3090908@pagestream.org>

I've been tinkering with the DeckLink patch submitted in August of 2009 
(http://mplayerhq.hu/pipermail/mplayer-dev-eng/2009-August/062097.html   
patch url 
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090817/0a55034d/attachment.diff) 
and have it working for the most part. I could use some pointers on how 
best to solve a few problems within the proper mplayer framework.

First, as I understand it the video output mode is selected using the 
width and height based on the width and height of the video data. It 
will fail if the width and height do not match. I can select the next 
size up, but is there someway for the decklink driver to cause a 
scale/crop/pad for mplayer etal to fill out the data or does it need to 
do that itself? I know the user can scale it, but is it recommended to 
do this automatically since it is required?

Second, that same code does not try and match the fps. It was just 
picking the first fps option that matched the width/height. Can I get 
the fps of the video data in the config call of the video driver? Again, 
if it does not match an available output, can I request it be scaled up?

Lastly (well for the video driver for now), I need to select from 
multiple output devices. I happen to have 2, but each device can have 
multiple outputs itself. What is the proper way to pass parameters like 
this to the driver?

If some existing drivers do these things, I'm happy to go look there, 
just which drivers to go look at? I'm not trying to get anyone else to 
do any heavy lifting, but I'm overwhelmed with the amount of unfamiliar 
code and would like to see this patch conforming to mplayer standards 
and included.

Thanks,

Deron


From Reimar.Doeffinger at gmx.de  Mon Sep 19 22:22:09 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 19 Sep 2011 22:22:09 +0200
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <4E77960B.20907@pagestream.org>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
	<4E74DF5F.1060106@pagestream.org>
	<20110917210830.GD1043@pool.informatik.rwth-aachen.de>
	<4E77960B.20907@pagestream.org>
Message-ID: <20110919202209.GB6403@1und1.de>

On Mon, Sep 19, 2011 at 01:20:43PM -0600, Deron Kazmaier wrote:
> patch url http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090817/0a55034d/attachment.diff.

Well, the configure part of that is a joke.

> libvo/vo_decklink.o:(.rodata._ZTV28IDeckLinkVideoOutputCallback[vtable
> for IDeckLinkVideoOutputCallback]+0x10): undefined reference to
> `__cxa_pure_virtual'
> libvo/vo_decklink.o:(.rodata._ZTI27DeckLinkVideoOutputCallback[typeinfo
> for DeckLinkVideoOutputCallback]+0x0): undefined reference to
> `vtable for __cxxabiv1::__si_class_type_info'

objdump -T /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16  | grep '\(__cxa_pure_virtual\|__si_class_type_info\)'
00000000000bdb10 g    DF .text  000000000000001f  CXXABI_1.3 __cxa_pure_virtual
00000000000bdb30 g    DF .text  0000000000000013  CXXABI_1.3 _ZN10__cxxabiv120__si_class_type_infoD2Ev

So you could just do as I suggested and add -lstdc++ to the linker flags
(e.g. libs_mplayer="$libs_mplayer -lstdc++", though when writing a
proper configure check that should become quite obvious how to do it).

From Reimar.Doeffinger at gmx.de  Mon Sep 19 22:28:44 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 19 Sep 2011 22:28:44 +0200
Subject: [MPlayer-dev-eng] Passing parameters to video/audio output
 drivers
In-Reply-To: <4E7796B9.3090908@pagestream.org>
References: <4E7796B9.3090908@pagestream.org>
Message-ID: <20110919202844.GC6403@1und1.de>

On Mon, Sep 19, 2011 at 01:23:37PM -0600, Deron Kazmaier wrote:
> First, as I understand it the video output mode is selected using
> the width and height based on the width and height of the video
> data. It will fail if the width and height do not match. I can
> select the next size up, but is there someway for the decklink
> driver to cause a scale/crop/pad for mplayer etal to fill out the
> data or does it need to do that itself? I know the user can scale
> it, but is it recommended to do this automatically since it is
> required?

There is no code for that there yet. I worked on it several years back
(for vo_x11) but it was never finished and the code got lost.
You could do the scaling in the vo like vo_x11, but IMO it's not
a good idea.

> Second, that same code does not try and match the fps. It was just
> picking the first fps option that matched the width/height. Can I
> get the fps of the video data in the config call of the video
> driver?

vo_fps, but is unreliable and generally a bad idea to rely on.
Also I'd expect anyone using the decklink stuff wants a very specific
output frame rate, which does not necessarily have anything to do
with the frame rate of the input.

> Again, if it does not match an available output, can I
> request it be scaled up?

Just draw the frame twice, or not at all?

> Lastly (well for the video driver for now), I need to select from
> multiple output devices. I happen to have 2, but each device can
> have multiple outputs itself. What is the proper way to pass
> parameters like this to the driver?

preinit gets a string as parameter.

> If some existing drivers do these things, I'm happy to go look
> there, just which drivers to go look at?

vo_gl is one of the more maintained ones.

From diego at biurrun.de  Mon Sep 19 23:11:02 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Mon, 19 Sep 2011 23:11:02 +0200
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <4E77960B.20907@pagestream.org>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
	<4E74DF5F.1060106@pagestream.org>
	<20110917210830.GD1043@pool.informatik.rwth-aachen.de>
	<4E77960B.20907@pagestream.org>
Message-ID: <20110919211100.GA28114@pool.informatik.rwth-aachen.de>

On Mon, Sep 19, 2011 at 01:20:43PM -0600, Deron Kazmaier wrote:
> On 9/17/11 3:08 PM, Diego Biurrun wrote:
> >On Sat, Sep 17, 2011 at 11:56:47AM -0600, Deron Kazmaier wrote:
> >>On 9/17/11 10:58 AM, Reimar D?ffinger wrote:
> >>>On Sat, Sep 17, 2011 at 10:49:04AM -0600, Deron Kazmaier wrote:
> >>>>I've updated the code to compile (well, one niggly that I don't
> >>>>fully understand but it is with a Delete which hopefully will at
> >>>>worst just leave memory unfreed at the end) but I couldn't get it
> >>>>too link. The error messages certainly made me believe that the
> >>>>problem is simply that the C++ libraries are not linked in. Just
> >>>>using g++ instead of gcc seems to fix it (I copy/pasted the link
> >>>>line, replacing gcc with g++), but what would be the proper way to
> >>>>handle this in the config? Obviously the average user would not
> >>>>enable/compile the decklink drivers and so it would be crazy to use
> >>>>g++ all the time to link it.
> >>>Well, you are really very vague and don't give us any relevant
> >>>information at all.
> >>>But usually that would be because you're missing -lstdc++
> >>Sorry, I may have given too much info.
> >No, you have given too little.  Please send the patch and show us
> >the error message.
> 
> Sorry. I was talking about the background. I never know how much to
> write before eyes start glazing over and people reach for the delete
> key :-)
> 
> I have this compiling and linking and running by hand (I simply
> copy/paste the final mplayer link line, replacing cc with g++), but
> it would be nice if configure could take care of it. The actual
> DeckLink driver patch was posted on this list and can be seen here:
> 
> http://mplayerhq.hu/pipermail/mplayer-dev-eng/2009-August/062097.html
> 
> patch url http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090817/0a55034d/attachment.diff.

Why not port this to C and be done with it?  I honestly don't think we
should accept C++ ao/vo drivers.

Diego

From Reimar.Doeffinger at gmx.de  Mon Sep 19 23:22:30 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 19 Sep 2011 23:22:30 +0200
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <20110919211100.GA28114@pool.informatik.rwth-aachen.de>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
	<4E74DF5F.1060106@pagestream.org>
	<20110917210830.GD1043@pool.informatik.rwth-aachen.de>
	<4E77960B.20907@pagestream.org>
	<20110919211100.GA28114@pool.informatik.rwth-aachen.de>
Message-ID: <20110919212230.GA31463@1und1.de>

On Mon, Sep 19, 2011 at 11:11:02PM +0200, Diego Biurrun wrote:
> On Mon, Sep 19, 2011 at 01:20:43PM -0600, Deron Kazmaier wrote:
> > On 9/17/11 3:08 PM, Diego Biurrun wrote:
> > >On Sat, Sep 17, 2011 at 11:56:47AM -0600, Deron Kazmaier wrote:
> > >>On 9/17/11 10:58 AM, Reimar D?ffinger wrote:
> > >>>On Sat, Sep 17, 2011 at 10:49:04AM -0600, Deron Kazmaier wrote:
> > >>>>I've updated the code to compile (well, one niggly that I don't
> > >>>>fully understand but it is with a Delete which hopefully will at
> > >>>>worst just leave memory unfreed at the end) but I couldn't get it
> > >>>>too link. The error messages certainly made me believe that the
> > >>>>problem is simply that the C++ libraries are not linked in. Just
> > >>>>using g++ instead of gcc seems to fix it (I copy/pasted the link
> > >>>>line, replacing gcc with g++), but what would be the proper way to
> > >>>>handle this in the config? Obviously the average user would not
> > >>>>enable/compile the decklink drivers and so it would be crazy to use
> > >>>>g++ all the time to link it.
> > >>>Well, you are really very vague and don't give us any relevant
> > >>>information at all.
> > >>>But usually that would be because you're missing -lstdc++
> > >>Sorry, I may have given too much info.
> > >No, you have given too little.  Please send the patch and show us
> > >the error message.
> > 
> > Sorry. I was talking about the background. I never know how much to
> > write before eyes start glazing over and people reach for the delete
> > key :-)
> > 
> > I have this compiling and linking and running by hand (I simply
> > copy/paste the final mplayer link line, replacing cc with g++), but
> > it would be nice if configure could take care of it. The actual
> > DeckLink driver patch was posted on this list and can be seen here:
> > 
> > http://mplayerhq.hu/pipermail/mplayer-dev-eng/2009-August/062097.html
> > 
> > patch url http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090817/0a55034d/attachment.diff.
> 
> Why not port this to C and be done with it?  I honestly don't think we
> should accept C++ ao/vo drivers.

Because accessing a C++ only library from C is madness of the kind where
you don't want to go?
Now I'd be all for beating decklink with a cluestick for making it
impossible to use their devices from pure C, particularly since I
don't really see them make any good use of C++, but I don't see
that having a large chance of success.

From ib at wupperonline.de  Mon Sep 19 23:10:51 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Mon, 19 Sep 2011 23:10:51 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation
In-Reply-To: <20110919095720.GA28145@pool.informatik.rwth-aachen.de>
Message-ID: <4e77b87b.5ae661aa.bm000@wupperonline.de>

Diego Biurrun wrote on Mon, 19 Sep 2011 11:57:20 +0200:

> I must say this has a smell of workaround to it.

If it's OK to make conditional definitions (to remove otherwise useless
code), I can't understand why everyone is saying this.

> What problem are you trying to fix exactly?

See gui/interface.h line 105 or gui/ui/gtk/menu.c, line 383 or mplayer.c,
line 542, for example. Shouldn't these show up in a (complete) MPlayer
documentation (i.e. shouldn't all the CONFIGs be set for a complete
documentation)?

>> -EXPAND_ONLY_PREDEF     = NO
>> +EXPAND_ONLY_PREDEF     = YES

> What about setting MACRO_EXPANSION to "yes" instead?

This doesn't help if a macro isn't defined at all.

MACRO_EXPANSION is a complete different matter and affects code like
libvo/vo_x11.c, line 67. (It may be a good idea to set it, too, though.)

Ingo

From Reimar.Doeffinger at gmx.de  Tue Sep 20 00:02:23 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 20 Sep 2011 00:02:23 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation
In-Reply-To: <4e77b87b.5ae661aa.bm000@wupperonline.de>
References: <20110919095720.GA28145@pool.informatik.rwth-aachen.de>
	<4e77b87b.5ae661aa.bm000@wupperonline.de>
Message-ID: <20110919220223.GA32531@1und1.de>

On Mon, Sep 19, 2011 at 11:10:51PM +0200, Ingo Br?ckl wrote:
> Diego Biurrun wrote on Mon, 19 Sep 2011 11:57:20 +0200:
> 
> > I must say this has a smell of workaround to it.
> 
> If it's OK to make conditional definitions (to remove otherwise useless
> code), I can't understand why everyone is saying this.

For _code_ yes, but not for _declarations in header files_.
The libvo X11 stuff was of the latter kind.

> > What problem are you trying to fix exactly?
> 
> See gui/interface.h line 105 or gui/ui/gtk/menu.c, line 383 or mplayer.c,
> line 542, for example. Shouldn't these show up in a (complete) MPlayer
> documentation (i.e. shouldn't all the CONFIGs be set for a complete
> documentation)?

Yes, for those that's probably the proper way.
Though in case of gui/interface.h most of those #ifdefs seems rather pointless
(saving only a few bytes in a configuration hopefully almost no-one
uses), or rather in light of e.g. Bluray probably incorrect.

From Reimar.Doeffinger at gmx.de  Tue Sep 20 00:22:00 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 20 Sep 2011 00:22:00 +0200
Subject: [MPlayer-dev-eng] [PATCH] Doxygen and conditional compilation
In-Reply-To: <20110919220223.GA32531@1und1.de>
References: <20110919095720.GA28145@pool.informatik.rwth-aachen.de>
	<4e77b87b.5ae661aa.bm000@wupperonline.de>
	<20110919220223.GA32531@1und1.de>
Message-ID: <20110919222200.GB1666@1und1.de>

On Tue, Sep 20, 2011 at 12:02:23AM +0200, Reimar D?ffinger wrote:
> On Mon, Sep 19, 2011 at 11:10:51PM +0200, Ingo Br?ckl wrote:
> > Diego Biurrun wrote on Mon, 19 Sep 2011 11:57:20 +0200:
> > 
> > > I must say this has a smell of workaround to it.
> > 
> > If it's OK to make conditional definitions (to remove otherwise useless
> > code), I can't understand why everyone is saying this.
> 
> For _code_ yes, but not for _declarations in header files_.
> The libvo X11 stuff was of the latter kind.

And I got rid of it, so you shouldn't need those anymore at least.

From Reimar.Doeffinger at gmx.de  Tue Sep 20 01:02:57 2011
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Tue, 20 Sep 2011 01:02:57 +0200
Subject: [MPlayer-dev-eng] [PATCH] Remove some useless ifdefs in
	x11_common.h
In-Reply-To: <20110918185130.GB3755@tane>
References: <20110917150134.GA13294@1und1.de> <20110918185130.GB3755@tane>
Message-ID: <12F897AF-4619-419D-AB5C-95792B49649C@gmx.de>



On 18 Sep 2011, at 20:51, Alexander Strasser <eclipse7 at gmx.net> wrote:

> Hi Reimar!
> 
> Reimar D?ffinger wrote:
> [...]
>> And btw. does anyone see any issues with completely removing all
>> X11_FULLSCREEN conditionals?
>> It seems it is only ever undefined when building only vo_dxr3 or
>> something and probably will fail to build in that case anyway...
> 
>  I don't know why X11_FULLSCREEN was introduced but I don't think
> it adds much value (if at all) today.

Patch applied and that one removed as well.
> 

From deron at pagestream.org  Tue Sep 20 15:56:12 2011
From: deron at pagestream.org (Deron Kazmaier)
Date: Tue, 20 Sep 2011 07:56:12 -0600
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <20110919202209.GB6403@1und1.de>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
	<4E74DF5F.1060106@pagestream.org>
	<20110917210830.GD1043@pool.informatik.rwth-aachen.de>
	<4E77960B.20907@pagestream.org> <20110919202209.GB6403@1und1.de>
Message-ID: <4E789B7C.8060502@pagestream.org>

On 9/19/11 2:22 PM, Reimar D?ffinger wrote:
> On Mon, Sep 19, 2011 at 01:20:43PM -0600, Deron Kazmaier wrote:
>> patch url http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090817/0a55034d/attachment.diff.
> Well, the configure part of that is a joke.

It may be, but it is better than I could write at this moment! Man 
stands on the shoulders of the accomplishments of those who came before.

I'm just thrilled to have it. With suggestion you provided 2 years ago 
to the original poster I have fixed the audio issues, and the multi 
threading has addressed the speed issues. "Just" takes 6 threads to play 
out the 720p 59.94fps ProRes files. I saw on the FFmpeg list that 
they/you are looking for samples of different formats so I'll be asking 
my friend to generate a variety of samples on the Mac editing station he 
uses.

>
>> libvo/vo_decklink.o:(.rodata._ZTV28IDeckLinkVideoOutputCallback[vtable
>> for IDeckLinkVideoOutputCallback]+0x10): undefined reference to
>> `__cxa_pure_virtual'
>> libvo/vo_decklink.o:(.rodata._ZTI27DeckLinkVideoOutputCallback[typeinfo
>> for DeckLinkVideoOutputCallback]+0x0): undefined reference to
>> `vtable for __cxxabiv1::__si_class_type_info'
> objdump -T /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.16  | grep '\(__cxa_pure_virtual\|__si_class_type_info\)'
> 00000000000bdb10 g    DF .text  000000000000001f  CXXABI_1.3 __cxa_pure_virtual
> 00000000000bdb30 g    DF .text  0000000000000013  CXXABI_1.3 _ZN10__cxxabiv120__si_class_type_infoD2Ev
>
> So you could just do as I suggested and add -lstdc++ to the linker flags
> (e.g. libs_mplayer="$libs_mplayer -lstdc++", though when writing a
> proper configure check that should become quite obvious how to do it).
> _______________________________________________

Yes, this resolved it as well, and I've adjusted the configure script to 
suit. Thanks!

Right now the configure script simply defaults to disabled and enables 
it when demanded. Would be acceptable to sniff out installed decklink 
includes and enable decklink automatically? I can't imagine someone 
having the includes on their computer any not wanting to compile it, but 
that is just a thought. Since my (eventual) goal is to have this patch 
accepted, I'd like to know your thoughts on this.

Thank you!

Deron


From deron at pagestream.org  Tue Sep 20 16:15:46 2011
From: deron at pagestream.org (Deron Kazmaier)
Date: Tue, 20 Sep 2011 08:15:46 -0600
Subject: [MPlayer-dev-eng] Passing parameters to video/audio output
	drivers
In-Reply-To: <20110919202844.GC6403@1und1.de>
References: <4E7796B9.3090908@pagestream.org> <20110919202844.GC6403@1und1.de>
Message-ID: <4E78A012.20003@pagestream.org>

On 9/19/11 2:28 PM, Reimar D?ffinger wrote:
> On Mon, Sep 19, 2011 at 01:23:37PM -0600, Deron Kazmaier wrote:
>> First, as I understand it the video output mode is selected using
>> the width and height based on the width and height of the video
>> data. It will fail if the width and height do not match. I can
>> select the next size up, but is there someway for the decklink
>> driver to cause a scale/crop/pad for mplayer etal to fill out the
>> data or does it need to do that itself? I know the user can scale
>> it, but is it recommended to do this automatically since it is
>> required?
> There is no code for that there yet. I worked on it several years back
> (for vo_x11) but it was never finished and the code got lost.
> You could do the scaling in the vo like vo_x11, but IMO it's not
> a good idea.

No problem. If it is ok to fail in this case, I will do so! Actually, it 
looks like it might promote according to some old comments. I'll check 
it out.

If not, should the decklink video driver then provide an error message? 
Should it dump a list of acceptable resolutions? Or give a hint like 
"Video must match available device resolutions. (for example, use -vf 
scale=h:v)"?

>
>> Second, that same code does not try and match the fps. It was just
>> picking the first fps option that matched the width/height. Can I
>> get the fps of the video data in the config call of the video
>> driver?
> vo_fps, but is unreliable and generally a bad idea to rely on.
> Also I'd expect anyone using the decklink stuff wants a very specific
> output frame rate, which does not necessarily have anything to do
> with the frame rate of the input.

Just trying to find a suitable default. I'll use vo_fps if nothing is 
specified.

>> Again, if it does not match an available output, can I
>> request it be scaled up?
> Just draw the frame twice, or not at all?

No problem, just didn't know if some approved method existed. I don't 
understand yet how timing is passed around, but I'll keep my eye out for 
examples from other drivers and ask here when I have a enough knowledge 
to even know what to ask.

>> Lastly (well for the video driver for now), I need to select from
>> multiple output devices. I happen to have 2, but each device can
>> have multiple outputs itself. What is the proper way to pass
>> parameters like this to the driver?
> preinit gets a string as parameter.
>
>> If some existing drivers do these things, I'm happy to go look
>> there, just which drivers to go look at?
> vo_gl is one of the more maintained ones.
>

And I will start with that one.

Thanks again!

Deron


From Reimar.Doeffinger at gmx.de  Tue Sep 20 19:16:53 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 20 Sep 2011 19:16:53 +0200
Subject: [MPlayer-dev-eng] DeckLink driver
In-Reply-To: <4E789B7C.8060502@pagestream.org>
References: <4E74CF80.9050002@pagestream.org> <20110917165830.GA24894@1und1.de>
	<4E74DF5F.1060106@pagestream.org>
	<20110917210830.GD1043@pool.informatik.rwth-aachen.de>
	<4E77960B.20907@pagestream.org> <20110919202209.GB6403@1und1.de>
	<4E789B7C.8060502@pagestream.org>
Message-ID: <20110920171653.GF2518@1und1.de>

On Tue, Sep 20, 2011 at 07:56:12AM -0600, Deron Kazmaier wrote:
> On 9/19/11 2:22 PM, Reimar D?ffinger wrote:
> >On Mon, Sep 19, 2011 at 01:20:43PM -0600, Deron Kazmaier wrote:
> >>patch url http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20090817/0a55034d/attachment.diff.
> >Well, the configure part of that is a joke.
> 
> It may be, but it is better than I could write at this moment! Man
> stands on the shoulders of the accomplishments of those who came
> before.

The point is that just making the patch compile it in unconditionally
would have been simpler and about as useful.
This definitely needs to be improved, having to hack around, adding
extra linker flags manually etc. just isn't acceptable.

> Right now the configure script simply defaults to disabled and
> enables it when demanded. Would be acceptable to sniff out installed
> decklink includes and enable decklink automatically?

Yes, unless something speaks against it that is the preferred approach,
used for almost everything.
That it is c++ will probably add some complications though.
You should probably look at the "LIVE555 Streaming Media libraries"
configure check, it solves similar issues, e.g. it uses cxx_check
to check compilation, and it too has to manually add "-lstdc++".

From Reimar.Doeffinger at gmx.de  Tue Sep 20 19:19:48 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 20 Sep 2011 19:19:48 +0200
Subject: [MPlayer-dev-eng] Passing parameters to video/audio output
 drivers
In-Reply-To: <4E78A012.20003@pagestream.org>
References: <4E7796B9.3090908@pagestream.org> <20110919202844.GC6403@1und1.de>
	<4E78A012.20003@pagestream.org>
Message-ID: <20110920171948.GG2518@1und1.de>

On Tue, Sep 20, 2011 at 08:15:46AM -0600, Deron Kazmaier wrote:
> If not, should the decklink video driver then provide an error
> message? Should it dump a list of acceptable resolutions? Or give a
> hint like "Video must match available device resolutions. (for
> example, use -vf scale=h:v)"?

Whatever is useful to the user. A list of acceptable resolutions
is probably something they will very much want.
A hint to -vf scale is probably a good idea, though slightly less
critical.

> Just trying to find a suitable default. I'll use vo_fps if nothing
> is specified.

Might be worth warning about it though. Particularly if it is
1000 like when playing variable-fps content like WMV.

From Reimar.Doeffinger at gmx.de  Tue Sep 20 20:19:54 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 20 Sep 2011 20:19:54 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
Message-ID: <20110920181954.GA32134@1und1.de>

Hello,
I am still interested in seeing performance numbers and statistics from
ffmp3 vs. mp3lib when ffmp3 is slower, but I guess it's time to start
some more specific moves to get rid of it.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: remove_mp3lib.diff
Type: text/x-diff
Size: 8341 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110920/7534fe14/attachment.bin>

From cehoyos at ag.or.at  Wed Sep 21 02:18:25 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Wed, 21 Sep 2011 00:18:25 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
References: <20110920181954.GA32134@1und1.de>
Message-ID: <loom.20110921T013825-226@post.gmane.org>

Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:

> I am still interested in seeing performance numbers and statistics from
> ffmp3 vs. mp3lib when ffmp3 is slower,

When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
slower than internal libmp3 on systems where I believe it does make a
difference, namely 32bit MMX and SSE.

I did not test external libmp3.

I was sure I sent detailed results once to one of the lists, but cannot find
them now, what I found is what I wrote to Vitor after he committed some
optimisations:
[quote]
I just tested compilation of MPlayer with a 32 bit compiler on the Core2 Duo,
and the resulting binary is significantly slower with -ac ffmp2float with our
sample file than -ac mp3: 10.1 vs 8.8 seconds.
[/quote}

His answer was:
[quote]
mp3lib uses a crazy scheme of mixing floating and fixed point to be able to
use MMX instructions for windowing
[/quote]

Carl Eugen


From 4720 at hushmail.com  Wed Sep 21 03:47:39 2011
From: 4720 at hushmail.com (4720 at hushmail.com)
Date: Wed, 21 Sep 2011 01:47:39 +0000
Subject: [MPlayer-dev-eng] [patch] add warning to vidix/mga_vid.c
Message-ID: <20110921014739.A710A14DBA6@smtp.hushmail.com>

i am submitting some patches that have been freebsd ports patches 
from
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/mplayer/files
/
for inclusion in your project.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-vidix-mga_vid.c
Type: application/octet-stream
Size: 519 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110921/d16a4fae/attachment-0001.obj>

From 4720 at hushmail.com  Wed Sep 21 03:49:02 2011
From: 4720 at hushmail.com (4720 at hushmail.com)
Date: Wed, 21 Sep 2011 01:49:02 +0000
Subject: [MPlayer-dev-eng] [patch] add device to vidix/radeon_vid.c
Message-ID: <20110921014902.3A47E14DBA6@smtp.hushmail.com>

i am submitting some patches that have been freebsd ports patches 
from
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/mplayer/files
/
for inclusion in your project.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-vidix-radeon_vid.c
Type: application/octet-stream
Size: 433 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110921/400444e0/attachment.obj>

From 4720 at hushmail.com  Wed Sep 21 03:55:08 2011
From: 4720 at hushmail.com (4720 at hushmail.com)
Date: Wed, 21 Sep 2011 01:55:08 +0000
Subject: [MPlayer-dev-eng] [patch] set sample rate in libao2/ao_oss.c
Message-ID: <20110921015508.264B214DBA6@smtp.hushmail.com>

i am submitting some patches that have been freebsd ports patches 
from
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/mplayer/files
/
for inclusion in your project.

Set sample rate when resuming playback.  This fixes AC3/DTS 
passthrough
on S/PDIF with snd_hda(4).

Submitted by:	mav
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-libao2-ao_oss.c
Type: application/octet-stream
Size: 574 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110921/9da676ce/attachment.obj>

From 4720 at hushmail.com  Wed Sep 21 04:00:39 2011
From: 4720 at hushmail.com (4720 at hushmail.com)
Date: Wed, 21 Sep 2011 02:00:39 +0000
Subject: [MPlayer-dev-eng] [patch] fix regression in stream/tvi_bsdbt848.c
Message-ID: <20110921020039.F296A14DBA6@smtp.hushmail.com>

i am submitting some patches that have been freebsd ports patches 
from
http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/mplayer/files
/
for inclusion in your project.

- Fix bt848 regression

PR:		119065
Submitted by:	Thomas Zander <riggs at rrr.de> (maintainer)
Tested by:	Oliver Brandmueller <ob at e-Gitt.NET>
		miwi (on current)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch-stream-tvi_bsdbt848.c
Type: application/octet-stream
Size: 2485 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110921/d421357a/attachment.obj>

From Dan.Oscarsson at tieto.com  Wed Sep 21 08:28:26 2011
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Wed, 21 Sep 2011 08:28:26 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <loom.20110921T013825-226@post.gmane.org>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
Message-ID: <1316586506.815.85.camel@valinor.malmo.kicore.net>

ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
> Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:
> 
> > I am still interested in seeing performance numbers and statistics from
> > ffmp3 vs. mp3lib when ffmp3 is slower,
> 
> When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
> on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
> slower than internal libmp3 on systems where I believe it does make a
> difference, namely 32bit MMX and SSE.

Does it make a difference that is significant?
I have used mplayer on a 32bit system for many years together with
vdpau. As vdpau does take nearly no CPU time, there was always lots of
CPU available for audio decoding. It may be different if you do not have
hardware video decoding, but sometime we have to decide if the work to
support old hardware is worth the extra mess in the code.
There are a lot of ancient drivers that would be nice to get rid of.

   Dan


From guorcn at msn.com  Wed Sep 21 10:37:49 2011
From: guorcn at msn.com (rui guo)
Date: Wed, 21 Sep 2011 16:37:49 +0800
Subject: [MPlayer-dev-eng] Is there any possible way that can get frame rate
 from sps / pps header?
Message-ID: <COL114-W174CD9600B0D25A9650BA7C70D0@phx.gbl>


Is there any possible way that get frame rate from sps / pps header? 		 	   		  

From ctrl.alt.sup at free.fr  Wed Sep 21 11:35:31 2011
From: ctrl.alt.sup at free.fr (xi)
Date: Wed, 21 Sep 2011 11:35:31 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <1316586506.815.85.camel@valinor.malmo.kicore.net>
References: <20110920181954.GA32134@1und1.de>	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
Message-ID: <4E79AFE3.5050908@free.fr>

Dan Oscarsson wrote:
> ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
>> Reimar D?ffinger<Reimar.Doeffinger<at>  gmx.de>  writes:
>>
>>> I am still interested in seeing performance numbers and statistics from
>>> ffmp3 vs. mp3lib when ffmp3 is slower,
>> When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
>> on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
>> slower than internal libmp3 on systems where I believe it does make a
>> difference, namely 32bit MMX and SSE.
>
> Does it make a difference that is significant?
> I have used mplayer on a 32bit system for many years together with
> vdpau. As vdpau does take nearly no CPU time, there was always lots of
> CPU available for audio decoding. It may be different if you do not have
> hardware video decoding, but sometime we have to decide if the work to
> support old hardware is worth the extra mess in the code.
> There are a lot of ancient drivers that would be nice to get rid of.
>

Hey, please don't drop support for old hardware. MPlayer has always been 
the best for playing the videos on my "old" hardware ; as a MPlayer 
user, I wouldn't like this to change.

Typically, thanks to mplayer, my main computer (Bi-amd MP2800+) is able 
to play full HD 30fps video _without_ VDPAU but using near than 100% of 
both processors. Any change in mplayer could drop HD playback for me 
(even though I must admit that libmp3 is most likely not used when 
decoding my HD videos). And I can't upgrade my hardware because there is 
_no_ AGP card supporting vdpau.

MPlayer also works out of the box for playing SD videos on my PIII 850, 
using libmp3 and xmga video output driver for matrox card ...

In brief, sorry to intrude in your discussion, but I send this email to 
recall you that there are some user who own some "old" hardware and who 
are really happy because mplayer provides those "old" drivers / 
"useless" functions / ...

Thanks for reading,
Xavier

From brad at comstyle.com  Wed Sep 21 11:42:22 2011
From: brad at comstyle.com (Brad)
Date: Wed, 21 Sep 2011 05:42:22 -0400
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <4E79AFE3.5050908@free.fr>
References: <20110920181954.GA32134@1und1.de>	<loom.20110921T013825-226@post.gmane.org>	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
Message-ID: <4E79B17E.1040609@comstyle.com>

On 21/09/11 5:35 AM, xi wrote:
> Dan Oscarsson wrote:
>> ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
>>> Reimar D?ffinger<Reimar.Doeffinger<at> gmx.de> writes:
>>>
>>>> I am still interested in seeing performance numbers and statistics from
>>>> ffmp3 vs. mp3lib when ffmp3 is slower,
>>> When I tested (after FFmpeg optimisations were committed), ffmp2float
>>> was faster
>>> on systems where it does not matter (including 64bit C, SSE2 and
>>> Altivec), but
>>> slower than internal libmp3 on systems where I believe it does make a
>>> difference, namely 32bit MMX and SSE.
>>
>> Does it make a difference that is significant?
>> I have used mplayer on a 32bit system for many years together with
>> vdpau. As vdpau does take nearly no CPU time, there was always lots of
>> CPU available for audio decoding. It may be different if you do not have
>> hardware video decoding, but sometime we have to decide if the work to
>> support old hardware is worth the extra mess in the code.
>> There are a lot of ancient drivers that would be nice to get rid of.
>>
>
> Hey, please don't drop support for old hardware. MPlayer has always been
> the best for playing the videos on my "old" hardware ; as a MPlayer
> user, I wouldn't like this to change.
>
> Typically, thanks to mplayer, my main computer (Bi-amd MP2800+) is able
> to play full HD 30fps video _without_ VDPAU but using near than 100% of
> both processors. Any change in mplayer could drop HD playback for me
> (even though I must admit that libmp3 is most likely not used when
> decoding my HD videos). And I can't upgrade my hardware because there is
> _no_ AGP card supporting vdpau.
>
> MPlayer also works out of the box for playing SD videos on my PIII 850,
> using libmp3 and xmga video output driver for matrox card ...
>
> In brief, sorry to intrude in your discussion, but I send this email to
> recall you that there are some user who own some "old" hardware and who
> are really happy because mplayer provides those "old" drivers /
> "useless" functions / ...

And have you done any testing with your particular environment what so
ever? Have any comparisons..? Have confirmation the MP3 decoder is even 
being used for your HD videos? Unlikely with most HD content I've ever 
run into but you need to actually confirm these details. Without that 
posts like this are pretty much useless IMO.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


From diego at biurrun.de  Wed Sep 21 11:59:38 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Wed, 21 Sep 2011 11:59:38 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <4E79AFE3.5050908@free.fr>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
Message-ID: <20110921095938.GA10027@pool.informatik.rwth-aachen.de>

On Wed, Sep 21, 2011 at 11:35:31AM +0200, xi wrote:
> 
> Hey, please don't drop support for old hardware. MPlayer has always
> been the best for playing the videos on my "old" hardware ; as a
> MPlayer user, I wouldn't like this to change.

This thread is not about "dropping support for old hardware", it's
about dropping the internal forked copy of libmpg123 in favor of the
external maintained version.  Please, let's stay on topic.

Diego

From Dan.Oscarsson at tieto.com  Wed Sep 21 13:45:36 2011
From: Dan.Oscarsson at tieto.com (Dan Oscarsson)
Date: Wed, 21 Sep 2011 13:45:36 +0200
Subject: [MPlayer-dev-eng] Response time
Message-ID: <1316605536.815.125.camel@valinor.malmo.kicore.net>

What is the acceptable delay between user requests an action and it
happens in mplayer?

In my a/v sync code, I try to maintain a/v sync even during a speed
change. As there is audio buffered in ao driver and in internal buffers
that is of previous speed, the speed change will not occur before the
buffered audio has been played and the new speed changed audio data
starts being played.

When using pulseaudio, I have a delay of about 1/4 second. When using
the oss emulator there is 2 seconds buffered so it takes 2 seconds
before the speed is changed.

If you want to feel that it happens instantly, I have heard that about
100 ms is max. What do you think?

To fix this, one can reduce the audio buffered in ao driver or one could
flush all audio data and resend it with new speed. I have tried to avoid
buffering to much data, but that instead triggered bugs in pulseaudio.

   Dan


From ctrl.alt.sup at free.fr  Wed Sep 21 13:56:13 2011
From: ctrl.alt.sup at free.fr (xi)
Date: Wed, 21 Sep 2011 13:56:13 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110921095938.GA10027@pool.informatik.rwth-aachen.de>
References: <20110920181954.GA32134@1und1.de>	<loom.20110921T013825-226@post.gmane.org>	<1316586506.815.85.camel@valinor.malmo.kicore.net>	<4E79AFE3.5050908@free.fr>
	<20110921095938.GA10027@pool.informatik.rwth-aachen.de>
Message-ID: <4E79D0DD.4090306@free.fr>

Diego Biurrun wrote:
> On Wed, Sep 21, 2011 at 11:35:31AM +0200, xi wrote:
>> Hey, please don't drop support for old hardware. MPlayer has always
>> been the best for playing the videos on my "old" hardware ; as a
>> MPlayer user, I wouldn't like this to change.
> 
> This thread is not about "dropping support for old hardware", it's
> about dropping the internal forked copy of libmpg123 in favor of the
> external maintained version.  Please, let's stay on topic.
> 
> Diego


No problem : my message about "dropping support for old hardware" was 
mostly in response of the sentence from Dan : "[...] There are a lot of 
ancient drivers that would be nice to get rid of."
(eg : last time you were about to drop mga_vid (matrox) support).

Regards,
Xavier

From dominik at greysector.net  Wed Sep 21 14:21:26 2011
From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski)
Date: Wed, 21 Sep 2011 14:21:26 +0200
Subject: [MPlayer-dev-eng] dvdread fix
In-Reply-To: <4E75C25F.7050809@roalter.it>
References: <4E75143D.3010702@roalter.it>
	<1613573B-8124-4468-818B-187749323DF9@gmx.de>
	<4E75A9F7.8010403@roalter.it>
	<20110918100151.GA21053@pool.informatik.rwth-aachen.de>
	<4E75C25F.7050809@roalter.it>
Message-ID: <20110921122126.GB20216@mokona.greysector.net>

On Sunday, 18 September 2011 at 12:05, Alexander Roalter wrote:
> On 09/18/2011 12:01 PM, Diego Biurrun wrote:
> >On Sun, Sep 18, 2011 at 10:21:11AM +0200, Alexander Roalter wrote:
> >>On 09/18/2011 02:38 AM, Reimar D?ffinger wrote:
> >>>On 17 Sep 2011, at 23:42, Alexander Roalter<alex at roalter.it>   wrote:
> >>>>The following patch was found at
> >>>>http://ubuntuforums.org/showthread.php?p=11254706
> >>>>
> >>>>and should go into libdvdread4.
> >>>
> >>>There is a separate mailing list for dvdread development though, and[...]
> >>Not to sound obnoxious, but where?
> >>googling for it doesn't turn up anything working or (still) active.
> >
> >http://lists.mplayerhq.hu/mailman/listinfo/dvdnav-discuss
> >
> >Diego
> Also libdvdREAD? I've subscribed to libdvdnav a long time ago, but I 
> wasn't aware it was for dvdread, too.

It's basically on life support, since Nico doesn't have too much time
to review patches. I try to help here and there, but I don't have
too much time either and I lack the necessary knowledge to review most
patches. So, help is welcome.

And yes, we need a project website/webpage, too.

Regards,
Dominik

-- 
MPlayer http://mplayerhq.hu | RPMFusion http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
	-- from "Collected Sayings of Muad'Dib" by the Princess Irulan

From auerswal at unix-ag.uni-kl.de  Wed Sep 21 16:49:25 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Wed, 21 Sep 2011 16:49:25 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <4E79AFE3.5050908@free.fr>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
Message-ID: <20110921144925.GA11022@sushi.unix-ag.uni-kl.de>

Hi Xavier,

On Wed, Sep 21, 2011 at 11:35:31AM +0200, xi wrote:
> Dan Oscarsson wrote:
>> ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
>>> Reimar D?ffinger<Reimar.Doeffinger<at>  gmx.de>  writes:
>>>
>>>> I am still interested in seeing performance numbers and statistics from
>>>> ffmp3 vs. mp3lib when ffmp3 is slower,
>>> When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
>>> on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
>>> slower than internal libmp3 on systems where I believe it does make a
>>> difference, namely 32bit MMX and SSE.
>>
>> Does it make a difference that is significant?
>> I have used mplayer on a 32bit system for many years together with
>> vdpau. As vdpau does take nearly no CPU time, there was always lots of
>> CPU available for audio decoding. It may be different if you do not have
>> hardware video decoding, but sometime we have to decide if the work to
>> support old hardware is worth the extra mess in the code.
>> There are a lot of ancient drivers that would be nice to get rid of.
>>
>
> Hey, please don't drop support for old hardware. MPlayer has always been  
> the best for playing the videos on my "old" hardware ; as a MPlayer  
> user, I wouldn't like this to change.

Could you test the speed of mp3 decoding on your systems?

Options to use:

# for mp3lib
-benchmark -vo null -ao null -afm mp3lib

# for ffmp$WHATEVER
-benchmark -vo null -vo null -afm ffmpeg

You might need to additionally add -format s16le to force the same output
format for a fair comparison.

I don't know if there is an "official" test sample and not even if mp3 or
mp2 format should be tested (Carl Eugen mentioned ffmp2float).

> Typically, thanks to mplayer, my main computer (Bi-amd MP2800+) is able  

For that one it should not matter (mp3 is usually not used for HD content).

> MPlayer also works out of the box for playing SD videos on my PIII 850,  
> using libmp3 and xmga video output driver for matrox card ...

That is a more interesting system to test.

Thanks,
Erik
-- 
Ringing telephones (and other symmetric communication lines) are the
bane of focused work.
                        -- Ren? Pfeiffer

From tempn at twmi.rr.com  Wed Sep 21 17:12:44 2011
From: tempn at twmi.rr.com (compn)
Date: Wed, 21 Sep 2011 11:12:44 -0400
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
Message-ID: <20110921111244.bc47237b.tempn@twmi.rr.com>

On Wed, 21 Sep 2011 16:49:25 +0200, Erik Auerswald wrote:
>Could you test the speed of mp3 decoding on your systems?
>
>Options to use:
>
># for mp3lib
>-benchmark -vo null -ao null -afm mp3lib
>
># for ffmp$WHATEVER
>-benchmark -vo null -vo null -afm ffmpeg
>
>You might need to additionally add -format s16le to force the same output
>format for a fair comparison.

p4 1.5ghz:
MPlayer Sherpya-SVN-r33574-4.2.5 (C) 2000-2011 MPlayer Team
CPU vendor name: GenuineIntel  max cpuid level: 2
CPU: Intel(R) Pentium(R) 4 CPU 1.50GHz (Family: 15, Model: 1, Stepping: 2)
extended cpuid-level: 4
CPUflags:  MMX: 1 MMX2: 1 3DNow: 0 3DNowExt: 0 SSE: 1 SSE2: 1 SSSE3: 0

mplayer 220_ziria_-_the_summer-mod.mp3 -afm mp3lib -benchmark -ao pcm:file=NUL
BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.212s Sys:   0.208s =    2.420s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A: 91.4050% Sys:  8.5950% = 100.0000%

mplayer 220_ziria_-_the_summer-mod.mp3  -benchmark -ao pcm:file=NUL
Selected audio codec: [ffmp3] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
BENCHMARKs: VC:   0.000s VO:   0.000s A:   7.115s Sys:   0.219s =    7.334s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A: 97.0139% Sys:  2.9861% = 100.0000%

mp3lib is the clear winner on my p4 1.5ghz on windows
(NUL = windows for /dev/null)



amd 3500:
mplaye 220_ziria_-_the_summer-mod.mp3 -noautosub -nocache -ao pcm:fast:file=NUL -benchmark

MPlayer SVN-r33713-4.2.4 (C) 2000-2011 MPlayer Team
CPU vendor name: AuthenticAMD  max cpuid level: 1
CPU: AMD Athlon(tm) 64 Processor 3500+ (Family: 15, Model: 47, Stepping: 0)
extended cpuid-level: 24
CPUflags:  MMX: 1 MMX2: 1 3DNow: 1 3DNowExt: 1 SSE: 1 SSE2: 1 SSSE3: 0


Selected audio codec: [ffmp3] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
BENCHMARKs: VC:   0.000s VO:   0.000s A:   1.880s Sys:   0.072s =    1.952s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A: 96.3115% Sys:  3.6885% = 100.0000%

with -afm mp3lib
mp3lib: using 3DNow!Ex optimized decore!
BENCHMARKs: VC:   0.000s VO:   0.000s A:   0.956s Sys:   0.059s =    1.015s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A: 94.1872% Sys:  5.8128% = 100.0000%

still ~2x faster on my windows amd box.


this is internal mp3lib, didnt test external mp3lib.

-compn

From tempn at twmi.rr.com  Wed Sep 21 17:23:55 2011
From: tempn at twmi.rr.com (compn)
Date: Wed, 21 Sep 2011 11:23:55 -0400
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
Message-ID: <20110921112355.e4674207.tempn@twmi.rr.com>

On Wed, 21 Sep 2011 16:49:25 +0200, Erik Auerswald wrote:
>Could you test the speed of mp3 decoding on your systems?
>
>Options to use:
>
># for mp3lib
>-benchmark -vo null -ao null -afm mp3lib
>
># for ffmp$WHATEVER
>-benchmark -vo null -vo null -afm ffmpeg
>
>You might need to additionally add -format s16le to force the same output
>format for a fair comparison.

oops, -ac mp3 and -ac ffmp3float are the same speed on my computers.

i marked ffmp3float as buggy in my codecs.conf. now i dont remember
why. possibly due to loud glitches when seeking? well i'll undo that
change and report any bugs.

-compn

From Reimar.Doeffinger at gmx.de  Wed Sep 21 19:14:29 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 21 Sep 2011 19:14:29 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <loom.20110921T013825-226@post.gmane.org>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
Message-ID: <20110921171429.GB3077@1und1.de>

On Wed, Sep 21, 2011 at 12:18:25AM +0000, Carl Eugen Hoyos wrote:
> His answer was:
> [quote]
> mp3lib uses a crazy scheme of mixing floating and fixed point to be able to
> use MMX instructions for windowing
> [/quote]

I can't really see why you'd need that when SSE is available.
Could you please run perf record / perf report on such a machine
with ffmp3?
Possibly also with mp3lib for comparison.

From Reimar.Doeffinger at gmx.de  Wed Sep 21 19:16:00 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 21 Sep 2011 19:16:00 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110921112355.e4674207.tempn@twmi.rr.com>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
	<20110921112355.e4674207.tempn@twmi.rr.com>
Message-ID: <20110921171600.GC3077@1und1.de>

On Wed, Sep 21, 2011 at 11:23:55AM -0400, compn wrote:
> On Wed, 21 Sep 2011 16:49:25 +0200, Erik Auerswald wrote:
> >Could you test the speed of mp3 decoding on your systems?
> >
> >Options to use:
> >
> ># for mp3lib
> >-benchmark -vo null -ao null -afm mp3lib
> >
> ># for ffmp$WHATEVER
> >-benchmark -vo null -vo null -afm ffmpeg
> >
> >You might need to additionally add -format s16le to force the same output
> >format for a fair comparison.
> 
> oops, -ac mp3 and -ac ffmp3float are the same speed on my computers.
> 
> i marked ffmp3float as buggy in my codecs.conf. now i dont remember
> why. possibly due to loud glitches when seeking? well i'll undo that
> change and report any bugs.

That probably was caused by no clipping in the float->int format
conversion audio filter and has been fixed since.

From diego at biurrun.de  Wed Sep 21 23:21:33 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Wed, 21 Sep 2011 23:21:33 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110921112355.e4674207.tempn@twmi.rr.com>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
	<20110921112355.e4674207.tempn@twmi.rr.com>
Message-ID: <20110921212132.GA30565@pool.informatik.rwth-aachen.de>

On Wed, Sep 21, 2011 at 11:23:55AM -0400, compn wrote:
> On Wed, 21 Sep 2011 16:49:25 +0200, Erik Auerswald wrote:
> >Could you test the speed of mp3 decoding on your systems?
> >
> >Options to use:
> >
> ># for mp3lib
> >-benchmark -vo null -ao null -afm mp3lib
> >
> ># for ffmp$WHATEVER
> >-benchmark -vo null -vo null -afm ffmpeg
> >
> >You might need to additionally add -format s16le to force the same output
> >format for a fair comparison.
> 
> oops, -ac mp3 and -ac ffmp3float are the same speed on my computers.

Could it be possible that the movie framerate is maintained?  Are you
playing faster than realtime?

Diego

From tempn at twmi.rr.com  Thu Sep 22 02:30:13 2011
From: tempn at twmi.rr.com (compn)
Date: Wed, 21 Sep 2011 20:30:13 -0400
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110921212132.GA30565@pool.informatik.rwth-aachen.de>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
	<20110921112355.e4674207.tempn@twmi.rr.com>
	<20110921212132.GA30565@pool.informatik.rwth-aachen.de>
Message-ID: <20110921203013.f308a5a4.tempn@twmi.rr.com>

On Wed, 21 Sep 2011 23:21:33 +0200, Diego Biurrun wrote:
>On Wed, Sep 21, 2011 at 11:23:55AM -0400, compn wrote:
>> On Wed, 21 Sep 2011 16:49:25 +0200, Erik Auerswald wrote:
>> >Could you test the speed of mp3 decoding on your systems?
>> >
>> >Options to use:
>> >
>> ># for mp3lib
>> >-benchmark -vo null -ao null -afm mp3lib
>> >
>> ># for ffmp$WHATEVER
>> >-benchmark -vo null -vo null -afm ffmpeg
>> >
>> >You might need to additionally add -format s16le to force the same output
>> >format for a fair comparison.
>> 
>> oops, -ac mp3 and -ac ffmp3float are the same speed on my computers.
>
>Could it be possible that the movie framerate is maintained?  Are you
>playing faster than realtime?

i meant they benchmark to roughly the same speed, i.e. mp3lib isnt
faster on my machine.

-compn

From ctrl.alt.sup at free.fr  Thu Sep 22 02:34:21 2011
From: ctrl.alt.sup at free.fr (xi)
Date: Thu, 22 Sep 2011 02:34:21 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
Message-ID: <4E7A828D.7080401@free.fr>

Erik Auerswald a ?crit :
> Hi Xavier,
>
> On Wed, Sep 21, 2011 at 11:35:31AM +0200, xi wrote:
>> Dan Oscarsson wrote:
>>> ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
>>>> Reimar D?ffinger<Reimar.Doeffinger<at>   gmx.de>   writes:
>>>>
>>>>> I am still interested in seeing performance numbers and statistics from
>>>>> ffmp3 vs. mp3lib when ffmp3 is slower,
>>>> When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
>>>> on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
>>>> slower than internal libmp3 on systems where I believe it does make a
>>>> difference, namely 32bit MMX and SSE.
>>>
>>> Does it make a difference that is significant?
>>> I have used mplayer on a 32bit system for many years together with
>>> vdpau. As vdpau does take nearly no CPU time, there was always lots of
>>> CPU available for audio decoding. It may be different if you do not have
>>> hardware video decoding, but sometime we have to decide if the work to
>>> support old hardware is worth the extra mess in the code.
>>> There are a lot of ancient drivers that would be nice to get rid of.
>>>
>>
>> Hey, please don't drop support for old hardware. MPlayer has always been
>> the best for playing the videos on my "old" hardware ; as a MPlayer
>> user, I wouldn't like this to change.
>
> Could you test the speed of mp3 decoding on your systems?
>
> Options to use:
>
> # for mp3lib
> -benchmark -vo null -ao null -afm mp3lib
>
> # for ffmp$WHATEVER
> -benchmark -vo null -vo null -afm ffmpeg
>
> You might need to additionally add -format s16le to force the same output
> format for a fair comparison.
>

Ok, here are the results :

*** Pentium III 850MHz :

[xi at localhost mp3]$ /usr/local/bin/mplayer -benchmark -vo null -ao null 
-afm mp3lib -format s16le E-Type_Made_in_Sweden.mp3
MPlayer SVN-r34117-4.2.2 (C) 2000-2011 MPlayer Team

Playing E-Type_Made_in_Sweden.mp3.
Audio only file format detected.
==========================================================================
Trying to force audio codec driver family mp3lib...
Opening audio decoder: [mp3lib] MPEG layer-2, layer-3
AUDIO: 44100 Hz, 2 ch, s16le, 128.0 kbit/9.07% (ratio: 16000->176400)
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
==========================================================================
AO: [null] 44100Hz 2ch s16le (2 bytes per sample)
A:  94.8 (01:34.7) of 94.0 (01:34.0)  1.7%

BENCHMARKs: VC:   0.000s VO:   0.000s A:   1.622s Sys:  96.708s =   98.330s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  1.6494% Sys: 98.3506% = 100.0000%


[xi at localhost mp3]$ /usr/local/bin/mplayer -benchmark -vo null -ao null 
-afm ffmpeg -format s16le E-Type_Made_in_Sweden.mp3 :
BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.057s Sys:  96.686s =   98.743s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  2.0837% Sys: 97.9163% = 100.0000%


[xi at localhost mp3]$ /usr/local/bin/mplayer -benchmark -vo null -ao null 
-afm ffmpeg -ac ffmp3 -format s16le E-Type_Made_in_Sweden.mp3 :
BENCHMARKs: VC:   0.000s VO:   0.000s A:   2.952s Sys:  94.833s =   97.786s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  3.0193% Sys: 96.9807% = 100.0000%




*** AMD Dual athlon MP2800+ :

mplayer -benchmark -vo null -ao null -afm mp3lib -format s16le 
/tmp/E-Type_Made_in_Sweden.mp3 :
BENCHMARKs: VC:   0.000s VO:   0.000s A:   0.773s Sys:  96.513s =   97.286s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  0.7944% Sys: 99.2056% = 100.0000%

mplayer -benchmark -vo null -ao null -afm ffmpeg -format s16le 
/tmp/E-Type_Made_in_Sweden.mp3 :
BENCHMARKs: VC:   0.000s VO:   0.000s A:   0.926s Sys:  96.484s =   97.410s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  0.9507% Sys: 99.0493% = 100.0000%

mplayer -benchmark -vo null -ao null -afm ffmpeg -ac ffmp3 -format s16le 
/tmp/E-Type_Made_in_Sweden.mp3 :
BENCHMARKs: VC:   0.000s VO:   0.000s A:   1.736s Sys:  96.480s =   98.216s
BENCHMARK%: VC:  0.0000% VO:  0.0000% A:  1.7674% Sys: 98.2326% = 100.0000%


Hope this helps,
Xavier

From Reimar.Doeffinger at gmx.de  Thu Sep 22 18:00:31 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Thu, 22 Sep 2011 18:00:31 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <4E7A828D.7080401@free.fr>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
	<4E7A828D.7080401@free.fr>
Message-ID: <20110922160031.GB2485@1und1.de>

On Thu, Sep 22, 2011 at 02:34:21AM +0200, xi wrote:
> Erik Auerswald a ?crit :
> >Hi Xavier,
> >
> >On Wed, Sep 21, 2011 at 11:35:31AM +0200, xi wrote:
> >>Dan Oscarsson wrote:
> >>>ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
> >>>>Reimar D?ffinger<Reimar.Doeffinger<at>   gmx.de>   writes:
> >>>>
> >>>>>I am still interested in seeing performance numbers and statistics from
> >>>>>ffmp3 vs. mp3lib when ffmp3 is slower,
> >>>>When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
> >>>>on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
> >>>>slower than internal libmp3 on systems where I believe it does make a
> >>>>difference, namely 32bit MMX and SSE.
> >>>
> >>>Does it make a difference that is significant?
> >>>I have used mplayer on a 32bit system for many years together with
> >>>vdpau. As vdpau does take nearly no CPU time, there was always lots of
> >>>CPU available for audio decoding. It may be different if you do not have
> >>>hardware video decoding, but sometime we have to decide if the work to
> >>>support old hardware is worth the extra mess in the code.
> >>>There are a lot of ancient drivers that would be nice to get rid of.
> >>>
> >>
> >>Hey, please don't drop support for old hardware. MPlayer has always been
> >>the best for playing the videos on my "old" hardware ; as a MPlayer
> >>user, I wouldn't like this to change.
> >
> >Could you test the speed of mp3 decoding on your systems?
> >
> >Options to use:
> >
> ># for mp3lib
> >-benchmark -vo null -ao null -afm mp3lib
> >
> ># for ffmp$WHATEVER
> >-benchmark -vo null -vo null -afm ffmpeg
> >
> >You might need to additionally add -format s16le to force the same output
> >format for a fair comparison.
> >
> 
> Ok, here are the results :

I would welcome performance measurements from you, too
(perf record/perf report for example).
Carl will need a while longer before he can provide any.

From ctrl.alt.sup at free.fr  Thu Sep 22 13:03:08 2011
From: ctrl.alt.sup at free.fr (xi)
Date: Thu, 22 Sep 2011 16:33:08 +0530
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110922160031.GB2485@1und1.de>
References: <20110920181954.GA32134@1und1.de>	<loom.20110921T013825-226@post.gmane.org>	<1316586506.815.85.camel@valinor.malmo.kicore.net>	<4E79AFE3.5050908@free.fr>	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>	<4E7A828D.7080401@free.fr>
	<20110922160031.GB2485@1und1.de>
Message-ID: <4E7B15EC.10405@free.fr>

Reimar D?ffinger wrote:
> On Thu, Sep 22, 2011 at 02:34:21AM +0200, xi wrote:
>> Erik Auerswald a ?crit :
>>> Hi Xavier,
>>>
>>> On Wed, Sep 21, 2011 at 11:35:31AM +0200, xi wrote:
>>>> Dan Oscarsson wrote:
>>>>> ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
>>>>>> Reimar D?ffinger<Reimar.Doeffinger<at>    gmx.de>    writes:
>>>>>>
>>>>>>> I am still interested in seeing performance numbers and statistics from
>>>>>>> ffmp3 vs. mp3lib when ffmp3 is slower,
>>>>>> When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
>>>>>> on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
>>>>>> slower than internal libmp3 on systems where I believe it does make a
>>>>>> difference, namely 32bit MMX and SSE.
>>>>> Does it make a difference that is significant?
>>>>> I have used mplayer on a 32bit system for many years together with
>>>>> vdpau. As vdpau does take nearly no CPU time, there was always lots of
>>>>> CPU available for audio decoding. It may be different if you do not have
>>>>> hardware video decoding, but sometime we have to decide if the work to
>>>>> support old hardware is worth the extra mess in the code.
>>>>> There are a lot of ancient drivers that would be nice to get rid of.
>>>>>
>>>> Hey, please don't drop support for old hardware. MPlayer has always been
>>>> the best for playing the videos on my "old" hardware ; as a MPlayer
>>>> user, I wouldn't like this to change.
>>> Could you test the speed of mp3 decoding on your systems?
>>>
>>> Options to use:
>>>
>>> # for mp3lib
>>> -benchmark -vo null -ao null -afm mp3lib
>>>
>>> # for ffmp$WHATEVER
>>> -benchmark -vo null -vo null -afm ffmpeg
>>>
>>> You might need to additionally add -format s16le to force the same output
>>> format for a fair comparison.
>>>
>> Ok, here are the results :
>
> I would welcome performance measurements from you, too
> (perf record/perf report for example).
> Carl will need a while longer before he can provide any.

No problem, however I don't know at all how to use the "perf" tool (I 
have just discovered it).

I suppose I have to run "perf record mplayer -benchmark..." ?
And then, what about perf record which seems to open perf.data file ? 
(An example would be helpful).

You need it for each of the 6 tests from yesterday ?

Xavier

From ctrl.alt.sup at free.fr  Fri Sep 23 02:13:27 2011
From: ctrl.alt.sup at free.fr (xi)
Date: Fri, 23 Sep 2011 02:13:27 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110922160031.GB2485@1und1.de>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
	<4E7A828D.7080401@free.fr> <20110922160031.GB2485@1und1.de>
Message-ID: <4E7BCF27.3070202@free.fr>

Reimar D?ffinger a ?crit :
> On Thu, Sep 22, 2011 at 02:34:21AM +0200, xi wrote:
>> Erik Auerswald a ?crit :
>>> Hi Xavier,
>>>
>>> On Wed, Sep 21, 2011 at 11:35:31AM +0200, xi wrote:
>>>> Dan Oscarsson wrote:
>>>>> ons 2011-09-21 klockan 00:18 +0000 skrev Carl Eugen Hoyos:
>>>>>> Reimar D?ffinger<Reimar.Doeffinger<at>    gmx.de>    writes:
>>>>>>
>>>>>>> I am still interested in seeing performance numbers and statistics from
>>>>>>> ffmp3 vs. mp3lib when ffmp3 is slower,
>>>>>> When I tested (after FFmpeg optimisations were committed), ffmp2float was faster
>>>>>> on systems where it does not matter (including 64bit C, SSE2 and Altivec), but
>>>>>> slower than internal libmp3 on systems where I believe it does make a
>>>>>> difference, namely 32bit MMX and SSE.
>>>>>
>>>>> Does it make a difference that is significant?
>>>>> I have used mplayer on a 32bit system for many years together with
>>>>> vdpau. As vdpau does take nearly no CPU time, there was always lots of
>>>>> CPU available for audio decoding. It may be different if you do not have
>>>>> hardware video decoding, but sometime we have to decide if the work to
>>>>> support old hardware is worth the extra mess in the code.
>>>>> There are a lot of ancient drivers that would be nice to get rid of.
>>>>>
>>>>
>>>> Hey, please don't drop support for old hardware. MPlayer has always been
>>>> the best for playing the videos on my "old" hardware ; as a MPlayer
>>>> user, I wouldn't like this to change.
>>>
>>> Could you test the speed of mp3 decoding on your systems?
>>>
>>> Options to use:
>>>
>>> # for mp3lib
>>> -benchmark -vo null -ao null -afm mp3lib
>>>
>>> # for ffmp$WHATEVER
>>> -benchmark -vo null -vo null -afm ffmpeg
>>>
>>> You might need to additionally add -format s16le to force the same output
>>> format for a fair comparison.
>>>
>>
>> Ok, here are the results :
>
> I would welcome performance measurements from you, too
> (perf record/perf report for example).
> Carl will need a while longer before he can provide any.

Ok, I tried to use "perf" command, hope this is correct. eg :
"perf record -f mplayer -benchmark -vo null -ao null -afm mp3lib -format 
s16le /tmp/E-Type_Made_in_Sweden.mp3"
Then
"perf report > /tmp/test.txt"

Note that "perf" seems to be a recent kernel tool that was not included 
in the 2.6.22 kernel used for my PIII 850. So, the tests below are 
_only_ for my Dual athlon MP2800+.

If you need these tests on the PIII, let me know, I will boot a disk 
with a more recent kernel on it.


*** perf report for mp3lib :
     16.96%  mplayer  mplayer                               [.] 
0x0000000024e574
     12.11%  mplayer                              b71184c1  [.] 
0x000000b71184c1
      6.46%  mplayer  mplayer                               [.] 
synth_1to1_MMX
      5.84%  mplayer  mplayer                               [.] 
dct36_3dnowex
      4.06%  mplayer  [kernel]                              [k] acpi_pm_read
      4.06%  mplayer  mplayer                               [.] 
dct64_MMX_3dnowex
      3.87%  mplayer  [kernel]                              [k] __do_fault
      2.20%  mplayer  mplayer                               [.] 
0x000000000e8373
      1.95%  mplayer  mplayer                               [.] main
      1.71%  mplayer  libc-2.11.1.so                        [.] __GI_memcpy
      1.68%  mplayer  libc-2.11.1.so                        [.] ___printf_fp
      1.68%  mplayer  libc-2.11.1.so                        [.] 
__GI_vfprintf
      1.07%  mplayer  libc-2.11.1.so                        [.] __GI_strncpy
      0.95%  mplayer  libGL.so.280.13                       [.] 
0x0000000007e242
      0.92%  mplayer  mplayer                               [.] 
0x0000000014f260
      0.77%  mplayer  mplayer                               [.] 
MP3_DecodeFrame
      0.76%  mplayer  libc-2.11.1.so                        [.] __strchrnul
      0.76%  mplayer  ld-2.11.1.so                          [.] 
_dl_map_object_from_fd
      0.73%  mplayer  [kernel]                              [k] n_tty_write
      0.70%  mplayer  libnvidia-tls.so.280.13               [.] 
0x00000000001ad3
      0.70%  mplayer  [kernel]                              [k] 
tty_buffer_request_room
      0.68%  mplayer  libc-2.11.1.so                        [.] memset
      0.67%  mplayer  mplayer                               [.] fast_memcpy
      0.60%  mplayer  [kernel]                              [k] 
sysenter_past_esp
      0.56%  mplayer  [kernel]                              [k] schedule
      0.56%  mplayer  mplayer                               [.] 
0x00000000903035
      0.54%  mplayer  [kernel]                              [k] copy_to_user
      0.52%  mplayer  mplayer                               [.] 
mp_decode_audio
      0.51%  mplayer  [kernel]                              [k] 
get_page_from_freelist
      0.48%  mplayer  [kernel]                              [k] do_select
      0.48%  mplayer  [kernel]                              [k] sys_ioctl
      0.44%  mplayer  libc-2.11.1.so                        [.] __GI_strcmp
      0.43%  mplayer  [kernel]                              [k] tty_write
      0.43%  mplayer  [kernel]                              [k] 
find_busiest_group
      0.41%  mplayer  [kernel]                              [k] tty_ioctl
      0.41%  mplayer  libc-2.11.1.so                        [.] __GI_memmove
      0.38%  mplayer  mplayer                               [.] GetTimerMS
      0.38%  mplayer  [kernel]                              [k] 
__copy_to_user_ll


*** perf report for ffmp3float :
     27.69%  mplayer  mplayer                               [.] 
0x000000003b2890
     10.76%  mplayer  mplayer                               [.] 
ff_mpadsp_apply_window_float
      4.12%  mplayer  libc-2.11.1.so                        [.] 
__GI_vfprintf
      3.78%  mplayer  libc-2.11.1.so                        [.] ___printf_fp
      3.59%  mplayer  [kernel]                              [k] __do_fault
      3.43%  mplayer  [kernel]                              [k] acpi_pm_read
      2.30%  mplayer  libc-2.11.1.so                        [.] memset
      2.28%  mplayer  libc-2.11.1.so                        [.] __GI_strncpy
      1.73%  mplayer  libc-2.11.1.so                        [.] __GI_memcpy
      1.62%  mplayer  libc-2.11.1.so                        [.] __GI_memmove
      1.13%  mplayer  libnvidia-tls.so.280.13               [.] 
0x000000000017d0
      1.11%  mplayer  libGL.so.280.13                       [.] 
0x0000000007d951
      1.09%  mplayer  mplayer                               [.] main
      0.97%  mplayer  libc-2.11.1.so                        [.] _int_malloc
      0.95%  mplayer  [kernel]                              [k] n_tty_write
      0.79%  mplayer  mplayer                               [.] mp_msg_va
      0.71%  mplayer  [kernel]                              [k] 
get_page_from_freelist
      0.69%  mplayer  libc-2.11.1.so                        [.] _int_free
      0.56%  mplayer  mplayer                               [.] 
update_subtitles
      0.54%  mplayer  [nvidia]                              [k] _nv015253rm
      0.53%  mplayer  libc-2.11.1.so                        [.] 
_IO_default_xsputn_internal
      0.50%  mplayer  ld-2.11.1.so                          [.] 
_dl_relocate_object
      0.50%  mplayer  libc-2.11.1.so                        [.] __GI_select
      0.50%  mplayer  libc-2.11.1.so                        [.] 
__GI_gettimeofday
      0.50%  mplayer  libc-2.11.1.so                        [.] 
mem2chunk_check
      0.49%  mplayer  libc-2.11.1.so                        [.] _IO_fputs
      0.47%  mplayer  libc-2.11.1.so                        [.] 
__GI___libc_malloc
      0.44%  mplayer  libc-2.11.1.so                        [.] 
__gconv_transform_utf8_internal
      0.42%  mplayer  libc-2.11.1.so                        [.] 
__gconv_transform_internal_utf8
      0.41%  mplayer  [kernel]                              [k] 
tty_buffer_request_room
      0.39%  mplayer  [vdso]                                [.] 
0x000000ffffe415
      0.39%  mplayer  libc-2.11.1.so                        [.] __vsnprintf
      0.38%  mplayer  [kernel]                              [k] do_select
      0.37%  mplayer  libc-2.11.1.so                        [.] __strchrnul
      0.37%  mplayer  libc-2.11.1.so                        [.] 
hack_digit.12363
      0.35%  mplayer  mplayer                               [.] 
mp_decode_audio
      0.33%  mplayer  libc-2.11.1.so                        [.] malloc_check
      0.32%  mplayer  [kernel]                              [k] 
_copy_from_user
      0.29%  mplayer  libc-2.11.1.so                        [.] 
__mpn_extract_double
      0.28%  mplayer  [kernel]                              [k] tty_write
      0.28%  mplayer  [kernel]                              [k] 
__copy_to_user_ll


*** perf report for ffmp3 :
     41.18%  mplayer                               80c8b47  [.] 
0x000000080c8b47
     19.81%  mplayer  mplayer                               [.] 
ff_mpadsp_apply_window_fixed
      6.51%  mplayer  mplayer                               [.] 
0x00000000903081
      3.32%  mplayer  [kernel]                              [k] acpi_pm_read
      2.49%  mplayer  [kernel]                              [k] __do_fault
      1.72%  mplayer  mplayer                               [.] 
ff_dct32_fixed
      0.79%  mplayer  libc-2.11.1.so                        [.] 
__GI_vfprintf
      0.71%  mplayer  mplayer                               [.] 
0x000000000d8cc2
      0.68%  mplayer  [kernel]                              [k] n_tty_write
      0.58%  mplayer  libc-2.11.1.so                        [.] ___printf_fp
      0.54%  mplayer  libc-2.11.1.so                        [.] __GI_memcpy
      0.52%  mplayer  libc-2.11.1.so                        [.] __GI_strncpy
      0.50%  mplayer  [kernel]                              [k] 
__copy_to_user_ll
      0.45%  mplayer  [kernel]                              [k] 
get_page_from_freelist
      0.43%  mplayer  mplayer                               [.] main
      0.42%  mplayer  ld-2.11.1.so                          [.] 
_dl_relocate_object
      0.39%  mplayer  libc-2.11.1.so                        [.] 
__gconv_transform_utf8_internal
      0.37%  mplayer  [kernel]                              [k] 
_raw_spin_lock_irqsave
      0.37%  mplayer  libc-2.11.1.so                        [.] _int_malloc
      0.34%  mplayer  [kernel]                              [k] tty_ioctl
      0.34%  mplayer  libGL.so.280.13                       [.] 
0x0000000007e217
      0.33%  mplayer  [vdso]                                [.] 
0x000000ffffe414
      0.29%  mplayer  [kernel]                              [k] 
sysenter_past_esp
      0.28%  mplayer  mplayer                               [.] 
0x000000001f2002
      0.24%  mplayer  libc-2.11.1.so                        [.] memset
      0.23%  mplayer  libc-2.11.1.so                        [.] 
__GI_gettimeofday
      0.23%  mplayer  [kernel]                              [k] 
tty_buffer_request_room
      0.22%  mplayer  libc-2.11.1.so                        [.] __GI_memmove
      0.21%  mplayer  libc-2.11.1.so                        [.] _int_free
      0.21%  mplayer  [kernel]                              [k] 
_raw_spin_lock_irq
      0.21%  mplayer  libm-2.11.1.so                        [.] 
0x00000000007bc0
      0.20%  mplayer  [kernel]                              [k] do_select
      0.20%  mplayer  [kernel]                              [k] 
perf_adjust_period
      0.20%  mplayer  [kernel]                              [k] 
enqueue_hrtimer
      0.20%  mplayer  libc-2.11.1.so                        [.] __strchrnul
      0.20%  mplayer  [kernel]                              [k] copy_to_user


Note : reports are incomplete, I have removed the end because it was huge.

Xavier

From ikalvachev at gmail.com  Fri Sep 23 02:45:49 2011
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Fri, 23 Sep 2011 03:45:49 +0300
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110920181954.GA32134@1und1.de>
References: <20110920181954.GA32134@1und1.de>
Message-ID: <CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>

On 9/20/11, Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:
> Hello,
> I am still interested in seeing performance numbers and statistics from
> ffmp3 vs. mp3lib when ffmp3 is slower, but I guess it's time to start
> some more specific moves to get rid of it.
>

I've done some benchmarks on my old Athlon TBird 1GHz.
(no sse of any kind, only mmx1/2, 3dnow1/2).

$ mplayer -loop 3 -ao pcm:fast:file=/dev/null -benchmark -quiet -ac
mp3 stream.dump
MPlayer SVN-r34123-4.5.2 (C) 2000-2011 MPlayer Team
Selected audio codec: [mp3] afm: mp3lib (mp3lib MPEG layer-2, layer-3)
AO: [pcm] 48000Hz 2ch s16le (2 bytes per sample)
BENCHMARKs: VC:   0.000s VO:   0.000s A:  49.342s Sys:   0.416s =   49.758s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  49.436s Sys:   0.436s =   49.872s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  49.516s Sys:   0.409s =   49.924s

$ mplayer -loop 3 -ao pcm:fast:file=/dev/null -benchmark -quiet -ac
ffmp3 stream.dump
Selected audio codec: [ffmp3] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
AO: [pcm] 48000Hz 2ch s16le (2 bytes per sample)
BENCHMARKs: VC:   0.000s VO:   0.000s A: 123.222s Sys:   0.406s =  123.627s
BENCHMARKs: VC:   0.000s VO:   0.000s A: 123.053s Sys:   0.415s =  123.467s
BENCHMARKs: VC:   0.000s VO:   0.000s A: 123.167s Sys:   0.444s =  123.611s

$ mplayer -loop 3 -ao pcm:fast:file=/dev/null -benchmark -quiet -ac
ffmp3float stream.dump
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
AO: [pcm] 48000Hz 2ch floatle (4 bytes per sample)
BENCHMARKs: VC:   0.000s VO:   0.000s A:  56.801s Sys:   0.760s =   57.562s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  56.831s Sys:   0.775s =   57.606s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  56.863s Sys:   0.766s =   57.629s

$ mplayer -loop 3 -ao pcm:fast:file=/dev/null -benchmark -quiet -ac
ffmp3float -af format=s16le stream.dump
Selected audio codec: [ffmp3float] afm: ffmpeg (FFmpeg MPEG layer-3 audio)
AO: [pcm] 48000Hz 2ch s16le (2 bytes per sample)
BENCHMARKs: VC:   0.000s VO:   0.000s A:  62.408s Sys:   0.635s =   63.042s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  62.791s Sys:   0.668s =   63.459s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  62.795s Sys:   0.633s =   63.428s

=====
Even if we assume the extra 6 seconds are because of the ugly float
conversion and clipping i've done in af_format, even then mp3lib is
still around 16% faster than the float only case.

Do you want oprofile from my cpu too?

From thomas-forum at orgis.org  Fri Sep 23 08:28:32 2011
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Fri, 23 Sep 2011 08:28:32 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
Message-ID: <20110923082832.24bf7c60@orgis.org>

Am Fri, 23 Sep 2011 03:45:49 +0300
schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 

> Even if we assume the extra 6 seconds are because of the ugly float
> conversion and clipping i've done in af_format, even then mp3lib is
> still around 16% faster than the float only case.

Would you care to give the ac mpg123 a spin, too? Regardless about the
performance of ffmpeg's mp3 (and mp2, and mp1) decoding, the comparison
to the official mpg123 code should work out on removing the internal
fork.

Because of improved SSE code, mpg123 should be faster on platforms
supporting that. The game is not that clear for MMX and 3DNow*, where
subtle effects of the libmpg123 binding could rule.

Make sure to use mpg123 version 1.13.x, please (there was some
optimization regarding the data transfer from MPlayer).


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110923/2e64ec57/attachment.asc>

From diego at biurrun.de  Fri Sep 23 11:17:24 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Fri, 23 Sep 2011 11:17:24 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110923082832.24bf7c60@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
Message-ID: <20110923091724.GA9230@pool.informatik.rwth-aachen.de>

On Fri, Sep 23, 2011 at 08:28:32AM +0200, Thomas Orgis wrote:
> Am Fri, 23 Sep 2011 03:45:49 +0300
> schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 
> 
> > Even if we assume the extra 6 seconds are because of the ugly float
> > conversion and clipping i've done in af_format, even then mp3lib is
> > still around 16% faster than the float only case.
> 
> Would you care to give the ac mpg123 a spin, too? Regardless about the
> performance of ffmpeg's mp3 (and mp2, and mp1) decoding, the comparison
> to the official mpg123 code should work out on removing the internal
> fork.
> 
> Because of improved SSE code, mpg123 should be faster on platforms
> supporting that. The game is not that clear for MMX and 3DNow*, where
> subtle effects of the libmpg123 binding could rule.
> 
> Make sure to use mpg123 version 1.13.x, please (there was some
> optimization regarding the data transfer from MPlayer).

I was about to step in and say something like this :)

The interesting case is comparing internal vs. external mp3lib/mpeg123,
not so much ffmp3 or ffmp3float.

Diego

From cehoyos at ag.or.at  Fri Sep 23 11:30:14 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Fri, 23 Sep 2011 09:30:14 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
	<4E7A828D.7080401@free.fr> <20110922160031.GB2485@1und1.de>
Message-ID: <loom.20110923T112730-33@post.gmane.org>

Reimar D?ffinger <Reimar.Doeffinger <at> gmx.de> writes:

> Carl will need a while longer before he can provide any.

They would not look any different from what Xi and Ivan provided. Their results
exactly match what I remember from my tests.

Carl Eugen


From sergey.kosov at project-10.de  Fri Sep 23 12:32:25 2011
From: sergey.kosov at project-10.de (sergey.kosov at project-10.de)
Date: Fri, 23 Sep 2011 12:32:25 +0200 (CEST)
Subject: [MPlayer-dev-eng] =?iso-8859-1?q?Motion_Field_VS_Macroblocks_Pred?=
	=?iso-8859-1?q?ictions?=
Message-ID: <20110923103225.4299D310002@can27.de>

Hi,

I have tried the MPlayer (v.0.6.9) on some h264/AVC video streams, which
contain only I and P data slices. I visualize the motion vectors and
achieve some dramatic noise on homogeneous static regions in video.
It is not real motion vectors isn't it?
If those are visualizations of mvd_L0 or mvd_L1 vectors for macro blocks
from the macro block prediction layer according to the H264 / MPEG 4
standard? If not, could you please describe or refer me to the code
section where you build these vectors?

thank you in advance,

Sergey


From ikalvachev at gmail.com  Fri Sep 23 15:46:05 2011
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Fri, 23 Sep 2011 16:46:05 +0300
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110923082832.24bf7c60@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
Message-ID: <CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>

On 9/23/11, Thomas Orgis <thomas-forum at orgis.org> wrote:
> Am Fri, 23 Sep 2011 03:45:49 +0300
> schrieb Ivan Kalvachev <ikalvachev at gmail.com>:
>
>> Even if we assume the extra 6 seconds are because of the ugly float
>> conversion and clipping i've done in af_format, even then mp3lib is
>> still around 16% faster than the float only case.
>
> Would you care to give the ac mpg123 a spin, too? Regardless about the
> performance of ffmpeg's mp3 (and mp2, and mp1) decoding, the comparison
> to the official mpg123 code should work out on removing the internal
> fork.
>
> Because of improved SSE code, mpg123 should be faster on platforms
> supporting that. The game is not that clear for MMX and 3DNow*, where
> subtle effects of the libmpg123 binding could rule.
>
> Make sure to use mpg123 version 1.13.x, please (there was some
> optimization regarding the data transfer from MPlayer).
>
>
> Alrighty then,
>
> Thomas.

Here they are:
athlon:$ for i in 1 2 3 ; do time mpg123 -w /dev/null stream.dump ; done
High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
        version 1.13.3; written and copyright by Michael Hipp and others
real 0m48.938s 		user 0m47.331s		sys 0m1.591s
real 0m48.790s		user 0m47.013s		sys 0m1.764s
real 0m48.736s		user 0m46.996s		sys 0m1.726s

athlon:$ ./mplayer -loop 3 -ao pcm:fast:file=/dev/null -benchmark
-quiet -ac mpg123 stream.dump
MPlayer SVN-r34123-4.5.3 (C) 2000-2011 MPlayer Team
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
AO: [pcm] 48000Hz 2ch s16le (2 bytes per sample)
BENCHMARKs: VC:   0.000s VO:   0.000s A:  55.760s Sys:   0.862s =   56.621s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  53.390s Sys:   0.515s =   53.906s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  52.770s Sys:   0.536s =   53.306s

=====
While the standalone run looked quite promising, the mplayer run
wasn't as good. Even if mpg123 is the fastest among the alternatives,
mp3lib is still 8% faster.

I used the version that comes with my distribution, as that would be
the typical user case. Fortunately it comes with 1.13.3 . It is
entirely possible that the package is not compiled with the best
options for my cpu. I may try with a custom build later.

From ikalvachev at gmail.com  Fri Sep 23 15:47:49 2011
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Fri, 23 Sep 2011 16:47:49 +0300
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110923091724.GA9230@pool.informatik.rwth-aachen.de>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
	<20110923091724.GA9230@pool.informatik.rwth-aachen.de>
Message-ID: <CABA=pqcOHFiWPT75N5H7B57derj=ryjE1PHwceaL3EVRXQyBSQ@mail.gmail.com>

On 9/23/11, Diego Biurrun <diego at biurrun.de> wrote:
> On Fri, Sep 23, 2011 at 08:28:32AM +0200, Thomas Orgis wrote:
>> Am Fri, 23 Sep 2011 03:45:49 +0300
>> schrieb Ivan Kalvachev <ikalvachev at gmail.com>:
>>
>> > Even if we assume the extra 6 seconds are because of the ugly float
>> > conversion and clipping i've done in af_format, even then mp3lib is
>> > still around 16% faster than the float only case.
>>
>> Would you care to give the ac mpg123 a spin, too? Regardless about the
>> performance of ffmpeg's mp3 (and mp2, and mp1) decoding, the comparison
>> to the official mpg123 code should work out on removing the internal
>> fork.
>>
>> Because of improved SSE code, mpg123 should be faster on platforms
>> supporting that. The game is not that clear for MMX and 3DNow*, where
>> subtle effects of the libmpg123 binding could rule.
>>
>> Make sure to use mpg123 version 1.13.x, please (there was some
>> optimization regarding the data transfer from MPlayer).
>
> I was about to step in and say something like this :)
>
> The interesting case is comparing internal vs. external mp3lib/mpeg123,
> not so much ffmp3 or ffmp3float.

Would you please do a full benchmark suit and post it here. If I
remember correctly you had some flavor of K6. It would be good to have
all benchmarks in single thread.

From diego at biurrun.de  Fri Sep 23 16:22:56 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Fri, 23 Sep 2011 16:22:56 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
	<CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
Message-ID: <20110923142256.GB9230@pool.informatik.rwth-aachen.de>

On Fri, Sep 23, 2011 at 04:46:05PM +0300, Ivan Kalvachev wrote:
> On 9/23/11, Thomas Orgis <thomas-forum at orgis.org> wrote:
> > Am Fri, 23 Sep 2011 03:45:49 +0300
> > schrieb Ivan Kalvachev <ikalvachev at gmail.com>:
> >
> >> Even if we assume the extra 6 seconds are because of the ugly float
> >> conversion and clipping i've done in af_format, even then mp3lib is
> >> still around 16% faster than the float only case.
> >
> > Would you care to give the ac mpg123 a spin, too? Regardless about the
> > performance of ffmpeg's mp3 (and mp2, and mp1) decoding, the comparison
> > to the official mpg123 code should work out on removing the internal
> > fork.
> >
> > Because of improved SSE code, mpg123 should be faster on platforms
> > supporting that. The game is not that clear for MMX and 3DNow*, where
> > subtle effects of the libmpg123 binding could rule.
> >
> > Make sure to use mpg123 version 1.13.x, please (there was some
> > optimization regarding the data transfer from MPlayer).
> 
> Here they are:
> athlon:$ for i in 1 2 3 ; do time mpg123 -w /dev/null stream.dump ; done
> High Performance MPEG 1.0/2.0/2.5 Audio Player for Layers 1, 2 and 3
>         version 1.13.3; written and copyright by Michael Hipp and others
> real 0m48.938s 		user 0m47.331s		sys 0m1.591s
> real 0m48.790s		user 0m47.013s		sys 0m1.764s
> real 0m48.736s		user 0m46.996s		sys 0m1.726s
> 
> athlon:$ ./mplayer -loop 3 -ao pcm:fast:file=/dev/null -benchmark
> -quiet -ac mpg123 stream.dump
> MPlayer SVN-r34123-4.5.3 (C) 2000-2011 MPlayer Team
> Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
> AO: [pcm] 48000Hz 2ch s16le (2 bytes per sample)
> BENCHMARKs: VC:   0.000s VO:   0.000s A:  55.760s Sys:   0.862s =   56.621s
> BENCHMARKs: VC:   0.000s VO:   0.000s A:  53.390s Sys:   0.515s =   53.906s
> BENCHMARKs: VC:   0.000s VO:   0.000s A:  52.770s Sys:   0.536s =   53.306s

The interesting comparison to see would be mplayer itself, once with
internal mp3lib vs. external libmpg123, not mpg123 the command line
program.

Diego

From thomas-forum at orgis.org  Fri Sep 23 16:24:20 2011
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Fri, 23 Sep 2011 16:24:20 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
	<CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
Message-ID: <20110923162420.207f190a@orgis.org>

Am Fri, 23 Sep 2011 16:46:05 +0300
schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 

> wasn't as good. Even if mpg123 is the fastest among the alternatives,
> mp3lib is still 8% faster.

I feared that. There is a distinct penalty when using libmpg123 from
MPlayer, which might be glossed over in the SSE case because the speed
of the SSE code in mpg123 is improved.

I remember doing some profiling that revealed that when used from
MPlayer, the CPU time of libmpg123 internal decdoding functions
increases. Also, I had some funny effects about changing some code line
in MPlayer having a big impact on performance through code alignment,
probably.

There have been posts to this list about this, but I don't think we
arrived at a final conclusion. Have to dig out the thread again... will
try to this evening.


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110923/b5a54a57/attachment.asc>

From diego at biurrun.de  Fri Sep 23 16:27:17 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Fri, 23 Sep 2011 16:27:17 +0200
Subject: [MPlayer-dev-eng] [patch] add device to vidix/radeon_vid.c
In-Reply-To: <20110921014902.3A47E14DBA6@smtp.hushmail.com>
References: <20110921014902.3A47E14DBA6@smtp.hushmail.com>
Message-ID: <20110923142717.GC9230@pool.informatik.rwth-aachen.de>

On Wed, Sep 21, 2011 at 01:49:02AM +0000, 4720 at hushmail.com wrote:
> i am submitting some patches that have been freebsd ports patches 
> from
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/mplayer/files
> /
> for inclusion in your project.

> --- vidix/radeon_vid.c.orig	2009-05-12 21:58:57.000000000 -0500
> +++ vidix/radeon_vid.c	2009-07-23 20:43:25.733650341 -0500
> @@ -345,6 +345,8 @@
>   { DEVICE_ATI_RAGE_128_PRO2, 0 },
>   { DEVICE_ATI_RAGE_128_PRO3, 0 },
>  /* these seem to be based on rage 128 instead of mach64 */
> + { DEVICE_ATI_RAGE_MOBILITY_M4, 0 },
> + { DEVICE_ATI_RAGE_MOBILITY_M42, 0 },
>   { DEVICE_ATI_RAGE_MOBILITY_M3, 0 },
>   { DEVICE_ATI_RAGE_MOBILITY_M32, 0 },

Applied.

Diego

From diego at biurrun.de  Fri Sep 23 16:27:59 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Fri, 23 Sep 2011 16:27:59 +0200
Subject: [MPlayer-dev-eng] [PATCH] stream_bluray: switch to new
 libbluray API
In-Reply-To: <20110915184941.GA3118@ryvius.greysector.net>
References: <1315762560-16131-1-git-send-email-diego@biurrun.de>
	<20110913152517.GE6665@pool.informatik.rwth-aachen.de>
	<20110915184941.GA3118@ryvius.greysector.net>
Message-ID: <20110923142759.GD9230@pool.informatik.rwth-aachen.de>

On Thu, Sep 15, 2011 at 08:49:41PM +0200, Dominik 'Rathann' Mierzejewski wrote:
> On Tuesday, 13 September 2011 at 17:25, Diego Biurrun wrote:
> > On Sun, Sep 11, 2011 at 07:36:00PM +0200, Diego Biurrun wrote:
> > > From: Rico Tzschichholz <ricotz at ubuntu.com>
> > > 
> > > Switch to new libbluray API with three parameters to bd_get_title_info().
> > > libbluray versions using the old API are no longer supported.
> > > 
> > > Signed-off-by: Diego Biurrun <diego at biurrun.de>
> > 
> > No opinions?  Then I'll push this by Friday or so.
> 
> Please mention those commit hashes (maybe with a date) from
> libbluray upstream in the commit message so that people can
> find out why their local libbluray version is not detected.

Applied with an amended log message.

Diego

From diego at biurrun.de  Fri Sep 23 17:14:38 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Fri, 23 Sep 2011 17:14:38 +0200
Subject: [MPlayer-dev-eng] [patch] add warning to vidix/mga_vid.c
In-Reply-To: <20110921014739.A710A14DBA6@smtp.hushmail.com>
References: <20110921014739.A710A14DBA6@smtp.hushmail.com>
Message-ID: <20110923151438.GE9230@pool.informatik.rwth-aachen.de>

On Wed, Sep 21, 2011 at 01:47:39AM +0000, 4720 at hushmail.com wrote:
> i am submitting some patches that have been freebsd ports patches 
> from
> http://www.freebsd.org/cgi/cvsweb.cgi/ports/multimedia/mplayer/files/
> for inclusion in your project.

Could you give us reasons for those changes?  It's hard to understand
why you patched the stuff you patched.

Also, are you the MPlayer packager?  I'd like to go over some of
those other patches in that list, parts of them are bogus.

Diego

From cehoyos at ag.or.at  Fri Sep 23 17:49:52 2011
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Fri, 23 Sep 2011 15:49:52 +0000 (UTC)
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
	<CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
Message-ID: <loom.20110923T174857-506@post.gmane.org>

Ivan Kalvachev <ikalvachev <at> gmail.com> writes:

> While the standalone run looked quite promising, the mplayer run
> wasn't as good. Even if mpg123 is the fastest among the alternatives,
> mp3lib is still 8% faster.

Didn't we already knew that from older tests?

> I used the version that comes with my distribution, as that would be
> the typical user case.

I strongly agree with that last sentence!

Carl Eugen


From Reimar.Doeffinger at gmx.de  Fri Sep 23 18:58:48 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 23 Sep 2011 18:58:48 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
Message-ID: <20110923165848.GA2951@1und1.de>

On Fri, Sep 23, 2011 at 03:45:49AM +0300, Ivan Kalvachev wrote:
> Do you want oprofile from my cpu too?

Well, I'd want something that allows to compare the CPU usage
of the different decoder parts for mp3lib and ffmp3float from
someone...
The more the better in principle, but one is the minimum.

From Reimar.Doeffinger at gmx.de  Fri Sep 23 19:03:18 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 23 Sep 2011 19:03:18 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <4E7BCF27.3070202@free.fr>
References: <20110920181954.GA32134@1und1.de>
	<loom.20110921T013825-226@post.gmane.org>
	<1316586506.815.85.camel@valinor.malmo.kicore.net>
	<4E79AFE3.5050908@free.fr>
	<20110921144925.GA11022@sushi.unix-ag.uni-kl.de>
	<4E7A828D.7080401@free.fr> <20110922160031.GB2485@1und1.de>
	<4E7BCF27.3070202@free.fr>
Message-ID: <20110923170318.GB2951@1und1.de>

On Fri, Sep 23, 2011 at 02:13:27AM +0200, xi wrote:
> Ok, I tried to use "perf" command, hope this is correct. eg :
> "perf record -f mplayer -benchmark -vo null -ao null -afm mp3lib
> -format s16le /tmp/E-Type_Made_in_Sweden.mp3"
> Then
> "perf report > /tmp/test.txt"

Yes, that is fine in principle.
But I'm afraid you need to configure with
--extra-cflags=-g --extra-ldflags=-g
to get readable/useful output.

> Note that "perf" seems to be a recent kernel tool that was not
> included in the 2.6.22 kernel used for my PIII 850. So, the tests
> below are _only_ for my Dual athlon MP2800+.

Yes, for older kernels oprofile would be the alternative, but in
comparison it's rather a pain to use, and for now I am happy
to just get something.

From alex.converse at gmail.com  Tue Sep 20 23:02:57 2011
From: alex.converse at gmail.com (Alex Converse)
Date: Tue, 20 Sep 2011 14:02:57 -0700
Subject: [MPlayer-dev-eng] [PATCH] Add support for arbitrary metadata in the
	lavf muxer.
Message-ID: <1316552577-30365-1-git-send-email-alex.converse@gmail.com>

---
 libmpdemux/muxer_lavf.c |   37 +++++++++++++++++++++++++++++++++++++
 1 files changed, 37 insertions(+), 0 deletions(-)

diff --git a/libmpdemux/muxer_lavf.c b/libmpdemux/muxer_lavf.c
index 5b5ab61..ce8cc3b 100644
--- a/libmpdemux/muxer_lavf.c
+++ b/libmpdemux/muxer_lavf.c
@@ -66,6 +66,7 @@ static int mux_packet_size= 0;
 static float mux_preload= 0.5;
 static float mux_max_delay= 0.7;
 static char *mux_avopt = NULL;
+static char *mux_avmetadata = NULL;
 
 const m_option_t lavfopts_conf[] = {
 	{"format", &(conf_format), CONF_TYPE_STRING, 0, 0, 0, NULL},
@@ -74,6 +75,7 @@ const m_option_t lavfopts_conf[] = {
 	{"preload", &mux_preload, CONF_TYPE_FLOAT, CONF_RANGE, 0, INT_MAX, NULL},
 	{"delay", &mux_max_delay, CONF_TYPE_FLOAT, CONF_RANGE, 0, INT_MAX, NULL},
         {"o", &mux_avopt, CONF_TYPE_STRING, 0, 0, 0, NULL},
+	{"metadata", &mux_avmetadata, CONF_TYPE_STRING, 0, 0, 0, NULL},
 
 	{NULL, NULL, 0, 0, 0, 0, NULL}
 };
@@ -313,6 +315,32 @@ static void list_formats(void) {
 		mp_msg(MSGT_DEMUX, MSGL_INFO, "%15s : %s\n", fmt->name, fmt->long_name);
 }
 
+static int parse_avmetadata(AVDictionary **v, const char *metadata_string) {
+	char *start, *str;
+	start = str = strdup(metadata_string);
+
+	while (str && *str) {
+		char *next_opt, *arg;
+
+		next_opt = strchr(str, ',');
+		if (next_opt)
+			*next_opt++ = 0;
+
+		arg = strchr(str, '=');
+		if (arg)
+			*arg++ = 0;
+
+		if (av_dict_set(v, str, arg, 0)) {
+			free(start);
+			return -1;
+		}
+		str = next_opt;
+	}
+
+	free(start);
+	return 0;
+}
+
 int muxer_init_muxer_lavf(muxer_t *muxer)
 {
 	muxer_priv_t *priv;
@@ -377,6 +405,15 @@ int muxer_init_muxer_lavf(muxer_t *muxer)
             }
         }
 
+	if (mux_avmetadata) {
+		if (parse_avmetadata(&priv->oc->metadata, mux_avmetadata) < 0) {
+			mp_msg(MSGT_MUXER,MSGL_ERR,
+				"Your metadata /%s/ looks like gibberish to me pal.\n",
+				mux_avmetadata);
+			goto fail;
+		}
+	}
+
 	priv->oc->pb = avio_alloc_context(priv->buffer, BIO_BUFFER_SIZE, 1, muxer, NULL, mp_write, mp_seek);
 	if ((muxer->stream->flags & MP_STREAM_SEEK) != MP_STREAM_SEEK)
             priv->oc->pb->is_streamed = 1;
-- 
1.7.3.1


From sergey.kosov at project-10.de  Thu Sep 22 13:23:46 2011
From: sergey.kosov at project-10.de (sergey.kosov at project-10.de)
Date: Thu, 22 Sep 2011 13:23:46 +0200 (CEST)
Subject: [MPlayer-dev-eng] =?iso-8859-1?q?Motion_Vector_Field_vs_Macrobloc?=
	=?iso-8859-1?q?k_Predictions?=
Message-ID: <20110922112346.B8292310005@can27.de>

Hi,

I have tried the MPlayer (v.0.6.9) on some h264/AVC video streams, which
contain only I and P data slices. I visualize the motion vectors and
achieve some dramatic noise on homogeneous static regions in video.
It is not real motion vectors isn't it?
If those are visualizations of mvd_L0 or mvd_L1 vectors for macro blocks
from the macro block prediction layer according to the H264 / MPEG 4
standard? If not, could you please describe or refer me to the code
section where you build these vectors?

thank you in advance,

Sergey


From Reimar.Doeffinger at gmx.de  Fri Sep 23 19:46:13 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 23 Sep 2011 19:46:13 +0200
Subject: [MPlayer-dev-eng] [PATCH] Add support for arbitrary metadata in
 the lavf muxer.
In-Reply-To: <1316552577-30365-1-git-send-email-alex.converse@gmail.com>
References: <1316552577-30365-1-git-send-email-alex.converse@gmail.com>
Message-ID: <20110923174613.GA25811@1und1.de>

On Tue, Sep 20, 2011 at 02:02:57PM -0700, Alex Converse wrote:
> +static int parse_avmetadata(AVDictionary **v, const char *metadata_string) {
> +	char *start, *str;
> +	start = str = strdup(metadata_string);
> +
> +	while (str && *str) {
> +		char *next_opt, *arg;
> +
> +		next_opt = strchr(str, ',');
> +		if (next_opt)
> +			*next_opt++ = 0;
> +
> +		arg = strchr(str, '=');
> +		if (arg)
> +			*arg++ = 0;
> +
> +		if (av_dict_set(v, str, arg, 0)) {
> +			free(start);
> +			return -1;
> +		}
> +		str = next_opt;
> +	}

That makes it impossible to specify metadata containing = or ,.
I would have suggested to reuse parse_str from subopt-helper.c
but I see that might get a bit messy.
Also misses a documentation update.

From mk at spline.de  Fri Sep 23 19:59:34 2011
From: mk at spline.de (Micha)
Date: Fri, 23 Sep 2011 19:59:34 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110923082832.24bf7c60@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
Message-ID: <4E7CC906.5020202@spline.de>

> Would you care to give the ac mpg123 a spin, too? Regardless about the
> performance of ffmpeg's mp3 (and mp2, and mp1) decoding, the comparison
> to the official mpg123 code should work out on removing the internal
> fork.

Please don't mind me jumping in here and contribute some numbers. I'm
not even sure they are very helpful to you.
I had quite an adventure compiling mplayer (svn) and libmpg123 (1.13.4)
on a very old x86 hardware that I use and a small embedded arm-device.
Although benchmarking on arm may not really fit into the discussion I
added it for your information.

==A==

model name      : Pentium II (Deschutes)
cpu MHz         : 348.487
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
mca cmov pat pse36 mmx fxsr up
Description:    Ubuntu 8.04.4 LTS

==B==

Processor       : Feroceon 88FR131 rev 1 (v5l)
Features        : swp half thumb fastmult edsp
Hardware        : Marvell SheevaPlug Reference Board
Description:    Debian GNU/Linux 6.0.2 (squeeze)


The Numbers:

/usr/local/bin/mplayer -ac mp3 -vo null -vc null -benchmark -ao
pcm:fast:file=/dev/null file.mp3 -endpos 300 -loop 3


==A==

Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III

VC:   0.000s VO:   0.000s A:  12.582s Sys:  28.006s =   40.588s

Opening audio decoder: [mp3lib] MPEG layer-2, layer-3

VC:   0.000s VO:   0.000s A:  11.650s Sys:  26.212s =   37.862s


==B==

Opening audio decoder: [mpg123] MPEG 1.0/2.0/2.5 layers I, II, III

VC:   0.000s VO:   0.000s A:   8.383s Sys:  17.308s =   25.691s

Opening audio decoder: [mp3lib] MPEG layer-2, layer-3

VC:   0.000s VO:   0.000s A:  77.976s Sys: 159.694s =  237.670s

From Reimar.Doeffinger at gmx.de  Fri Sep 23 20:10:31 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 23 Sep 2011 20:10:31 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
Message-ID: <20110923181030.GA26273@1und1.de>

On Fri, Sep 23, 2011 at 03:45:49AM +0300, Ivan Kalvachev wrote:
> Even if we assume the extra 6 seconds are because of the ugly float
> conversion and clipping i've done in af_format, even then mp3lib is
> still around 16% faster than the float only case.

-demuxer lavf will show how much if any of that comes from the
parser.

From Reimar.Doeffinger at gmx.de  Fri Sep 23 20:18:10 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 23 Sep 2011 20:18:10 +0200
Subject: [MPlayer-dev-eng] [PATCH] ae_lavc: set nBlockAlign like
 libavformat
In-Reply-To: <20110828182242.GA9313@phare.normalesup.org>
References: <20110827143421.GB8976@phare.normalesup.org>
	<20110827155142.GB2930@1und1.de>
	<20110827181226.GA23855@phare.normalesup.org>
	<20110827192046.GA18299@1und1.de>
	<20110827195244.GA4669@phare.normalesup.org>
	<20110827201047.GA4120@1und1.de>
	<20110828182242.GA9313@phare.normalesup.org>
Message-ID: <20110923181810.GA26313@1und1.de>

On Sun, Aug 28, 2011 at 08:22:42PM +0200, Nicolas George wrote:
> Le decadi 10 fructidor, an CCXIX, Reimar D?ffinger a ?crit?:
> > The muxer mostly takes the values as they come from the demuxer, sight
> > unseen.
> > This works with the mkv demuxer that keeps the dwScale/dwRate as they
> > are, based on bitrate.
> > For demuxer lavf I guess there are two ways to fix it: Also keeping
> > dwScale/dwRate (will break other things) or by using the same logic
> > as you suggest for ae_lavc - but then that IMO should not be duplicated
> > but go into some shared file.
> 
> For stream copy from demux_lavf, the base problem is the same (AVI has a
> mess of fields with overlapping semantic that are used chaotically by
> various implementations) but the exact problem is different: the culprit
> here is dwSampleSize, not nBlockAlign.
> 
> You can see how ffmpeg handles the problem in ffmpeg.c near lines 2275 (and
> do not be fooled, icodec->block_align is dwSampleSize, not nBlockAlign).
> 
> The attached patch does the same thing to mencoder.c. It fixes stream copy
> for the sample case I made, with AC3. I am downloading the sample from bug
> #1958 you mentioned yesterday (AC3) to see if it fixes it.
> 
> The MP3 case does not work very well, there is a different problem there,
> with a lot of "1 duplicate frame" that should not be there. But there is a
> lot I do not understand in the AV-sync system of mencoder (I spent half the
> day trying to understand why ae_lame causes three frames to be skipped while
> ae_lavc does not, in vain).
> 
> This is not perfect, but it is still an improvement.
> 
> I also attach a slightly updated version of the patch for ae_lavc.
> 
> Regards,
> 
> -- 
>   Nicolas George

> From f56edf73f5e38e88d7b0750dacbfd7796e825304 Mon Sep 17 00:00:00 2001
> From: Nicolas George <nicolas.george at normalesup.org>
> Date: Sun, 28 Aug 2011 19:46:39 +0200
> Subject: [PATCH 3/3] mencoder: set dwSampleSize to 0 for MP3 and AC3 stream
>  copy.
> 
> This fixes stream copy from demuxers that set dwSampleSize, especially lavf.
> The hack is similar to the one in ffmpeg.c near line 2275.
> ---
>  libmpdemux/demuxer.c |    1 +
>  mencoder.c           |    3 +++
>  2 files changed, 4 insertions(+), 0 deletions(-)
> 
> diff --git a/libmpdemux/demuxer.c b/libmpdemux/demuxer.c
> index d3f0395..8e3043c 100644
> --- a/libmpdemux/demuxer.c
> +++ b/libmpdemux/demuxer.c
> @@ -17,6 +17,7 @@
>   * with MPlayer; if not, write to the Free Software Foundation, Inc.,
>   * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
>   */
> +#include <execinfo.h>
>  
>  #include <stdio.h>
>  #include <stdlib.h>

That does not belong in that I guess.
But otherwise since A-V sync seems quite broken currently, could
you just go ahead and apply these?
I won't be able to come up with anything much better I expect.

> diff --git a/mencoder.c b/mencoder.c
> index 9efeb75..65a8c8d 100644
> --- a/mencoder.c
> +++ b/mencoder.c
> @@ -1098,6 +1098,9 @@ case ACODEC_COPY:
>  	mux_a->h.dwScale=mux_a->h.dwSampleSize;
>  	mux_a->h.dwRate=mux_a->wf->nAvgBytesPerSec;
>      }
> +    if ((mux_a->wf->wFormatTag ==   0x55 /* MP3 */ && mux_a->h.dwSampleSize == 1) ||
> +        (mux_a->wf->wFormatTag == 0x2000 /* AC3 */))

Hm, those have a lot more possible tags, this should really look up the
codecs.conf entry or some such I'd say.

From thomas-forum at orgis.org  Fri Sep 23 23:14:29 2011
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Fri, 23 Sep 2011 23:14:29 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110923162420.207f190a@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
	<CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
	<20110923162420.207f190a@orgis.org>
Message-ID: <20110923231429.40fca988@orgis.org>

Am Fri, 23 Sep 2011 16:24:20 +0200
schrieb Thomas Orgis <thomas-forum at orgis.org>: 

> There have been posts to this list about this, but I don't think we
> arrived at a final conclusion. Have to dig out the thread again... will
> try to this evening.

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-May/064656.html

Around there seems to be the conclusion of the last discussion on the
performance inconsistencies.

Quoting Reimar:
> > Not much, but I'd really start with cleaning up the stack issues
> > with the 3dnow code, they might cause cache issue that can easily
> > have that kind of effect.

Well, he might have a point there. Meanwhile, I posted about the
shiftily moving target that is the performance of mp3lib:

http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-May/064673.html
and
http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-June/064726.html

(I'd like to point out that it is a really, really, braindead idea to
organize mailing list archives separated on monthly boundaries... you
have a fun time stitching threads back together.)

I'm sorry that I did not push further on that topic, but I didn't (and
still don't) have endless time to spare for such hunts. Actually, I was
more busy hunting compiler bugs that sabotage my thesis work...

Would be nice if we got this settled now for good.


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110923/4f6914e3/attachment-0001.asc>

From ib at wupperonline.de  Sun Sep 25 10:24:46 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 25 Sep 2011 10:24:46 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <4e7209e4.1b0a0978.bm001@wupperonline.de>
Message-ID: <4e7ee55d.1ff0a814.bm000@wupperonline.de>

I wrote on Thu, 15 Sep 2011 16:06:23 +0200:

> Here we go.

Any opinion, anyone?

Or does no comment at all mean that it is ok to commit?

Ingo

From nicolas.george at normalesup.org  Sun Sep 25 11:58:10 2011
From: nicolas.george at normalesup.org (Nicolas George)
Date: Sun, 25 Sep 2011 11:58:10 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility
 off (was Re:	 Question for dev's: Does mplayer disable DPMS	timeouts? "xset
 q" looks good, but timeouts never trigger)
In-Reply-To: <4E75F00A.4000804@unix-ag.uni-kl.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
	<1315547954.15632.67.camel@valinor.malmo.kicore.net>
	<4E75F00A.4000804@unix-ag.uni-kl.de>
Message-ID: <20110925095810.GB7607@phare.normalesup.org>

Le jour du G?nie, an CCXIX, Erik Auerswald a ?crit?:
> But most of the time, looking for preferred languages would do The
> Right Thing?.

Beg to differ: automatically selecting the dubbed version instead of the
original version is clearly always The Wrong Thing.

Well, avoiding trolls, the preferences of people about languages can be
quite varied. I know mine can not be expressed in terms of simple command
line options. Therefore, I think keeping things as simple and predictable as
possible is the best course.

> Some table specifying the equivalence of two- and three-letter
> language codes (e.g. en == eng) would help usability.

This, OTOH, is a very good idea.

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110925/bc877331/attachment.asc>

From tempn at twmi.rr.com  Sun Sep 25 14:03:56 2011
From: tempn at twmi.rr.com (compn)
Date: Sun, 25 Sep 2011 08:03:56 -0400
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <4e7ee55d.1ff0a814.bm000@wupperonline.de>
References: <4e7209e4.1b0a0978.bm001@wupperonline.de>
	<4e7ee55d.1ff0a814.bm000@wupperonline.de>
Message-ID: <20110925080356.34c6a771.tempn@twmi.rr.com>

On Sun, 25 Sep 2011 10:24:46 +0200, Ingo Br?ckl wrote:
>I wrote on Thu, 15 Sep 2011 16:06:23 +0200:
>
>> Here we go.
>
>Any opinion, anyone?
>
>Or does no comment at all mean that it is ok to commit?

better give reimar more time to review it.

-compn

From Reimar.Doeffinger at gmx.de  Sun Sep 25 15:22:01 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 25 Sep 2011 15:22:01 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <4e7209e4.1b0a0978.bm001@wupperonline.de>
References: <20110903074205.ddd04da0.tempn@twmi.rr.com>
	<4e7209e4.1b0a0978.bm001@wupperonline.de>
Message-ID: <20110925132201.GB2344@1und1.de>

On Thu, Sep 15, 2011 at 04:06:23PM +0200, Ingo Br?ckl wrote:
> +static unsigned int mp3_vbr_frames(stream_t *s, off_t off) {
> +  uint8_t hdr[HDR_SIZE];
> +  int framesize, chans, spf, layer;
> +  const off_t xing_offt[2][2] = {{32, 17}, {17, 9}};
> +
> +  if ((s->flags & MP_STREAM_SEEK) == MP_STREAM_SEEK) {
> +
> +    if (!stream_seek(s, off)) return 0;
> +    if (stream_read(s, hdr, HDR_SIZE) != HDR_SIZE) return 0;

Since your code will break completely if HDR_SIZE is anything but 4,
using it serves at best as obfuscation.
Even more since stream_read_dword in all cases except maybe this first
should result in much more readable code.
And have you tested all cases? Because the FFmpeg code until recently
read things from the wrong place for one of the headers.

> @@ -382,6 +440,8 @@
>  	demux_info_add(demuxer,"Genre",genres[g]);
>        }
>      }
> +    if (duration) sh_audio->wf->nAvgBytesPerSec = demuxer->movi_end / duration;
> +    sh_audio->i_bps = sh_audio->wf->nAvgBytesPerSec;

Why not just move this to where sh_audio->i_bps is already assigned
currently?
Also I am not sure demuxer->movi_end is necessarily set/!= 0.

From ib at wupperonline.de  Sun Sep 25 19:00:55 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 25 Sep 2011 19:00:55 +0200
Subject: [MPlayer-dev-eng] vbr mp3 runtime
In-Reply-To: <20110925132201.GB2344@1und1.de>
Message-ID: <4e7f609a.2f5267c1.bm000@wupperonline.de>

Reimar D?ffinger wrote on Sun, 25 Sep 2011 15:22:01 +0200:

> Since your code will break completely if HDR_SIZE is anything but 4,
> using it serves at best as obfuscation.
> Even more since stream_read_dword in all cases except maybe this first
> should result in much more readable code.

2nd attempt.

> And have you tested all cases?

I did so with numerous vbr mp3 files, both Xing/Info and VBRI, and I used
zzuf.

> Because the FFmpeg code until recently read things from the wrong place for
> one of the headers.

Do you refer to the bug I fixed in FFmpeg while developing this patch?

Everything is read from the right place.

>> @@ -382,6 +440,8 @@
>>       demux_info_add(demuxer,"Genre",genres[g]);
>>        }
>>      }
>> +    if (duration) sh_audio->wf->nAvgBytesPerSec = demuxer->movi_end / duration;
>> +    sh_audio->i_bps = sh_audio->wf->nAvgBytesPerSec;

> Why not just move this to where sh_audio->i_bps is already assigned
> currently?

Because demuxer->movi_end is needed which is set correctly only after the
tags evaluating code.

> Also I am not sure demuxer->movi_end is necessarily set/!= 0.

Well, if so, it's already with the current code. demux_audio.patch will
ensure it is set, but that is not directly related to the vbr patch.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mp3.vbr.patch
Type: text/x-diff
Size: 3437 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110925/0e5ccd93/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: demux_audio.patch
Type: text/x-diff
Size: 800 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110925/0e5ccd93/attachment-0001.bin>

From auerswal at unix-ag.uni-kl.de  Mon Sep 26 00:13:56 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Mon, 26 Sep 2011 00:13:56 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility
 off	(was Re:	 Question for dev's: Does mplayer disable	DPMS	timeouts? "xset
 q" looks good, but timeouts never trigger)
In-Reply-To: <4E75E951.8000800@unix-ag.uni-kl.de>
References: <4E665A5E.7010409@tedpavlic.com>	<20110906201622.GA3206@1und1.de>	<4E66833D.5050208@tedpavlic.com>	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>	<20110907104723.GA9561@phare.normalesup.org>	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>	<4E6A6EDA.8080200@unix-ag.uni-kl.de>
	<4E75E951.8000800@unix-ag.uni-kl.de>
Message-ID: <4E7FA7A4.6060701@unix-ag.uni-kl.de>

Ping again,

On 09/18/2011 02:51 PM, Erik Auerswald wrote:
> no comments regarding the small patch that hides subtitles unless the
> subtitle selection code actually selects a subtitle stream?
>
> On 09/09/2011 09:54 PM, Erik Auerswald wrote:
>> [...]
>> The attached patch (actually tested) is a definite improvement for me.
>> When specifying -slang XX or having a suitably named .srt file lying
>> near a movie, subtitles are displayed. But the mere presence of
>> subtitles on a DVD does not result in displaying them automatically.
>>
>> Please consider applying.
>
> The patch still applies cleanly.

It still does.

The change in behavior is practically just hiding subtitles on DVD 
unless a subtitle language is specified. In all other cases (MPlayer 
finds some subtitles, e.g. because of command line or file name) they 
are still displayed.

ACK/NAK/Timeout?

Thanks,
Erik

From ikalvachev at gmail.com  Mon Sep 26 01:03:13 2011
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Mon, 26 Sep 2011 02:03:13 +0300
Subject: [MPlayer-dev-eng] [PATCH]SPDIF pass through decoder
In-Reply-To: <20110917132528.0c8f8f8b.tempn@twmi.rr.com>
References: <CAJz3U+WyC1FbN+yO3Rip=OkQVdwXyF6LXF8LgvrObtOiE0bH1w@mail.gmail.com>
	<20110811212406.GA17697@pool.informatik.RWTH-Aachen.DE>
	<CAJz3U+Ue=nau=C2mVf+0RmS+QoAQ8cA3yBKgA16fi6PCfT4n+w@mail.gmail.com>
	<loom.20110818T161554-16@post.gmane.org>
	<CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>
	<20110917132528.0c8f8f8b.tempn@twmi.rr.com>
Message-ID: <CABA=pqetxnBVAoVnkz43uhfpMYoF=4+TrDaFFytJe2nRsxVvOw@mail.gmail.com>

On 9/17/11, compn <tempn at twmi.rr.com> wrote:
> On Fri, 2 Sep 2011 01:53:10 +0900, Naoya OYAMA wrote:
>>Hi, patch updated.
>
> ping.
> anyone going to apply this ?

As it have been more than a week without any reply, I think I'll apply
that one tomorrow. Too bad I can't test it.

From Reimar.Doeffinger at gmx.de  Mon Sep 26 20:15:11 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 26 Sep 2011 20:15:11 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle visibility
	off	(was Re:	 Question for dev's: Does mplayer
	disable	DPMS	timeouts? "xset q" looks good,
	but timeouts never trigger)
In-Reply-To: <4E7FA7A4.6060701@unix-ag.uni-kl.de>
References: <4E665A5E.7010409@tedpavlic.com> <20110906201622.GA3206@1und1.de>
	<4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
	<4E6A6EDA.8080200@unix-ag.uni-kl.de>
	<4E75E951.8000800@unix-ag.uni-kl.de>
	<4E7FA7A4.6060701@unix-ag.uni-kl.de>
Message-ID: <20110926181511.GB2399@1und1.de>

On Mon, Sep 26, 2011 at 12:13:56AM +0200, Erik Auerswald wrote:
> Ping again,
> 
> On 09/18/2011 02:51 PM, Erik Auerswald wrote:
> >no comments regarding the small patch that hides subtitles unless the
> >subtitle selection code actually selects a subtitle stream?
> >
> >On 09/09/2011 09:54 PM, Erik Auerswald wrote:
> >>[...]
> >>The attached patch (actually tested) is a definite improvement for me.
> >>When specifying -slang XX or having a suitably named .srt file lying
> >>near a movie, subtitles are displayed. But the mere presence of
> >>subtitles on a DVD does not result in displaying them automatically.
> >>
> >>Please consider applying.
> >
> >The patch still applies cleanly.
> 
> It still does.
> 
> The change in behavior is practically just hiding subtitles on DVD
> unless a subtitle language is specified. In all other cases (MPlayer
> finds some subtitles, e.g. because of command line or file name)
> they are still displayed.
> 
> ACK/NAK/Timeout?

I am not sure what exactly sub_visibility does, but it does not cause
the same behaviour as using -nosub or similar so I am rather sceptical
to it. In particular I think it causes the subtitle to be demuxed, which
in some cases (which you could cause bugs) has a chance of causing
playback issues over slow/non-seekable connections like a stream or
http.

From Reimar.Doeffinger at gmx.de  Mon Sep 26 20:37:19 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 26 Sep 2011 20:37:19 +0200
Subject: [MPlayer-dev-eng] [PATCH]SPDIF pass through decoder
In-Reply-To: <CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>
References: <CAJz3U+WyC1FbN+yO3Rip=OkQVdwXyF6LXF8LgvrObtOiE0bH1w@mail.gmail.com>
	<20110811212406.GA17697@pool.informatik.RWTH-Aachen.DE>
	<CAJz3U+Ue=nau=C2mVf+0RmS+QoAQ8cA3yBKgA16fi6PCfT4n+w@mail.gmail.com>
	<loom.20110818T161554-16@post.gmane.org>
	<CAJz3U+VOx+BbkGsVNAkBccwxUSOiM9uPCy-TG2yz6Fq=5OF4Jg@mail.gmail.com>
Message-ID: <20110926183719.GC2399@1und1.de>

On Fri, Sep 02, 2011 at 01:53:10AM +0900, Naoya OYAMA wrote:
> +/* set up max. outburst. use 131072 for TrueHD SPDIF psss-through,

"pass" not "psss" I guess.

> @@ -55,6 +55,9 @@ int af_str2fmt(const char* str)
>    if(strstr(str,"imaadpcm") || strstr(str,"IMAADPCM")){
>      format |= AF_FORMAT_IMA_ADPCM; return format;
>    }
> +  if(strstr(str,"iec61937") || strstr(str,"IEC61937")){
> +    format |= AF_FORMAT_IEC61937 | AF_FORMAT_16BIT; return format;
> +  }
>  
>    // Scan for int/float
>    if(strstr(str,"float") || strstr(str,"FLOAT")){
> @@ -123,6 +126,8 @@ char* af_fmt2str(int format, char* str, int size)
>        i+=snprintf(&str[i],size-i,"AC3 "); break;
>      case(AF_FORMAT_IMA_ADPCM):
>        i+=snprintf(&str[i],size-i,"IMA-ADPCM "); break;
> +    case(AF_FORMAT_IEC61937):
> +      i+=snprintf(&str[i],size-i,"IEC61937 "); break;
>      default:
>        i+=snprintf(&str[i],size-i,MSGTR_AF_FORMAT_UnknownFormat);
>      }
> @@ -161,6 +166,9 @@ static struct {
>      { "ac3le", AF_FORMAT_AC3_LE },
>      { "ac3be", AF_FORMAT_AC3_BE },
>      { "ac3ne", AF_FORMAT_AC3_NE },
> +    { "iec61937le", AF_FORMAT_IEC61937_LE },
> +    { "iec61937be", AF_FORMAT_IEC61937_BE },
> +    { "iec61937ne", AF_FORMAT_IEC61937_NE },
>      { "imaadpcm", AF_FORMAT_IMA_ADPCM },

That ordering is inconsistent.
I would prefer it to be next to ac3, even if it breaks alphabetical
order.

> @@ -418,9 +420,9 @@ static int init(int rate_hz, int channels, int format, int flags)
>       * while opening the abstract alias for the spdif subdevice
>       * 'iec958'
>       */
> -    if (AF_FORMAT_IS_AC3(format)) {
> +    if (AF_FORMAT_IS_AC3(format) || AF_FORMAT_IS_IEC61937(format)) {
>  	device.str = "iec958";
> -	mp_msg(MSGT_AO,MSGL_V,"alsa-spdif-init: playing AC3, %i channels\n", channels);
> +	mp_msg(MSGT_AO,MSGL_V,"alsa-spdif-init: playing IEC 61937, %i channels\n", channels);

Not that it matters much, but that is quite confusing, is it now AC3,
iec958 or IEC 61937...

> +#define OUTBUF_SIZE (65536)

Useless ()

> +    unsigned char *out_buffer;
> +    unsigned char *pb_buffer;

uint8_t is the preferred type for that really.

> +static int write_packet(void *p, uint8_t *buf, int buf_size)
> +{
> +    int len;
> +    struct spdifContext *ctx;
> +
> +    ctx = (struct spdifContext *)p;
> +    len = FFMIN(buf_size, ctx->out_buffer_size -ctx->out_buffer_len);
> +    memcpy(&ctx->out_buffer[ctx->out_buffer_len], buf, len);

The cast is unnecessary and the declarations and assignments can be
merged.

> +static int64_t seek(void *p, int64_t offset, int whence)
> +{
> +    //do nothing.
> +    return (int64_t)0LL;

return 0;
does exactly the same.

> +    ctx2 = av_mallocz(sizeof(struct spdifContext2));
> +    ctx2->spdif_ctx = av_mallocz(sizeof(struct spdifContext));

Please use sizeof(*ctx) / sizeof(*ctx2->spdif_ctx)
I wonder why two, separately allocated, contexts are necessary anyway,
I think it shouldn't be.

> +    stream = av_mallocz(sizeof(AVStream));
> +    streams = av_mallocz(sizeof(AVStream*)*1);

The same, though I think the lavc API forbids using sizeof on AVStream.

> +    spdif_ctx->pb_buffer = av_mallocz(sizeof(unsigned char)*OUTBUF_SIZE);

sizeof(char) is guaranteed to be 1...

> +    codec = av_mallocz(sizeof(AVCodecContext));

same as for AVStream.

> +    } else {
> +        if (sh->avctx) {

This should be "} else if (sh->avctx) {" without the extra unnecessary
block.

> +    ctx2 = (struct spdifContext2*)sh->context;

Unnecessary cast.

> +    while ((spdif_ctx->out_buffer_len + spdif_ctx->iec61937_packet_size < maxlen)
> +           && (spdif_ctx->out_buffer_len < minlen)) {

The innermost () are unnecessary really

> +        x = ds_get_packet_pts(sh->ds, &start, &pts);
> +        if (sh->ds->eof)
> +            break;

I think that's wrong when using the parser, you should see if
there's any data still stuck in the parser.

> +    if (lavf_ctx)
> +        if (lavf_ctx->oformat)

Can be merged in to a single if, or

> +            lavf_ctx->oformat->write_trailer(lavf_ctx);
> +
> +    if (lavf_ctx) {

Just moved in here.

From ikalvachev at gmail.com  Tue Sep 27 03:39:12 2011
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Tue, 27 Sep 2011 04:39:12 +0300
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <20110923231429.40fca988@orgis.org>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
	<CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
	<20110923162420.207f190a@orgis.org>
	<20110923231429.40fca988@orgis.org>
Message-ID: <CABA=pqcnEnUnvVQhMVYndyv2x_-UJ2ErQUqf+-=2pdNbvjVNng@mail.gmail.com>

On 9/24/11, Thomas Orgis <thomas-forum at orgis.org> wrote:
> Am Fri, 23 Sep 2011 16:24:20 +0200
> schrieb Thomas Orgis <thomas-forum at orgis.org>:
>
>> There have been posts to this list about this, but I don't think we
>> arrived at a final conclusion. Have to dig out the thread again... will
>> try to this evening.
>
> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-May/064656.html
>
> Around there seems to be the conclusion of the last discussion on the
> performance inconsistencies.
>
> Quoting Reimar:
>> > Not much, but I'd really start with cleaning up the stack issues
>> > with the 3dnow code, they might cause cache issue that can easily
>> > have that kind of effect.
>
> Well, he might have a point there. Meanwhile, I posted about the
> shiftily moving target that is the performance of mp3lib:
>
> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-May/064673.html
> and
> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2010-June/064726.html
>
> (I'd like to point out that it is a really, really, braindead idea to
> organize mailing list archives separated on monthly boundaries... you
> have a fun time stitching threads back together.)

Next time use gmane.org ;)

> I'm sorry that I did not push further on that topic, but I didn't (and
> still don't) have endless time to spare for such hunts. Actually, I was
> more busy hunting compiler bugs that sabotage my thesis work...
>
> Would be nice if we got this settled now for good.

It took me quite a lot of time, but I hope there will be useful
information in the data I provide.
If you need the raw perf.data files, I can send them to you.

First, few observations:

- demuxer lavf added 4 more seconds to all my test... Wonder why
everybody think lavf demuxers for slow ;)

- compiling specifically for my system lowered the mp3lib vs mpg123
speed difference from 8% to 6%.

- increasing alignment (of most big arrays) actually made mp3lib a
percent or 2 slower... so I dropped this road.

- nocache actually makes the test slower. it is still in the margin of
error, but...

athlon:$ mplayer -loop 3 -benchmark -ao pcm:fast:file=/dev/null -quiet
stream.dump
MPlayer SVN-r34123-4.5.3 (C) 2000-2011 MPlayer Team
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
AO: [pcm] 48000Hz 2ch s16le (2 bytes per sample)
BENCHMARKs: VC:   0.000s VO:   0.000s A:  51.116s Sys:   0.511s =   51.628s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  51.040s Sys:   0.530s =   51.569s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  51.137s Sys:   0.520s =   51.657s

athlon$ mplayer -loop 3 -benchmark -ao pcm:fast:file=/dev/null -quiet
stream.dump -nocache
MPlayer SVN-r34123-4.5.3 (C) 2000-2011 MPlayer Team
Selected audio codec: [mpg123] afm: mpg123 (MPEG 1.0/2.0/2.5 layers I, II, III)
BENCHMARKs: VC:   0.000s VO:   0.000s A:  51.248s Sys:   0.508s =   51.756s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  51.507s Sys:   0.551s =   52.058s
BENCHMARKs: VC:   0.000s VO:   0.000s A:  51.581s Sys:   0.528s =   52.109s

======================

In the following `perf stat` single runs there is something that could
easily be seen:
Cache misses are 2 times more for the mpg123 case and I think this is
what affects the instructions per cycle ratio. Have in mind that older
CPU actually have smaller cache, thus they are more affected by cache
misses.
======================
 Performance counter stats for './mplayer -benchmark -ao
pcm:fast:file=/dev/null -quiet -nocache stream.dump -ac mpg123':

       49288983690 cycles:u                  #    0.000 GHz
         [60.00%]
       54555534568 instructions:u            #    1.11  insns per
cycle         [60.00%]
       30754388474 l1-dcache-loads:u
         [60.00%]
         104031324 l1-dcache-load-misses:u   #    0.34% of all
L1-dcache hits   [60.00%]
         668863945 branch-misses
         [60.00%]

      53.125250828 seconds time elapsed

 Performance counter stats for './mplayer -benchmark -ao
pcm:fast:file=/dev/null -quiet -nocache stream.dump -ac mp3':

       47339857524 cycles:u                  #    0.000 GHz
         [60.00%]
       54276441494 instructions:u            #    1.15  insns per
cycle         [60.00%]
       28642127395 l1-dcache-loads:u
         [60.00%]
         176993369 l1-dcache-load-misses:u   #    0.62% of all
L1-dcache hits   [60.00%]
         665329666 branch-misses
         [60.00%]

      50.901825505 seconds time elapsed

==============
==============
athlon# perf record -e cycles:u -e instructions:u -e l1-dcache-loads:u
-e l1-dcache-load-misses:u -e branch-misses ./mplayer -loop 10
-benchmark -ao pcm:fast:file=/dev/null -quiet -nocache stream.dump -ac
mp3
athlon# perf report

# Events: 2K cycles
#
# Overhead  Command      Shared Object                        Symbol
# ........  .......  .................  ............................
#
    31.31%  mplayer  mplayer            [.] III_dequantize_sample
    18.69%  mplayer  mplayer            [.] synth_1to1_MMX
    15.99%  mplayer  mplayer            [.] dct64_MMX_3dnowex
    15.58%  mplayer  mplayer            [.] dct36_3dnowex
     8.13%  mplayer  mplayer            [.] do_layer3.clone.3
     1.62%  mplayer  libc-2.13.so       [.] memcpy
     1.49%  mplayer  ld-2.13.so         [.] do_lookup_x
     1.27%  mplayer  ld-2.13.so         [.] check_match.8296
     0.82%  mplayer  mplayer            [.] fast_memcpy
     0.64%  mplayer  mplayer            [.] III_get_scale_factors_1
     0.46%  mplayer  mplayer            [.] synth_1to1
     0.43%  mplayer  ld-2.13.so         [.] strcmp
     0.38%  mplayer  ld-2.13.so         [.] .L180
     0.37%  mplayer  mplayer            [.] demux_audio_fill_buffer
     0.27%  mplayer  mplayer            [.] MP3_DecodeFrame


# Events: 2K instructions
#
# Overhead  Command           Shared Object                        Symbol
# ........  .......  ......................  ............................
#
    26.46%  mplayer  mplayer                 [.] III_dequantize_sample
    23.69%  mplayer  mplayer                 [.] synth_1to1_MMX
    18.06%  mplayer  mplayer                 [.] dct64_MMX_3dnowex
    15.58%  mplayer  mplayer                 [.] dct36_3dnowex
    11.58%  mplayer  mplayer                 [.] do_layer3.clone.3
     0.95%  mplayer  mplayer                 [.] synth_1to1
     0.90%  mplayer  mplayer                 [.] III_get_scale_factors_1
     0.44%  mplayer  ld-2.13.so              [.] do_lookup_x
     0.38%  mplayer  mplayer                 [.] dct12
     0.24%  mplayer  ld-2.13.so              [.] check_match.8296
     0.19%  mplayer  mplayer                 [.] demux_audio_fill_buffer
     0.17%  mplayer  ld-2.13.so              [.] strcmp
     0.15%  mplayer  mplayer                 [.] demux_mpg_fill_buffer
     0.14%  mplayer  mplayer                 [.] nsv_check_file
     0.09%  mplayer  mplayer                 [.] fast_memcpy
     0.09%  mplayer  mplayer                 [.] MP3_DecodeFrame
     0.09%  mplayer  libc-2.13.so            [.] malloc_consolidate

# Events: 2K L1-dcache-loads
#
# Overhead  Command           Shared Object                   Symbol
# ........  .......  ......................  .......................
#
    28.01%  mplayer  mplayer                 [.] synth_1to1_MMX
    22.17%  mplayer  mplayer                 [.] dct64_MMX_3dnowex
    16.62%  mplayer  mplayer                 [.] dct36_3dnowex
    16.20%  mplayer  mplayer                 [.] III_dequantize_sample
     9.84%  mplayer  mplayer                 [.] do_layer3.clone.3
     2.24%  mplayer  libc-2.13.so            [.] memcpy
     1.33%  mplayer  mplayer                 [.] synth_1to1
     0.57%  mplayer  ld-2.13.so              [.] do_lookup_x
     0.47%  mplayer  mplayer                 [.] III_get_scale_factors_1
     0.38%  mplayer  mplayer                 [.] fast_memcpy
     0.35%  mplayer  ld-2.13.so              [.] check_match.8296
     0.24%  mplayer  libc-2.13.so            [.] _int_malloc
     0.24%  mplayer  mplayer                 [.] dct12
     0.15%  mplayer  ld-2.13.so              [.] strcmp
     0.14%  mplayer  libc-2.13.so            [.] __cfree
     0.14%  mplayer  mplayer                 [.] MP3_DecodeFrame
     0.14%  mplayer  mplayer                 [.] demux_read_data

# Events: 1K L1-dcache-load-misses
#
# Overhead  Command      Shared Object                     Symbol
# ........  .......  .................  .........................
#
    24.61%  mplayer  libc-2.13.so       [.] memcpy
    15.37%  mplayer  mplayer            [.] synth_1to1_MMX
     9.81%  mplayer  mplayer            [.] fast_memcpy
     9.44%  mplayer  mplayer            [.] dct36_3dnowex
     8.47%  mplayer  mplayer            [.] dct64_MMX_3dnowex
     7.20%  mplayer  mplayer            [.] III_dequantize_sample
     5.34%  mplayer  ld-2.13.so         [.] do_lookup_x
     4.50%  mplayer  ld-2.13.so         [.] check_match.8296
     3.83%  mplayer  mplayer            [.] do_layer3.clone.3
     1.13%  mplayer  libc-2.13.so       [.] __GI___mempcpy
     0.93%  mplayer  ld-2.13.so         [.] .L180
     0.90%  mplayer  ld-2.13.so         [.] strcmp
     0.67%  mplayer  mplayer            [.] synth_1to1
     0.64%  mplayer  libc-2.13.so       [.] __GI_memmove
     0.58%  mplayer  libc-2.13.so       [.] _int_malloc
     0.52%  mplayer  libc-2.13.so       [.] __malloc
     0.48%  mplayer  mplayer            [.] demux_audio_fill_buffer
     0.48%  mplayer  [kernel.kallsyms]  [k] page_fault
     0.43%  mplayer  mplayer            [.] demux_read_data


# Events: 2K branch-misses
#
# Overhead  Command      Shared Object                       Symbol
# ........  .......  .................  ...........................
#
    79.96%  mplayer  mplayer            [.] III_dequantize_sample
     4.82%  mplayer  mplayer            [.] synth_1to1_MMX
     3.38%  mplayer  mplayer            [.] do_layer3.clone.3
     2.59%  mplayer  mplayer            [.] dct64_MMX_3dnowex
     0.41%  mplayer  ld-2.13.so         [.] do_lookup_x
     0.41%  mplayer  [kernel.kallsyms]  [k] __lock_acquire
     0.38%  mplayer  mplayer            [.] fast_memcpy
     0.38%  mplayer  mplayer            [.] ds_fill_buffer
     0.33%  mplayer  [kernel.kallsyms]  [k] lock_acquire
     0.33%  mplayer  mplayer            [.] dct36_3dnowex
     0.33%  mplayer  mplayer            [.] III_get_scale_factors_1
     0.32%  mplayer  mplayer            [.] demux_audio_fill_buffer



athlon# perf record -e cycles:u -e instructions:u -e l1-dcache-loads:u
-e l1-dcache-load-misses:u -e branch-misses ./mplayer -loop 10
-benchmark -ao pcm:fast:file=/dev/null -quiet -nocache stream.dump -ac
mpg123
athlon# perf report

# Events: 3K cycles
#
# Overhead  Command        Shared Object                            Symbol
# ........  .......  ...................  ................................
#
    31.04%  mplayer  libmpg123.so.0.29.6  [.] III_dequantize_sample
    15.34%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct64_3dnowext
    14.67%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct36_3dnowext
    11.26%  mplayer  libmpg123.so.0.29.6  [.] synth_1to1_3dnowext_asm
     7.42%  mplayer  libmpg123.so.0.29.6  [.] INT123_do_layer3
     7.15%  mplayer  libmpg123.so.0.29.6  [.] .next_loop
     3.10%  mplayer  libc-2.13.so         [.] memcpy
     1.39%  mplayer  libmpg123.so.0.29.6  [.] INT123_synth_1to1_3dnowext
     1.15%  mplayer  libmpg123.so.0.29.6  [.] III_get_scale_factors_1.clone.1
     1.04%  mplayer  ld-2.13.so           [.] do_lookup_x
     0.77%  mplayer  ld-2.13.so           [.] check_match.8296
     0.49%  mplayer  libmpg123.so.0.29.6  [.] dct12


# Events: 3K instructions
#
# Overhead  Command           Shared Object                           Symbol
# ........  .......  ......................  ...............................
#
    23.14%  mplayer  libmpg123.so.0.29.6     [.] III_dequantize_sample
    19.15%  mplayer  libmpg123.so.0.29.6     [.] INT123_dct64_3dnowext
    15.96%  mplayer  libmpg123.so.0.29.6     [.] INT123_dct36_3dnowext
    13.29%  mplayer  libmpg123.so.0.29.6     [.] synth_1to1_3dnowext_asm
    11.04%  mplayer  libmpg123.so.0.29.6     [.] .next_loop
    10.96%  mplayer  libmpg123.so.0.29.6     [.] INT123_do_layer3
     1.88%  mplayer  libmpg123.so.0.29.6     [.] INT123_synth_1to1_3dnowext
     1.11%  mplayer  libmpg123.so.0.29.6     [.] III_get_scale_factors_1.clone.1
     0.40%  mplayer  libmpg123.so.0.29.6     [.] dct12
     0.33%  mplayer  ld-2.13.so              [.] do_lookup_x
     0.26%  mplayer  libc-2.13.so            [.] _int_malloc

# Events: 3K L1-dcache-loads
#
# Overhead  Command        Shared Object                           Symbol
# ........  .......  ...................  ...............................
#
    21.63%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct64_3dnowext
    15.47%  mplayer  libmpg123.so.0.29.6  [.] synth_1to1_3dnowext_asm
    15.28%  mplayer  libmpg123.so.0.29.6  [.] III_dequantize_sample
    14.05%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct36_3dnowext
    11.40%  mplayer  libmpg123.so.0.29.6  [.] .next_loop
    11.07%  mplayer  libmpg123.so.0.29.6  [.] INT123_do_layer3
     4.02%  mplayer  libc-2.13.so         [.] memcpy
     2.06%  mplayer  libmpg123.so.0.29.6  [.] INT123_synth_1to1_3dnowext
     1.20%  mplayer  libmpg123.so.0.29.6  [.] III_get_scale_factors_1.clone.1
     0.37%  mplayer  libmpg123.so.0.29.6  [.] dct12
     0.31%  mplayer  ld-2.13.so           [.] do_lookup_x


# Events: 2K L1-dcache-load-misses
#
# Overhead  Command        Shared Object                           Symbol
# ........  .......  ...................  ...............................
#
    38.99%  mplayer  libc-2.13.so         [.] memcpy
    11.54%  mplayer  libmpg123.so.0.29.6  [.] III_dequantize_sample
    11.00%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct36_3dnowext
     8.19%  mplayer  libmpg123.so.0.29.6  [.] INT123_do_layer3
     5.05%  mplayer  ld-2.13.so           [.] do_lookup_x
     4.48%  mplayer  libmpg123.so.0.29.6  [.] synth_1to1_3dnowext_asm
     4.12%  mplayer  libmpg123.so.0.29.6  [.] .next_loop
     2.49%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct64_3dnowext
     2.32%  mplayer  ld-2.13.so           [.] check_match.8296
     1.48%  mplayer  libc-2.13.so         [.] __GI___mempcpy
     0.81%  mplayer  libc-2.13.so         [.] _int_malloc
     0.80%  mplayer  mplayer              [.] demux_audio_fill_buffer
     0.73%  mplayer  ld-2.13.so           [.] strcmp
     0.69%  mplayer  libc-2.13.so         [.] __cfree
     0.64%  mplayer  ld-2.13.so           [.] .L180
     0.46%  mplayer  libmpg123.so.0.29.6  [.] buffered_forget
     0.42%  mplayer  mplayer              [.] ds_fill_buffer


# Events: 3K branch-misses
#
# Overhead  Command        Shared Object                           Symbol
# ........  .......  ...................  ...............................
#
    80.36%  mplayer  libmpg123.so.0.29.6  [.] III_dequantize_sample
     3.09%  mplayer  libmpg123.so.0.29.6  [.] synth_1to1_3dnowext_asm
     2.24%  mplayer  libmpg123.so.0.29.6  [.] INT123_do_layer3
     1.11%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct64_3dnowext
     1.00%  mplayer  libmpg123.so.0.29.6  [.] synth_stereo_wrap
     0.67%  mplayer  libmpg123.so.0.29.6  [.] .next_loop
     0.64%  mplayer  libc-2.13.so         [.] memcpy
     0.64%  mplayer  [kernel.kallsyms]    [k] __lock_acquire
     0.61%  mplayer  libmpg123.so.0.29.6  [.] INT123_dct36_3dnowext
     0.50%  mplayer  libmpg123.so.0.29.6  [.] mpg123_decode
     0.46%  mplayer  libmpg123.so.0.29.6  [.] INT123_synth_1to1_3dnowext

==========
Strange things I noticed in the above reports:

- I see ld.so "do_lookup_x" take noticeable amount of time.  To
benchmark less of startup and more the runtime execution, at first I
added "-loop 5". It however had way smaller impact than I expected,
aka something like from 1.6% to 1.2%. It's quite strange why something
that (probably) looks up symbols, is so persistent in runtime
benchmarks. Dalias didn't had explanation, other than me having
LD_PRELOAD nasty (I didn't see any).
(the function shows in both mp3lib and mpg123).

-there is a memcpy in glibc that takes most of the cache misses. I
wonder how I can make a nice percentage table of the functions that
call this memcpy().



Conclusion:
The speed slowdown may be caused by something as simple as moving
variables and buffers around.
III_dequantize_sample() seems like the function that needs most love.
And it seems to be the core function. It have a lot of cache misses
and a lot of branch misses. All things that older cpu are quite bad at
;)

Best Regards.

From auerswal at unix-ag.uni-kl.de  Tue Sep 27 09:21:48 2011
From: auerswal at unix-ag.uni-kl.de (Erik Auerswald)
Date: Tue, 27 Sep 2011 09:21:48 +0200
Subject: [MPlayer-dev-eng] [RFC PATCH] Default to subtitle
	visibility	off (was Re: Question for dev's: Does mplayer
	disable DPMS timeouts?	"xset q" looks good,
	but timeouts never trigger)
In-Reply-To: <20110926181511.GB2399@1und1.de>
References: <20110906201622.GA3206@1und1.de> <4E66833D.5050208@tedpavlic.com>
	<20110907083001.GA32239@sushi.unix-ag.uni-kl.de>
	<20110907104723.GA9561@phare.normalesup.org>
	<92D71C59-FBFC-4F18-A3A1-BDF863427879@gmx.de>
	<20110908201516.GB21744@sushi.unix-ag.uni-kl.de>
	<4E6A6EDA.8080200@unix-ag.uni-kl.de>
	<4E75E951.8000800@unix-ag.uni-kl.de>
	<4E7FA7A4.6060701@unix-ag.uni-kl.de>
	<20110926181511.GB2399@1und1.de>
Message-ID: <20110927072148.GA9599@sushi.unix-ag.uni-kl.de>

Hi,

On Mon, Sep 26, 2011 at 08:15:11PM +0200, Reimar D?ffinger wrote:
> On Mon, Sep 26, 2011 at 12:13:56AM +0200, Erik Auerswald wrote:
> > Ping again,
> > 
> > On 09/18/2011 02:51 PM, Erik Auerswald wrote:
> > >no comments regarding the small patch that hides subtitles unless the
> > >subtitle selection code actually selects a subtitle stream?
> > >
> > >On 09/09/2011 09:54 PM, Erik Auerswald wrote:
> > >>[...]
> > >>The attached patch (actually tested) is a definite improvement for me.
> > >>When specifying -slang XX or having a suitably named .srt file lying
> > >>near a movie, subtitles are displayed. But the mere presence of
> > >>subtitles on a DVD does not result in displaying them automatically.
> > >>
> > >>Please consider applying.
> > >
> > >The patch still applies cleanly.
> > 
> > It still does.
> > 
> > The change in behavior is practically just hiding subtitles on DVD
> > unless a subtitle language is specified. In all other cases (MPlayer
> > finds some subtitles, e.g. because of command line or file name)
> > they are still displayed.
> > 
> > ACK/NAK/Timeout?
> 
> I am not sure what exactly sub_visibility does, but it does not cause
> the same behaviour as using -nosub or similar so I am rather sceptical
> to it.

Well, it is bound to the 'v' key by default, which toggles it. I have
not yet observed breakage using this functionality. It can be set via
slave commands as well.

> In particular I think it causes the subtitle to be demuxed, which

I'd say it does not prevent subtitles from being demuxed.

> in some cases (which you could cause bugs) has a chance of causing
> playback issues over slow/non-seekable connections like a stream or
> http.

Can you point to a test case?

The sub_visibility variable is not used very often, so it should be
possible to estimate its effects for someone familiar with the subtitle
subsystem(s) of MPlayer:

mplayer$ fgrep -r sub_visibility . | wc -l
20
mplayer$ fgrep -lr sub_visibility .
./DOCS/tech/slave.txt
./DOCS/xml/es/usage.xml
./gui/win32/gui.c
./etc/menu.conf
./sub/sub.c
./sub/ass_mp.c
./sub/sub.h
./input/input.c
./command.c

Anyway, I don't expect any problems from changing the default starting
value of sub_visibility.

Thanks,
Erik
-- 
My life's project is to hunt down the guy who invented mail client
wordwrapping, set him on fire then dance on his ashes.
                        -- Andrew Morton

From sfsheldo at gmail.com  Tue Sep 27 18:44:01 2011
From: sfsheldo at gmail.com (Stephen Sheldon)
Date: Tue, 27 Sep 2011 09:44:01 -0700
Subject: [MPlayer-dev-eng] [PATCH] Windows GUI does not work in idle mode
Message-ID: <4E81FD51.8020004@gmail.com>

The Windows gui does not work in idle mode (-idle) with mingw64
and cygwin.  It only seems to work with ming32.  On mingw64 and cygwin,
if you play a file, and then attempt to play a second file, gmplayer
aborts.  The cause is a double free because of the code in win32/interface.c
about line 605.  I also changed the code about line 466 because I did
not see how that could possibly work.  Setting the global pointer "filename"
multiple times leads to memory leaks, so I changed assignments and
strdups to setdup.  This required changing a reference to "filename" in
guiPlayListInitialize to a local variable.


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mplayer.patch3
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110927/a3e6244e/attachment.ksh>

From ib at wupperonline.de  Tue Sep 27 23:29:31 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 27 Sep 2011 23:29:31 +0200
Subject: [MPlayer-dev-eng] [PATCH] Windows GUI does not work in idle mode
In-Reply-To: <4E81FD51.8020004@gmail.com>
Message-ID: <4e824375.12babb30.bm000@wupperonline.de>

Stephen Sheldon wrote on Tue, 27 Sep 2011 09:44:01 -0700:

> The Windows gui does not work in idle mode (-idle) with mingw64
> and cygwin.  It only seems to work with ming32.

That is strange. Why would there be a difference?

> The cause is [...]

Unfortunately, the Win32 and X11/GTK GUIs differ, but guiInfo.Filename and
global variable filename handling is the same. While guiInfo.Filename is
allocated, filename isn't.

> I also changed the code about line 466 because I did not see how that could
> possibly work.

I think already the old code is pointless at all, because guiInfo.Filename
must be set and "passed" to MPlayer using global variable filename.

Here is a revised version of your patch. Please test with and without idle
mode and with and without playlists (both explicit ones by loading through
the GUI playlist button and implicit ones by passing on the command line
which should cause the GUI to run immediately - even mixing files and
-playlist options ought to work).

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32.interface.patch
Type: text/x-diff
Size: 1165 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110927/3d549428/attachment.bin>

From sfsheldo at gmail.com  Wed Sep 28 01:02:13 2011
From: sfsheldo at gmail.com (Stephen Sheldon)
Date: Tue, 27 Sep 2011 16:02:13 -0700
Subject: [MPlayer-dev-eng] [PATCH] Windows GUI does not work in idle mode
In-Reply-To: <4e824375.12babb30.bm000@wupperonline.de>
References: <4e824375.12babb30.bm000@wupperonline.de>
Message-ID: <4E8255F5.3020700@gmail.com>

On 9/27/2011 2:29 PM, Ingo Br?ckl wrote:
> Stephen Sheldon wrote on Tue, 27 Sep 2011 09:44:01 -0700:
>
>> The Windows gui does not work in idle mode (-idle) with mingw64
>> and cygwin.  It only seems to work with ming32.
> That is strange. Why would there be a difference?
Different heap implementations.  The better ones will complain about 
bogus pointers being passed to free.
Remember that was what started me down this path to get the Windows GUI 
to work on mingw64.
>> The cause is [...]
> Unfortunately, the Win32 and X11/GTK GUIs differ, but guiInfo.Filename and
> global variable filename handling is the same. While guiInfo.Filename is
> allocated, filename isn't.
>
I tried to apply your patch and compile, but unfortunately uiCurr does 
not exist in the Windows GUI
implementation.  I did a cut and paste, but uiCurr has stuff named "gtk" 
and there is no uiEventHandling
in the Windows GUI.  I need to do more research.

From thomas-forum at orgis.org  Wed Sep 28 08:48:00 2011
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Wed, 28 Sep 2011 08:48:00 +0200
Subject: [MPlayer-dev-eng] [PATCH] remove mp3lib
In-Reply-To: <CABA=pqcnEnUnvVQhMVYndyv2x_-UJ2ErQUqf+-=2pdNbvjVNng@mail.gmail.com>
References: <20110920181954.GA32134@1und1.de>
	<CABA=pqd8FMQsrvMiZ8+D2QiD46mRKqjzosLkRPwm6GsrznUOQA@mail.gmail.com>
	<20110923082832.24bf7c60@orgis.org>
	<CABA=pqde20OOqS_Pa22i359Av9z7a4KEomahHAUO+Ub0RgOPyQ@mail.gmail.com>
	<20110923162420.207f190a@orgis.org>
	<20110923231429.40fca988@orgis.org>
	<CABA=pqcnEnUnvVQhMVYndyv2x_-UJ2ErQUqf+-=2pdNbvjVNng@mail.gmail.com>
Message-ID: <20110928084800.78dc91ac@orgis.org>

Am Tue, 27 Sep 2011 04:39:12 +0300
schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 

> It took me quite a lot of time, but I hope there will be useful
> information in the data I provide.
> If you need the raw perf.data files, I can send them to you.

Thanks! Now it's my turn to allocate a time slot to digest this and try
to fix the mpg123 binding. 

> - increasing alignment (of most big arrays) actually made mp3lib a
> percent or 2 slower... so I dropped this road.

Well, OK, this helped for more modern CPUs. Hm, was about to wonder if
this makes mpg123 generally slower as it might overalign stuff for your
case, but we're talking about the big hit compared to standalone mpg123.

> Cache misses are 2 times more for the mpg123 case and I think this is
> what affects the instructions per cycle ratio. 

I'll focus on that...

> -there is a memcpy in glibc that takes most of the cache misses. I
> wonder how I can make a nice percentage table of the functions that
> call this memcpy().

Well, memcpy() is involved in copying over data from MPlayer. That we
waste cycles in that is not new, but the impact is the question.
But internally in mpg123, there are also copies between input stream
buffer and frame handle.

It might be that just cutting down on the copying of memory could do
it. But it's non-trivial to eliminate it all.

> III_dequantize_sample() seems like the function that needs most love.
> And it seems to be the core function. It have a lot of cache misses
> and a lot of branch misses. All things that older cpu are quite bad at
> ;)

Well, this function does the huffman decoding from the frame buffer.
There's reading some bytes (bits, even), computing/looking at table, and
writing some to another location. But not memcpy() of buffer blocks.
So the memory blocks it correlates (reads/writes on intermittendly) are
further apart in the MPlayer case?

Important point is that this is not one of the assembly-optimized
functions.


Alrighty then,

Thomas.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110928/0199596c/attachment.asc>

From diego at biurrun.de  Wed Sep 28 12:09:55 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Wed, 28 Sep 2011 12:09:55 +0200
Subject: [MPlayer-dev-eng] [patch] fix SPDIF output on Mac
In-Reply-To: <20110912214554.GB4549@pool.informatik.rwth-aachen.de>
References: <loom.20110822T054102-115@post.gmane.org>
	<20110912214554.GB4549@pool.informatik.rwth-aachen.de>
Message-ID: <20110928100955.GA12311@pool.informatik.rwth-aachen.de>

On Mon, Sep 12, 2011 at 11:45:56PM +0200, Diego Biurrun wrote:
> On Mon, Aug 22, 2011 at 03:49:47AM +0000, Zongyao Qu wrote:
> > 
> > Recently, I made a fix for Mac users on Mac OS X 10.7.
> > 
> > I didn't test it myself, 
> > but my users told me that this fixed the SPDIF output problem.
> > 
> > I think I should share it, so other Mac mplayer users will be 
> > happy with it.
> > 
> > I was told the line width is limited to 80 chars.
> > so please refer to the link below to review the patch.
> > 
> > https://www.gitorious.org/mplayer-for-mplayerx/
> > mplayer/commit/b41d5d28fe2b2087e94e2facd035efb79dc0e93b
> 
> Please eliminate the tabs and just send your patch here.
> git-send-email will do, as will attaching the patch to an email.
> 
> I was told at videolan dev days that this indeed fix problems
> for some people, so the patch is desirable.  Would be great if
> somebody could test it.  Do you know if it keeps older systems
> in working order?

I have attached the (whitespace-cleaned-up) patch here for reference.
If somebody with a Mac could test or at least compile it, that would
be much appreciated.  Otherwise I think I will apply it blind in a
few days...

Diego
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ao_coreaudio-Fix-spdif-output-for-OS-X-10.7.patch
Type: text/x-diff
Size: 9109 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110928/ebb81eee/attachment.bin>

From ib at wupperonline.de  Wed Sep 28 14:22:56 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 28 Sep 2011 14:22:56 +0200
Subject: [MPlayer-dev-eng] [PATCH] Windows GUI does not work in idle mode
In-Reply-To: <4E8255F5.3020700@gmail.com>
Message-ID: <4e8311a3.1e60fb5a.bm000@wupperonline.de>

Stephen Sheldon wrote on Tue, 27 Sep 2011 16:02:13 -0700:

> I tried to apply your patch and compile, but unfortunately uiCurr does
> not exist in the Windows GUI implementation.

My mistake. Please try this one.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32.interface.patch
Type: text/x-diff
Size: 1228 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110928/57bcb4c8/attachment.bin>

From sfsheldo at gmail.com  Wed Sep 28 17:38:23 2011
From: sfsheldo at gmail.com (Stephen Sheldon)
Date: Wed, 28 Sep 2011 08:38:23 -0700
Subject: [MPlayer-dev-eng] [PATCH] Windows GUI does not work in idle mode
In-Reply-To: <4e8311a3.1e60fb5a.bm000@wupperonline.de>
References: <4e8311a3.1e60fb5a.bm000@wupperonline.de>
Message-ID: <4E833F6F.7090307@gmail.com>

Your last patch works for me, both with and without idle mode and with 
playlist in a file and on the command line.
Thank you.  Shall I send a patch to make idle mode the default in the 
windows gui as it is in gtk?

From ib at wupperonline.de  Wed Sep 28 18:02:05 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 28 Sep 2011 18:02:05 +0200
Subject: [MPlayer-dev-eng] [PATCH] Windows GUI does not work in idle mode
In-Reply-To: <4E833F6F.7090307@gmail.com>
Message-ID: <4e834502.17eccadf.bm000@wupperonline.de>

Stephen Sheldon wrote on Wed, 28 Sep 2011 08:38:23 -0700:

> Your last patch works for me, both with and without idle mode and with
> playlist in a file and on the command line.

Great.

> Shall I send a patch to make idle mode the default in the windows gui as it
> is in gtk?

Yes, please.

BTW, you pointed out something that goes farther than being only a filename
problem in the Win32 GUI. There will be some more changes to come (in X11/GTK
and I'll try to port to Win32), so please stay tuned and be ready for
testing.

Ingo

From ib at wupperonline.de  Wed Sep 28 18:03:44 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 28 Sep 2011 18:03:44 +0200
Subject: [MPlayer-dev-eng] [PATCH] Allow GUI to use filename related config
Message-ID: <4e834604.6fa0a862.bm000@wupperonline.de>

I know we hate that, but we need it.

The GUI provides MPlayer with the respective (next) filename to play.
playtree_iter is always NULL in connection with the GUI, so MPlayer
must not clear the filename, or else filename related config like
load_per_protocol_config(), load_per_extension_config() or
load_per_file_config() won't work.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mplayer.patch
Type: text/x-diff
Size: 466 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110928/c0a1063d/attachment.bin>

From hermi.hg at gmail.com  Wed Sep 28 18:36:10 2011
From: hermi.hg at gmail.com (Hermi Mercury)
Date: Wed, 28 Sep 2011 09:36:10 -0700
Subject: [MPlayer-dev-eng] [patch] fix SPDIF output on Mac
In-Reply-To: <20110928100955.GA12311@pool.informatik.rwth-aachen.de>
References: <loom.20110822T054102-115@post.gmane.org>
	<20110912214554.GB4549@pool.informatik.rwth-aachen.de>
	<20110928100955.GA12311@pool.informatik.rwth-aachen.de>
Message-ID: <CADqZJLsaaS556HRrQ_OhUkJLBTFgMREM0MYkc-d4F5f4tkrRXw@mail.gmail.com>

2011/9/28 Diego Biurrun <diego at biurrun.de>

> On Mon, Sep 12, 2011 at 11:45:56PM +0200, Diego Biurrun wrote:
> > On Mon, Aug 22, 2011 at 03:49:47AM +0000, Zongyao Qu wrote:
> > >
> > > Recently, I made a fix for Mac users on Mac OS X 10.7.
> > >
> > > I didn't test it myself,
> > > but my users told me that this fixed the SPDIF output problem.
> > >
> > > I think I should share it, so other Mac mplayer users will be
> > > happy with it.
> > >
> > > I was told the line width is limited to 80 chars.
> > > so please refer to the link below to review the patch.
> > >
> > > https://www.gitorious.org/mplayer-for-mplayerx/
> > > mplayer/commit/b41d5d28fe2b2087e94e2facd035efb79dc0e93b
> >
> > Please eliminate the tabs and just send your patch here.
> > git-send-email will do, as will attaching the patch to an email.
> >
> > I was told at videolan dev days that this indeed fix problems
> > for some people, so the patch is desirable.  Would be great if
> > somebody could test it.  Do you know if it keeps older systems
> > in working order?
>
> I have attached the (whitespace-cleaned-up) patch here for reference.
> If somebody with a Mac could test or at least compile it, that would
> be much appreciated.  Otherwise I think I will apply it blind in a
> few days...
>

I have tested this patch (applied to an mplayer2 branch), and it does indeed
work properly for both AC3 and DTS audio under OS X 10.7.1 and 10.6.7.
 Though there is a crash bug present when muting the S/PDIF stream.  I have
proposed a fix for the crash here: http://devel.mplayer2.org/ticket/112

- Hermi

From Reimar.Doeffinger at gmx.de  Wed Sep 28 19:07:04 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 28 Sep 2011 19:07:04 +0200
Subject: [MPlayer-dev-eng] [PATCH] Allow GUI to use filename related
 config
In-Reply-To: <4e834604.6fa0a862.bm000@wupperonline.de>
References: <4e834604.6fa0a862.bm000@wupperonline.de>
Message-ID: <20110928170704.GA2406@1und1.de>

On Wed, Sep 28, 2011 at 06:03:44PM +0200, Ingo Br?ckl wrote:
> I know we hate that, but we need it.
> 
> The GUI provides MPlayer with the respective (next) filename to play.
> playtree_iter is always NULL in connection with the GUI, so MPlayer
> must not clear the filename, or else filename related config like
> load_per_protocol_config(), load_per_extension_config() or
> load_per_file_config() won't work.
> 
> Ingo

> Index: mplayer.c
> ===================================================================
> --- mplayer.c	(revision 34144)
> +++ mplayer.c	(working copy)
> @@ -4059,8 +4059,10 @@
>          (use_gui && guiInfo.Playing) ||
>  #endif
>                                          mpctx->playtree_iter != NULL || player_idle_mode) {
> +#ifndef CONFIG_GUI
>          if (!mpctx->playtree_iter)
>              filename = NULL;
> +#endif

If that works you can just remove the code...
I expect you wanted to add a !use_gui really but obviously I'm no going
to ask you to find a test-case for that code...

From diego at biurrun.de  Wed Sep 28 19:20:43 2011
From: diego at biurrun.de (Diego Biurrun)
Date: Wed, 28 Sep 2011 19:20:43 +0200
Subject: [MPlayer-dev-eng] [patch] fix SPDIF output on Mac
In-Reply-To: <CADqZJLsaaS556HRrQ_OhUkJLBTFgMREM0MYkc-d4F5f4tkrRXw@mail.gmail.com>
References: <loom.20110822T054102-115@post.gmane.org>
	<20110912214554.GB4549@pool.informatik.rwth-aachen.de>
	<20110928100955.GA12311@pool.informatik.rwth-aachen.de>
	<CADqZJLsaaS556HRrQ_OhUkJLBTFgMREM0MYkc-d4F5f4tkrRXw@mail.gmail.com>
Message-ID: <20110928172043.GA31682@pool.informatik.rwth-aachen.de>

On Wed, Sep 28, 2011 at 09:36:10AM -0700, Hermi Mercury wrote:
> 2011/9/28 Diego Biurrun <diego at biurrun.de>
> 
> > On Mon, Sep 12, 2011 at 11:45:56PM +0200, Diego Biurrun wrote:
> > > On Mon, Aug 22, 2011 at 03:49:47AM +0000, Zongyao Qu wrote:
> > > >
> > > > Recently, I made a fix for Mac users on Mac OS X 10.7.
> > > >
> > > > I didn't test it myself,
> > > > but my users told me that this fixed the SPDIF output problem.
> > > >
> > > > I think I should share it, so other Mac mplayer users will be
> > > > happy with it.
> > > >
> > > > I was told the line width is limited to 80 chars.
> > > > so please refer to the link below to review the patch.
> > > >
> > > > https://www.gitorious.org/mplayer-for-mplayerx/
> > > > mplayer/commit/b41d5d28fe2b2087e94e2facd035efb79dc0e93b
> > >
> > > Please eliminate the tabs and just send your patch here.
> > > git-send-email will do, as will attaching the patch to an email.
> > >
> > > I was told at videolan dev days that this indeed fix problems
> > > for some people, so the patch is desirable.  Would be great if
> > > somebody could test it.  Do you know if it keeps older systems
> > > in working order?
> >
> > I have attached the (whitespace-cleaned-up) patch here for reference.
> > If somebody with a Mac could test or at least compile it, that would
> > be much appreciated.  Otherwise I think I will apply it blind in a
> > few days...
> 
> I have tested this patch (applied to an mplayer2 branch), and it does indeed
> work properly for both AC3 and DTS audio under OS X 10.7.1 and 10.6.7.

Thanks for the testing, patch applied.

>  Though there is a crash bug present when muting the S/PDIF stream.  I have
> proposed a fix for the crash here: http://devel.mplayer2.org/ticket/112

Please let me know when this is committed to mplayer2, I'll apply then.

Diego

From ib at wupperonline.de  Wed Sep 28 19:34:44 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 28 Sep 2011 19:34:44 +0200
Subject: [MPlayer-dev-eng] [PATCH] Allow GUI to use filename related
	config
In-Reply-To: <20110928170704.GA2406@1und1.de>
Message-ID: <4e835dd0.4ccedb5e.bm000@wupperonline.de>

Reimar D?ffinger wrote on Wed, 28 Sep 2011 19:07:04 +0200:

> On Wed, Sep 28, 2011 at 06:03:44PM +0200, Ingo Br?ckl wrote:
>> I know we hate that, but we need it.
>>
>> The GUI provides MPlayer with the respective (next) filename to play.
>> playtree_iter is always NULL in connection with the GUI, so MPlayer
>> must not clear the filename, or else filename related config like
>> load_per_protocol_config(), load_per_extension_config() or
>> load_per_file_config() won't work.
>>
>> Ingo

>> Index: mplayer.c
>> ===================================================================
>> --- mplayer.c (revision 34144)
>> +++ mplayer.c (working copy)
>> @@ -4059,8 +4059,10 @@
>>          (use_gui && guiInfo.Playing) ||
>>  #endif
>>                                          mpctx->playtree_iter != NULL || player_idle_mode) {
>> +#ifndef CONFIG_GUI
>>          if (!mpctx->playtree_iter)
>>              filename = NULL;
>> +#endif

> If that works you can just remove the code...
> I expect you wanted to add a !use_gui really

Oops! You are right. It should be:

  if (!mpctx->playtree_iter && !use_gui)
      filename = NULL;

> but obviously I'm no going to ask you to find a test-case for that code...

Which one? The #ifndef or the correct one?

The patch enables gmplayer with a -playlist to get the per file configs
(after I've fixed a few things in the GUI).

Ingo

From Reimar.Doeffinger at gmx.de  Wed Sep 28 20:37:16 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 28 Sep 2011 20:37:16 +0200
Subject: [MPlayer-dev-eng] [patch] fix SPDIF output on Mac
In-Reply-To: <CADqZJLsaaS556HRrQ_OhUkJLBTFgMREM0MYkc-d4F5f4tkrRXw@mail.gmail.com>
References: <loom.20110822T054102-115@post.gmane.org>
	<20110912214554.GB4549@pool.informatik.rwth-aachen.de>
	<20110928100955.GA12311@pool.informatik.rwth-aachen.de>
	<CADqZJLsaaS556HRrQ_OhUkJLBTFgMREM0MYkc-d4F5f4tkrRXw@mail.gmail.com>
Message-ID: <20110928183716.GA2964@1und1.de>

On Wed, Sep 28, 2011 at 09:36:10AM -0700, Hermi Mercury wrote:
> 2011/9/28 Diego Biurrun <diego at biurrun.de>
> 
> > On Mon, Sep 12, 2011 at 11:45:56PM +0200, Diego Biurrun wrote:
> > > On Mon, Aug 22, 2011 at 03:49:47AM +0000, Zongyao Qu wrote:
> > > >
> > > > Recently, I made a fix for Mac users on Mac OS X 10.7.
> > > >
> > > > I didn't test it myself,
> > > > but my users told me that this fixed the SPDIF output problem.
> > > >
> > > > I think I should share it, so other Mac mplayer users will be
> > > > happy with it.
> > > >
> > > > I was told the line width is limited to 80 chars.
> > > > so please refer to the link below to review the patch.
> > > >
> > > > https://www.gitorious.org/mplayer-for-mplayerx/
> > > > mplayer/commit/b41d5d28fe2b2087e94e2facd035efb79dc0e93b
> > >
> > > Please eliminate the tabs and just send your patch here.
> > > git-send-email will do, as will attaching the patch to an email.
> > >
> > > I was told at videolan dev days that this indeed fix problems
> > > for some people, so the patch is desirable.  Would be great if
> > > somebody could test it.  Do you know if it keeps older systems
> > > in working order?
> >
> > I have attached the (whitespace-cleaned-up) patch here for reference.
> > If somebody with a Mac could test or at least compile it, that would
> > be much appreciated.  Otherwise I think I will apply it blind in a
> > few days...
> >
> 
> I have tested this patch (applied to an mplayer2 branch), and it does indeed
> work properly for both AC3 and DTS audio under OS X 10.7.1 and 10.6.7.
>  Though there is a crash bug present when muting the S/PDIF stream.  I have
> proposed a fix for the crash here: http://devel.mplayer2.org/ticket/112

That seems overcomplicated, why not just:
Index: ao_coreaudio.c
===================================================================
--- ao_coreaudio.c      (revision 34128)
+++ ao_coreaudio.c      (working copy)
@@ -133,7 +133,10 @@
 static int read_buffer(unsigned char* data,int len){
   int buffered = av_fifo_size(ao->buffer);
   if (len > buffered) len = buffered;
+  if (data)
   av_fifo_generic_read(ao->buffer, data, len, NULL);
+  else
+    av_fifo_drain(ao->buffer, len);
   return len;
 }
 


From Reimar.Doeffinger at gmx.de  Wed Sep 28 20:38:20 2011
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 28 Sep 2011 20:38:20 +0200
Subject: [MPlayer-dev-eng] [PATCH] Allow GUI to use filename related
 config
In-Reply-To: <4e835dd0.4ccedb5e.bm000@wupperonline.de>
References: <20110928170704.GA2406@1und1.de>
	<4e835dd0.4ccedb5e.bm000@wupperonline.de>
Message-ID: <20110928183820.GB2964@1und1.de>

On Wed, Sep 28, 2011 at 07:34:44PM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Wed, 28 Sep 2011 19:07:04 +0200:
> 
> > On Wed, Sep 28, 2011 at 06:03:44PM +0200, Ingo Br?ckl wrote:
> >> I know we hate that, but we need it.
> >>
> >> The GUI provides MPlayer with the respective (next) filename to play.
> >> playtree_iter is always NULL in connection with the GUI, so MPlayer
> >> must not clear the filename, or else filename related config like
> >> load_per_protocol_config(), load_per_extension_config() or
> >> load_per_file_config() won't work.
> >>
> >> Ingo
> 
> >> Index: mplayer.c
> >> ===================================================================
> >> --- mplayer.c (revision 34144)
> >> +++ mplayer.c (working copy)
> >> @@ -4059,8 +4059,10 @@
> >>          (use_gui && guiInfo.Playing) ||
> >>  #endif
> >>                                          mpctx->playtree_iter != NULL || player_idle_mode) {
> >> +#ifndef CONFIG_GUI
> >>          if (!mpctx->playtree_iter)
> >>              filename = NULL;
> >> +#endif
> 
> > If that works you can just remove the code...
> > I expect you wanted to add a !use_gui really
> 
> Oops! You are right. It should be:
> 
>   if (!mpctx->playtree_iter && !use_gui)
>       filename = NULL;
> 
> > but obviously I'm no going to ask you to find a test-case for that code...
> 
> Which one? The #ifndef or the correct one?

For the code you are changing.
Something that shows it has a purpose and the change you make does not
break it, with or without GUI.

From ib at wupperonline.de  Wed Sep 28 22:11:14 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 28 Sep 2011 22:11:14 +0200
Subject: [MPlayer-dev-eng] [PATCH] Allow GUI to use filename related
	config
In-Reply-To: <20110928183820.GB2964@1und1.de>
Message-ID: <4e838074.133fe04c.bm000@wupperonline.de>

Reimar D?ffinger wrote on Wed, 28 Sep 2011 20:38:20 +0200:

>> > but obviously I'm no going to ask you to find a test-case for that code...
>>
>> Which one? The #ifndef or the correct one?

> For the code you are changing.
> Something that shows it has a purpose and the change you make does not
> break it, with or without GUI.

Sorry, I don't get it.

The purpose of the code I'm changing? I'm sure you know better than I do...
Well, if MPlayer is started in idle mode and has played all files, it frees
mpctx->playtree_iter, NULLs filename and goes in its wait-for-command mode.
filename == NULL triggers this (line 3078).

In case of the GUI there never is a mpctx->playtree_iter (the GUI has its
own playlist), thus filename gets NULLed for every file in a list. At label
play_next_file, the file related configs will be read for a filename != NULL
only, i.e. never in case of the GUI.

Without GUI it can't break anything, because !use_gui is true, i.e. the
condition doesn't really change. With GUI, filename now doesn't get NULLed
(the GUI is setting the filename for MPlayer) and thus the file related
configs can be read at play_next_file.

BTW, there seems to be an issue with pure MPlayer. When continuing from
wait-for-command mode for a file playback, the file related configs won't
be read. filename is set in line 3134, but no load_per_xxx_config() there.

Ingo

From hermi.hg at gmail.com  Wed Sep 28 22:26:10 2011
From: hermi.hg at gmail.com (Hermi Mercury)
Date: Wed, 28 Sep 2011 13:26:10 -0700
Subject: [MPlayer-dev-eng] [patch] fix SPDIF output on Mac
In-Reply-To: <20110928183716.GA2964@1und1.de>
References: <loom.20110822T054102-115@post.gmane.org>
	<20110912214554.GB4549@pool.informatik.rwth-aachen.de>
	<20110928100955.GA12311@pool.informatik.rwth-aachen.de>
	<CADqZJLsaaS556HRrQ_OhUkJLBTFgMREM0MYkc-d4F5f4tkrRXw@mail.gmail.com>
	<20110928183716.GA2964@1und1.de>
Message-ID: <CADqZJLsn+pab2M15gkGmwrnff0haETyHxtansUJAmvOq9XhZrg@mail.gmail.com>

> That seems overcomplicated, why not just:
> Index: ao_coreaudio.c
> ===================================================================
> --- ao_coreaudio.c      (revision 34128)
> +++ ao_coreaudio.c      (working copy)
> @@ -133,7 +133,10 @@
>  static int read_buffer(unsigned char* data,int len){
>   int buffered = av_fifo_size(ao->buffer);
>   if (len > buffered) len = buffered;
> +  if (data)
>   av_fifo_generic_read(ao->buffer, data, len, NULL);
> +  else
> +    av_fifo_drain(ao->buffer, len);
>   return len;
>  }
>

This shorter patch works.  I thought this might cause a problem if
attempting to remove too much from the buffer, but I haven't encountered it.

From ib at wupperonline.de  Thu Sep 29 01:25:13 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 29 Sep 2011 01:25:13 +0200
Subject: [MPlayer-dev-eng] load_per_xxx_config() issue
Message-ID: <4e83ae78.6ca534e7.bm000@wupperonline.de>

Is this considered to be ok or a bug?

  $ mplayer test.mp3
  MPlayer SVN-r34149-4.3.4 (C) 2000-2011 MPlayer Team
  Loading extension-related profile 'extension.mp3'

  Playing test.mp3.

Extension-related profile is loaded.

  $ mplayer -slave -idle
  MPlayer SVN-r34149-4.3.4 (C) 2000-2011 MPlayer Team
  load test.mp3

  Playing test.mp3.

Extension-related profile isn't loaded.

Ingo

From ib at wupperonline.de  Thu Sep 29 13:14:02 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 29 Sep 2011 13:14:02 +0200
Subject: [MPlayer-dev-eng] Win32 GUI enqueue patch
Message-ID: <4e8454fb.3739665d.bm000@wupperonline.de>

Stephen,

could you please check out this patch?

While

  gmplayer file

should start playing "file",

  gmplayer -enqueue file

should start, but not play. You'll find "file" in the GUI's playlist instead.
It plays after pressing the play button.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: win32.enqueue.patch
Type: text/x-diff
Size: 387 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110929/ef6478ce/attachment.bin>

From ib at wupperonline.de  Thu Sep 29 14:10:42 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 29 Sep 2011 14:10:42 +0200
Subject: [MPlayer-dev-eng] Playlist recognition
In-Reply-To: <20110605121642.GA4204@1und1.de>
Message-ID: <4e8460f9.2d37a145.bm000@wupperonline.de>

Reimar D?ffinger wrote on Sun, 5 Jun 2011 14:16:42 +0200:

> On Sun, Jun 05, 2011 at 02:02:18PM +0200, Ingo Br?ckl wrote:
>> Is there a special reason for commenting
>>
>>   //        { "pls", DEMUXER_TYPE_PLAYLIST },
>>   //        { "m3u", DEMUXER_TYPE_PLAYLIST },
>>
>> in libmpdemux\extension.c?

> Yes, playlists can be used for all kinds of mischief ("pinging" a
> certain website for user tracking, trying to play certain /dev
> things and combining with that to detect what kind of hardware
> is installed in a PC, if there is a DVD in the driver, maybe even
> other things - anything that can be triggered by reading/trying to play
> an arbitrary file and being able to time that) and thus should not
> be enable without user consent, at least when the playlist comes
> from an untrusted source.

I see. But why are MOV reference files allowed then?

Ingo

From ib at wupperonline.de  Thu Sep 29 16:08:25 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Thu, 29 Sep 2011 16:08:25 +0200
Subject: [MPlayer-dev-eng] [PATCH] Windows GUI does not work in idle mode
In-Reply-To: <4E833F6F.7090307@gmail.com>
Message-ID: <4e847cf0.7b567730.bm000@wupperonline.de>

Stephen,

could you please test again with a recent svn checkout? There were some
changes concerning this issue.

Ingo

From ib at wupperonline.de  Fri Sep 30 17:50:16 2011
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 30 Sep 2011 17:50:16 +0200
Subject: [MPlayer-dev-eng] load_per_xxx_config() issue
In-Reply-To: <4e83ae78.6ca534e7.bm000@wupperonline.de>
Message-ID: <4e85e594.48c8acc9.bm000@wupperonline.de>

I wrote on Thu, 29 Sep 2011 01:25:13 +0200:

> Is this considered to be ok or a bug?

>   $ mplayer test.mp3
>   MPlayer SVN-r34149-4.3.4 (C) 2000-2011 MPlayer Team
>   Loading extension-related profile 'extension.mp3'

>   Playing test.mp3.

> Extension-related profile is loaded.

>   $ mplayer -slave -idle
>   MPlayer SVN-r34149-4.3.4 (C) 2000-2011 MPlayer Team
>   load test.mp3

>   Playing test.mp3.

> Extension-related profile isn't loaded.

Well, if not ok, this patch could fix it.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: profile_config.patch
Type: text/x-diff
Size: 1662 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20110930/ccd90400/attachment.bin>

From srilatha.addanki at vayavyalabs.com  Fri Sep 30 09:11:55 2011
From: srilatha.addanki at vayavyalabs.com (Srilatha Addanki)
Date: Fri, 30 Sep 2011 07:11:55 -0000
Subject: [MPlayer-dev-eng] error: unknown option `ff-only' while configuring
	mplayer
Message-ID: <CAMt=raVmxVSx95xqk04T_fBdhAfKR7jXGM2+Oz1zHDHEgXx0eg@mail.gmail.com>

Hi all,

I got mplayer source code from svn using *svn checkout svn://
svn.mplayerhq.hu/mplayer/trunk mplayer *and i am trying to build mplayer for
arm board so trying to configure.

Tried with just ./configure and also with few options relevant to arm target
board, in both ways of configuring i am getting the  unknown option
`ff-only' error and the total error message is:

./configure
*error: unknown option `ff-only'*
*usage: git fetch [options] [<repository> <refspec>...]*
*
*
*    -v, --verbose         be more verbose*
*    -q, --quiet           be more quiet*
*    -a, --append          append to .git/FETCH_HEAD instead of overwriting*
*    --upload-pack <PATH>  path to upload pack on remote end*
*    -f, --force           force overwrite of local branch*
*    -t, --tags            fetch all tags and associated objects*
*    -n                    do not fetch all tags (--no-tags)*
*    -k, --keep            keep downloaded pack*
*    -u, --update-head-ok  allow updating of HEAD ref*
*    --depth <DEPTH>       deepen history of shallow clone*
*
*
*git pull failed, (re)move ffmpeg/mp_auto_pull to disable pulling*

I tried to google and find out solution if any, but did not find any
solution. If any one knows why i am getting this error and what needs to be
done to come out of this error, Please suggest me.

Thanks.
Srilatha.