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 |
|---|---|---|
| .. | ||
| bear.opus | Loading commit data... | |
| bear_flac.ogg | Loading commit data... | |
| bear_flac_noseektable.ogg | Loading commit data... | |
| bear_vorbis.ogg | Loading commit data... | |
| bear_vorbis_gap.ogg | Loading commit data... | |
| bear_vorbis_with_large_metadata.ogg | Loading commit data... | |
| continued_packet_at_start | Loading commit data... | |
| continued_packet_over_four_pages | Loading commit data... | |
| continued_packet_over_two_pages | Loading commit data... | |
| eof_header | Loading commit data... | |
| flac_header | Loading commit data... | |
| four_packets_with_empty_page | Loading commit data... | |
| invalid_header | Loading commit data... | |
| invalid_ogg_header | Loading commit data... | |
| opus_header | Loading commit data... | |
| packet_with_zero_size_terminator | Loading commit data... | |
| page_header | Loading commit data... | |
| random_1000_pages | Loading commit data... | |
| three_headers | Loading commit data... | |
| vorbis_header | Loading commit data... | |
| zero_sized_packets_at_end_of_stream | Loading commit data... |