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 ?

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.