libmpg123 decoder plugin

[Roland Poppenreiter]

Hello everybody,

I hope this is the right mailinglist for this anouncement.  I wrote
a mp3 decoder plugin with the mpg123 library. One reason is that
mpg123 has some processor optimization (SSE, MMX, 3DNow, ...) in it
and should be faster than the mad decoder. I used the mad decoder
plugin (gstmad.c) as template for my plugin - so they are quite
similar. I wanted to benchmark both decoders and compare the results
but I ran into several problems and I got a few questions:

 - sometimes i get a short white noise sound when i start playing an
   mp3 file with my mpg123 decoder plugin.
 - short white noise sound appears after seeking as well.
 - is it possible that data comming from the filesrc is sometimes
   overlapping?
 - seeking is not always working, also not with the mad decoder.
 - the mad decoder decodes mpg samples to audio/x-raw-int 32 Bit,
   but most extensions (SSE, MMX, ...) can just handle 16 Bit
   samples, therefore I would preferre 16 Bit audio/x-raw-int as
   output for my decoder.

I wrote a small mediaplayer (described in the GStreamer Application
Development Manual) to test my plugin. The problems occur with my
mediaplayer and also with the gst-launch program.

Sourcecode can be found here: https://semsemilla.kastel.net/gst/

I would appreciate little help to solve my problems or any opinion
about this plugin.

-- Roland Poppenreiter



------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Felipe Contreras]

On Wed, Jan 14, 2009 at 5:41 PM, Roland Poppenreiter <[hidden email]> wrote:

> Hello everybody,
>
> I hope this is the right mailinglist for this anouncement.  I wrote
> a mp3 decoder plugin with the mpg123 library. One reason is that
> mpg123 has some processor optimization (SSE, MMX, 3DNow, ...) in it
> and should be faster than the mad decoder. I used the mad decoder
> plugin (gstmad.c) as template for my plugin - so they are quite
> similar. I wanted to benchmark both decoders and compare the results
> but I ran into several problems and I got a few questions:
>
>  - sometimes i get a short white noise sound when i start playing an
>   mp3 file with my mpg123 decoder plugin.
>  - short white noise sound appears after seeking as well.
>  - is it possible that data comming from the filesrc is sometimes
>   overlapping?
>  - seeking is not always working, also not with the mad decoder.

Are you using the mp3parse element?

>  - the mad decoder decodes mpg samples to audio/x-raw-int 32 Bit,
>   but most extensions (SSE, MMX, ...) can just handle 16 Bit
>   samples, therefore I would preferre 16 Bit audio/x-raw-int as
>   output for my decoder.

Then output that.

Is that mpg123 library new? If I recall correctly the last time I
tried it wasn't there, I even suggested them to create a library, but
they didn't look too interested.

Another option is to provide an OpenMAX IL API for the library. In
that case the gst-openmax wrapper would be able to use the decoder
transparently.

--
Felipe Contreras

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Roland Poppenreiter]

* On Thu, 15 Jan 2009 at  7:47 +0200, Felipe Contreras wrote:

> On Wed, Jan 14, 2009 at 5:41 PM, Roland Poppenreiter <[hidden email]> wrote:
> > Hello everybody,
> >
> > I hope this is the right mailinglist for this anouncement.  I wrote
> > a mp3 decoder plugin with the mpg123 library. One reason is that
> > mpg123 has some processor optimization (SSE, MMX, 3DNow, ...) in it
> > and should be faster than the mad decoder. I used the mad decoder
> > plugin (gstmad.c) as template for my plugin - so they are quite
> > similar. I wanted to benchmark both decoders and compare the results
> > but I ran into several problems and I got a few questions:
> >
> >  - sometimes i get a short white noise sound when i start playing an
> >   mp3 file with my mpg123 decoder plugin.
> >  - short white noise sound appears after seeking as well.
> >  - is it possible that data comming from the filesrc is sometimes
> >   overlapping?
> >  - seeking is not always working, also not with the mad decoder.
>
> Are you using the mp3parse element?

 
no, I dont even know this plugin ....
the pipeline I'm using is this:

gst-launch filesrc location="foo.mp3" ! mpg123 ! audioconvert !
osssink

> >  - the mad decoder decodes mpg samples to audio/x-raw-int 32 Bit,
> >   but most extensions (SSE, MMX, ...) can just handle 16 Bit
> >   samples, therefore I would preferre 16 Bit audio/x-raw-int as
> >   output for my decoder.
>
> Then output that.

okay, fine!

> Is that mpg123 library new? If I recall correctly the last time I
> tried it wasn't there, I even suggested them to create a library, but
> they didn't look too interested.

the libmpg123 is not new, its the api from the mpg123 mp3-player
(http://www.mpg123.de/api/) and I already used it for my mpg123
gstreamer plugin.

> Another option is to provide an OpenMAX IL API for the library. In
> that case the gst-openmax wrapper would be able to use the decoder
> transparently.

I dont know this library, I will take a look at it, but for the
moment I have to solve my problems with the mpg123 plugin.

> --
> Felipe Contreras
>

-- Roland Poppenreiter

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Felipe Contreras]

On Thu, Jan 15, 2009 at 2:35 PM, Roland Poppenreiter <[hidden email]> wrote:

> * On Thu, 15 Jan 2009 at  7:47 +0200, Felipe Contreras wrote:
>> On Wed, Jan 14, 2009 at 5:41 PM, Roland Poppenreiter <[hidden email]> wrote:
>> > Hello everybody,
>> >
>> > I hope this is the right mailinglist for this anouncement.  I wrote
>> > a mp3 decoder plugin with the mpg123 library. One reason is that
>> > mpg123 has some processor optimization (SSE, MMX, 3DNow, ...) in it
>> > and should be faster than the mad decoder. I used the mad decoder
>> > plugin (gstmad.c) as template for my plugin - so they are quite
>> > similar. I wanted to benchmark both decoders and compare the results
>> > but I ran into several problems and I got a few questions:
>> >
>> >  - sometimes i get a short white noise sound when i start playing an
>> >   mp3 file with my mpg123 decoder plugin.
>> >  - short white noise sound appears after seeking as well.
>> >  - is it possible that data comming from the filesrc is sometimes
>> >   overlapping?
>> >  - seeking is not always working, also not with the mad decoder.
>>
>> Are you using the mp3parse element?
>
> no, I dont even know this plugin ....
> the pipeline I'm using is this:
>
> gst-launch filesrc location="foo.mp3" ! mpg123 ! audioconvert !
> osssink

It's on the mpegaudio parse plug-in. It would do the proper frame
seeking so your decoder element doesn't have to.

<snip/>

>> Is that mpg123 library new? If I recall correctly the last time I
>> tried it wasn't there, I even suggested them to create a library, but
>> they didn't look too interested.
>
> the libmpg123 is not new, its the api from the mpg123 mp3-player
> (http://www.mpg123.de/api/) and I already used it for my mpg123
> gstreamer plugin.

Yeah, I know, but it was a standalone player (no library) before.
Anyway, it's good that they've split it.

>> Another option is to provide an OpenMAX IL API for the library. In
>> that case the gst-openmax wrapper would be able to use the decoder
>> transparently.
>
> I dont know this library, I will take a look at it, but for the
> moment I have to solve my problems with the mpg123 plugin.

But that's the point, if you provide the mp123 library with OpenMAX IL
interface, then you don't need to write your decoder element.

--
Felipe Contreras

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Roland Poppenreiter]

* On Thu, 15 Jan 2009 at 15:06 +0200, Felipe Contreras wrote:

> On Thu, Jan 15, 2009 at 2:35 PM, Roland Poppenreiter <[hidden email]> wrote:
> > * On Thu, 15 Jan 2009 at  7:47 +0200, Felipe Contreras wrote:
> >> On Wed, Jan 14, 2009 at 5:41 PM, Roland Poppenreiter <[hidden email]> wrote:
> >> > Hello everybody,
> >> >
> >> > I hope this is the right mailinglist for this anouncement.  I wrote
> >> > a mp3 decoder plugin with the mpg123 library. One reason is that
> >> > mpg123 has some processor optimization (SSE, MMX, 3DNow, ...) in it
> >> > and should be faster than the mad decoder. I used the mad decoder
> >> > plugin (gstmad.c) as template for my plugin - so they are quite
> >> > similar. I wanted to benchmark both decoders and compare the results
> >> > but I ran into several problems and I got a few questions:
> >> >
> >> >  - sometimes i get a short white noise sound when i start playing an
> >> >   mp3 file with my mpg123 decoder plugin.
> >> >  - short white noise sound appears after seeking as well.
> >> >  - is it possible that data comming from the filesrc is sometimes
> >> >   overlapping?
> >> >  - seeking is not always working, also not with the mad decoder.
> >>
> >> Are you using the mp3parse element?
> >
> > no, I dont even know this plugin ....
> > the pipeline I'm using is this:
> >
> > gst-launch filesrc location="foo.mp3" ! mpg123 ! audioconvert !
> > osssink
>
> It's on the mpegaudio parse plug-in. It would do the proper frame
> seeking so your decoder element doesn't have to.
>
> <snip/>

oh, thanks for the information, but anyway I solved my seeking
problems without using another plugin. Also the problems with the
white noise disappeared - the reason was that I initialized my
GST_BUFFER (=outbuffer) with a wrong size.  

> >> Is that mpg123 library new? If I recall correctly the last time I
> >> tried it wasn't there, I even suggested them to create a library, but
> >> they didn't look too interested.
> >
> > the libmpg123 is not new, its the api from the mpg123 mp3-player
> > (http://www.mpg123.de/api/) and I already used it for my mpg123
> > gstreamer plugin.
>
> Yeah, I know, but it was a standalone player (no library) before.
> Anyway, it's good that they've split it.

Yep, the library is good and well documented so I can recommended
for everybody who wants to write an mp3 player.

> >> Another option is to provide an OpenMAX IL API for the library. In
> >> that case the gst-openmax wrapper would be able to use the decoder
> >> transparently.
> >
> > I dont know this library, I will take a look at it, but for the
> > moment I have to solve my problems with the mpg123 plugin.
>
> But that's the point, if you provide the mp123 library with OpenMAX IL
> interface, then you don't need to write your decoder element.

Sorry I dont get it, why should I use the mpg123 library with
OpenMAX interface if I already have a working implementation of the
mpg123 decoder plugin.

> --
> Felipe Contreras
>

So now that my plugin seems to work correctly and produce a nice
quality sound, even faster than the MAD decoder plugin, I would like
to know if anybody want to try it?

-- Roland Poppenreiter

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel

[Felipe Contreras]

On Thu, Jan 15, 2009 at 6:44 PM, Roland Poppenreiter <[hidden email]> wrote:
> * On Thu, 15 Jan 2009 at 15:06 +0200, Felipe Contreras wrote:
>> But that's the point, if you provide the mp123 library with OpenMAX IL
>> interface, then you don't need to write your decoder element.
>
> Sorry I dont get it, why should I use the mpg123 library with
> OpenMAX interface if I already have a working implementation of the
> mpg123 decoder plugin.

Now that you have your mpg123 plugin working it probably doesn't make
much sense.

Ideally other multimedia frameworks would have OpenMAX IL support, and
so if both mad and libmpg123 provide an OpenMAX IL API they would work
transparently on the same multimedia frameworks [1].

That's of course theoretical because so far I only know of GStreamer,
Helix, and Android's player that support OpenMAX IL.

[1] http://www.freedesktop.org/wiki/GstOpenMAX?action=AttachFile&do=get&target=gst-openmax.png

--
Felipe Contreras

------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/gstreamer-devel