Wrong PTS when seeking in Opus file
Seeking in Opus file with ffprobe/ffplay everything seems work fine. PTS changes correctly and all works as expected.
Scenario when one wants to seek to X PTS in file and then read Y bytes after that jump Y bytes ahead to read next Y bytes one gets the same output as first readied Y bytes.
If you just keep doing that reading procedure after next Z times you just get new loop to read on. This bug somehow follows the OggS-headers and granule points in Ogg-container. It seems you always got Y bytes from start of the last header-point. On Ogg/Vorbis with or without libvorbis everything works with same code.
https://github.com/illuusio/ffmpeg-example.git have example application to demo this bug report.
Change History
(4)
Keywords: |
ogg added
|
Reproduced by developer: |
set
|
Resolution: |
→ fixed
|
Status: |
new → closed
|
I believe we're seeing the same issue in Chrome. Specifically, PTS values are going backwards on granule boundaries. There also appears to be issues with the oggopus_private data not being reset after seek (so cur_dts increases forever), but I'm not sure that matters.
I've attached a test case and test file which repro this issue. You can build it like so:
clang ogg-seek.c -lavformat -lavcodec -lavutil -lopus -lpthread -lz
./a.out detodos.opus
You'll see some pts printouts followed by a seek, and then eventually the pts goes backwards in time:
pts: 134088 -- dts: 134088
pts: 95688 -- dts: 95688 <------------ BACKWARDS!