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
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Xiph.Org
  • OggOgg
  • Issues
  • #2292

Closed (moved)
Open
Opened Oct 09, 2017 by stenyak@stenyak

Granulepos corruption with large/numerous packets (with test case)

I'm having issues when dealing with oggz streams that have certain amount of packets and/or certain packet size. I have attached a test case.

I have reproduced the problem with:

  • msvs2015 compiler
  • both 32 and 64 bit
  • both liboggz v1.1.1 (git 70b58a45, from 2010-04-29) and the head of master (git f49574ed from 2014-04-24). Repo URL: https://git.xiph.org/liboggz.git

In the attached test case, the file writing phase seems to go OK, at least no errors are returned anywhere.

main.cpp

The writer code is based on the example found here: https://xiph.org/oggz/doc/group__force__feed.html#details

The reading phase is more problematic:

  • Passing the file through oggz-validate.exe (as downloaded from https://xiph.org/oggz ) crashes with an Out of Memory error
  • Using oggz-dump.exe instead, it seems to read all packets correctly, and output the expected granule positions
  • The attached source code is unable to finish without errors though.

To verify the problem, follow these steps:

  1. Compile the code as-is, in debug mode (to run all asserts). Everything should go ok. The resulting file foo.oggz will be around 160 megs.
  2. Set FAIL = true, compile and run. An assert will fail, around packet #491. The granule position is corrupted now.
  3. Decrease packetSize 1 byte (setting it to packetSize = 163388), compile and run. Granule position will be okay again, all asserts will pass.

So it seems that both amount of packets and size of packets can contribute to the corrupted granulepos.

If you need any help reproducing the issue, please let me know.

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: xiph/ogg#2292