When I moved ParsableByteArray#data behind a getter I replaced some assignments with calls to reset(byte[]): https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd reset(byte[]) deliberately sets `limit` to `data.length`, in order to handle cases that were reassigning `data` but not updating `limit`. However OggPacket was already using `limit` to track where to write 'new' data into the array, so changing `limit` to `data.length` caused us to try and write new data beyond the end of the array. I looked at other uses of reset(byte[]) in https://github.com/google/ExoPlayer/commit/ce2e6e2fd625db787b1f400614adcd7458144bbd and condluded the only other usage in MatroskaExtractor is legit and shouldn't be updated like this (because MatroskaExtractor previously *wasn't* correctly updating/maintaining `limit`). Issue: #7992 PiperOrigin-RevId: 334601586
| Name |
Last commit
|
Last Update |
|---|---|---|
| .. | ||
| ad-responses | Loading commit data... | |
| amr | Loading commit data... | |
| binary | Loading commit data... | |
| bitmap | Loading commit data... | |
| download-actions | Loading commit data... | |
| dvbsi | Loading commit data... | |
| flac | Loading commit data... | |
| flv | Loading commit data... | |
| id3 | Loading commit data... | |
| mka | Loading commit data... | |
| mkv | Loading commit data... | |
| mp3 | Loading commit data... | |
| mp4 | Loading commit data... | |
| mpd | Loading commit data... | |
| offline | Loading commit data... | |
| ogg | Loading commit data... | |
| rawcc | Loading commit data... | |
| smooth-streaming | Loading commit data... | |
| ssa | Loading commit data... | |
| subrip | Loading commit data... | |
| ts | Loading commit data... | |
| ttml | Loading commit data... | |
| tx3g | Loading commit data... | |
| vp9 | Loading commit data... | |
| wav | Loading commit data... | |
| webvtt | Loading commit data... |