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 744580 - tagdemux: mp3 File playback is skipping first some seconds data
tagdemux: mp3 File playback is skipping first some seconds data
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
unspecified
Other All
: Normal normal
: 1.4.6
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-02-16 06:49 UTC by Biju Malayil
Modified: 2015-02-19 00:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
mp3 file with id3 tag (859.12 KB, audio/mp3)
2015-02-16 06:49 UTC, Biju Malayil
Details

Description Biju Malayil 2015-02-16 06:49:41 UTC
Created attachment 296905 [details]
mp3 file with id3 tag

I have a pipeline as below
filesrc ! id3demux ! mpegaudioparse ! mad ! pulsesink
for certain files, playback skips initial some seconds of playback (10sec).
if I remove id3demux in the pipeline this issue is not there. also with playbin issue is not there. As I have to go ahead with id3demux please help me to fix this issue ASAP. Please find the attached file for your reference.
Comment 1 Thiago Sousa Santos 2015-02-19 00:13:30 UTC
Thanks for reporting it. The problem as at tagdemux (id3demux) that, due to the sequence of calls made by mpegaudioparse, would get confused with its tag offsets and skip some data from the file. This patch fixes it and will be available in the next releases: 1.4.6 and 1.5

commit cd071014209d167ca8664a47249bdc4a9cb89866
Author: Thiago Santos <thiagoss@osg.samsung.com>
Date:   Wed Feb 18 20:58:15 2015 -0300

    tagdemux: ensure tags have been fetched before pulling data
    
    Otherwise upstream can get confused about offsets as there will
    be a jump once the tags have been parsed due to the stripped area.
    
    If upstream pulls from 0 to 100, and then tagdemux does the
    tag reading and finds out that the first 200 bytes are the tag, the
    next pull from upstream will have an offset of 200 bytes. So
    upstream will get the following data:
    
    0 - 100, 300 - (EOS), as it will continue requesting from where
    it has last stopped, but tagdemux will add an offset to skip the
    tags.
    
    This patch makes sure that the tags have been parsed and skipped
    since the first pull range call.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=744580


In 1.4: 1bed71c622c66fa47fd6137ec283b73ae7b7cec7