TeamNewPipe/NewPipe · error · EOFException

parser go beyond limits of the box. type=%s offset=%s size=%

Error message

parser go beyond limits of the box. type=%s offset=%s size=%s position=%s

What it means

Mp4DashReader.ensure(ref) computes how many bytes remain until the end of the current box (ref.offset + ref.size - stream.position()). A negative skip means the parser already read PAST the declared box boundary — the sub-parser consumed more bytes than the box allows, indicating a corrupt or inconsistent box. The EOFException reports type/offset/size/position for diagnosis.

Source

Thrown at app/src/main/java/org/schabi/newpipe/streams/Mp4DashReader.java:311

        buffer.putInt(ref.type);

        final int read = size - 8;

        if (stream.read(buffer.array(), 8, read) != read) {
            throw new EOFException(String.format("EOF reached in box: type=%s offset=%s size=%s",
                    boxName(ref.type), ref.offset, ref.size));
        }

        return buffer.array();
    }

    private void ensure(final Box ref) throws IOException {
        final long skip = ref.offset + ref.size - stream.position();

        if (skip == 0) {
            return;
        } else if (skip < 0) {
            throw new EOFException(String.format(
                    "parser go beyond limits of the box. type=%s offset=%s size=%s position=%s",
                    boxName(ref), ref.offset, ref.size, stream.position()
            ));
        }

        stream.skipBytes((int) skip);
    }

    private Box untilBox(final Box ref, final int... expected) throws IOException {
        Box b;
        while (stream.position() < (ref.offset + ref.size)) {
            b = readBox();
            for (final int type : expected) {
                if (b.type == type) {
                    return b;
                }
            }
            ensure(b);

View on GitHub (pinned to 9e8be09156)

Solutions

  1. Re-download or re-mux the file; nested box sizes are internally inconsistent.
  2. Validate with MP4Box/mp4info which also reports size inconsistencies.
  3. If you produce the files, audit nested box size computation to ensure children never exceed parent extents.
  4. Treat the error as fatal for the fragment and skip to the next moof if resilience is required.

Example fix

// before — sub-parser can overrun the parent box and trigger ensure()
parseChildren(box); // reads past box.size

// after — clamp child reads to the parent box boundary
long limit = box.offset + box.size;
while (stream.position() < limit) { parseChild(box); }
Defensive patterns

Strategy: validation

Validate before calling

// Producer-side: ensure sub-parsers never read past the parent box boundary.
long parentEnd = box.offset + box.size;
while (stream.position() < parentEnd) {
    parseChild(box, parentEnd); // pass limit, clamp child reads
}

Type guard

public static boolean childWithinParent(long childEnd, long parentEnd) {
    return childEnd <= parentEnd;
}

Try / catch

try {
    ensure(box);
} catch (EOFException e) {
    if (e.getMessage().contains("beyond limits")) {
        // parser overran the box — fragment is corrupt, skip to next moof
        Log.w(TAG, "box overrun at " + e.getMessage());
        continue;
    } else throw e;
}

Prevention

When it happens

Trigger: Any ensure(ref) call after parsing box children where a sub-parser read beyond the parent box's declared size. The parent box size is smaller than the sum of its children, or a child's declared length overran the parent.

Common situations: A malformed box with an undersized size field relative to its content; a corrupted trun/stbl/traf where field lengths are inconsistent; a tampered file; a muxer bug producing inconsistent nested sizes.

Related errors


AI-assisted analysis of TeamNewPipe/NewPipe@9e8be09156 (2026-08-14). Data as JSON: /api/errors/6175b0b028f216eb. Report an issue: GitHub.