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 629
    • Issues 629
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 105
    • Merge Requests 105
  • 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
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GStreamer
  • gst-plugins-basegst-plugins-base
  • Issues
  • #152

Closed
Open
Opened Jan 08, 2015 by Bugzilla Migration User@bugzilla-migration

videodecoder: Should not renegotiate at start of finish_frame()

Submitted by Nicolas Dufresne @ndufresne

Link to original bug (#742619)

Description

It has always been this way, there is obvious way to workaround it, but it make very little sense to reconfigure on finish frame. On finish frame, it is too late to negotiate the allocation. In fact, this case only get triggered when we are already configured and may cause more arm then good.

In most cases, the frame holds a buffer allocated from the previously negotiated pool. The old pool cannot be stopped or reconfigured, since it has outstanding buffers.

I think we should drop this check. If there is a video decoder not using one of:

gst_video_decoder_allocate_output_buffer()
gst_video_decoder_allocate_output_frame()
gst_video_decoder_negotiate ()

It should most likely call gst_video_decoder_negotiate() (if it can renegotiate). Any known decoder triggers this case ? If so, do it work well ?

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: gstreamer/gst-plugins-base#152