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 764648 - splitmuxsink: not sure GAP events are handled correctly
splitmuxsink: not sure GAP events are handled correctly
Status: RESOLVED OBSOLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
unspecified
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-04-05 14:34 UTC by Xavier Claessens
Modified: 2018-11-03 15:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
splitmuxsink: Handle GAP events (1.71 KB, patch)
2016-04-06 10:52 UTC, Xavier Claessens
none Details | Review
splitmuxsink: cleanup how buffer timestamp is updated (1.37 KB, patch)
2016-04-07 09:39 UTC, Xavier Claessens
none Details | Review
splitmuxsink: Update in_running_time on incoming GAP events (3.85 KB, patch)
2016-04-07 09:39 UTC, Xavier Claessens
none Details | Review

Description Xavier Claessens 2016-04-05 14:34:56 UTC
Reading that code, I find 2 things supsicious:

 - GAP events are not catched in handle_mq_input(), that means ctx->in_running_time won't be updated. In case of a long gap, that means it's going to queue other streams a lot because the stream with a gap won't be considered ready to let GOPs out. I think in_running_time should be set to gap's timestamp+duration, no?

 - GAP's duration is not taken into account in handle_mq_output(). In the case of a long gap, that means out_running_time will stay in the past, and complete_or_wait_on_out() won't send EOS until we get the next buffer/gap on that stream which could freeze the pipeline for some time.

I'm not really sure how gap events works, so maybe I'm just wrong here.
Comment 1 Jan Schmidt 2016-04-05 15:18:39 UTC
When I wrote splitmuxsink, it was targetted only at audio and video streams. You're right, it'll need gap handling to handle sparse subpicture streams properly.
Comment 2 Xavier Claessens 2016-04-06 10:52:46 UTC
Created attachment 325469 [details] [review]
splitmuxsink: Handle GAP events

ctx->in_running_time must be updated on incoming GAP event,
otherwise a GOP could never complete.

It should probably also take GAP's duration into account in
the case we have long gap in one stream we shouldn't queue
other streams.
Comment 3 Tim-Philipp Müller 2016-04-06 11:02:02 UTC
wonder if it'd be possible to make a unit test for this :)
Comment 4 Xavier Claessens 2016-04-07 09:39:45 UTC
Created attachment 325526 [details] [review]
splitmuxsink: cleanup how buffer timestamp is updated
Comment 5 Xavier Claessens 2016-04-07 09:39:54 UTC
Created attachment 325527 [details] [review]
splitmuxsink: Update in_running_time on incoming GAP events

This avoids queueing potentially long perdiods of audio/video because
in_running_time won't reach max_in_running_time until a subtitle buffer
arrives. Until then the GOP won't be considered complete and won't be
allowed to go out of the mq.
Comment 6 GStreamer system administrator 2018-11-03 15:08:47 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/gst-plugins-good/issues/267.