headers
compn | 1 May 2008 04:19
Picon
Favicon

Re: Start Volume for mplayer

On Thu, 1 May 2008 00:37:46 +0200
rvm <rvm3000 <at> ya.com> wrote:

> El Miércoles, 30 de Abril de 2008 08:22, Gianluigi Tiesi escribió:
> > Hello,
> > I often receive request about the ability of setting start volume by
> > command line, this is useful if using frontend with salve mode
> >
> > the author of smplayer made a little patch
> > http://smplayer.svn.sourceforge.net/viewvc/*checkout*/smplayer/mplayer-buil
> >ds/patches/startupvol.diff?revision=1203
> 
> Actually the patch was made by Reimar Döffinger, I've just took it:
> http://lists.mplayerhq.hu/pipermail/mplayer-users/2007-December/070500.html
> 
> This -volume option is really useful (and needed) for smplayer.

yes, this should be applied asap.

-compn
Permalink | Reply | 0 comments |
headers
compn | 1 May 2008 05:20
Picon
Favicon

Re: pardus patches

On Tue, 29 Apr 2008 17:49:18 +0400
Vladimir Mosgalin <mosgalin <at> VM10124.spb.edu> wrote:

> Hi compn!
> 
>  On 2008.04.29 at 08:30:36 -0500, compn wrote next:
> 
> > pulse_s32.patch
> 
> This simple fix can be useful
> 
> > vo_keep_window_state.patch
> 
> This patch is usefull as hell, is there any reason why it isn't still
> applied?

http://paketler.pardus.org.tr/devel/source/mplayer.html

ping reimar and rxt and diego
there are some vo/ao and demuxer patches
also some locale/translation patches
it would be nice if pardus would send these upstream.
is ismail donmez still maintainer there ? i've cc'd ismail.

tta_for_mkv.patch
eac3_mkv.patch
eac3_codec_id.patch
could be applied? also need to notify ffmpeg about these formats in mkv.
need some samples...
(Continue reading)

Permalink | Reply | 5 comments |
headers
Siarhei Siamashka | 1 May 2008 11:05
Picon

Re: [PATCH] Fix for ARM compilation failure?when?IWMMXT support is disabled

On Wednesday 30 April 2008, Diego Biurrun wrote:
[...]
> > > The bug must be elsewhere.  Where is mpeg2_mc_iwmmxt declared?  And why
> > > is it declared on your machine?
> >
> > This code refers to 'mpeg2_mc_iwmmxt' symbol, which is defined
> > in 'motion_comp_iwmmxt.c' when HAVE_IWMMXT macro is enabled.
> >
> > So either the code which refers to 'mpeg2_mc_iwmmxt' in 'motion_comp.c'
> > should be hidden under conditional compilation too, or something more
> > cluttered should be introduced.
> >
> > Well, having one more look, turns out that now neither MPEG2_ACCEL_ARM
> > nor MPEG2_ACCEL_ARM_IWMMXT flags get ever set in 'accel' variable, so
> > these optimizations can not be activated. Looks like a lot has changed
> > since I looked at this code last time.
>
> This sounds more as if the HAVE_IWMMXT ifdef should be removed from
> motion_comp_iwmmxt.c.  mpeg2_mc_init works fine on other platforms.
>
> I suspect that some optimizations are not set on ARM.  Please try the
> attached patch.

Naturally it does not help, because libmpeg2 tries to link with more 
iwmmx related symbols from libavcodec in this case:

libmpeg2/motion_comp_iwmmxt.o:(.data+0x0): undefined reference to 
`put_pixels16_iwmmxt'
libmpeg2/motion_comp_iwmmxt.o:(.data+0x4): undefined reference to 
`put_pixels16_x2_iwmmxt'
(Continue reading)

Permalink | Reply | 0 comments |
headers
Siarhei Siamashka | 1 May 2008 12:05
Picon

Re: ARM and liba52

On Monday 28 April 2008, Siarhei Siamashka wrote:
> Hi,
>
> Currently liba52 is broken for ARM processors which require strict
> alignment for accessing memory (ARM9, XScale, ...). AC3 audio playback just
> produces noise.
>
> Interestingly enough, the problem was introduced in 2003 (SVN revision
> 10314), and it was supposedly a fix for ARM:
> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-June/019377.html
>
> I wonder if it was a fix that turned compilation error into runtime failure
> ;)
>
> Anyway, it should be mentioned that modern ARM cores (such as ARM11)
> support unaligned memory access natively. Older cores can emulate unaligned
> memory accesses by handling alignment faults in the kernel, but this is
> very slow.
>
> PS. liba52 uses floating point math which is very slow on old ARM cores
> without hardware FPU, so using liba52 on such old cores is not very
> practical anyway.

Ping.

Can anybody consider reverting r10314 change? Or alternatively you can try to
use the attached patch. Anyway, some kind of action needs to be taken to fix
this breakage.

Also I strongly suspect that r10490 was a proper fix for that ARM
(Continue reading)

Permalink | Reply | 5 comments |
headers
Uoti Urpala | 1 May 2008 12:26
Picon
Picon

Re: ARM and liba52

On Thu, 2008-05-01 at 13:05 +0300, Siarhei Siamashka wrote:
> On Monday 28 April 2008, Siarhei Siamashka wrote:
> > Anyway, it should be mentioned that modern ARM cores (such as ARM11)
> > support unaligned memory access natively. Older cores can emulate unaligned
> > memory accesses by handling alignment faults in the kernel, but this is
> > very slow.
> >
> > PS. liba52 uses floating point math which is very slow on old ARM cores
> > without hardware FPU, so using liba52 on such old cores is not very
> > practical anyway.
> 
> Ping.
> 
> Can anybody consider reverting r10314 change? Or alternatively you can try to
> use the attached patch. Anyway, some kind of action needs to be taken to fix
> this breakage.

So this problem only occurs on cores where the code is "not very
practical" anyway?

Reverting it should be OK though - gcc seems to generate the same code
for both versions on x86 where unaligned access works, so there should
be little reason to use the raw unaligned access code except possibly to
force unaligned access on a target which may support it but isn't
guaranteed to.

> Also I strongly suspect that r10490 was a proper fix for that ARM
> compilation issue with gcc 2.95 that r10314 tried to address but introduced
> a bigger problem instead.
(Continue reading)

Permalink | Reply | 0 comments |
headers
The Wanderer | 1 May 2008 12:43
Picon

Re: pardus patches

(This would have been sent significantly earlier - Tuesrday evening, in
fact - but my SMTP server is having problems.)

Vladimir Mosgalin wrote:

> Hi compn!
> 
> On 2008.04.29 at 08:30:36 -0500, compn wrote next:

>> vo_keep_window_state.patch
> 
> This patch is usefull as hell, is there any reason why it isn't still
> applied?

I think it was because I strongly objected to it, and to all other fixes
for which a patch had been provided, in the discussion which took place
at the time. This was on this same mailing list, back in September of
last year (in a thread begun late that June); I can find an archive link
if necessary.

The discussion did wind up settling on a solution which would be
agreeable to all concerned, but there was no patch for that, and the
people still taking part in the discussion at the time (Reimar, who
wrote the patch you refer to, and myself) did not consider themselves
capable of producing one.

--

-- 
     The Wanderer

     My usual .sig is on vacation while I adjust to my new computer
(Continue reading)

Permalink | Reply | 1 comment |
headers
The Wanderer | 1 May 2008 12:53
Picon

Re: pardus patches

The Wanderer wrote:

> (This would have been sent significantly earlier - Tuesday evening,
> in fact - but my SMTP server is having problems.)

(Which seem to have been that the ISP changed the required port from 25
to 587 and didn't tell anybody... and didn't even mention the fact when
we called to report the problem.)

> Vladimir Mosgalin wrote:
> 
>> Hi compn!
>> 
>> On 2008.04.29 at 08:30:36 -0500, compn wrote next:
> 
>>> vo_keep_window_state.patch
>> 
>> This patch is usefull as hell, is there any reason why it isn't
>> still applied?
> 
> I think it was because I strongly objected to it, and to all other
> fixes for which a patch had been provided, in the discussion which
> took place at the time. This was on this same mailing list, back in
> September of last year (in a thread begun late that June); I can find
> an archive link if necessary.

Thread listing:

http://thread.gmane.org/gmane.comp.video.mplayer.devel/43947
(Continue reading)

Permalink | Reply | 0 comments |
headers
The Wanderer | 1 May 2008 12:53
Picon

Re: Start Volume for mplayer

Gianluigi Tiesi wrote:

> Hello,
> I often receive request about the ability of setting start volume by
> command line, this is useful if using frontend with salve mode

What's wrong with '-af volume'?

Not that a more explicit way of doing this would necessarily not be
good, but it can certainly be done already...

--

-- 
     The Wanderer

     My usual .sig is on vacation while I adjust to my new computer
Permalink | Reply | 2 comments |
headers
Uoti Urpala | 1 May 2008 13:22
Picon
Picon

Re: Start Volume for mplayer

On Thu, 2008-05-01 at 06:53 -0400, The Wanderer wrote:
> Gianluigi Tiesi wrote:
> 
> > Hello,
> > I often receive request about the ability of setting start volume by
> > command line, this is useful if using frontend with salve mode
> 
> What's wrong with '-af volume'?
> 
> Not that a more explicit way of doing this would necessarily not be
> good, but it can certainly be done already...

-af volume adds a filter to scale the audio samples. Adjusting volume at
runtime sets the mixer level instead if possible (which may be hardware
volume).
Permalink | Reply | 0 comments |
headers
Ivan Kalvachev | 1 May 2008 14:28
Picon

Re: ARM and liba52

On Thu, May 1, 2008 at 1:05 PM, Siarhei Siamashka
<siarhei.siamashka <at> gmail.com> wrote:
> On Monday 28 April 2008, Siarhei Siamashka wrote:
>  > Hi,
>  >
>  > Currently liba52 is broken for ARM processors which require strict
>  > alignment for accessing memory (ARM9, XScale, ...). AC3 audio playback just
>  > produces noise.
>  >
>  > Interestingly enough, the problem was introduced in 2003 (SVN revision
>  > 10314), and it was supposedly a fix for ARM:
>  > http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2003-June/019377.html
>  >
>  > I wonder if it was a fix that turned compilation error into runtime failure
>  > ;)
>  >
>  > Anyway, it should be mentioned that modern ARM cores (such as ARM11)
>  > support unaligned memory access natively. Older cores can emulate unaligned
>  > memory accesses by handling alignment faults in the kernel, but this is
>  > very slow.
>  >
>  > PS. liba52 uses floating point math which is very slow on old ARM cores
>  > without hardware FPU, so using liba52 on such old cores is not very
>  > practical anyway.
>
>  Ping.
>
>  Can anybody consider reverting r10314 change? Or alternatively you can try to
>  use the attached patch. Anyway, some kind of action needs to be taken to fix
>  this breakage.
(Continue reading)

Permalink | Reply | 2 comments |

Gmane