Skip to content

baseparse: data_bytecount is not reset when parser is reset

gstbaseparse.c does not reset parse->priv->data_bytecount in gst_base_parse_reset(), while others such as bytecount and acc_duration are reset properly. This leads to wild avg_bitrate calculations in gst_base_parse_update_bitrates(), because these calculations use data_bytecount and acc_duration, but only acc_duration is reset.

How to see the issue: The test setup uses MP3 file playback with a pipeline like: filesrc ! mpegaudioparse ! mpg123audiodec ! fakesink I am using GStreamer 1.16.3, but I can see that the bug also exists in the source code of GStreamer 1.18.5. It cannot be reproduced with gst-launch-1.0, as you must play 2 songs using the same pipeline for the issue to occur.

Steps:

  • Start playing an MP3 file with no metadata (see note about this below).
  • Allow the song to play for a while (let's say about 30 seconds).
  • Stop the pipeline.
  • Start playing the same MP3 file again.

Result: Tons of events of type "tag" will be sent by the mpegaudioparse plugin while the song is playing for the second time. If you look at the average bitrate provided by the event, it's completely wrong.

Additional notes:

  • The calculation which uses data_bytecount and acc_duration happens at gstbaseparse.c:1909 (function gst_base_parse_update_bitrates()). It's computing a avg_bitrate using a cumulative data_bytecount that includes the bytes from the first playback.
  • This only occurs with an MP3 file with no metadata in it! If there is metadata in the file that specifies a bitrate, the bad avg_bitrate is immediately replaced by the bitrate from the metadata (gstbaseparse.c:1923, a few lines below the above calculation).

Proposed solution: Set data_bytecount to 0 in gst_base_parse_reset().