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 742661 - qtdemux: EOS in push mode when seeking in m4a
qtdemux: EOS in push mode when seeking in m4a
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
git master
Other Linux
: Normal normal
: 1.5.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2015-01-09 18:13 UTC by Arnaud Vrac
Modified: 2015-02-14 14:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Arnaud Vrac 2015-01-09 18:13:59 UTC 
In push mode, seeking can result in EOS instead of prerolling and playing. This happens with this file:

http://absolut.zogzog.org/share/samples/m4a/Tie%cc%88sto%60s%20club%20life%20podcast%20396.m4a

This is a podcast with embedded covers, so the video frames are very sparse. In push mode I guess the best thing to do would be to send a GAP event until the next frame.
Comment 1 Arnaud Vrac 2015-01-09 18:16:01 UTC 
BTW this also happens with the 1.4 branch
Comment 2 Thiago Sousa Santos 2015-02-14 14:46:11 UTC 
commit afa5481c5016b1ae45fa72648fd5df33375feb54
Author: Thiago Santos <thiagoss@osg.samsung.com>
Date:   Sat Feb 14 11:11:30 2015 -0300

    qtdemux: do not use sparse streams in push-based seeking
    
    Using the sparse streams can make the push-based seeking return
    too far in the stream. It also can lead to issues as the
    sparse streams will be ignored when restarting playback and,
     if the sparse stream is the one that has the earliest sample,
    it will confuse qtdemux's offsets as one stream will have
    an earlier offset than the demuxer's one which might lead to
    early EOS.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=742661