Ivan Kalvachev | 1 Feb 01:31
Picon

Re: [PATCH] remove mp3lib

On 1/30/12, Thomas Orgis <thomas-forum <at> orgis.org> wrote:
> Am Tue, 13 Dec 2011 22:56:05 +0100
> schrieb Thomas Orgis <thomas-forum <at> orgis.org>:
>
>> On the actual topic of my investigations... I am still hunting the
>> reason why gcc produces inferior binary from mpg123's sources compared
>> to mp3lib... even when the concerned code is the same (well,
>> basically...). This will be a christmas/new year thing... but hopefully
>> I can resolve it.
>
> Just a heads-up, I'm spending spare minutes on this as I can. I am
> documenting my efforts on
>
> 	http://mpg123.org/beating_mp3lib_in_mplayer/
>
> Suggestions welcome...

I've read it and I must say I'm impressed by the work you've done so far.

If I understood correctly the major slowdown is caused by
WRITE_SAMPLE() that basically clips a float and writes it as (short).

Then the inefficient code is used as basis for writing the "hand"
assembly version in synth_i586.S.
The funny thing is that mp3lib/decode_i586.c seems to contain equally
inefficient assembler code o_O

There is another trick to saturate floats to short range and convert
them to integer.

(Continue reading)

Thomas Orgis | 1 Feb 12:28
Favicon

Re: [PATCH] remove mp3lib

Am Wed, 1 Feb 2012 02:31:32 +0200
schrieb Ivan Kalvachev <ikalvachev <at> gmail.com>: 

> If I understood correctly the major slowdown is caused by
> WRITE_SAMPLE() that basically clips a float and writes it as (short).

That seemed to me as the main point, as the code generated for that
macro seems to differ strangely.

> Then the inefficient code is used as basis for writing the "hand"
> assembly version in synth_i586.S.

Good point, I already noticed that this "optimization" is getting
overtaken by a good compiler nowadays and wondered if it might get
removed. It wasn't a particulary huge optimization to begin with. But
perhaps updating it would yield something. It could be that this code
predates some optimizations that happened in mpg123 regarding
WRITE_SAMPLE. I'll think about that one later, anyway.

> The funny thing is that mp3lib/decode_i586.c seems to contain equally
> inefficient assembler code o_O

Yeah, on the Duron, this code is still a bit faster than MPlayer's
generic mp3lib code, around 29 seconds vs. 32. Some updating should
increase that distance; meaning that even without SIMD usage, one can
easily beat what gcc-4.4.5 produces. So perhaps it's really not yet
time to kill of even that not-very-effective assembly code.

> There is another trick to saturate floats to short range and convert
> them to integer.
(Continue reading)

Favicon

Re: [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.

Hi Ingo, Reimar, all,

> > > I personally would only perform a footer flag check and accept
> > > the
> > > 3DI footer
> > > if version is 4 or above.
> >
> > Done (see attachment).
> >
> > > AFAIK valid ID3v2 tag headers start with version 2, so we should
> > > not
> > > drop
> > > this check.
> >
> > Done.
> >
> > > You already mentioned that ("very, very unlikely to matter") in
> > > case
> > > len is 0
> > > (error or malformed tag), the stream position may be somewhere
> > > between ID3v2
> > > flags and ID3v2 size, but we step 4.
> >
> > The 4 that are stepped here are "ID3" and the major version. At
> > least
> > one
> > more byte has been read after these by id3v2_tag_size(), so hdr has
> > to be
> > fully refilled, hence step = 4. id3v2_tag_size() could be modified
> > to
(Continue reading)

Ingo Brückl | 3 Feb 11:14
Picon

Re: [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.

Benoît Thébaudeau wrote on Thu, 02 Feb 2012 22:54:06 +0100 (CET):

> I have not received any answer for more than 2 weeks. Are you guys too
> busy, or is there any problem?

I've expressed my reservations and there isn't much more I can say or do.

Ingo
Favicon

Re: [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.

Ingo Brückl wrote on Fri, 03 Feb 2012 11:14:41 +0100 (CET):

> Benoît Thébaudeau wrote on Thu, 02 Feb 2012 22:54:06 +0100 (CET):
>
> > I have not received any answer for more than 2 weeks. Are you guys
> > too
> > busy, or is there any problem?
>
> I've expressed my reservations and there isn't much more I can say or
> do.

OK, then Reimar, what do you think about the points I disagree with Ingo? Is my
latest patch acceptable for you, or do you think I should follow Ingo about
everything?

Benoît
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
Reimar Döffinger | 3 Feb 19:19
Picon
Picon

Re: [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.

On Fri, Jan 27, 2012 at 02:06:31PM +0100, Benoît Thébaudeau wrote:
> diff -Nrdup mplayer.orig/libmpdemux/demux_audio.c mplayer/libmpdemux/demux_audio.c
> --- mplayer.orig/libmpdemux/demux_audio.c	2012-01-27 13:42:31.522983827 +0100
> +++ mplayer/libmpdemux/demux_audio.c	2012-01-27 13:55:08.946980169 +0100
> @@ -441,12 +441,12 @@ static int demux_audio_open(demuxer_t* d
>      free(mp3_found);
>      mp3_found = NULL;
>      if(s->end_pos && (s->flags & MP_STREAM_SEEK) == MP_STREAM_SEEK) {
> -      stream_seek(s,s->end_pos-128);
> +      stream_seek(s,demuxer->movi_end-128);

Semantics-wise, it doesn't really make sense to check
for s->end_pos but then use demuxer->movi_end.
Also I realize that it would probably make sense to check
for it >/>= 128.
Reimar Döffinger | 3 Feb 19:26
Picon
Picon

Re: [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.

On Wed, Jan 18, 2012 at 03:19:43PM +0100, Benoît Thébaudeau wrote:
> > messages,
> > if any,
> > should be translatable.
> 
> What does it imply for MPlayer? I don't see anything special done for the
> two similar messages I mentioned above.

Using (generally means adding) a define from
help/help_mp-en.h
Reimar Döffinger | 3 Feb 19:27
Picon
Picon

Re: [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.

On Fri, Feb 03, 2012 at 12:53:40PM +0100, Benoît Thébaudeau wrote:
> Ingo Brückl wrote on Fri, 03 Feb 2012 11:14:41 +0100 (CET):
> 
> > Benoît Thébaudeau wrote on Thu, 02 Feb 2012 22:54:06 +0100 (CET):
> >
> > > I have not received any answer for more than 2 weeks. Are you guys
> > > too
> > > busy, or is there any problem?
> >
> > I've expressed my reservations and there isn't much more I can say or
> > do.
> 
> OK, then Reimar, what do you think about the points I disagree with Ingo? Is my
> latest patch acceptable for you, or do you think I should follow Ingo about
> everything?

I think it should be fine really, the rest is really just some nits we
shouldn't get hung up on.
Reimar Döffinger | 3 Feb 19:31
Picon
Picon

Re: [PATCH] libmpdemux/demux_audio: Skip ID3v2.4 tags.

On Fri, Feb 03, 2012 at 07:26:41PM +0100, Reimar Döffinger wrote:
> On Wed, Jan 18, 2012 at 03:19:43PM +0100, Benoît Thébaudeau wrote:
> > > messages,
> > > if any,
> > > should be translatable.
> > 
> > What does it imply for MPlayer? I don't see anything special done for the
> > two similar messages I mentioned above.
> 
> Using (generally means adding) a define from
> help/help_mp-en.h

Sorry, I hit send too early.
The need for translation is really mean for errors,
where "error" means the playback will be significantly
impacted or the file will not play at all (FATAL might
be more appropriate for the later one though).
However I think this will never really be the case
for these "errors", so they probably should only be
warnings.
Andrew Wason | 3 Feb 19:40
Gravatar

[PATCH] fix encoding -oac pcm in lavf MOV container

Encoding with -oac pcm in a MOV container incorrectly uses audio tag
'WRLE', see http://bugzilla.mplayerhq.hu/show_bug.cgi?id=2038

Andrew
Attachment (pcm_codec_tag.diff): application/octet-stream, 1542 bytes
_______________________________________________
MPlayer-dev-eng mailing list
MPlayer-dev-eng <at> mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng

Gmane