Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Register
  • Sign in
  • gst-plugins-bad gst-plugins-bad
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 891
    • Issues 891
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 98
    • Merge requests 98
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GStreamerGStreamer
  • gst-plugins-badgst-plugins-bad
  • Issues
  • #415
Closed
Open
Issue created Aug 05, 2016 by Bugzilla Migration User@bugzilla-migration

tsdemux: playback is faster than normal speed for certain files

Submitted by Nirmal Palanisamy

Link to original bug (#769565)

Description

There are some streams in which PCR is present at interval more than 500ms(say for example 1 sec or 1.5 sec) at few positions. When there is a PCR gap of more than 500ms between last PCR and new PCR, a new PCR group is formed. While forming new PCR group, PCR offset is computed with respect to previous group and stored. But this stored PCR offset is not computed properly. And when this group is referred to compute timestamp for a frame, it is done based on first PCR and PCR offset of this group. Since the PCR offset is wrongly stored when forming the group, time stamp computation also goes wrong. PCR offset stored is little less than the right PCR offset. Because of lesser PCR offset, time stamp computed also lesser than actual. Due to this playback ends very fast than the actual duration. And also because of wrong PCR offset for last group(which set during initial scanning), duration of file computed is less than the actual.

Version: 1.8.0

Assignee
Assign to
Time tracking