[Bug 769949] New: baseparse: Buffers are dropped after concat element switches pad

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=769949

            Bug ID: 769949
           Summary: baseparse: Buffers are dropped after concat element
                    switches pad
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: dv at pseudoterminal.org
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.