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 647940 - basesrc: - fails to send updated segment event when duration changes
basesrc: - fails to send updated segment event when duration changes
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-04-16 14:28 UTC by Thomas
Modified: 2018-11-03 12:15 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Thomas 2011-04-16 14:28:37 UTC
The issue in Bug 345929 still stands: if you try to play a file that is currently being written to (downloaded or created via recording for example) totem will only play up to the portion that was available at file open time.

The user story here is that I try to watch something on a laptop that is on remote machine (SSH). The network is a WLAN with random connectivity issues. If I try to watch the movie direcetly via gvfs, totem won't buffer enough data to cover a small drop in connectivity and will have trouble to resume playing when the connection is back up (it will load the network to the max and the video will lag behind the audio). If I try to download to disk and just watch the growing on-disk file (doing manual buffering, so to say), the bug mentioned here kicks in and I'd have to constantly restart the movie and skip to the part I haven't seen yet.

As a point of comparison, VLC is able to just keep playing if it notices that the file grew since it opened it.
Comment 1 Bastien Nocera 2011-04-16 14:49:00 UTC
What type of file is it?
Comment 2 Thomas 2011-04-16 15:50:09 UTC
I didn't know the behavior differs with file type, but I mostly use avi's for this:

TOTEM_INFO_DURATION=6100
TOTEM_INFO_HAS_VIDEO=True
TOTEM_INFO_VIDEO_WIDTH=640
TOTEM_INFO_VIDEO_HEIGHT=256
TOTEM_INFO_VIDEO_CODEC=XVID MPEG-4
TOTEM_INFO_FPS=24
TOTEM_INFO_HAS_AUDIO=True
TOTEM_INFO_AUDIO_BITRATE=132
TOTEM_INFO_AUDIO_CODEC=MPEG 1 Audio, Layer 3 (MP3)
TOTEM_INFO_AUDIO_SAMPLE_RATE=48000
TOTEM_INFO_AUDIO_CHANNELS=Stereo
Comment 3 David Schleef 2011-05-25 06:09:15 UTC
filesrc (basesrc, actually) creates a segment with a specific duration (the file size) at pipeline startup, and checks for a new file size when it hits the end of the file.  However, it never sends an updated segment event.
Comment 4 Christian Fredrik Kalager Schaller 2011-05-26 15:00:30 UTC
Updating title to reflect current state of bug
Comment 5 Sebastian Dröge (slomo) 2011-05-27 07:07:46 UTC
commit 934faf163caf10ed3d54d81fd7b793069913dffd
Author: Sebastian Dröge <sebastian.droege@collabora.co.uk>
Date:   Fri May 27 09:05:46 2011 +0200

    basesrc: Send an update NEWSEGMENT event downstream if the duration changes
    
    This allows streaming the complete file for files that have grown since
    streaming started.
    
    Fixes bug #647940.
Comment 6 Mark Nauwelaerts 2011-06-08 18:25:27 UTC
Reverted commit above, for reasons partially given below.

Also, it is not clear how it would affect the situation for e.g. avidemux operating in pull mode, which would not have received initial segment info and can then hardly benefit from an "update" of it (nor should it need one to operate properly in this case afaik). 

commit c040305b8c6dac84e8c7abc96bb19d1bf70ac976
Author: Mark Nauwelaerts <mark.nauwelaerts@collabora.co.uk>
Date:   Wed Jun 8 20:14:16 2011 +0200

    Revert "basesrc: Send an update NEWSEGMENT event downstream if the duration changes"
    
    This reverts commit 934faf163caf10ed3d54d81fd7b793069913dffd.
    
    Original commit leads to possibly sending newsegment event downstream
    in pull mode.  In push mode, quite some downstream elements
    are likely to only expect newsegment event following a seek they performed
    and as such may have their state messed up.
Comment 7 David Schleef 2011-06-10 19:10:36 UTC
Mark, is this fixed with f8168cd7?
Comment 8 Mark Nauwelaerts 2011-06-11 19:39:28 UTC
That particular commit should arrange for a proper response to a duration query, which is usually what downstream (from filesrc) will be most interested in getting right when it is asking (when file is growing).

Not sure what it would do in this case, and what "this case" actually is.

If this is about e.g. filesrc ! avidemux on a file that is still being downloaded, there are likely more structural problems such as not having an index yet etc.  iirc not having an index in pull mode will have avidemux scan the file to build one on the fly, which will then only have an index on the file as currently downloaded, and so will only play that part.
On the other hand, running avidemux in push mode (probably?) does not have that problem, so it should work when playing with e.g. a pushfile:// uri.

In cases where no structural issues, e.g. filesrc ! mp3parse (or so), it should already work just fine (and that commit should arrange for properly updated duration).
Comment 9 David Schleef 2011-06-12 00:40:30 UTC
I'm currently testing with:

  gst-launch videotestsrc is-live=true ! theoraenc ! oggmux ! filesink location=out.ogv

And playing the file in totem.  This is a very simple case that should work, but does not.  (Neither with master, nor with Sebastian's patch.)  It is unclear to me which element is broken in this case.
Comment 10 Mark Nauwelaerts 2011-06-13 12:41:14 UTC
Another best guess for that case; iirc oggdemux performs an initial scan to check for chains/durations, and it may send a segment based on what it finds initially and stick to that later on.

In any case, oggdemux ---being the driving element in pull mode--- is likely culprit ...

There are likely quite some elements/demuxers that are a bit (heavily) optimized for classical assumptions for pull mode and not expecting some "dynamic" cases.
Comment 11 Edward Hervey 2013-08-23 12:04:41 UTC
confirmed, still an issue in master.
Comment 12 GStreamer system administrator 2018-11-03 12:15:00 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gstreamer/issues/21.