This is reproducible using the sample provided here.
From an initial look, it appears the samples are queued with incorrect timestamps in SpliceInfoSectionReader.consume. In particular because getLastAdjustedTimestampUs appears to return an unadjusted timestamp, rather than an adjusted one? It could be that simply fixing this is the right thing to do, but it's a bit unclear to me exactly how the subsample offset and its use in SpliceInfoDecoder works, so it's possible I've misunderstood.