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 762302 - Docs improvement: Dynamically changing the pipeline: why flush any queued data?
Docs improvement: Dynamically changing the pipeline: why flush any queued data?
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: documentation
git master
Other Linux
: Normal enhancement
: 1.7.90
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-02-19 05:38 UTC by George Yunaev
Modified: 2016-02-20 09:03 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to add this information into documentation (1.12 KB, patch)
2016-02-19 08:43 UTC, George Yunaev
committed Details | Review

Description George Yunaev 2016-02-19 05:38:43 UTC
The documentation when talking about "Dynamically changing the pipeline" explains why we need to make sure that there is no dataflow on unlinked pads - "because that will cause a fatal pipeline error"

However it doesn't explain why "When unlinking elements from an upstream chain, always make sure to flush any queued data in the element by sending an EOS event" - notably it is unclear what would happen if I don't do that. Would it be:

"If you do not do this, GStreamer will crash/format your hard drive/Universe will collapse"; or

"If you do not do this, GStreamer will cause a fatal pipeline error in some cases"; or

"If you do not do this, you'll lose this data"

In my opinion, explaining this is important as the code which doesn't do that seems to work just fine in my case on two platforms, and since those changes cause significant alteration of sound (pitch/tempo change), I don't care about losing the data in buffers anyway.
Comment 1 Sebastian Dröge (slomo) 2016-02-19 06:59:42 UTC
It's going to be a variation of the last, meaning in the best case that some data is missing but everything else is good otherwise and in the worst case that you created a unplayable file (in the case of muxers).

Do you want to provide a patch against the docs to make this clearer?
Comment 2 George Yunaev 2016-02-19 08:21:00 UTC
So, to summarize it properly:

"If you do not this, the result depends on which object of the pipeline you are removing. If this is an appsrv or demuxer object, you will corrupt the encoded data, which most likely will result in an unplayable media file. However if the data is already decoded, such as audio/x-raw or video/x-raw, this will only result in dropping the data already in a buffers, which might result in skipped frames for video, or missing audio for audio."

Would that work?
Comment 3 George Yunaev 2016-02-19 08:21:28 UTC
If this is an *appsrc*
Comment 4 Sebastian Dröge (slomo) 2016-02-19 08:25:32 UTC
Well, in any case you lose data. If that results in corrupted output or not depends on which data it is, and what kind of format.

It will never result in crashes or anything else though (or you found a bug).



Removing a appsrc and demuxer usually does not cause corruptions, downstream of them would just not get any new data. Removing a muxer on the other hand can cause corrupted output if not drained properly as the muxer might have to e.g. rewrite headers to create a valid file (duration, seek table, etc).
Comment 5 George Yunaev 2016-02-19 08:43:12 UTC
Created attachment 321636 [details] [review]
Patch to add this information into documentation
Comment 6 Sebastian Dröge (slomo) 2016-02-20 09:03:26 UTC
commit e6f00957507e6d22158c9db4c7ce19950a9aafc4
Author: George Yunaev <gyunaev@gmail.com>
Date:   Fri Feb 19 08:43:00 2016 +0000

    manual: Explain what happens if upstream elements are removed from the pipeline without draining them first
    
    https://bugzilla.gnome.org/show_bug.cgi?id=762302