Here's what I came up with so far.
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng <at> mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Hi Reimar, Reimar Döffinger wrote: > Here's what I came up with so far. sounds good to me so far. I especially like the rather humorous parts :) Some minor remarks follow. > Index: src/dload.en > =================================================================== [...] > Index: src/news.en > =================================================================== > --- src/news.en (revision 3616) > +++ src/news.en (working copy) > <at> <at> -8,6 +8,76 <at> <at> > <div class="newsentry"> > > <h2> > + <a name="mplayer11">2011-01-30, Sunday :: MPlayer 1.1 released</a> > + <br><span class="poster">posted by the <a href="mailto:projects <at> mplayerhq.hu">release team</a></span> > +</h2> > + > +<p> > +We gave up on 1.0 > +</p> > + > +<p> > +After a long pause, we decided that it might be a good idea to make(Continue reading)
Reimar Döffinger wrote: > Also the internal mp3lib copy is no > +longer used by default, also because the codebase has often show issues with the > +newest compilers. However it is still selectable at runtime by default. > +If you do not actually need it consider disabling it at compile time with --disable-mp3lib. Doesn't read too well. Is the issue with new compilers at run time or a build fail?
Am Thu, 07 Jun 2012 21:59:57 +0100 schrieb Andy Furniss <andyqos <at> ukfsn.org>: > Reimar Döffinger wrote: > > > Also the internal mp3lib copy is no > > +longer used by default, also because the codebase has often show issues with the > > +newest compilers. However it is still selectable at runtime by default. > > +If you do not actually need it consider disabling it at compile time with --disable-mp3lib. > > Doesn't read too well. > > Is the issue with new compilers at run time or a build fail? AFAIK, it was build failure. Is there a specific reason that you would rather rely on the mp3lib fork of mpg123 code (some time ago, it was) instead of the libmpg123 binding that replaces it? Also, there is the mp3 decoder in ffmpeg. So, MPlayer doesn't loose functionality here, just code that needed extra maintenance. Alrighty then, Thomas
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng <at> mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Thomas Orgis wrote: > Am Thu, 07 Jun 2012 21:59:57 +0100 > schrieb Andy Furniss <andyqos <at> ukfsn.org>: > >> Reimar Döffinger wrote: >> >>> Also the internal mp3lib copy is no >>> +longer used by default, also because the codebase has often show issues with the >>> +newest compilers. However it is still selectable at runtime by default. >>> +If you do not actually need it consider disabling it at compile time with --disable-mp3lib. >> >> Doesn't read too well. >> >> Is the issue with new compilers at run time or a build fail? > > AFAIK, it was build failure. Is there a specific reason that you would > rather rely on the mp3lib fork of mpg123 code (some time ago, it was) > instead of the libmpg123 binding that replaces it? Also, there is the > mp3 decoder in ffmpeg. So, MPlayer doesn't loose functionality here, > just code that needed extra maintenance. Sorry for any confusion, I should have replied to Alexander. My question was to do with his request for a native English speaker to look over the wording. Anyway given you answer, here's how I would word it. The internal mp3lib copy is no longer used by default, but it is still built by default. This may cause build issues with the newest compilers.(Continue reading)
Am Fri, 08 Jun 2012 13:03:10 +0100 schrieb Andy Furniss <andyqos <at> ukfsn.org>: > Sorry for any confusion, I should have replied to Alexander. > > My question was to do with his request for a native English speaker to > look over the wording. Oh, eh ... sorry for jumping in without the correct context. /me adjusting mail reply firing threshold Alrighty then, Thomas
_______________________________________________ MPlayer-dev-eng mailing list MPlayer-dev-eng <at> mplayerhq.hu https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
On Fri, Jun 08, 2012 at 01:03:10PM +0100, Andy Furniss wrote: > Thomas Orgis wrote: > >Am Thu, 07 Jun 2012 21:59:57 +0100 > >schrieb Andy Furniss <andyqos <at> ukfsn.org>: > > > >>Reimar Döffinger wrote: > >> > >>>Also the internal mp3lib copy is no > >>>+longer used by default, also because the codebase has often show issues with the > >>>+newest compilers. However it is still selectable at runtime by default. > >>>+If you do not actually need it consider disabling it at compile time with --disable-mp3lib. > >> > >>Doesn't read too well. > >> > >>Is the issue with new compilers at run time or a build fail? > > > >AFAIK, it was build failure. Is there a specific reason that you would > >rather rely on the mp3lib fork of mpg123 code (some time ago, it was) > >instead of the libmpg123 binding that replaces it? Also, there is the > >mp3 decoder in ffmpeg. So, MPlayer doesn't loose functionality here, > >just code that needed extra maintenance. > > Sorry for any confusion, I should have replied to Alexander. > > My question was to do with his request for a native English speaker > to look over the wording. > > Anyway given you answer, here's how I would word it. > > The internal mp3lib copy is no longer used by default, but it is(Continue reading)
Reimar Döffinger wrote: [...] > > Thank you all for your comments. > I tried to make it more readable. > While it's up on the homepage already (at least www1.mplayerhq.hu), > comments and suggestions still welcome. Looks good! Thank you for your hard work to push out the release. Alexander
Reimar Döffinger wrote: > Thank you all for your comments. > I tried to make it more readable. > While it's up on the homepage already (at least www1.mplayerhq.hu), > comments and suggestions still welcome. Reads OK to me now.
On Fri, Jun 08, 2012 at 09:10:34AM +0200, Thomas Orgis wrote: > Am Thu, 07 Jun 2012 21:59:57 +0100 > schrieb Andy Furniss <andyqos <at> ukfsn.org>: > > > Reimar Döffinger wrote: > > > > > Also the internal mp3lib copy is no > > > +longer used by default, also because the codebase has often show issues with the > > > +newest compilers. However it is still selectable at runtime by default. > > > +If you do not actually need it consider disabling it at compile time with --disable-mp3lib. > > > > Doesn't read too well. > > > > Is the issue with new compilers at run time or a build fail? > > AFAIK, it was build failure. No, then the solution to disable it only for runtime would be pointless. Usually the reason is something like incorrect asm constraints, leading to hissy decoding for example. There might have been compile issues as well though, but they tend to be much easier to fix.
RSS Feed