After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 768178 - tagdemux: Drops data of too small files in PUSH mode
tagdemux: Drops data of too small files in PUSH mode
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other Linux
: Normal normal
: 1.8.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2016-06-29 12:23 UTC by Jyoti tripathi
Modified: 2016-07-04 10:51 UTC
See Also:
GNOME target: ---
GNOME version: ---

small file issue tagdemux (8.71 KB, audio/mp3)
2016-06-29 12:23 UTC, Jyoti tripathi

Description Jyoti tripathi 2016-06-29 12:23:06 UTC
Created attachment 330566 [details]
small file issue tagdemux

Tried to play an 8kb file in push mode, gives EOS immediately though the file is of 4sec.
Below is the pipeline used and logs:
gst-launch-1.0 filesrc location=~/Documents/in.mp3 ! queue ! id3demux ! faad ! autoaudiosink 
Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: GstSystemClock
Got EOS from element "pipeline0".
Execution ended after 0:00:00.000158745
Setting pipeline to PAUSED ...
Setting pipeline to READY ...
Setting pipeline to NULL ...
Freeing pipeline ...

It plays entire 4sec when queue is removed.
Attaching the audio file.
Comment 1 Sebastian Dröge (slomo) 2016-06-29 16:06:51 UTC
I can confirm this with GIT master too.
Comment 2 Tim-Philipp Müller 2016-06-30 17:57:49 UTC
Thanks for the bug report. This fixes it for me:

commit a2c050a4beaa7ec92eaf30ee6ac644e3de7dcaf3
Author: Tim-Philipp Müller <>
Date:   Thu Jun 30 18:53:07 2016 +0100

    tagdemux: fix handling of very short files in push mode
    By default we'll wait for a certain amount of data before
    attempting typefinding. However, if the stream is fairly
    short, we might get EOS before we ever attempted any
    typefinding, so at this point we should force typefinding
    and output any pending data if we manage to detect the

commit 130e78dbd8ac2a11f8f8f0c293d1193ad639c2bf
Author: Tim-Philipp Müller <>
Date:   Thu Jun 30 17:30:34 2016 +0100

    tagdemux: fix erroring out if we reach EOS without detecting type
    In 0.10 the source pad was a dynamic pad that was only added once
    the type had been detected, but in 1.x it's an always source pad,
    so checking whether it's still NULL won't work to detect if the
    type has been detected.
    Makes tagdemux error out when we get EOS but haven't managed to
    identify the format of the data after the tag.

We might still want some minimum threshold on typefind probability or so in this case, but we can fix that later as needed.
Comment 3 Jyoti tripathi 2016-07-01 12:13:55 UTC
Thanks for the fix,and quick response on the bug.