baseparse: Buffers are dropped after concat element switches pad
Submitted by Carlos Rafael Giani
Link to original bug (#769949)
Description
If a baseparse-based element is placed after a concat element, and the parser element lets baseparse compute timestamps, then after concat switches to the next sinkpad, baseparse will drop buffers.
Example:
gst-launch-1.0 -v \
filesrc location=test.mp3 name=a \
filesrc location=test.mp3 name=b \
concat name=c \
a. ! c. b. ! c. \
c. ! mpegaudioparse ! fakesink sync=false silent=false
The -v switch shows that after concat switched to element "b", no buffers are received by the fakesink.
(I picked mpegaudioparse because it fulfilled the criteria above. It does not have to be MP3 data.)
After some digging, I found that it may have something to do with the PTS timestamps that come from the sources. I inserted identity elements into the pipeline to check:
gst-launch-1.0 -v \
filesrc location=test.mp3 ! identity silent=false name=a \
filesrc location=test.mp3 ! identity silent=false name=b \
concat name=c \
a. ! c. b. ! c. \
c. ! mpegaudioparse ! fakesink sync=false silent=false
And the output shows for "a":
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: 0:00:00.000000000, pts: none, duration: none, offset: 0, offset_end: 4096, flags: 00000040 discont ) 0x7f3f280060b0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 4096, offset_end: 8192, flags: 00000000 ) 0x7f3f280063e0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 8192, offset_end: 12288, flags: 00000000 ) 0x7f3f280061c0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 12288, offset_end: 16384, flags: 00000000 ) 0x7f3f280064f0
/GstPipeline:pipeline0/GstIdentity:a: last-message = chain ******* (a:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 16384, offset_end: 20480, flags: 00000000 ) 0x7f3f280060b0
....
while for "b", it shows:
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: 0:00:00.000000000, pts: 0:00:00.000000000, duration: none, offset: 0, offset_end: 4096, flags: 00000040 discont ) 0x7f5884006820
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 4096, offset_end: 8192, flags: 00000000 ) 0x7f5884006b50
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 8192, offset_end: 12288, flags: 00000000 ) 0x7f5884006600
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 12288, offset_end: 16384, flags: 00000000 ) 0x7f5884006c60
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 16384, offset_end: 20480, flags: 00000000 ) 0x7f5884006930
/GstPipeline:pipeline0/GstIdentity:b: last-message = chain ******* (b:sink) (4096 bytes, dts: none, pts: none, duration: none, offset: 20480, offset_end: 24576, flags: 00000000 ) 0x7f5884006600
....
Note that the first "a" buffer has PTS NONE, while the first "b" buffer has PTS 0.
It is my impression that baseparse sees this first PTS 0, and bases its computed PTS on that. In other words, they start at 0, and they are not adjusted to the segment's base time. The result is that baseparse drops the buffer because the timestamp is too old:
0:00:00.115488463 19446 0x20f7720 TRACE baseparse gstbaseparse.c:2389:gst_base_parse_push_frame:<mpegaudioparse0> pushing frame 0x7f3a5c0021e0
0:00:00.115496270 19446 0x20f7720 LOG baseparse gstbaseparse.c:2399:gst_base_parse_push_frame:<mpegaudioparse0> processing buffer of size 288 with dts 0:00:00.036000000, pts 0:00:00.036000000, duration 0:00:00.036000000
0:00:00.115512084 19446 0x20f7720 LOG baseparse gstbaseparse.c:1858:gst_base_parse_update_bitrates:<mpegaudioparse0> frame bitrate 64000, avg bitrate 64000
0:00:00.115520227 19446 0x20f7720 LOG baseparse gstbaseparse.c:2525:gst_base_parse_push_frame:<mpegaudioparse0> Dropped frame, before segment
0:00:00.115525584 19446 0x20f7720 LOG baseparse gstbaseparse.c:2534:gst_base_parse_push_frame:<mpegaudioparse0> frame (288 bytes) dropped
0:00:00.115532254 19446 0x20f7720 LOG baseparse gstbaseparse.c:2173:gst_base_parse_handle_buffer:<mpegaudioparse0> handle_frame skipped 0, flushed 288
0:00:00.115539301 19446 0x20f7720 TRACE baseparse gstbaseparse.c:711:gst_base_parse_frame_free: freeing frame 0x7f3a5c0021e0
....
However, I am not sure if this is a bug in basesrc or in baseparse. basesrc's behavior with regards to the first buffer's PTS is odd. I do not know if it is expected though.