From ffplay99 at gmail.com  Tue May  1 10:16:22 2012
From: ffplay99 at gmail.com (Jon Doe)
Date: Tue, 1 May 2012 10:16:22 +0200
Subject: [MPlayer-dev-eng] [PATCH] Fix regression in v4l2 channel tuning on
	cx88 cards
Message-ID: <CAHJnY44T5x9==cAwWvHM8OcW6Ojs6qnEGRSMkVYWCSuWBuwy-Q@mail.gmail.com>

Hi,

This patch tries to improve (not completely fix) a v4l regression from
svn r27057 which introduced per channel resetting of v4l2 normids when
tuning channels. The relevant bug report can be found at
http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1326. I tested on cx88
and bt878 based cards. Only the cx88 is affected.

The problem is that cx88 based cards will reset the picture size to
320x240 when changing norms, squashing the picture to a quarter size
in the top left corner when changing channels in mplayer. The cx8800
driver needs to reset the picture size due to a hardware filter
recalculation requirement when changing norms. Others have also
noticed this problem in the driver, but no comprehensive fix was found
- see http://www.mail-archive.com/linux-media at vger.kernel.org/msg00157.html

The fix proposed is to only change the norm if the new channel norm
(eg. NTSC) differs from the current norm (eg. PAL-I), as specified in
the user config file. This should at least work for most people most
of the time and speed up channel tuning at the same time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: normid.patch
Type: application/octet-stream
Size: 2737 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120501/25fa81da/attachment.obj>

From ikalvachev at gmail.com  Wed May  2 23:22:52 2012
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Thu, 3 May 2012 00:22:52 +0300
Subject: [MPlayer-dev-eng] [PATCH] fix mpg123 resync (for massive
	seeking)
In-Reply-To: <20120430111817.24f770e7@orgis.org>
References: <20120430111817.24f770e7@orgis.org>
Message-ID: <CABA=pqeYJHiy6sn1GF9dqSa2OBW4_ppxQY4S6mHhLxuukeHKdw@mail.gmail.com>

On 4/30/12, Thomas Orgis <thomas-forum at orgis.org> wrote:
> Hi,
>
> Ivan noticed that, on some files, wild seeking can provoke hangup of
> the mpg123 decoder. I tracked that down to mpg123_getformat()
> triggering premature parsing of the next frame which may have not
> been provided yet. I fixed the offending code in mpg123 for the upcoming
> release and also prepared attached patch that prevents this from the
> mplayer side.
>
> As a bonus, it actually simplifies the code by avoiding unnecessary
> calls to mpg123_getformat() --- 12 lines less, yay! ;-)
>
> Please test (Ivan with the special trigger video) and apply.

Patch committed.

The patch seems to work as advertised.
However sometimes I see some debug messages and parser errors. (no
audible artifacts or skips, it resumes normal play as it should)

We talked about the possibility of avi demuxer returning garbage,
that could confuse the mpg123 parser. In your investigation have you
found any clues if this might be true? Was mpg123_getformat() confused
by completely normal packages?

Is it possible that e.g. packets cut mp3 frames at strange places
(e.g. at half) and this causes the problems.

Best Regards

From thomas-forum at orgis.org  Thu May  3 08:30:02 2012
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Thu, 3 May 2012 08:30:02 +0200
Subject: [MPlayer-dev-eng] [PATCH] fix mpg123 resync (for massive
 seeking)
In-Reply-To: <CABA=pqeYJHiy6sn1GF9dqSa2OBW4_ppxQY4S6mHhLxuukeHKdw@mail.gmail.com>
References: <20120430111817.24f770e7@orgis.org>
	<CABA=pqeYJHiy6sn1GF9dqSa2OBW4_ppxQY4S6mHhLxuukeHKdw@mail.gmail.com>
Message-ID: <20120503083002.487936f3@orgis.org>

Am Thu, 3 May 2012 00:22:52 +0300
schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 

> However sometimes I see some debug messages and parser errors. (no
> audible artifacts or skips, it resumes normal play as it should)

Do you mean

	trying to decode obviously invalid header
	Note: missing %d bytes in bit reservoir for frame %li

? The first is a harmless message that trunk mg123 printed for a while,
but which is gone in released 1.14.0, the second just means that one
started decoding in the middle of the stream where a frame depends on
bits from previous frames and cannot be properly decoded if it's the
first in line.

> We talked about the possibility of avi demuxer returning garbage,
> that could confuse the mpg123 parser. In your investigation have you
> found any clues if this might be true? 

Not really, mpg123 1.14.0 was wholly silent with the test video.

> Was mpg123_getformat() confused
> by completely normal packages?

The confusion was not about the packages themselves, but about the
question if they were feed to the decoder when needed /
mpg123_getformat() expected more data without reason.

> Is it possible that e.g. packets cut mp3 frames at strange places
> (e.g. at half) and this causes the problems.

That would not matter to mpg123: You can feed it 1-byte blocks, if you
want. It is a full bitstream in, audio byte stream out decoder.

Now, what errors do you see? On which mpg123 version?


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/20120503/08b7e659/attachment.asc>

From ikalvachev at gmail.com  Thu May  3 14:58:51 2012
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Thu, 3 May 2012 15:58:51 +0300
Subject: [MPlayer-dev-eng] [PATCH] fix mpg123 resync (for massive
	seeking)
In-Reply-To: <20120503083002.487936f3@orgis.org>
References: <20120430111817.24f770e7@orgis.org>
	<CABA=pqeYJHiy6sn1GF9dqSa2OBW4_ppxQY4S6mHhLxuukeHKdw@mail.gmail.com>
	<20120503083002.487936f3@orgis.org>
Message-ID: <CABA=pqegQ=TqHTYSjQCLmR+yTOSHs+Y0dysDe_zwjDwqJGGh_w@mail.gmail.com>

On 5/3/12, Thomas Orgis <thomas-forum at orgis.org> wrote:
> Am Thu, 3 May 2012 00:22:52 +0300
> schrieb Ivan Kalvachev <ikalvachev at gmail.com>:
>
>> However sometimes I see some debug messages and parser errors. (no
>> audible artifacts or skips, it resumes normal play as it should)
>
> Do you mean
>
> 	trying to decode obviously invalid header
> 	Note: missing %d bytes in bit reservoir for frame %li
>
> ? The first is a harmless message that trunk mg123 printed for a while,
> but which is gone in released 1.14.0, the second just means that one
> started decoding in the middle of the stream where a frame depends on
> bits from previous frames and cannot be properly decoded if it's the
> first in line.
>
>> We talked about the possibility of avi demuxer returning garbage,
>> that could confuse the mpg123 parser. In your investigation have you
>> found any clues if this might be true?
>
> Not really, mpg123 1.14.0 was wholly silent with the test video.
>
>> Was mpg123_getformat() confused
>> by completely normal packages?
>
> The confusion was not about the packages themselves, but about the
> question if they were feed to the decoder when needed /
> mpg123_getformat() expected more data without reason.
>
>> Is it possible that e.g. packets cut mp3 frames at strange places
>> (e.g. at half) and this causes the problems.
>
> That would not matter to mpg123: You can feed it 1-byte blocks, if you
> want. It is a full bitstream in, audio byte stream out decoder.
>
> Now, what errors do you see? On which mpg123 version?

You got me, I'm with 1.13.8 version.
After all, I had to test the patch with "broken" mpg123 versions.

I was just curious and wanted more details. Thank you for detailed reply.

If I find any other problem, I'll inform you.

Best Regards.

From szo at szo.hu  Thu May  3 15:02:09 2012
From: szo at szo.hu (Szokovacs Robert)
Date: Thu, 03 May 2012 15:02:09 +0200
Subject: [MPlayer-dev-eng] A bit more liberal parsing of tags in .srt
	files?
In-Reply-To: <201204131835.10218.szo@szo.hu>
References: <5034955.XdKuXqR298@gollum> <20120413152051.GA13268@leki>
	<201204131835.10218.szo@szo.hu>
Message-ID: <445352568.oe8l1YNHge@gollum>

Ping?

From thomas-forum at orgis.org  Fri May  4 09:25:57 2012
From: thomas-forum at orgis.org (Thomas Orgis)
Date: Fri, 4 May 2012 09:25:57 +0200
Subject: [MPlayer-dev-eng] [PATCH] fix mpg123 resync (for massive
 seeking)
In-Reply-To: <CABA=pqegQ=TqHTYSjQCLmR+yTOSHs+Y0dysDe_zwjDwqJGGh_w@mail.gmail.com>
References: <20120430111817.24f770e7@orgis.org>
	<CABA=pqeYJHiy6sn1GF9dqSa2OBW4_ppxQY4S6mHhLxuukeHKdw@mail.gmail.com>
	<20120503083002.487936f3@orgis.org>
	<CABA=pqegQ=TqHTYSjQCLmR+yTOSHs+Y0dysDe_zwjDwqJGGh_w@mail.gmail.com>
Message-ID: <20120504092557.1320db16@orgis.org>

Am Thu, 3 May 2012 15:58:51 +0300
schrieb Ivan Kalvachev <ikalvachev at gmail.com>: 

> You got me, I'm with 1.13.8 version.
> After all, I had to test the patch with "broken" mpg123 versions.
> 
> I was just curious and wanted more details. Thank you for detailed reply.

Could you ease my mind and tell what messages you see with that
version? I cannot provoke any utterings with mpg123 1.13.8 and the test
video. It's always possible that you see something I didn't see yet
(well, of course I have seen every mpg123 message, but not in every
context).


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/20120504/668aa04f/attachment.asc>

From Reimar.Doeffinger at gmx.de  Sun May  6 13:15:02 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 6 May 2012 13:15:02 +0200
Subject: [MPlayer-dev-eng] release.sh script?
Message-ID: <20120506111502.GA21145@1und1.de>

Hello,
DOCS/tech/release-howto.txt mentions a release.sh script.
Does that actually exist/does someone have a copy of it?
I'm sure it would be quite outdated, but it wouldn't hurt to
have it as a starting point to make it easier to avoid forgetting
things.

Reimar

From Reimar.Doeffinger at gmx.de  Sun May  6 14:04:57 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 6 May 2012 14:04:57 +0200
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
Message-ID: <20120506120457.GA22808@1und1.de>

Hello,
we decided it is time to do a release again.
However there are two problems with that
1) We generally need a lot of testing to check that there are no too
serious issues.
2) The usual people seem to have no time, FFmpeg has switched to git
etc. so some knowledge on how to make the release tarball got lost.

So I just made the first try of creating one from current trunk.
I'd like as many people as possible to test compiling and running.
I'd also like people to check that the right stuff is included
(i.e. the HTML DOCS are there and work as expected, there are no
.svn or .git directories etc.).
I also have not decided on the formats, though I tend towards not making
a .tar.gz available but only a .tar.bz2 and possibly .tar.xz.
Opinions on that are welcome, too.

And here's the tarball for you to test:
http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2

Thanks for your help,
Reimar D?ffinger

From rxt at rtogni.it  Sun May  6 14:05:08 2012
From: rxt at rtogni.it (Roberto Togni)
Date: Sun, 6 May 2012 14:05:08 +0200
Subject: [MPlayer-dev-eng] release.sh script?
In-Reply-To: <20120506111502.GA21145@1und1.de>
References: <20120506111502.GA21145@1und1.de>
Message-ID: <20120506140508.63e613f0@blacktower.myhome.qwe>

On Sun, 6 May 2012 13:15:02 +0200
Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:

> Hello,
> DOCS/tech/release-howto.txt mentions a release.sh script.
> Does that actually exist/does someone have a copy of it?
> I'm sure it would be quite outdated, but it wouldn't hurt to
> have it as a starting point to make it easier to avoid forgetting
> things.
> 

Hi,
 I attached the script that I used when I did the releases.
It's surely outdated, since it gets ffmpeg by svn externals instead of
git; also the paths refer to the old server, I have no idea about the
layout of the new one.

I'm attaching also my personal version of the release howto that I ever
got to commit, in case there is something useful in it for you.


Ciao,
 Roberto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: release.sh
Type: application/x-shellscript
Size: 1076 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120506/c6074988/attachment.bin>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: release-howto.txt
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120506/c6074988/attachment.txt>

From Reimar.Doeffinger at gmx.de  Sun May  6 14:38:38 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sun, 6 May 2012 14:38:38 +0200
Subject: [MPlayer-dev-eng] release.sh script?
In-Reply-To: <20120506140508.63e613f0@blacktower.myhome.qwe>
References: <20120506111502.GA21145@1und1.de>
	<20120506140508.63e613f0@blacktower.myhome.qwe>
Message-ID: <20120506123838.GA28213@1und1.de>

On Sun, May 06, 2012 at 02:05:08PM +0200, Roberto Togni wrote:
> On Sun, 6 May 2012 13:15:02 +0200
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:
> 
> > Hello,
> > DOCS/tech/release-howto.txt mentions a release.sh script.
> > Does that actually exist/does someone have a copy of it?
> > I'm sure it would be quite outdated, but it wouldn't hurt to
> > have it as a starting point to make it easier to avoid forgetting
> > things.
> > 
> 
> Hi,
>  I attached the script that I used when I did the releases.
> It's surely outdated, since it gets ffmpeg by svn externals instead of
> git; also the paths refer to the old server, I have no idea about the
> layout of the new one.

Due to the docs generation I'm not sure I'll want to run it on the
server anyway.
I've committed my variant that seems to at least produce something
compilable, hopefully there'll be some feedback to be more sure if it
is ok.

> I'm attaching also my personal version of the release howto that I ever
> got to commit, in case there is something useful in it for you.

That's a good idea, though unless there are volunteers I'll probably
skip quite a few of the steps (like Changelog update).

>    - commit all release-related changes to the branch
>      - version.sh

I believe version.sh is no longer supposed to be modified,
just a VERSION file is created.

From ib at wupperonline.de  Sun May  6 15:22:07 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 06 May 2012 15:22:07 +0200
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <20120506120457.GA22808@1und1.de>
Message-ID: <4fa67b01.373b9ecf.bm000@wupperonline.de>

Reimar D?ffinger wrote on Sun, 6 May 2012 14:04:57 +0200:

> I'd like as many people as possible to test compiling and running.

Works for me.

> I'd also like people to check that the right stuff is included

Remember that we have a .gitignore under svn version control.

Ingo

From tojesseg at gmail.com  Tue May  8 08:55:41 2012
From: tojesseg at gmail.com (Jesse Gordon)
Date: Mon, 07 May 2012 23:55:41 -0700
Subject: [MPlayer-dev-eng] Where is video frame processing in source code?
Message-ID: <4FA8C36D.7010808@gmail.com>

Where in the source code for mplayer do I find a place where I can 
insert my own code to analyze and modify the video frames before they 
are displayed?

Specifically, I wish to add focus detection and indication. I know how 
to do focus detection in C, but I just can't find in the source code 
where (or what variables/buffers) I can analyze and modify each frame 
with my own code.

Thank you very much,

Jesse Gordon

From cehoyos at ag.or.at  Tue May  8 10:05:27 2012
From: cehoyos at ag.or.at (Carl Eugen Hoyos)
Date: Tue, 8 May 2012 08:05:27 +0000 (UTC)
Subject: [MPlayer-dev-eng] Where is video frame processing in source
	code?
References: <4FA8C36D.7010808@gmail.com>
Message-ID: <loom.20120508T100043-175@post.gmane.org>

Jesse Gordon <tojesseg <at> gmail.com> writes:

> Where in the source code for mplayer do I find a place where I can 
> insert my own code to analyze and modify the video frames before they 
> are displayed?

I suspect you want to implement a FFmpeg video filter.
See http://ffmpeg.org/libavfilter.html

Carl Eugen


From komh78 at gmail.com  Tue May  8 14:57:09 2012
From: komh78 at gmail.com (KO Myung-Hun)
Date: Tue, 08 May 2012 21:57:09 +0900
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <20120506120457.GA22808@1und1.de>
References: <20120506120457.GA22808@1und1.de>
Message-ID: <4FA91825.6060909@chollian.net>

Hi/2.

Reimar D?ffinger wrote:
> Hello,
> we decided it is time to do a release again.
> However there are two problems with that
> 1) We generally need a lot of testing to check that there are no too
> serious issues.
> 2) The usual people seem to have no time, FFmpeg has switched to git
> etc. so some knowledge on how to make the release tarball got lost.
> 
> So I just made the first try of creating one from current trunk.
> I'd like as many people as possible to test compiling and running.
> I'd also like people to check that the right stuff is included
> (i.e. the HTML DOCS are there and work as expected, there are no
> .svn or .git directories etc.).
> I also have not decided on the formats, though I tend towards not making
> a .tar.gz available but only a .tar.bz2 and possibly .tar.xz.
> Opinions on that are welcome, too.
> 
> And here's the tarball for you to test:
> http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2
> 

Works on OS/2. ^^

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.0.14
Under OS/2 Warp 4 for Korean with FixPak #15
On Intel Core i5-2520M 2.50GHz with 4GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr


From sfsheldo at gmail.com  Tue May  8 18:25:49 2012
From: sfsheldo at gmail.com (Stephen Sheldon)
Date: Tue, 08 May 2012 09:25:49 -0700
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <20120506120457.GA22808@1und1.de>
References: <20120506120457.GA22808@1und1.de>
Message-ID: <4FA9490D.1030303@gmail.com>

On 5/6/2012 5:04 AM, Reimar D?ffinger wrote:
> Hello,
> we decided it is time to do a release again.
> However there are two problems with that
> 1) We generally need a lot of testing to check that there are no too
> serious issues.
> 2) The usual people seem to have no time, FFmpeg has switched to git
> etc. so some knowledge on how to make the release tarball got lost.
>
> So I just made the first try of creating one from current trunk.
> I'd like as many people as possible to test compiling and running.
> I'd also like people to check that the right stuff is included
> (i.e. the HTML DOCS are there and work as expected, there are no
> .svn or .git directories etc.).
> I also have not decided on the formats, though I tend towards not making
> a .tar.gz available but only a .tar.bz2 and possibly .tar.xz.
> Opinions on that are welcome, too.
>
> And here's the tarball for you to test:
> http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2
>
> Thanks for your help,
> Reimar D?ffinger
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
The tarball compiled and the executable worked for me in Windows 7 
64-bit with the x86_64-w64-mingw32 toolchain.

From eclipse7 at gmx.net  Wed May  9 03:25:20 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Wed, 9 May 2012 03:25:20 +0200
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <20120506120457.GA22808@1und1.de>
References: <20120506120457.GA22808@1und1.de>
Message-ID: <20120509012520.GB2832@akuma>

Hi Reimar,

Reimar D?ffinger wrote:
> we decided it is time to do a release again.
[...]
> 
> And here's the tarball for you to test:
> http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2

  Builds for me on x86_64 GNU/Linux.

  From a bunch of quick tests mplayer binary seems to work fine.

  Did not yet test mencoder.

  Alexander

From tojesseg at gmail.com  Wed May  9 08:17:26 2012
From: tojesseg at gmail.com (Jesse Gordon)
Date: Tue, 08 May 2012 23:17:26 -0700
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <4FA9490D.1030303@gmail.com>
References: <20120506120457.GA22808@1und1.de> <4FA9490D.1030303@gmail.com>
Message-ID: <4FAA0BF6.1040402@gmail.com>

On 5/6/2012 5:04 AM, Reimar D?ffinger wrote:
>> Hello,
>> we decided it is time to do a release again.
>> However there are two problems with that
>> 1) We generally need a lot of testing to check that there are no too
>> serious issues.
>> 2) The usual people seem to have no time, FFmpeg has switched to git
>> etc. so some knowledge on how to make the release tarball got lost.
>>
>> So I just made the first try of creating one from current trunk.
>> I'd like as many people as possible to test compiling and running.
>> I'd also like people to check that the right stuff is included
>> (i.e. the HTML DOCS are there and work as expected, there are no
>> .svn or .git directories etc.).
>> I also have not decided on the formats, though I tend towards not making
>> a .tar.gz available but only a .tar.bz2 and possibly .tar.xz.
>> Opinions on that are welcome, too.
>>
>> And here's the tarball for you to test:
>> http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2 
>>
>>
>> Thanks for your help,
>> Reimar D?ffinger
>> _______________________________________________
>> MPlayer-dev-eng mailing list
>> MPlayer-dev-eng at mplayerhq.hu
>> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Happily compiles and plays various video formats for me.


~Jesse Gordon

cat /etc/slackware-version
Slackware 13.1.0
uname -a
Linux videoflier.com 2.6.33.4-smp #2 SMP Wed May 12 22:47:36 CDT 2010 
i686 AMD Turion(tm) 64 Mobile Technology MK-36 AuthenticAMD GNU/Linux
uname -m
i686


From eclipse7 at gmx.net  Sat May 12 21:19:10 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 12 May 2012 21:19:10 +0200
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <20120509012520.GB2832@akuma>
References: <20120506120457.GA22808@1und1.de>
 <20120509012520.GB2832@akuma>
Message-ID: <20120512191909.GA4953@akuma>

Alexander Strasser wrote:
> Reimar D?ffinger wrote:
> > we decided it is time to do a release again.
> [...]
> > 
> > And here's the tarball for you to test:
> > http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2
> 
>   Builds for me on x86_64 GNU/Linux.
> 
>   From a bunch of quick tests mplayer binary seems to work fine.
> 
>   Did not yet test mencoder.

  Build on Cygwin installed on WinXP worked fine too.

  I have discovered some small problems with configure, so please
look at the patches I will sent in a new thread.

  I try to exercise mencoder a bit this weekend, but more regular
mencoder users are invited to test with their use cases and report!

  Alexander

From eclipse7 at gmx.net  Sat May 12 21:34:07 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 12 May 2012 21:34:07 +0200
Subject: [MPlayer-dev-eng] [PATCH 0/2] configure fixes
Message-ID: <cover.1336850969.git.eclipse7@gmx.net>

Hi!

  While testing on Cygwin I stumbled over 2 problems
this patch series tries to solve.

  These patches apply to both the code base from the 1.1
release preview and current SVN.

  For the first patch I do not know if it is the best
solution, but it was the first Idea that came to mind
and it worked fine. I tested vo directx with and without
hwaccel and the module worked fine here AFAICT.

  Please let me know what you think about it.

Alexander Strasser (2):
  build: Fix vo directx compilation on Cygwin
  build: Update SDL test to check for new features

 configure |    8 ++++++++
 1 files changed, 8 insertions(+), 0 deletions(-)

-- 
1.7.5.4

From eclipse7 at gmx.net  Sat May 12 21:35:08 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 12 May 2012 21:35:08 +0200
Subject: [MPlayer-dev-eng] [PATCH 1/2] build: Fix vo directx compilation on
	Cygwin
In-Reply-To: <cover.1336850969.git.eclipse7@gmx.net>
References: <cover.1336850969.git.eclipse7@gmx.net>
Message-ID: <1bba6263e45ed28f8fb74145f9584d943dbe4bab.1336850969.git.eclipse7@gmx.net>

  Without windows.h included syntax errors will
arise inside the ddraw.h header.
---
 configure |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 1afb4c1..13e1683 100755
--- a/configure
+++ b/configure
@@ -5252,6 +5252,7 @@ echores "$_direct3d"
 echocheck "Directx"
 if test "$_directx" = auto ; then
   cat > $TMPC << EOF
+#include <windows.h>
 #include <ddraw.h>
 #include <dsound.h>
 int main(void) { return 0; }
-- 
1.7.5.4

From eclipse7 at gmx.net  Sat May 12 21:36:06 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 12 May 2012 21:36:06 +0200
Subject: [MPlayer-dev-eng] [PATCH 2/2] build: Update SDL test to check for
	new features
In-Reply-To: <cover.1336850969.git.eclipse7@gmx.net>
References: <cover.1336850969.git.eclipse7@gmx.net>
Message-ID: <7a9b18e84ebf9ba18018ddbbe87d026c64bda308.1336850969.git.eclipse7@gmx.net>

  Since we are using SDL_VideoInfo() now to get current_w
and current_h, we must check for their existence in our
configure script to avoid build failures on systems with an
outdated SDL.
---
 configure |    7 +++++++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/configure b/configure
index 13e1683..a519de0 100755
--- a/configure
+++ b/configure
@@ -5026,7 +5026,14 @@ if test "$_sdl" = auto || test "$_sdl" = yes ; then
 #undef main
 #endif
 int main(int argc, char *argv[]) {
+  int tmp;
+  const SDL_VideoInfo *vi;
+
   SDL_Init(SDL_INIT_VIDEO|SDL_INIT_NOPARACHUTE);
+  vi = SDL_GetVideoInfo();
+  tmp = vi->current_w;
+  tmp = vi->current_h;
+
   return 0;
 }
 EOF
-- 
1.7.5.4

From eclipse7 at gmx.net  Sun May 13 01:03:14 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 13 May 2012 01:03:14 +0200
Subject: [MPlayer-dev-eng] [PATCH] build: Check if SCTP is available
Message-ID: <20120512230314.GA12883@akuma>

  Test for SCTP and remove it from the list of libavformat
protocols in case the test did not succeed or the feature
was explicitly disabled.

  Unconditionally trying to build it, as it was done before
if you had a new enough libavformat version that contains
that feature, is obviously not a good idea.

  This patch is closely based on a patch from Johan Andersson.
---
 configure |   25 ++++++++++++++++++++++++-
 1 files changed, 24 insertions(+), 1 deletions(-)

diff --git a/configure b/configure
index 1afb4c1..9ad2692 100755
--- a/configure
+++ b/configure
@@ -384,6 +384,7 @@ Optional features:
                          parsing [disabled]
   --enable-macosx-bundle enable Mac OS X bundle file locations [autodetect]
   --disable-inet6        disable IPv6 support [autodetect]
+  --disable-sctp         disable SCTP support [autodetect]
   --disable-gethostbyname2  gethostbyname2 part of the C library [autodetect]
   --disable-ftp          disable FTP support [enabled]
   --disable-vstream      disable TiVo vstream client support [autodetect]
@@ -855,6 +856,7 @@ _freetypeconfig='freetype-config'
 _fribidi=auto
 _enca=auto
 _inet6=auto
+_sctp=auto
 _gethostbyname2=auto
 _ftp=auto
 _musepack=no
@@ -1375,6 +1377,9 @@ for ac_option do
   --enable-inet6)       _inet6=yes      ;;
   --disable-inet6)      _inet6=no       ;;
 
+  --enable-sctp)        _sctp=yes       ;;
+  --disable-sctp)       _sctp=no        ;;
+
   --enable-gethostbyname2)      _gethostbyname2=yes     ;;
   --disable-gethostbyname2)     _gethostbyname2=no      ;;
 
@@ -3364,7 +3369,7 @@ else
   def_network='#define CONFIG_NETWORK 0'
   def_networking='#undef CONFIG_NETWORKING'
   def_rtpdec='#define CONFIG_RTPDEC 0'
-  libavprotocols=$(echo $libavprotocols | sed -e s/GOPHER_PROTOCOL// -e s/HTTP_PROTOCOL// -e s/RTMP_PROTOCOL// -e s/RTP_PROTOCOL// -e s/TCP_PROTOCOL// -e s/UDP_PROTOCOL// -e s/MMSH_PROTOCOL// -e s/MMST_PROTOCOL//)
+  libavprotocols=$(echo $libavprotocols | sed -e s/GOPHER_PROTOCOL// -e s/HTTP_PROTOCOL// -e s/RTMP_PROTOCOL// -e s/RTP_PROTOCOL// -e s/TCP_PROTOCOL// -e s/UDP_PROTOCOL// -e s/MMSH_PROTOCOL// -e s/MMST_PROTOCOL// -e s/SCTP_PROTOCOL//)
   libavdemuxers=$(echo $libavdemuxers | sed -e s/RTSP_DEMUXER// -e s/SDP_DEMUXER// -e s/SAP_DEMUXER// -e s/RTP_DEMUXER//)
 fi
 echores "$networking"
@@ -3415,6 +3420,24 @@ else
 fi
 echores "$_gethostbyname2"
 
+echocheck "SCTP"
+if test "$_sctp" = auto ; then
+cat > $TMPC << EOF
+#include <netinet/in.h>
+#include <netinet/sctp.h>
+#include <sys/time.h>
+#include <unistd.h>
+int main(void) { socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP ); return 0; }
+EOF
+  _sctp=no
+  if cc_check ; then
+    _sctp=yes
+  fi
+fi
+if test "$_sctp" = no ; then
+  libavprotocols=$(echo $libavprotocols | sed -e s/SCTP_PROTOCOL//)
+fi
+echores "$_sctp"
 
 echocheck "sys/poll.h"
 poll_h=no
-- 
1.7.5.4

From Reimar.Doeffinger at gmx.de  Sun May 13 14:48:20 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Sun, 13 May 2012 14:48:20 +0200
Subject: [MPlayer-dev-eng] [PATCH 1/2] build: Fix vo directx compilation
	on Cygwin
In-Reply-To: <1bba6263e45ed28f8fb74145f9584d943dbe4bab.1336850969.git.eclipse7@gmx.net>
References: <cover.1336850969.git.eclipse7@gmx.net>
	<1bba6263e45ed28f8fb74145f9584d943dbe4bab.1336850969.git.eclipse7@gmx.net>
Message-ID: <32B2EBDF-5338-4B43-8580-6002BA1F956D@gmx.de>

The "recommended", wine-based ddraw.h header I believe does not have that problem, but the change is fine by me.

On 12 May 2012, at 21:35, Alexander Strasser <eclipse7 at gmx.net> wrote:

>  Without windows.h included syntax errors will
> arise inside the ddraw.h header.
> ---
> configure |    1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/configure b/configure
> index 1afb4c1..13e1683 100755
> --- a/configure
> +++ b/configure
> @@ -5252,6 +5252,7 @@ echores "$_direct3d"
> echocheck "Directx"
> if test "$_directx" = auto ; then
>   cat > $TMPC << EOF
> +#include <windows.h>
> #include <ddraw.h>
> #include <dsound.h>
> int main(void) { return 0; }
> -- 
> 1.7.5.4
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

From Reimar.Doeffinger at gmx.de  Sun May 13 14:50:44 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Sun, 13 May 2012 14:50:44 +0200
Subject: [MPlayer-dev-eng] [PATCH 2/2] build: Update SDL test to check
	for new features
In-Reply-To: <7a9b18e84ebf9ba18018ddbbe87d026c64bda308.1336850969.git.eclipse7@gmx.net>
References: <cover.1336850969.git.eclipse7@gmx.net>
	<7a9b18e84ebf9ba18018ddbbe87d026c64bda308.1336850969.git.eclipse7@gmx.net>
Message-ID: <05F3427F-3CE0-460D-9C4C-AAA3F896EED7@gmx.de>

On 12 May 2012, at 21:36, Alexander Strasser <eclipse7 at gmx.net> wrote:
>  Since we are using SDL_VideoInfo() now to get current_w
> and current_h, we must check for their existence in our
> configure script to avoid build failures on systems with an
> outdated SDL.
> ---
> configure |    7 +++++++
> 1 files changed, 7 insertions(+), 0 deletions(-)
> 
> diff --git a/configure b/configure
> index 13e1683..a519de0 100755
> --- a/configure
> +++ b/configure
> @@ -5026,7 +5026,14 @@ if test "$_sdl" = auto || test "$_sdl" = yes ; then
> #undef main
> #endif
> int main(int argc, char *argv[]) {
> +  int tmp;
> +  const SDL_VideoInfo *vi;
> +
>   SDL_Init(SDL_INIT_VIDEO|SDL_INIT_NOPARACHUTE);
> +  vi = SDL_GetVideoInfo();
> +  tmp = vi->current_w;
> +  tmp = vi->current_h;

Seems a bit like overkill to me.
Any reason to believe that just adding a call to GetVideoInfo (without any of the extra variables) wouldn't be good enough?
Alternatively that call could be put under an SDL_VERSION ifdef or such...

From Reimar.Doeffinger at gmx.de  Sun May 13 14:52:49 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Sun, 13 May 2012 14:52:49 +0200
Subject: [MPlayer-dev-eng] [PATCH] build: Check if SCTP is available
In-Reply-To: <20120512230314.GA12883@akuma>
References: <20120512230314.GA12883@akuma>
Message-ID: <E3C071B1-2152-4078-A7AB-B3A4A1E175B7@gmx.de>

On 13 May 2012, at 01:03, Alexander Strasser <eclipse7 at gmx.net> wrote:
> +echocheck "SCTP"
> +if test "$_sctp" = auto ; then
> +cat > $TMPC << EOF
> +#include <netinet/in.h>
> +#include <netinet/sctp.h>
> +#include <sys/time.h>
> +#include <unistd.h>
> +int main(void) { socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP ); return 0; }

Can't you just do a check_header netinet/sctp.h ?

From eclipse7 at gmx.net  Sun May 13 16:54:00 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 13 May 2012 16:54:00 +0200
Subject: [MPlayer-dev-eng] [PATCH 1/2] build: Fix vo directx compilation
 on Cygwin
In-Reply-To: <32B2EBDF-5338-4B43-8580-6002BA1F956D@gmx.de>
References: <cover.1336850969.git.eclipse7@gmx.net>
	<1bba6263e45ed28f8fb74145f9584d943dbe4bab.1336850969.git.eclipse7@gmx.net>
	<32B2EBDF-5338-4B43-8580-6002BA1F956D@gmx.de>
Message-ID: <20120513145400.GB2417@akuma>

Hi Reimar,

Reimar D?ffinger wrote:
> The "recommended", wine-based ddraw.h header I believe does not have that problem, but the change is fine by me.

  Oh, I didn't know about that. But at least if they didn't change in
the last years, it does not work with the headers on MPHQ website which
are linked from the Windows documentation chapter.

  So I will wait a bit if someone else wants to speak up. If I hear no
objections I will apply it to make life easier for those not using the
wine-based headers.

> On 12 May 2012, at 21:35, Alexander Strasser <eclipse7 at gmx.net> wrote:
[patch snipped]

  Alexander

From eclipse7 at gmx.net  Sun May 13 17:14:49 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 13 May 2012 17:14:49 +0200
Subject: [MPlayer-dev-eng] [PATCH 2/2] build: Update SDL test to check
 for new features
In-Reply-To: <05F3427F-3CE0-460D-9C4C-AAA3F896EED7@gmx.de>
References: <cover.1336850969.git.eclipse7@gmx.net>
	<7a9b18e84ebf9ba18018ddbbe87d026c64bda308.1336850969.git.eclipse7@gmx.net>
	<05F3427F-3CE0-460D-9C4C-AAA3F896EED7@gmx.de>
Message-ID: <20120513151448.GC2417@akuma>

Hi,

Reimar D?ffinger wrote:
> On 12 May 2012, at 21:36, Alexander Strasser <eclipse7 at gmx.net> wrote:
[...]
> > +  int tmp;
> > +  const SDL_VideoInfo *vi;
> > +
> >   SDL_Init(SDL_INIT_VIDEO|SDL_INIT_NOPARACHUTE);
> > +  vi = SDL_GetVideoInfo();
> > +  tmp = vi->current_w;
> > +  tmp = vi->current_h;
> 
> Seems a bit like overkill to me.
> Any reason to believe that just adding a call to GetVideoInfo (without any of the extra variables) wouldn't be good enough?

  There was a time when SDL_VideoInfo structure didn't have those
members.

  Checking only for one of them should be fine though. Not using
the tmp variables would probably be good enough too, since the
compiler required to check if the member exists syntactically, even
if it isn't used in the end AFAIK.

  I guess I was a bit too paranoid while writing that code :)

> Alternatively that call could be put under an SDL_VERSION ifdef or such...

  Not sure if I like that...

  What do you think about me figuring out how to get the runtime version
and checking that version in configure and in the sdl_common module before
calling that function? Would probably make both places more correct and
make potential baseline SDL checks easier in the future.


Thanks for the review,
  Alexander

From j at i19.se  Sun May 13 17:16:37 2012
From: j at i19.se (Johan Andersson)
Date: Sun, 13 May 2012 17:16:37 +0200
Subject: [MPlayer-dev-eng] [PATCH] build: Check if SCTP is available
In-Reply-To: <E3C071B1-2152-4078-A7AB-B3A4A1E175B7@gmx.de>
References: <20120512230314.GA12883@akuma>
	<E3C071B1-2152-4078-A7AB-B3A4A1E175B7@gmx.de>
Message-ID: <20120513151637.GA31579@i19.se>

On Sun, May 13, 2012 at 02:52:49PM +0200, Reimar D?ffinger wrote:
> On 13 May 2012, at 01:03, Alexander Strasser <eclipse7 at gmx.net> wrote:
> > +echocheck "SCTP"
> > +if test "$_sctp" = auto ; then
> > +cat > $TMPC << EOF
> > +#include <netinet/in.h>
> > +#include <netinet/sctp.h>
> > +#include <sys/time.h>
> > +#include <unistd.h>
> > +int main(void) { socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP ); return 0; }
> 
> Can't you just do a check_header netinet/sctp.h ?

Yeah that should work too.

-- 
Johan Andersson

From eclipse7 at gmx.net  Sun May 13 18:33:42 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 13 May 2012 18:33:42 +0200
Subject: [MPlayer-dev-eng] [PATCH] build: Check if SCTP is available
In-Reply-To: <20120513151637.GA31579@i19.se>
References: <20120512230314.GA12883@akuma>
	<E3C071B1-2152-4078-A7AB-B3A4A1E175B7@gmx.de>
	<20120513151637.GA31579@i19.se>
Message-ID: <20120513163342.GA29167@akuma>

Johan Andersson wrote:
> On Sun, May 13, 2012 at 02:52:49PM +0200, Reimar D?ffinger wrote:
> > On 13 May 2012, at 01:03, Alexander Strasser <eclipse7 at gmx.net> wrote:
> > > +echocheck "SCTP"
> > > +if test "$_sctp" = auto ; then
> > > +cat > $TMPC << EOF
> > > +#include <netinet/in.h>
> > > +#include <netinet/sctp.h>
> > > +#include <sys/time.h>
> > > +#include <unistd.h>
> > > +int main(void) { socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP ); return 0; }
> > 
> > Can't you just do a check_header netinet/sctp.h ?
> 
> Yeah that should work too.

  I did miss it is available in MPlayer's configure. But I found it
now under the name header_check.

  Simplified patch attached.

Thank you for the careful review, Reimar!

  Alexander
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-build-Check-if-SCTP-is-available.patch
Type: text/x-diff
Size: 2865 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120513/4bc281de/attachment.bin>

From Reimar.Doeffinger at gmx.de  Sun May 13 19:39:17 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Sun, 13 May 2012 19:39:17 +0200
Subject: [MPlayer-dev-eng] [PATCH] build: Check if SCTP is available
In-Reply-To: <20120513163342.GA29167@akuma>
References: <20120512230314.GA12883@akuma>
	<E3C071B1-2152-4078-A7AB-B3A4A1E175B7@gmx.de>
	<20120513151637.GA31579@i19.se> <20120513163342.GA29167@akuma>
Message-ID: <14429333-6714-4CEE-88CF-3A613CEC6B94@gmx.de>


On 13 May 2012, at 18:33, Alexander Strasser <eclipse7 at gmx.net> wrote:
> Johan Andersson wrote:
>> On Sun, May 13, 2012 at 02:52:49PM +0200, Reimar D?ffinger wrote:
>>> On 13 May 2012, at 01:03, Alexander Strasser <eclipse7 at gmx.net> wrote:
>>>> +echocheck "SCTP"
>>>> +if test "$_sctp" = auto ; then
>>>> +cat > $TMPC << EOF
>>>> +#include <netinet/in.h>
>>>> +#include <netinet/sctp.h>
>>>> +#include <sys/time.h>
>>>> +#include <unistd.h>
>>>> +int main(void) { socket( AF_INET, SOCK_STREAM, IPPROTO_SCTP ); return 0; }
>>> 
>>> Can't you just do a check_header netinet/sctp.h ?
>> 
>> Yeah that should work too.
> 
>  I did miss it is available in MPlayer's configure. But I found it
> now under the name header_check.

IMO please commit.
Though you could replace the innermost if by &&, i.e.
header_check ... && sctp=yes

From eclipse7 at gmx.net  Sun May 13 22:04:56 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sun, 13 May 2012 22:04:56 +0200
Subject: [MPlayer-dev-eng] [PATCH] build: Check if SCTP is available
In-Reply-To: <14429333-6714-4CEE-88CF-3A613CEC6B94@gmx.de>
References: <20120512230314.GA12883@akuma>
	<E3C071B1-2152-4078-A7AB-B3A4A1E175B7@gmx.de>
	<20120513151637.GA31579@i19.se> <20120513163342.GA29167@akuma>
	<14429333-6714-4CEE-88CF-3A613CEC6B94@gmx.de>
Message-ID: <20120513200456.GD29167@akuma>

Hi Reimar,

Reimar D?ffinger wrote:
> On 13 May 2012, at 18:33, Alexander Strasser <eclipse7 at gmx.net> wrote:
[...]
> >  I did miss it is available in MPlayer's configure. But I found it
> > now under the name header_check.
> 
> IMO please commit.
> Though you could replace the innermost if by &&, i.e.
> header_check ... && sctp=yes

  Committed.

  I did see the opportunity to get rid of this "if" but as it is
a matter of personal taste I wasn't sure what to do; so I left it
as it was before in Johan's patch. I was under the impression his
patch was strongly modelled after another existing check.

  As the matter is quite annoying and multiple users (rightly)
complained until now I did not want to edit the tested patch.

  If you insist on avoiding the "if" I can change it locally and
commit after I tested it.

  Alexander

From ib at wupperonline.de  Sun May 13 22:29:54 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Sun, 13 May 2012 22:29:54 +0200
Subject: [MPlayer-dev-eng] [PATCH 1/2] build: Fix vo directx compilation
	on Cygwin
In-Reply-To: <20120513145400.GB2417@akuma>
Message-ID: <4fb01a94.2de8b754.bm000@wupperonline.de>

Alexander Strasser wrote on Sun, 13 May 2012 16:54:00 +0200:

> Reimar D?ffinger wrote:
>> The "recommended", wine-based ddraw.h header I believe does not have that
>> problem, but the change is fine by me.

Yes, that's right.

>   Oh, I didn't know about that. But at least if they didn't change in
> the last years, it does not work with the headers on MPHQ website which
> are linked from the Windows documentation chapter.

>   So I will wait a bit if someone else wants to speak up. If I hear no
> objections I will apply it to make life easier for those not using the
> wine-based headers.

The patch, although not necessary, harms neither the Wine port nor the
legacy-Cygwin port nor the MinGW port (all using different ddraw.h headers,
at least on my system), so no objection.

Ingo

From ib at wupperonline.de  Fri May 18 10:41:22 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 18 May 2012 10:41:22 +0200
Subject: [MPlayer-dev-eng] MIME types / samples
Message-ID: <4fb60c21.7b8f1a6b.bm000@wupperonline.de>

I'm just about to update the completely outdated list of supported MIME types
in mplayer.desktop for the GUI.

There's probably only the list of extensions (libmpdemux/extension.c) and the
list of demuxers in libmpdemux/ itself that might give me a clue about what
MIME types are supported, isn't it?

It would be nice if I had samples to test with. Is there a collection
somewhere?

Ingo

From tempn at twmi.rr.com  Fri May 18 12:33:19 2012
From: tempn at twmi.rr.com (compn)
Date: Fri, 18 May 2012 06:33:19 -0400
Subject: [MPlayer-dev-eng] MIME types / samples
In-Reply-To: <4fb60c21.7b8f1a6b.bm000@wupperonline.de>
References: <4fb60c21.7b8f1a6b.bm000@wupperonline.de>
Message-ID: <20120518063319.fcb82033.tempn@twmi.rr.com>

On Fri, 18 May 2012 10:41:22 +0200, Ingo Br?ckl wrote:
>I'm just about to update the completely outdated list of supported MIME types
>in mplayer.desktop for the GUI.
>
>There's probably only the list of extensions (libmpdemux/extension.c) and the
>list of demuxers in libmpdemux/ itself that might give me a clue about what
>MIME types are supported, isn't it?

there are some media mime types listed here:
http://www.iana.org/assignments/media-types/index.html

>It would be nice if I had samples to test with. Is there a collection
>somewhere?

i dont believe we have a mime sample collection, mostly because mime
types lie and we have to guess the formats anyways.

copying the mime types that vlc supports might work
http://git.videolan.org/?p=vlc.git;a=blob;f=share/vlc.desktop.in;hb=HEAD

-compn

From ib at wupperonline.de  Fri May 18 12:36:01 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Fri, 18 May 2012 12:36:01 +0200
Subject: [MPlayer-dev-eng] MIME types / samples
In-Reply-To: <20120518063319.fcb82033.tempn@twmi.rr.com>
Message-ID: <4fb62750.4f0f80e7.bm000@wupperonline.de>

compn wrote on Fri, 18 May 2012 06:33:19 -0400:

> On Fri, 18 May 2012 10:41:22 +0200, Ingo Br?ckl wrote:
>>It would be nice if I had samples to test with. Is there a collection
>>somewhere?

> i dont believe we have a mime sample collection, mostly because mime
> types lie and we have to guess the formats anyways.

I meant a collection of video and audio samples (all types) MPlayer can play.
It's hard to find a specific sample file for download by searching the web.

Ingo

From tempn at twmi.rr.com  Fri May 18 14:35:43 2012
From: tempn at twmi.rr.com (compn)
Date: Fri, 18 May 2012 08:35:43 -0400
Subject: [MPlayer-dev-eng] MIME types / samples
In-Reply-To: <4fb62750.4f0f80e7.bm000@wupperonline.de>
References: <20120518063319.fcb82033.tempn@twmi.rr.com>
	<4fb62750.4f0f80e7.bm000@wupperonline.de>
Message-ID: <20120518083543.4f342aac.tempn@twmi.rr.com>

On Fri, 18 May 2012 12:36:01 +0200, Ingo Br?ckl wrote:
>compn wrote on Fri, 18 May 2012 06:33:19 -0400:
>
>> On Fri, 18 May 2012 10:41:22 +0200, Ingo Br?ckl wrote:
>>>It would be nice if I had samples to test with. Is there a collection
>>>somewhere?
>
>> i dont believe we have a mime sample collection, mostly because mime
>> types lie and we have to guess the formats anyways.
>
>I meant a collection of video and audio samples (all types) MPlayer can play.
>It's hard to find a specific sample file for download by searching the web.

we happen to run the largest selection of multimedia formats
collection on the internet: http://samples.mplayerhq.hu
(archive.org may want to argue this point haha)

i think the raw and image format extensions should not be added, since
mplayer cannot play them back correctly unless the user specifies some
options. e.g. .raw .h264 .png, .gif .jpg

-compn

From benoit.thebaudeau at advansee.com  Fri May 18 18:18:28 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 18 May 2012 18:18:28 +0200 (CEST)
Subject: [MPlayer-dev-eng] [PATCH]
	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <97757b7e-01ba-414a-a384-e9999872428b@zose-store-12>
Message-ID: <492569134.882936.1337357908217.JavaMail.root@advansee.com>

Hi Reimar, all,

On Mon, Feb 13, 2012 at 08:57:03PM +0100, Beno?t Th?baudeau wrote:
> On Mon, Feb 13, 2012 at 08:39:48PM +0100, Reimar D?ffinger wrote:
> > but I'd need this one without the reindentation
> > because it's not really possibly to review like this.
> > -uwb as extra options to diff would probably work (obviously I
> > could
> > do
> > that on my own, but that might take a bit longer till I get round
> > to
> > it).
>
> Here it is.

Ping?

Thanks in advance.

Regards,
Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1-demux-audio-use-movi-end-no-reindent.patch
Type: text/x-patch
Size: 1632 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120518/1b8b8832/attachment.bin>

From benoit.thebaudeau at advansee.com  Fri May 18 18:20:39 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 18 May 2012 18:20:39 +0200 (CEST)
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Fix audio
 time length.
In-Reply-To: <c9af45bb-33f1-4561-a0c8-1c0e320d94f3@zose-store-12>
Message-ID: <217705533.883045.1337358039773.JavaMail.root@advansee.com>

On Tue, Jan 17, 2012 at 07:45:02PM +0100, Beno?t Th?baudeau wrote:
> Reimar,
> 
> > > diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c
> > > mplayer/libmpdemux/demux_audio.c
> > > --- mplayer.orig/libmpdemux/demux_audio.c	2012-01-17
> > > 15:03:29.757246846 +0100
> > > +++ mplayer/libmpdemux/demux_audio.c	2012-01-17
> > > 15:11:47.549260678
> > > +0100
> > > @@ -787,7 +787,9 @@ static void demux_close_audio(demuxer_t*
> > >
> > >  static int demux_audio_control(demuxer_t *demuxer,int cmd, void
> > >  *arg){
> > >      sh_audio_t *sh_audio=demuxer->audio->sh;
> > > -    int audio_length = sh_audio->i_bps ? demuxer->movi_end /
> > > sh_audio->i_bps : 0;
> > > +    off_t movi_size = (demuxer->movi_end > demuxer->movi_start)
> > > ?
> > > +                      demuxer->movi_end - demuxer->movi_start :
> > > demuxer->movi_end;
> > > +    int audio_length = sh_audio->i_bps ? movi_size /
> > > sh_audio->i_bps : 0;
> >
> > Hm, is there much point/sense in falling back to just movi_end?
> > I would have suggest something like e.g.
> > int audio_length = sh_audio->i_bps && demuxer->movi_end >
> > demuxer->movi_start ? ... : 0;
> 
> I don't know. I just put that because it was the previous code, and
> because
> it might be a better length indication than 0 even if not accurate.
> 
> I attach the patch with your suggestion.

Ping?

Thanks in advance.

Regards,
Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 4-fix-audio-length.patch
Type: text/x-patch
Size: 730 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120518/0e012a89/attachment.bin>

From benoit.thebaudeau at advansee.com  Fri May 18 18:22:08 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 18 May 2012 18:22:08 +0200 (CEST)
Subject: [MPlayer-dev-eng] [PATCH] Fix wrong runtime and average bitrate
	for VBR MP3.
In-Reply-To: <5d363081-00a7-4bab-acde-24438f20f623@zose-store-12>
Message-ID: <951349215.883104.1337358128705.JavaMail.root@advansee.com>

On Fri, Jan 13, 2012 at 09:47:36PM +0100, Beno?t Th?baudeau wrote:
> Hi all,
> 
> According to http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm,
> the MP3
> frame size depends only on the MP3 Layer, while according to
> http://www.codeproject.com/KB/audio-video/mpegaudioinfo.aspx#XINGHeader,
> the
> size of the Layer III side information depends only on the MPEG
> version, so spf
> can not be used by mp3_vbr_frames() to determine the Layer III side
> information
> size. Fix this by using lsf instead.
> 
> Moreover, spf was not filled by mp_get_mp3_header() for NULL freq,
> which was an
> issue for mp3_vbr_frames(). This is also fixed.
> 
> Signed-off-by: "Beno?t Th?baudeau" <benoit.thebaudeau at advansee.com>

Ping?

Thanks in advance.

Regards,
Beno?t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2-fix-mp3-vbr.patch
Type: text/x-patch
Size: 7176 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120518/a0550182/attachment-0001.bin>

From Reimar.Doeffinger at gmx.de  Fri May 18 19:01:21 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 18 May 2012 19:01:21 +0200
Subject: [MPlayer-dev-eng] [PATCH]
	libmpdemux/demux_audio:	Skip	ID3v2.4	tags.
In-Reply-To: <492569134.882936.1337357908217.JavaMail.root@advansee.com>
References: <97757b7e-01ba-414a-a384-e9999872428b@zose-store-12>
	<492569134.882936.1337357908217.JavaMail.root@advansee.com>
Message-ID: <20120518170121.GA18628@1und1.de>

On Fri, May 18, 2012 at 06:18:28PM +0200, Beno?t Th?baudeau wrote:
> Hi Reimar, all,
> 
> On Mon, Feb 13, 2012 at 08:57:03PM +0100, Beno?t Th?baudeau wrote:
> > On Mon, Feb 13, 2012 at 08:39:48PM +0100, Reimar D?ffinger wrote:
> > > but I'd need this one without the reindentation
> > > because it's not really possibly to review like this.
> > > -uwb as extra options to diff would probably work (obviously I
> > > could
> > > do
> > > that on my own, but that might take a bit longer till I get round
> > > to
> > > it).
> >
> > Here it is.
> 
> Ping?

Committed.

From Reimar.Doeffinger at gmx.de  Fri May 18 19:03:17 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 18 May 2012 19:03:17 +0200
Subject: [MPlayer-dev-eng] [PATCH] libmpdemux/demux_audio: Fix audio
 time length.
In-Reply-To: <c9af45bb-33f1-4561-a0c8-1c0e320d94f3@zose-store-12>
References: <20120117182618.GD2120@1und1.de>
	<c9af45bb-33f1-4561-a0c8-1c0e320d94f3@zose-store-12>
Message-ID: <20120518170317.GB18628@1und1.de>

On Tue, Jan 17, 2012 at 07:45:02PM +0100, Beno?t Th?baudeau wrote:
> Reimar,
> 
> > > diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c
> > > mplayer/libmpdemux/demux_audio.c
> > > --- mplayer.orig/libmpdemux/demux_audio.c	2012-01-17
> > > 15:03:29.757246846 +0100
> > > +++ mplayer/libmpdemux/demux_audio.c	2012-01-17 15:11:47.549260678
> > > +0100
> > > @@ -787,7 +787,9 @@ static void demux_close_audio(demuxer_t*
> > >
> > >  static int demux_audio_control(demuxer_t *demuxer,int cmd, void
> > >  *arg){
> > >      sh_audio_t *sh_audio=demuxer->audio->sh;
> > > -    int audio_length = sh_audio->i_bps ? demuxer->movi_end /
> > > sh_audio->i_bps : 0;
> > > +    off_t movi_size = (demuxer->movi_end > demuxer->movi_start) ?
> > > +                      demuxer->movi_end - demuxer->movi_start :
> > > demuxer->movi_end;
> > > +    int audio_length = sh_audio->i_bps ? movi_size /
> > > sh_audio->i_bps : 0;
> >
> > Hm, is there much point/sense in falling back to just movi_end?
> > I would have suggest something like e.g.
> > int audio_length = sh_audio->i_bps && demuxer->movi_end >
> > demuxer->movi_start ? ... : 0;
> 
> I don't know. I just put that because it was the previous code, and because
> it might be a better length indication than 0 even if not accurate.
> 
> I attach the patch with your suggestion.
> 
> Can someone also take a look at these?
> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2012-January/069820.html
> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2012-January/069821.html
> 
> Beno?t

> diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c mplayer/libmpdemux/demux_audio.c
> --- mplayer.orig/libmpdemux/demux_audio.c	2012-01-17 15:03:29.757246846 +0100
> +++ mplayer/libmpdemux/demux_audio.c	2012-01-17 19:31:57.477694450 +0100
> @@ -787,7 +787,8 @@ static void demux_close_audio(demuxer_t*
>  
>  static int demux_audio_control(demuxer_t *demuxer,int cmd, void *arg){
>      sh_audio_t *sh_audio=demuxer->audio->sh;
> -    int audio_length = sh_audio->i_bps ? demuxer->movi_end / sh_audio->i_bps : 0;
> +    int audio_length = sh_audio->i_bps && demuxer->movi_end > demuxer->movi_start ?
> +                       (demuxer->movi_end - demuxer->movi_start) / sh_audio->i_bps : 0;
>      da_priv_t* priv = demuxer->priv;
>  
>      switch(cmd) {

Thanks, finally committed.

From Reimar.Doeffinger at gmx.de  Fri May 18 19:29:44 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 18 May 2012 19:29:44 +0200
Subject: [MPlayer-dev-eng] [PATCH] Fix wrong runtime and average bitrate
 for VBR MP3.
In-Reply-To: <951349215.883104.1337358128705.JavaMail.root@advansee.com>
References: <5d363081-00a7-4bab-acde-24438f20f623@zose-store-12>
	<951349215.883104.1337358128705.JavaMail.root@advansee.com>
Message-ID: <20120518172944.GC18628@1und1.de>

On Fri, May 18, 2012 at 06:22:08PM +0200, Beno?t Th?baudeau wrote:
> +int mp_get_mp3_header(unsigned char* hbuf,int* chans, int* srate, int* spf, int* mpa_layer, int* br, int* lsf){
> +    int stereo,ssize,_lsf,framesize,padding,bitrate_index,sampling_frequency, divisor;

I'd prefer that without all the renaming.
You can name the argument e.g. lsfp or even give it the full name
and the whole change to this file becomes a one-liner.

> -    if(srate) {
> +    if(srate)
>        *srate = freqs[sampling_frequency];
> -      if(spf) {
> -        if(layer == 1)
> -	  *spf = 384;
> -        else if(layer == 2)
> -	  *spf = 1152;
> -        else if(*srate < 32000)
> -          *spf = 576;
> -        else
> -	  *spf = 1152;
> -      }
> +    if(spf) {
> +      if(layer == 1)
> +	*spf = 384;
> +      else if(layer == 2)
> +	*spf = 1152;
> +      else if(*srate < 32000)
> +        *spf = 576;
> +      else
> +	*spf = 1152;

Well, that would now crash exactly in the case you are trying to fix.
I committed a fixed version of that part.

From benoit.thebaudeau at advansee.com  Fri May 18 22:48:16 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 18 May 2012 22:48:16 +0200 (CEST)
Subject: [MPlayer-dev-eng] [PATCH] Fix wrong runtime and average bitrate
 for VBR MP3.
In-Reply-To: <20120518172944.GC18628@1und1.de>
Message-ID: <1313904598.891982.1337374096121.JavaMail.root@advansee.com>

On Fri, May 18, 2012 at 07:29:44PM +0200, Reimar D?ffinger wrote:
> On Fri, May 18, 2012 at 06:22:08PM +0200, Beno?t Th?baudeau wrote:
> > +int mp_get_mp3_header(unsigned char* hbuf,int* chans, int* srate,
> > int* spf, int* mpa_layer, int* br, int* lsf){
> > +    int
> > stereo,ssize,_lsf,framesize,padding,bitrate_index,sampling_frequency,
> > divisor;
> 
> I'd prefer that without all the renaming.
> You can name the argument e.g. lsfp or even give it the full name
> and the whole change to this file becomes a one-liner.

http://www.mpgedit.org/mpgedit/mpeg_format/mpeghdr.htm says "Frame size is the
number of samples contained in a frame. It is constant and always 384 samples
for Layer I and 1152 samples for Layer II and Layer III.", which contradicts
http://www.codeproject.com/Articles/8295/MPEG-Audio-Frame-Header#MPEGAudioFrameHeader,
which gives 576 s/f for LSF Layer III. The latter information seems more
reliable, and MPlayer's code is based on it. If we rely on this, [spf < 1152]
and [lsf] are the same for mp3_vbr_frames() since it has checked beforehand that
the layer is III. Hence, you can drop this part of my patch.

BTW, ssize is computed by mp_get_mp3_header(), but never used.

> > -    if(srate) {
> > +    if(srate)
> >        *srate = freqs[sampling_frequency];
> > -      if(spf) {
> > -        if(layer == 1)
> > -	  *spf = 384;
> > -        else if(layer == 2)
> > -	  *spf = 1152;
> > -        else if(*srate < 32000)
> > -          *spf = 576;
> > -        else
> > -	  *spf = 1152;
> > -      }
> > +    if(spf) {
> > +      if(layer == 1)
> > +	*spf = 384;
> > +      else if(layer == 2)
> > +	*spf = 1152;
> > +      else if(*srate < 32000)
> > +        *spf = 576;
> > +      else
> > +	*spf = 1152;
> 
> Well, that would now crash exactly in the case you are trying to fix.
> I committed a fixed version of that part.

Correct.

Regards,
Beno?t

From Reimar.Doeffinger at gmx.de  Fri May 18 22:53:32 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 18 May 2012 22:53:32 +0200
Subject: [MPlayer-dev-eng] [PATCH] Fix wrong runtime and average bitrate
 for VBR MP3.
In-Reply-To: <1313904598.891982.1337374096121.JavaMail.root@advansee.com>
References: <20120518172944.GC18628@1und1.de>
	<1313904598.891982.1337374096121.JavaMail.root@advansee.com>
Message-ID: <20120518205332.GA3934@1und1.de>

On Fri, May 18, 2012 at 10:48:16PM +0200, Beno?t Th?baudeau wrote:
> BTW, ssize is computed by mp_get_mp3_header(), but never used.

Thanks, removed.
Am I right that everything should be fine now?

From benoit.thebaudeau at advansee.com  Fri May 18 23:06:29 2012
From: benoit.thebaudeau at advansee.com (=?utf-8?Q?Beno=C3=AEt_Th=C3=A9baudeau?=)
Date: Fri, 18 May 2012 23:06:29 +0200 (CEST)
Subject: [MPlayer-dev-eng] [PATCH] Fix wrong runtime and average bitrate
 for VBR MP3.
In-Reply-To: <20120518205332.GA3934@1und1.de>
Message-ID: <336554626.892279.1337375188985.JavaMail.root@advansee.com>

On Fri, May 18, 2012 at 10:53:32PM +0200, Reimar D?ffinger wrote:
> Am I right that everything should be fine now?

Indeed. Thanks!

Regards,
Beno?t

From szo at szo.hu  Mon May 21 17:46:20 2012
From: szo at szo.hu (Szokovacs Robert)
Date: Mon, 21 May 2012 17:46:20 +0200
Subject: [MPlayer-dev-eng] A bit more liberal parsing of tags in .srt
	files?
In-Reply-To: <201204131835.10218.szo@szo.hu>
References: <5034955.XdKuXqR298@gollum> <20120413152051.GA13268@leki>
	<201204131835.10218.szo@szo.hu>
Message-ID: <2968233.N3B1FaxRlN@gollum>

On 2012 Apr 13, Fri 18:35:10 you wrote:

Could somebody take a look please?

br

Szo

> On 2012. April 13., Cl?ment B?sch wrote:
> > On Fri, Apr 13, 2012 at 05:00:18PM +0200, Szokovacs Robert wrote:
> > > On 2012 Mar 03, Sat 15:04:35 Cl?ment B?sch wrote:
> > > > On Sat, Mar 03, 2012 at 02:57:18PM +0100, Reimar D?ffinger wrote:
> > > > > On Wed, Feb 22, 2012 at 09:50:42PM +0100, SZOKOVACS Robert wrote:
> > > > > > On 2012. February 16. Thu 07:39:55 compn wrote:
> > > > > > > On Thu, 16 Feb 2012 11:13:01 +0100, Szokovacs Robert wrote:
> > > > > > > >Hi,
> > > > > > > >
> > > > > > > >A lot of .srt subtitle files I encounter on the net is deemed
> > > > > > > >incorrect by
> > > > > > > >the current mplayer, so the <font> tag is displayed as if it
> > > > > > > >was part of
> > > > > > > >the script.
> > > > > > > >(example: http://www.tvsubtitles.net/download-204587.html,
> > > > > > > >some color=
> > > > > > > 
> > > > > > > i think we shouldnt render any <tag> with < and >.
> > > > > > > but instead silently drop it.
> > > > > > > 
> > > > > > > i dont know whats best re: your idea. better wait for reimar.
> > > > > > 
> > > > > > Reimar, would you please give us some pointers?
> > > > > 
> > > > > I guess looking for < followed by a-z and where a > exists before
> > > > > the next < is about as reliable as you can make it if you want it
> > > > > to catch every case (well, the tags itself, handling hypothetical
> > > > > stuff like <comment>everything here should not be shown</comment>
> > > > > is definitely out of scope for MPlayer IMO.
> > > > 
> > > > Not dropping the invalid tags was intentional; it helps showing
> > > > "invalid" samples. IMO it would be wise to instead fix the code to
> > > > support attributes specified without quotes.
> > > 
> > > Hi,
> > > 
> > > Attached is the patch doing this change.
> > > It also contains the color aliases mentioned it Federico Kereki's email
> > > at 12/03/24
> 
> Hi,
> 
> > Thank you, but before someone do a review, could you send a patch
> > following the coding style around?
> 
> updated version attached.
> 
> > And just a few things: can't you just skip the '"' if you find one? (so
> > <font size="foo> would be supported too, but it would simplifies the
> > code.
> 
> I considered this, but then the font tags with more than one attribute would
> become confusing...
> 
> > Also, just a nit: please use post increment/decrement (it's not
> > faster to do a pre inc/dec in C).
> 
> br
> 
> Szo

From Reimar.Doeffinger at gmx.de  Mon May 21 22:54:15 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Mon, 21 May 2012 22:54:15 +0200
Subject: [MPlayer-dev-eng] [PATCH] compile as PIE by default
Message-ID: <20120521205415.GA31770@1und1.de>

Hello,
below patch would compile MPlayer as PIE on x86 by default.
On 32 bit, the cost would only be in a larger binary size and having to do
relocations at startup, but no real cost at runtime.
On 64 bit, there is almost no size or runtime overhead, mostly that
in some cases PIC-relative addressing has to be used.
I believe that none of the assembler code will be disabled by either.
I have not made any changes to other architectures since I can't
judge the impact.
A side effect of the 64 bit case is that MPlayer will refuse to link
against some static libraries (those not compiled with PIC and thus violating
the ABI), one example (which only exists as static library) is LIVE555
as provided by Debian.
Another point is that backtraces without debug info will probably be
even less useful.
Any comments? My belief is that there is negligible if any disadvantage
for a sometimes significant win in security.

Index: configure
===================================================================
--- configure	(revision 34955)
+++ configure	(working copy)
@@ -2643,6 +2643,22 @@
 fi
 
 
+# try to create a relocatable binary by default
+echocheck "relocatable binary"
+if x86_32 && cflag_check -pie ; then
+  extra_ldflags="$extra_ldflags -pie"
+  relocatable=yes
+  res_comment="non-PIC"
+elif x86_64 && cflag_check -fpie -pie ; then
+  extra_ldflags="$extra_ldflags -fpie -pie"
+  extra_cflags="$extra_cflags -fpie"
+  relocatable=yes
+  res_comment="fast PIC"
+else
+  relocatable=no
+  res_comment="unavailable or untested architecture"
+fi
+echores $relocatable
 
 if x86_32 ; then
   # Checking assembler (_as) compatibility...


From ib at wupperonline.de  Tue May 22 00:24:34 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 22 May 2012 00:24:34 +0200
Subject: [MPlayer-dev-eng] [PATCH] Plaintext playlist parsing
Message-ID: <4fbac102.529d2b7c.bm000@wupperonline.de>

I'm missing plaintext playlist parsing. Is this patch ok or should it be
somehow restricted to the GUI (use_gui)?

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

From eclipse7 at gmx.net  Tue May 22 00:43:42 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Tue, 22 May 2012 00:43:42 +0200
Subject: [MPlayer-dev-eng] [PATCH 0/2] configure fixes
In-Reply-To: <cover.1336850969.git.eclipse7@gmx.net>
References: <cover.1336850969.git.eclipse7@gmx.net>
Message-ID: <20120521224341.GA2778@akuma>

Alexander Strasser wrote:
>   While testing on Cygwin I stumbled over 2 problems
> this patch series tries to solve.
> 
>   These patches apply to both the code base from the 1.1
> release preview and current SVN.
> 
>   For the first patch I do not know if it is the best
> solution, but it was the first Idea that came to mind
> and it worked fine. I tested vo directx with and without
> hwaccel and the module worked fine here AFAICT.
> 
>   Please let me know what you think about it.
> 
> Alexander Strasser (2):
>   build: Fix vo directx compilation on Cygwin

  Applied this one as there were no objections and it
makes things easier for people (including me).

>   build: Update SDL test to check for new features

  This one is dropped.
  Thanks for the alternative fix go to Reimar!


  Alexander

From eclipse7 at gmx.net  Tue May 22 00:56:14 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Tue, 22 May 2012 00:56:14 +0200
Subject: [MPlayer-dev-eng] [PATCH] compile as PIE by default
In-Reply-To: <20120521205415.GA31770@1und1.de>
References: <20120521205415.GA31770@1und1.de>
Message-ID: <20120521225614.GB2778@akuma>

Hello Reimar,

Reimar D?ffinger wrote:
> below patch would compile MPlayer as PIE on x86 by default.
> On 32 bit, the cost would only be in a larger binary size and having to do
> relocations at startup, but no real cost at runtime.
> On 64 bit, there is almost no size or runtime overhead, mostly that
> in some cases PIC-relative addressing has to be used.
> I believe that none of the assembler code will be disabled by either.
> I have not made any changes to other architectures since I can't
> judge the impact.
> A side effect of the 64 bit case is that MPlayer will refuse to link
> against some static libraries (those not compiled with PIC and thus violating
> the ABI), one example (which only exists as static library) is LIVE555
> as provided by Debian.
> Another point is that backtraces without debug info will probably be
> even less useful.
> Any comments? My belief is that there is negligible if any disadvantage
> for a sometimes significant win in security.

  Sounds reasonable, judging from what you say. I cannot evaluate the
ramifications myself. So no strong opinions on my side.

  Waiting a bit for more informed comments, may be better though.

  Alexander

From ikalvachev at gmail.com  Tue May 22 03:27:12 2012
From: ikalvachev at gmail.com (Ivan Kalvachev)
Date: Tue, 22 May 2012 04:27:12 +0300
Subject: [MPlayer-dev-eng] [PATCH] compile as PIE by default
In-Reply-To: <20120521205415.GA31770@1und1.de>
References: <20120521205415.GA31770@1und1.de>
Message-ID: <CABA=pqdeFFQDxKwuQdPiH9D1iFHa_dF-t9wBHdNCP8vhvDFCuA@mail.gmail.com>

On 5/21/12, Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:
> Hello,
> below patch would compile MPlayer as PIE on x86 by default.
> On 32 bit, the cost would only be in a larger binary size and having to do
> relocations at startup, but no real cost at runtime.
> On 64 bit, there is almost no size or runtime overhead, mostly that
> in some cases PIC-relative addressing has to be used.
> I believe that none of the assembler code will be disabled by either.
> I have not made any changes to other architectures since I can't
> judge the impact.
> A side effect of the 64 bit case is that MPlayer will refuse to link
> against some static libraries (those not compiled with PIC and thus
> violating
> the ABI), one example (which only exists as static library) is LIVE555
> as provided by Debian.
> Another point is that backtraces without debug info will probably be
> even less useful.
> Any comments? My belief is that there is negligible if any disadvantage
> for a sometimes significant win in security.
>
> Index: configure
> ===================================================================
> --- configure	(revision 34955)
> +++ configure	(working copy)
> @@ -2643,6 +2643,22 @@
>  fi
>
>
> +# try to create a relocatable binary by default
> +echocheck "relocatable binary"
> +if x86_32 && cflag_check -pie ; then
> +  extra_ldflags="$extra_ldflags -pie"
> +  relocatable=yes
> +  res_comment="non-PIC"
> +elif x86_64 && cflag_check -fpie -pie ; then
> +  extra_ldflags="$extra_ldflags -fpie -pie"
> +  extra_cflags="$extra_cflags -fpie"
> +  relocatable=yes
> +  res_comment="fast PIC"
> +else
> +  relocatable=no
> +  res_comment="unavailable or untested architecture"
> +fi
> +echores $relocatable
>
>  if x86_32 ; then
>    # Checking assembler (_as) compatibility...

Without researching the topic.
Would the above check fail if --enable-static is used?
I think there must be a way to disable this with configure option,
e.g. --disable-pie

Have you tested it with the win32loader?

From Reimar.Doeffinger at gmx.de  Tue May 22 09:20:23 2012
From: Reimar.Doeffinger at gmx.de (=?utf-8?Q?Reimar_D=C3=B6ffinger?=)
Date: Tue, 22 May 2012 09:20:23 +0200
Subject: [MPlayer-dev-eng] [PATCH] compile as PIE by default
In-Reply-To: <CABA=pqdeFFQDxKwuQdPiH9D1iFHa_dF-t9wBHdNCP8vhvDFCuA@mail.gmail.com>
References: <20120521205415.GA31770@1und1.de>
	<CABA=pqdeFFQDxKwuQdPiH9D1iFHa_dF-t9wBHdNCP8vhvDFCuA@mail.gmail.com>
Message-ID: <807CCBA5-E6C1-40FD-946D-2CFD3EE6849A@gmx.de>

On 22 May 2012, at 03:27, Ivan Kalvachev <ikalvachev at gmail.com> wrote:
> On 5/21/12, Reimar D?ffinger <Reimar.Doeffinger at gmx.de> wrote:
>> Hello,
>> below patch would compile MPlayer as PIE on x86 by default.
>> On 32 bit, the cost would only be in a larger binary size and having to do
>> relocations at startup, but no real cost at runtime.
>> On 64 bit, there is almost no size or runtime overhead, mostly that
>> in some cases PIC-relative addressing has to be used.
>> I believe that none of the assembler code will be disabled by either.
>> I have not made any changes to other architectures since I can't
>> judge the impact.
>> A side effect of the 64 bit case is that MPlayer will refuse to link
>> against some static libraries (those not compiled with PIC and thus
>> violating
>> the ABI), one example (which only exists as static library) is LIVE555
>> as provided by Debian.
>> Another point is that backtraces without debug info will probably be
>> even less useful.
>> Any comments? My belief is that there is negligible if any disadvantage
>> for a sometimes significant win in security.
>> 
>> Index: configure
>> ===================================================================
>> --- configure    (revision 34955)
>> +++ configure    (working copy)
>> @@ -2643,6 +2643,22 @@
>> fi
>> 
>> 
>> +# try to create a relocatable binary by default
>> +echocheck "relocatable binary"
>> +if x86_32 && cflag_check -pie ; then
>> +  extra_ldflags="$extra_ldflags -pie"
>> +  relocatable=yes
>> +  res_comment="non-PIC"
>> +elif x86_64 && cflag_check -fpie -pie ; then
>> +  extra_ldflags="$extra_ldflags -fpie -pie"
>> +  extra_cflags="$extra_cflags -fpie"
>> +  relocatable=yes
>> +  res_comment="fast PIC"
>> +else
>> +  relocatable=no
>> +  res_comment="unavailable or untested architecture"
>> +fi
>> +echores $relocatable
>> 
>> if x86_32 ; then
>>   # Checking assembler (_as) compatibility...
> 
> Without researching the topic.
> Would the above check fail if --enable-static is used?

I'll have to test, though it really shouldn't, these are orthogonal things (even though I admit it is a bit confusing).

> I think there must be a way to disable this with configure option,
> e.g. --disable-pie

Agreed in principle, I was too lazy to do it for an RFC oatch.

> Have you tested it with the win32loader?

Was a long time ago, so I don't remember. However we have no win32loader for 64 bit, and for 32 bit it is a link only option, so compiling should work.
The only issue should be that loading some dlls might randomly fail if MPlayer by chance is placed at the location where the dll needs to be loaded. Disabling address randomization for MPlayer would fix it, even if it eliminates the advantage.

From ib at wupperonline.de  Tue May 22 11:18:44 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 22 May 2012 11:18:44 +0200
Subject: [MPlayer-dev-eng] [PATCH] Plaintext playlist parsing
In-Reply-To: <4fbac102.529d2b7c.bm000@wupperonline.de>
Message-ID: <4fbb5b19.2031979d.bm000@wupperonline.de>

I wrote on Tue, 22 May 2012 00:24:34 +0200:

> Is this patch ok or should it be somehow restricted to the GUI (use_gui)?

Yeah, I think

  entry      = parse_playtree(mpctx->stream, use_gui);

is probably much better, because it doesn't change the current (non-GUI)
behaviour.

Ingo

From zongyao.qu at gmail.com  Tue May 22 16:16:03 2012
From: zongyao.qu at gmail.com (Zongyao Qu)
Date: Tue, 22 May 2012 23:16:03 +0900
Subject: [MPlayer-dev-eng] [Patch] live555 configure error
Message-ID: <CAJNu5+ju-a1zokAZz-+dyyGT7ZMRZZu5hHSDc_Fun70Zf3nvNA@mail.gmail.com>

I found live555 checking is extended, but libliveMedia.a is forgotten.
as a result, live555 will never get passed.

this patch is going to fix this.

Best Regards,
Zongyao QU
-------------- next part --------------
A non-text attachment was scrubbed...
Name: configure.diff
Type: application/octet-stream
Size: 1199 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120522/022c8dfe/attachment.obj>

From Reimar.Doeffinger at gmx.de  Tue May 22 19:52:15 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 22 May 2012 19:52:15 +0200
Subject: [MPlayer-dev-eng] [Patch] live555 configure error
In-Reply-To: <CAJNu5+ju-a1zokAZz-+dyyGT7ZMRZZu5hHSDc_Fun70Zf3nvNA@mail.gmail.com>
References: <CAJNu5+ju-a1zokAZz-+dyyGT7ZMRZZu5hHSDc_Fun70Zf3nvNA@mail.gmail.com>
Message-ID: <20120522175215.GA6296@1und1.de>

On Tue, May 22, 2012 at 11:16:03PM +0900, Zongyao Qu wrote:
> I found live555 checking is extended, but libliveMedia.a is forgotten.
> as a result, live555 will never get passed.
> 
> this patch is going to fix this.

Thanks, fixed differently in r34960, I really dislike the duplication.
Can you test that it actually works? I have only the "distribution
version" so the test always worked for me...

From Reimar.Doeffinger at gmx.de  Tue May 22 19:57:09 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 22 May 2012 19:57:09 +0200
Subject: [MPlayer-dev-eng] [PATCH] Plaintext playlist parsing
In-Reply-To: <4fbb5b19.2031979d.bm000@wupperonline.de>
References: <4fbac102.529d2b7c.bm000@wupperonline.de>
	<4fbb5b19.2031979d.bm000@wupperonline.de>
Message-ID: <20120522175709.GB6296@1und1.de>

On Tue, May 22, 2012 at 11:18:44AM +0200, Ingo Br?ckl wrote:
> I wrote on Tue, 22 May 2012 00:24:34 +0200:
> 
> > Is this patch ok or should it be somehow restricted to the GUI (use_gui)?
> 
> Yeah, I think
> 
>   entry      = parse_playtree(mpctx->stream, use_gui);
> 
> is probably much better, because it doesn't change the current (non-GUI)
> behaviour.

I am not sure this is a good idea at all, even for the GUI.
The problem is that there is no sanity checking at all for plain text
playlist.
Imagine if someone by accident gets a DVD image in there, I am sure
really bad things will happen (like a few million or so playlist
entries, using up loads of memory, swapping, possibly even
out-of-memory crashes).
At least I really hate it when programs can't deal with me having
too thick fingers and click on the wrong file (since I don't use
gmplayer I don't really care, but still).

From ib at wupperonline.de  Tue May 22 23:18:48 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 22 May 2012 23:18:48 +0200
Subject: [MPlayer-dev-eng] [PATCH] Plaintext playlist parsing
In-Reply-To: <20120522175709.GB6296@1und1.de>
Message-ID: <4fbc05f8.0c1e0a22.bm000@wupperonline.de>

Reimar D?ffinger wrote on Tue, 22 May 2012 19:57:09 +0200:

> On Tue, May 22, 2012 at 11:18:44AM +0200, Ingo Br?ckl wrote:
>> I wrote on Tue, 22 May 2012 00:24:34 +0200:
>>
>> > Is this patch ok or should it be somehow restricted to the GUI (use_gui)?
>>
>> Yeah, I think
>>
>>   entry      = parse_playtree(mpctx->stream, use_gui);
>>
>> is probably much better, because it doesn't change the current (non-GUI)
>> behaviour.

> I am not sure this is a good idea at all, even for the GUI.
> The problem is that there is no sanity checking at all for plain text
> playlist.
> Imagine if someone by accident gets a DVD image in there, I am sure
> really bad things will happen (like a few million or so playlist
> entries, using up loads of memory, swapping, possibly even
> out-of-memory crashes).

I'm aware of this, but since this additional plain text playlist parsing will
only happen if the user selects from the "Playlists" filter of the file
selector it's up to him to deal with the consequences if he selects something
that is not a playlist (but having a playlist extension, as the selection is
limited). There isn't much more that (security-wise) can be done in order to
allow playlists with the GUI. (And if you're using option -playlist by
accident with a DVD image and plain MPlayer, well, the same bad things will
happen.)

The "Playlists" filter is the GUI's equivalent to the -playlist option.

> (since I don't use gmplayer I don't really care, but still).

I really get your point and share your concerns, but I think the limitation
to the "Playlists" filter for this feature makes the risks acceptable.

So, ok to commit?

Ingo

From zongyao.qu at gmail.com  Wed May 23 15:04:00 2012
From: zongyao.qu at gmail.com (Zongyao Qu)
Date: Wed, 23 May 2012 13:04:00 +0000 (UTC)
Subject: [MPlayer-dev-eng] [Patch] live555 configure error
References: <CAJNu5+ju-a1zokAZz-+dyyGT7ZMRZZu5hHSDc_Fun70Zf3nvNA@mail.gmail.com>
	<20120522175215.GA6296@1und1.de>
Message-ID: <loom.20120523T150308-110@post.gmane.org>


> Can you test that it actually works? I have only the "distribution
> version" so the test always worked for me...
> 
tested. Worked as it should be, pass the old version and refuse
the new version of live555.
Thank you.




From eclipse7 at gmx.net  Thu May 24 00:22:33 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Thu, 24 May 2012 00:22:33 +0200
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <20120512191909.GA4953@akuma>
References: <20120506120457.GA22808@1und1.de> <20120509012520.GB2832@akuma>
	<20120512191909.GA4953@akuma>
Message-ID: <20120523222233.GB3539@akuma>

Alexander Strasser wrote:
> Alexander Strasser wrote:
> > Reimar D?ffinger wrote:
> > > we decided it is time to do a release again.
> > [...]
> > > 
> > > And here's the tarball for you to test:
> > > http://www1.mplayerhq.hu/MPlayer/releases/MPlayer-1.1_testing_only.tar.bz2
> > 
> >   Builds for me on x86_64 GNU/Linux.
> > 
> >   From a bunch of quick tests mplayer binary seems to work fine.
> > 
> >   Did not yet test mencoder.
> 
>   Build on Cygwin installed on WinXP worked fine too.
> 
>   I have discovered some small problems with configure, so please
> look at the patches I will sent in a new thread.

>   I try to exercise mencoder a bit this weekend, but more regular
> mencoder users are invited to test with their use cases and report!

  I did a bunch of small encodes from DVD material and I can say: it kind
of works. Not sure how good, and if there are any regressions but at least
it can be used.

  Alexander

From rxt at rtogni.it  Fri May 25 00:37:18 2012
From: rxt at rtogni.it (Roberto Togni)
Date: Fri, 25 May 2012 00:37:18 +0200
Subject: [MPlayer-dev-eng] [PATCH] ralf support with native demuxer
Message-ID: <20120525003718.0f294624@blacktower.myhome.qwe>

Hi,
 this adds support for ralf codec (ffmpeg decoder only, not the binary 
dll) to our real demuxer.

Tested with the two ralf sample that I have.


I'll apply it in a few days if no comments (and if my svn account still
works).

Ciao,
 Roberto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ralf.patch
Type: text/x-patch
Size: 1575 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120525/afc1044a/attachment.bin>

From stefano.pigozzi at gmail.com  Fri May 25 10:45:30 2012
From: stefano.pigozzi at gmail.com (Stefano Pigozzi)
Date: Fri, 25 May 2012 10:45:30 +0200
Subject: [MPlayer-dev-eng] Release 1.1 first packaging attempt
In-Reply-To: <20120506120457.GA22808@1und1.de>
References: <20120506120457.GA22808@1und1.de>
Message-ID: <CACZO2wHJpVXq5Ow05kxeDr9mn4hu6qYWypxgceNWT2dydiS0=w@mail.gmail.com>

On Sun, May 6, 2012 at 2:04 PM, Reimar D?ffinger
<Reimar.Doeffinger at gmx.de>wrote:

> 1) We generally need a lot of testing to check that there are no too
> serious issues.
>

I compiled the tarball on Mac OSX Lion (Xcode 4.3):
 -  clang 3.1 compiles and works correctly. When cc is clang (so you don't
have to call configure with --cc=clang) there is a fair amount of spam like
this:
clang: warning: argument unused during compilation: '-falign-loops=16'
clang: warning: argument unused during compilation: '-shared-libgcc'

This is because the configure script adds those flags basing the choice on
$_cc instead of $cc_vendor.

 -  llvm-gcc-4.2.1: there's the usual problem when linking vf_fspp:
Undefined symbols for architecture x86_64:
  "_MM_FIX_0_707106781", referenced from:
      _filter in vf_fspp.o
  "_MM_FIX_0_541196100", referenced from:
      _filter in vf_fspp.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [mplayer] Error 1

This ticket (http://ffmpeg.org/trac/ffmpeg/ticket/353) contains all the
interesting information about this issue. I'll try to make a patch for
libav/ffmpeg in the following days, the fix is really simple.

From Reimar.Doeffinger at gmx.de  Fri May 25 22:56:05 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Fri, 25 May 2012 22:56:05 +0200
Subject: [MPlayer-dev-eng] [PATCH] ralf support with native demuxer
In-Reply-To: <20120525003718.0f294624@blacktower.myhome.qwe>
References: <20120525003718.0f294624@blacktower.myhome.qwe>
Message-ID: <20120525205604.GA16314@1und1.de>

On Fri, May 25, 2012 at 12:37:18AM +0200, Roberto Togni wrote:
> I'll apply it in a few days if no comments (and if my svn account still
> works).

It should, and nice to see you're still around :-)
I think you can just go ahead and commit.

> +		    sh->wf->nChannels = 0;//sh->channels;
> +		    sh->wf->wBitsPerSample = 16;
> +		    sh->wf->nSamplesPerSec = 0;//sh->samplerate;
> +		    sh->wf->nAvgBytesPerSec = 0;//bitrate;
> +		    sh->wf->nBlockAlign = 0;//frame_size;

I don't see the point of the comments though.

> +		    stream_read(demuxer->stream, ((char*)(sh->wf+1)), codec_data_size);

The outermost () are not really necessary.

> +		    if(demuxer->audio->id==stream_id){
> +			    sh->ds=demuxer->audio;
> +			    demuxer->audio->sh=sh;
> +		    }

Since that's probably a copy from other code in the file it's kind of unrelated,
but I think this kind of code shouldn't be necessary anymore, it is
already handled in new_sh_audio nowadays.

From eclipse7 at gmx.net  Sat May 26 01:45:19 2012
From: eclipse7 at gmx.net (Alexander Strasser)
Date: Sat, 26 May 2012 01:45:19 +0200
Subject: [MPlayer-dev-eng] [PATCH] ralf support with native demuxer
In-Reply-To: <20120525003718.0f294624@blacktower.myhome.qwe>
References: <20120525003718.0f294624@blacktower.myhome.qwe>
Message-ID: <20120525234519.GA3157@akuma>

Hi Roberto,

Roberto Togni wrote:
>  this adds support for ralf codec (ffmpeg decoder only, not the binary 
> dll) to our real demuxer.
> 
> Tested with the two ralf sample that I have.

  Patch looks good to me. 

  I noticed 2 minor points that should *not* be addressed in this patch:
  1) realloc is not used properly (failure case)
     not sure if it wouldn't even be better to solve it without the realloc
  2) the formatting of the (whole?) file is a bit weird
     - mix of tabs and spaces
     - probably more...
 
> I'll apply it in a few days if no comments (and if my svn account still
> works).

  If it doesn't work, please complain here. It will for sure be fixed :)
 
[...]

  Alexander

From rxt at rtogni.it  Sat May 26 20:00:34 2012
From: rxt at rtogni.it (Roberto Togni)
Date: Sat, 26 May 2012 20:00:34 +0200
Subject: [MPlayer-dev-eng] [PATCH] ralf support with native demuxer
In-Reply-To: <20120525003718.0f294624@blacktower.myhome.qwe>
References: <20120525003718.0f294624@blacktower.myhome.qwe>
Message-ID: <20120526200034.55a8518d@blacktower.myhome.qwe>

On Fri, 25 May 2012 00:37:18 +0200
Roberto Togni <rxt at rtogni.it> wrote:

Revised patch attached: useless comments removed and without realloc.

Also removed the 
> +		    if(demuxer->audio->id==stream_id){
> +			    sh->ds=demuxer->audio;
> +			    demuxer->audio->sh=sh;
> +		    }  
code, it works even without it.

Since most of this patch was copy&paste from other parts of the file,
should I remove this code also elsewhere? I'm not really up to date with
the lates api changes.

Same applies to the realloc: is it just lacking the check for failed
allocation, or is there some bigger issue?


Ciao,
 Roberto
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ralf.patch
Type: text/x-patch
Size: 1354 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120526/05c09018/attachment.bin>

From Reimar.Doeffinger at gmx.de  Sat May 26 20:21:41 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 26 May 2012 20:21:41 +0200
Subject: [MPlayer-dev-eng] [PATCH] ralf support with native demuxer
In-Reply-To: <20120526200034.55a8518d@blacktower.myhome.qwe>
References: <20120525003718.0f294624@blacktower.myhome.qwe>
	<20120526200034.55a8518d@blacktower.myhome.qwe>
Message-ID: <20120526182141.GA4047@1und1.de>

On Sat, May 26, 2012 at 08:00:34PM +0200, Roberto Togni wrote:
> Since most of this patch was copy&paste from other parts of the file,
> should I remove this code also elsewhere? I'm not really up to date with
> the lates api changes.

It's a really old change, but yes, it should be removed everywhere.
Note this applies to code like this that handles explicit selection
of a stream, like what happens with -aid 1 or -vid 2 or such.
The code to auto-select a most suitable (i.e. when the "chosen" id is
-1) needs to stay, new_sh_* can't really chose the "most suitable"
stream on its own, that kind of code needs to be in the demuxer (well,
I was thinking about making it select the first one by default and
just allowing the demuxer to override it, but I don't think I ever did
that).

From Reimar.Doeffinger at gmx.de  Sat May 26 20:55:41 2012
From: Reimar.Doeffinger at gmx.de (=?UTF-8?q?Reimar=20D=C3=B6ffinger?=)
Date: Sat, 26 May 2012 20:55:41 +0200
Subject: [MPlayer-dev-eng] [PATCH] Build as relocatable PIE binary by
	default on x86.
In-Reply-To: <CABA=pqdeFFQDxKwuQdPiH9D1iFHa_dF-t9wBHdNCP8vhvDFCuA@mail.gmail.com>
References: <CABA=pqdeFFQDxKwuQdPiH9D1iFHa_dF-t9wBHdNCP8vhvDFCuA@mail.gmail.com>
Message-ID: <1338058541-22570-1-git-send-email-Reimar.Doeffinger@gmx.de>

---
 configure |   31 +++++++++++++++++++++++++++++++
 1 file changed, 31 insertions(+)

diff --git a/configure b/configure
index 722b8a4..5b150f5 100755
--- a/configure
+++ b/configure
@@ -596,6 +596,7 @@ Advanced options:
   --enable-debug[=1-3]      compile-in debugging information [disable]
   --enable-profile          compile-in profiling information [disable]
   --disable-sighandler      disable sighandler for crashes [enable]
+  --disable-relocatable     disable compiling as relocatable/PIE executable [autodetect]
   --enable-crash-debug      enable automatic gdb attach on crash [disable]
   --enable-dynamic-plugins  enable dynamic A/V plugins [disable]
 
@@ -842,6 +843,7 @@ _charset="UTF-8"
 _dynamic_plugins=no
 _crash_debug=no
 _sighandler=yes
+relocatable=auto
 _libdv=auto
 _cdparanoia=auto
 _cddb=auto
@@ -1422,6 +1424,8 @@ for ac_option do
   --disable-crash-debug) _crash_debug=no ;;
   --enable-sighandler)  _sighandler=yes  ;;
   --disable-sighandler) _sighandler=no   ;;
+  --enable-relocatable)  relocatable=yes  ;;
+  --disable-relocatable) relocatable=no   ;;
   --enable-win32dll) _win32dll=yes ;;
   --disable-win32dll) _win32dll=no ;;
 
@@ -2643,6 +2647,33 @@ if test -n "$CPPFLAGS" ; then
 fi
 
 
+# try to create a relocatable binary by default
+echocheck "relocatable binary"
+if test $relocatable = "auto" ; then
+  if x86_32 && cflag_check -pie ; then
+    extra_ldflags="$extra_ldflags -pie"
+    relocatable=yes
+    res_comment="non-PIC"
+  elif x86_64 && cflag_check -fpie -pie ; then
+    extra_ldflags="$extra_ldflags -fpie -pie"
+    extra_cflags="$extra_cflags -fpie"
+    relocatable=yes
+    res_comment="fast PIC"
+  else
+    relocatable=no
+    res_comment="unavailable or untested architecture"
+  fi
+elif test $relocatable = "yes" ; then
+  if return_check "stdint.h" '(intptr_t)"test" >> 16' -pie ; then
+    extra_ldflags="$extra_ldflags -pie"
+    res_comment="non-PIC"
+  else
+    extra_ldflags="$extra_ldflags -fpie -pie"
+    extra_cflags="$extra_cflags -fpie"
+    res_comment="possibly slow PIC!"
+  fi
+fi
+echores $relocatable
 
 if x86_32 ; then
   # Checking assembler (_as) compatibility...
-- 
1.7.10


From Reimar.Doeffinger at gmx.de  Sat May 26 21:05:28 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Sat, 26 May 2012 21:05:28 +0200
Subject: [MPlayer-dev-eng] [PATCH] compile as PIE by default
In-Reply-To: <CABA=pqdeFFQDxKwuQdPiH9D1iFHa_dF-t9wBHdNCP8vhvDFCuA@mail.gmail.com>
References: <20120521205415.GA31770@1und1.de>
	<CABA=pqdeFFQDxKwuQdPiH9D1iFHa_dF-t9wBHdNCP8vhvDFCuA@mail.gmail.com>
Message-ID: <20120526190528.GA29902@1und1.de>

On Tue, May 22, 2012 at 04:27:12AM +0300, Ivan Kalvachev wrote:
> Without researching the topic.
> Would the above check fail if --enable-static is used?

This is very irritating. For 32 bit, --enable-static just fine creates a file
about which "ldd" says "statically linked", and "file" says is
relocatable (well, and also that it is dynamically linked), and
everything seems fine except that trying to execute it results
in "bash: ./mplayer: No such file or directory". WTF?
I can't test for 64 bit, because at least my system there is no static
crt available that is compatible with PIE, thus the feature is disabled:
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/4.7/crtbeginT.o: relocation
R_X86_64_32 against `__TMC_END__' can not be used when making a shared
object; recompile with -fPIC
Obviously nobody bothered to in the slightest bit test -pie with
-static, even though that combination very much makes sense (even if
not when you take the names literally)...

From ib at wupperonline.de  Tue May 29 17:59:25 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Tue, 29 May 2012 17:59:25 +0200
Subject: [MPlayer-dev-eng] Crash with unsharp filter and x264 mp4 files
Message-ID: <4fc4f2eb.4d9c1a68.bm000@wupperonline.de>

Since a short time ago (can't exactly say since when) I'm noticing a strange
behaviour with x264 encoded mp4 video files which I blamed the files for,
thinking they were buggy, but they aren't.

When playing those files with the unsharp filter (l7x7:1.7), there are some
greenish stripes at the top of the video and after a while MPlayer crashes
after printing "Ran out of numbered images, expect crash. Filter before vo
is broken." Without the filter, everything is fine.

You can experience this with one of our sample files, namely
http://samples.mplayerhq.hu/V-codecs/h264/mp4_h264/h264_parser.mp4
although this sample is too short to cause the crash.

I've had an issue with this filter once before (some alignment issue on
ffmpeg's side if I remember correctly). Any idea what it might be this time
(side effect of recent changes concerning frames / direct rendering?) or
what I should do to track it down?

Ingo

From Reimar.Doeffinger at gmx.de  Tue May 29 19:48:48 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Tue, 29 May 2012 19:48:48 +0200
Subject: [MPlayer-dev-eng] Crash with unsharp filter and x264 mp4 files
In-Reply-To: <4fc4f2eb.4d9c1a68.bm000@wupperonline.de>
References: <4fc4f2eb.4d9c1a68.bm000@wupperonline.de>
Message-ID: <20120529174848.GA3698@1und1.de>

On Tue, May 29, 2012 at 05:59:25PM +0200, Ingo Br?ckl wrote:
> When playing those files with the unsharp filter (l7x7:1.7), there are some
> greenish stripes at the top of the video

That means it passes on the wrong size to get_image when doing direct
rendering, see the recent change to vf_ass.c

> and after a while MPlayer crashes
> after printing "Ran out of numbered images, expect crash. Filter before vo
> is broken." Without the filter, everything is fine.

Does that still happen? It means that the usage count tracking is
incorrect, however I haven't been able to trigger that case anymore
with latest SVN.
I guess this means we should rather disable the nonref_dr feature for
the release...

From ib at wupperonline.de  Wed May 30 18:21:03 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 30 May 2012 18:21:03 +0200
Subject: [MPlayer-dev-eng] Crash with unsharp filter and x264 mp4 files
In-Reply-To: <20120529174848.GA3698@1und1.de>
Message-ID: <4fc65d1d.68af7c2a.bm000@wupperonline.de>

Reimar D?ffinger wrote on Tue, 29 May 2012 19:48:48 +0200:

> On Tue, May 29, 2012 at 05:59:25PM +0200, Ingo Br?ckl wrote:
>> When playing those files with the unsharp filter (l7x7:1.7), there are some
>> greenish stripes at the top of the video

> That means it passes on the wrong size to get_image when doing direct
> rendering, see the recent change to vf_ass.c

The attached patch (by analogy with vf_ass.c) fixes the greenish stripes (if
it's ok I'd like to commit), but...

>> and after a while MPlayer crashes after printing "Ran out of numbered
>> images, expect crash. Filter before vo is broken." Without the filter,
>> everything is fine.

...it doesn't fix this crash.

> Does that still happen? It means that the usage count tracking is
> incorrect, however I haven't been able to trigger that case anymore
> with latest SVN.

Reverting r34949 fixes the crash.

Prior to r34949, number in vf.c's vf_get_image() is always 0, causing the
usage of just the first vf->imgctx.numbered_images. After r34949, number is
always -1, causing the search for a "free" vf->imgctx.numbered_images. This
is very often the first one (index 0) as well, but sometimes the first ones
aren't "free" and the longer the video plays, this number increases. (I have
actually no idea what I'm talking about here.)

Please see the log. Variable 'number' is printed at three different stages:

### number: -1          // this is the assignment at line 281
### number is -1        // this is after case MP_IMGTYPE_NUMBERED
### number set 0        // this is the assignment at line 334

This log is from start of the video until the crash. Maybe it helps. It is
interesting (at least to me) that the call prior to the crash used index 0,
and the next call couldn't find a "free" vf->imgctx.numbered_images, ending
with 50, so between two calls all the vf->imgctx.numbered_images have been
used up.

Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: vf_unsharp.patch
Type: text/x-diff
Size: 639 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20120530/63829645/attachment.bin>
-------------- next part --------------
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 2
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 2
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 3
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 4
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 4
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 5
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 6
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 6
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 6
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 6
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 7
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 8
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 8
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 8
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 8
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 9
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 9
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 9
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 9
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 10
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 10
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 11
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 11
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 12
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 12
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 13
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 14
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 15
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 16
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 17
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 18
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 18
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 18
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 19
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 20
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 20
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 21
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 21
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 22
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 22
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 23
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 23
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 24
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 24
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 24
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 24
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 25
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 26
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 26
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 27
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 28
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 29
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 30
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 31
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 32
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 33
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 34
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 34
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 35
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 36
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 37
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 38
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 39
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 40
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 40
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 41
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 41
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 42
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 42
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 43
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 43
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 44
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 44
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 45
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 45
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 46
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 46
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 47
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 47
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 48
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 48
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 49
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 49
### number: -1
### number: -1
### number: -1
### number: -1
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 0
### number: -1
### number is -1
### number set 50

From Reimar.Doeffinger at gmx.de  Wed May 30 20:57:26 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 30 May 2012 20:57:26 +0200
Subject: [MPlayer-dev-eng] Crash with unsharp filter and x264 mp4 files
In-Reply-To: <4fc65d1d.68af7c2a.bm000@wupperonline.de>
References: <20120529174848.GA3698@1und1.de>
	<4fc65d1d.68af7c2a.bm000@wupperonline.de>
Message-ID: <20120530185726.GB3045@1und1.de>

On Wed, May 30, 2012 at 06:21:03PM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Tue, 29 May 2012 19:48:48 +0200:
> 
> > On Tue, May 29, 2012 at 05:59:25PM +0200, Ingo Br?ckl wrote:
> >> When playing those files with the unsharp filter (l7x7:1.7), there are some
> >> greenish stripes at the top of the video
> 
> > That means it passes on the wrong size to get_image when doing direct
> > rendering, see the recent change to vf_ass.c
> 
> The attached patch (by analogy with vf_ass.c) fixes the greenish stripes (if
> it's ok I'd like to commit), but...

There is no need for max, mpi->width must/will always be >= mpi->w
(basically, width is the allocate dimension and w the used dimension).

> >> and after a while MPlayer crashes after printing "Ran out of numbered
> >> images, expect crash. Filter before vo is broken." Without the filter,
> >> everything is fine.
> 
> ...it doesn't fix this crash.
> 
> > Does that still happen? It means that the usage count tracking is
> > incorrect, however I haven't been able to trigger that case anymore
> > with latest SVN.
> 
> Reverting r34949 fixes the crash.
> 
> Prior to r34949, number in vf.c's vf_get_image() is always 0, causing the
> usage of just the first vf->imgctx.numbered_images.

Obviously resulting in completely wrong output.
I know kind of what is going on, but not why.
My problem is that I can't reproduce it, can you please give exact
instructions for reproducing?
The most obvious explanation is that the decoder is allocating
frames that are never output.

From ib at wupperonline.de  Wed May 30 21:55:41 2012
From: ib at wupperonline.de (=?ISO-8859-1?Q?Ingo=20Br=FCckl?=)
Date: Wed, 30 May 2012 21:55:41 +0200
Subject: [MPlayer-dev-eng] Crash with unsharp filter and x264 mp4 files
In-Reply-To: <20120530185726.GB3045@1und1.de>
Message-ID: <4fc67cd3.3d900317.bm000@wupperonline.de>

Reimar D?ffinger wrote on Wed, 30 May 2012 20:57:26 +0200:

> There is no need for max, mpi->width must/will always be >= mpi->w
> (basically, width is the allocate dimension and w the used dimension).

So this patch should be ok?

> Obviously resulting in completely wrong output.
> I know kind of what is going on, but not why.
> My problem is that I can't reproduce it, can you please give exact
> instructions for reproducing?

I've sent you a small sample (as email). Play it with 'mplayer -vf-add
unsharp=l7x7:1.7' and soon it will crash.

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

From Reimar.Doeffinger at gmx.de  Wed May 30 22:17:51 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 30 May 2012 22:17:51 +0200
Subject: [MPlayer-dev-eng] Crash with unsharp filter and x264 mp4 files
In-Reply-To: <4fc67cd3.3d900317.bm000@wupperonline.de>
References: <20120530185726.GB3045@1und1.de>
	<4fc67cd3.3d900317.bm000@wupperonline.de>
Message-ID: <20120530201751.GB5223@1und1.de>

On Wed, May 30, 2012 at 09:55:41PM +0200, Ingo Br?ckl wrote:
> Reimar D?ffinger wrote on Wed, 30 May 2012 20:57:26 +0200:
> 
> > There is no need for max, mpi->width must/will always be >= mpi->w
> > (basically, width is the allocate dimension and w the used dimension).
> 
> So this patch should be ok?

I believe so.

> > Obviously resulting in completely wrong output.
> > I know kind of what is going on, but not why.
> > My problem is that I can't reproduce it, can you please give exact
> > instructions for reproducing?
> 
> I've sent you a small sample (as email). Play it with 'mplayer -vf-add
> unsharp=l7x7:1.7' and soon it will crash.

I can reproduce it now.
I have a suspicion that vf_clone_mpi_attributes might be the bad guy
here.

From Reimar.Doeffinger at gmx.de  Wed May 30 23:04:18 2012
From: Reimar.Doeffinger at gmx.de (Reimar =?iso-8859-1?Q?D=F6ffinger?=)
Date: Wed, 30 May 2012 23:04:18 +0200
Subject: [MPlayer-dev-eng] Crash with unsharp filter and x264 mp4 files
In-Reply-To: <20120530201751.GB5223@1und1.de>
References: <20120530185726.GB3045@1und1.de>
	<4fc67cd3.3d900317.bm000@wupperonline.de>
	<20120530201751.GB5223@1und1.de>
Message-ID: <20120530210418.GB7125@1und1.de>

On Wed, May 30, 2012 at 10:17:51PM +0200, Reimar D?ffinger wrote:
> On Wed, May 30, 2012 at 09:55:41PM +0200, Ingo Br?ckl wrote:
> > Reimar D?ffinger wrote on Wed, 30 May 2012 20:57:26 +0200:
> > 
> > > There is no need for max, mpi->width must/will always be >= mpi->w
> > > (basically, width is the allocate dimension and w the used dimension).
> > 
> > So this patch should be ok?
> 
> I believe so.

Note that you should get better performance if you also change the other
one. If you play with -v you should see lots of "REALLOCATE" warnings
due to it.