Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
Ogg
Ogg
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 8
    • Issues 8
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • Xiph.Org
  • OggOgg
  • Issues
  • #548

Closed
Open
Opened Jul 24, 2004 by Arc Riley@arc

sync-to-sync data loss

I believe there to be a bug in sync.c's buffer handling whereas it doesn't 
appear to be incrementing the buffer size when pages that come from one 
ogg_sync_state object are passed into another.  In the tests I've run, using 
Vorbis files to test with, I've been getting between 30% to 40% of the page 
data I put in. 
 
The data comes out unmangled but "short" in length.  ogginfo shows the output 
to be a normal Vorbis file, only shorted than it should be and lacking EOS. 
 
I have only seen this error by using py-ogg2 and have not attempted to 
replicate this with a C program, however I looked trough py-ogg2's sync.c and 
saw nothing that could cause a bug such as this.  It's really just glue code 
between Python and libogg2, and it seems to work fine for full encoding and 
decoding.
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: xiph/ogg#548