Does the MP3 encoder is capable of providing constant sized MP3 frames ?

[jalopez10]

Hi,

This is my setup:

imx6 Solo

3.0.35 kernel

gst-plugins-imx-3.0.9

I currently have a matroska muxing pipe, part of it involves audio capture and encoding, that part of the pipeline is described as follows:

gst-launch -e alsasrc ! mfw_mp3encoder bitrate=128 optmod=1 channels=2 sample-rate=44100 ! queue  max-size-buffers=0 max-size-bytes=0 max-size-time=9000000000 ! matroskamux ...

Doing an inspection of the audio buffers that arrive at the matroskamuxer all of them have a variable size, for example using GST_LOG this is the size of some consecutive audio buffers (in bytes):

441

415

417

419

426

416

410

421

424

416

402

420

431

410

425

418

Now, according to the MPEG1 Layer 3 spec, having 128 Kbps and 44100 Hz Sample Rate the framesize should be:

MP3 Frame Size = 417 + (paddingBit == 1 ? 1 : 0);

When I insert some GST_LOG symbols inside the mfw_mp3encoder plugin I can tell that for each of the encoded frames I am having a 128 bitrate and 44100 sample rate, so that would lead to a constant framesize of 417 or 418 if padded.

Is it possible for the mp3 encoder (talking here of hardware/codec) to output this constant framesize ?

Thanks

- Jose Lopez

[jamesbone]

Have you try using a different muxing pipe, because we have no validation of the matroskamux .

The mp3 is a container, so you need a demuxer before decoding. You can see what elements are being instantiated by playbin2 with --gst-debug=GST_ELEMENT_FACTORY:3

[jalopez10]

jamesbone,

Changing the muxing pipe is not going to contribute to this issue, currently we have a fairly decent matroska muxing pipe that generate MKV output with A/V in sync. As the mp3encoder and matroskamuxer pads are connected, the mux is going to pop the incomming mp3 buffers and eventually write it to an MKV file as an MKV audio frame.

The problem is that we are not having a single mp3 frame for each MKV audio frame, we can say this is an alignment problem. We already managed to implement FIFO/adapter in the mp3encoder plugin that helps us

satisfy  < MP3 framesize = 417 + (paddingBit == 1? 1 : 0)  > when working at 128kpbs and 44100 sample rate. What happens is that this is a software approach that is affecting our performance slightly, what we want to know is if the mp3 encoding hardware is capable providing this constant framesize, and if needed manipulate this behavior through the mp3 codec.

Thanks