GNOME Bugzilla – Bug 414988
Stream encoded by lame has gap after decoding
Last modified: 2007-11-15 21:51:34 UTC
When encoding the audio of the alien.mpg video, the output has audio glitch. Even if the audio stream pass by a audiorate element before encoding, the audio stream out of the decoder has gaps. 1. gst-launch filesrc=alien.mpg ! decodebin2 ! audioconvert ! audiorate ! fakesink -v => Some buffer have gap flag set 2. gst-launch filesrc=alien.mpg ! decodebin2 ! audioconvert ! audiorate ! lame ! mad ! audiorate ! fakesink -v => Some buffers still have the gap flag set
I can't reproduce this (with CVS), neither with the fluendo mpeg demuxer nor with the mpeg demuxer from -ugly. None of the buffers arriving at the sink have the discont flag set here. Maybe you're using an audiorate element that's not up-to-date? Could you re-try with CVS of things please?
With CVS, if I play the file with the command: > gst-launch filesrc=alien.mpg ! decodebin2 ! audioconvert ! audiorate ! lame ! mad ! alsasink The output is perfect, but with either of the following commands the output sound have glitches: > gst-launch filesrc=alien.mpg ! decodebin2 ! audioconvert ! lame ! mad ! alsasink > gst-launch filesrc=alien.mpg ! decodebin2 ! audioconvert ! audiorate ! lame ! mad ! audiorate ! alsasink The first command may be normal if the source have some timestamp discontinuities, but the second one should work. I don't think of any reasons why after a decoder an audiorate could add gaps.
Seems that the lame ! mad part creates discontinuites. The folowing command show no discontinuities: > GST_DEBUG=2 gst-launch -v filesrc location=alien.mpg ! decodebin2 ! audioconvert ! audiorate ! identity check-perfect=1 silent=1 ! lame ! mad ! alsasink But if we check for discontinuites after the mad decoder with the command: > GST_DEBUG=2 gst-launch -v filesrc location=alien.mpg ! decodebin2 ! audioconvert ! audiorate ! lame ! mad ! identity check-imperfect-timestamp=1 check-perfect=1 silent=1 ! alsasink The log show: ... 0:00:00.999891000 3095 0x8197530 WARN identity gstidentity.c:369:gst_identity_check_perfect:<identity0> Buffer not data-contiguous with previous one: prev offset_end -1, new offset 49065 0:00:01.001326000 3095 0x8197530 WARN identity gstidentity.c:369:gst_identity_check_perfect:<identity0> Buffer not data-contiguous with previous one: prev offset_end -1, new offset 50217 0:00:01.002687000 3095 0x8197530 WARN identity gstidentity.c:369:gst_identity_check_perfect:<identity0> Buffer not data-contiguous with previous one: prev offset_end -1, new offset 51369 0:00:01.004938000 3095 0x8197530 WARN identity gstidentity.c:369:gst_identity_check_perfect:<identity0> Buffer not data-contiguous with previous one: prev offset_end -1, new offset 52521 0:00:01.077371000 3095 0x8197530 WARN identity gstidentity.c:369:gst_identity_check_perfect:<identity0> Buffer not data-contiguous with previous one: prev offset_end -1, new offset 53673 0:00:01.078790000 3095 0x8197530 WARN identity gstidentity.c:369:gst_identity_check_perfect:<identity0> Buffer not data-contiguous with previous one: prev offset_end -1, new offset 54825 ...
I'm not sure that identity should be complaining when offset_end for the previous buffer was not provided (-1 = GST_BUFFER_OFFSET_NONE)
identity still complain, but with the current HEAD there is no audio glitches anymore. I think this bug can be closed.