Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
gst-plugins-base
gst-plugins-base
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 631
    • Issues 631
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 102
    • Merge Requests 102
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamer
  • gst-plugins-basegst-plugins-base
  • Issues
  • #499

Closed
Open
Opened Oct 24, 2018 by Bugzilla Migration User@bugzilla-migration

Potential Error Case is Ignored by GstAudioRingBuffer

Submitted by Andrew

Link to original bug (#797334)

Description

In trying to debug issues behind Bug 797329 (https://bugzilla.gnome.org/show_bug.cgi?id=797329) it was discovered that an error case seems to be completely ignored by the GstAudioRingBuffer.

default_commit 'skips' the writing of a segment to the output buffer when the read pointers has surpassed the write pointer (diff < 0), but still advances the write pointer by the segment size. The intention appearing to be that this should advance the write pointer a segment ahead of the read pointer, and allow the next segment to write.

The issue is that default_commit's return indicates that the full segment was written, and fails to track this error internally. Thus, the potential error state were the write pointer never catches up to the read pointer (and the rendering is for all intents broken), appears to be undetectable.

  • Due to no internal error tracking GstAudioRingBuffer will have no idea that it has skipped the millionth segment in a row.

  • Due to GstAudioRingBuffer indicating by it's return that full segment was written and advancing the write pointer, higher level elements appear to have no way of knowing a segment was drop. Thus they appear to have no way of tracking how many segments have been successively dropped, and detecting if this exceeds an error threshold.

I am sure that the error state is a rare one, and in this case caused by an unrelated issue. However never detecting an error state in the pipeline seems bad.

See also

  • Bug 797329
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: gstreamer/gst-plugins-base#499