GNOME Bugzilla – Bug 647940
basesrc: - fails to send updated segment event when duration changes
Last modified: 2018-11-03 12:15:00 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.
What type of file is it?
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
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.
Updating title to reflect current state of bug
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.
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.
Mark, is this fixed with f8168cd7?
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).
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.
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.
confirmed, still an issue in master.
-- 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.