packet.is_corrupt is off by one

[dotysan]

Not sure if this is a bug in PyAV or ffmpeg. But here goes...

Overview

When ffmpeg debugging is enabled, and a corrupt packet is encountered, it reports a different pts from the current PyAV packet that has .is_corrupt == True.

Reproduction

#! /usr/bin/env python3.12

import av

from logger import log

av.logging.set_level(av.logging.INFO)
# av.logging.restore_default_callback()

input_mpegts = 'rtsp://127.0.0.1:3011/net0'
input_options = {
    'rtsp_transport': 'tcp',
}

with av.open(
    input_mpegts,
    container_options=input_options,
) as in_container:

    for packet in in_container.demux():
        log.debug(packet)

        if packet.is_corrupt:
            log.warning(f"corrupt: {packet}")

The ffmpeg logging indicates a corrupt packet of pts=X. However, the packet.is_corrupt is the next one.

Versions

• OS: Ubuntu 22.04LTS
• PyAV: v13.1.0

Ugly workaround

last_packet = av.Packet()
for packet in in_container.demux():
    if last_packet.is_corrupt:  # BUG! why is it off by one?!?
        log.warning(f"this corrupt: {packet}")
    last_packet = packet

In the above, the pts of the ffmpeg DEBUG corrupt packet matches ours.

[WyattBlue]

I don't have logger or a connection to the tsp stream. It would be difficult for me or anyone to reproduce this.

[dotysan]

Oops! It turns out logger is just a subclass of logging that add a VERBOSE log level.

But you're right on the live RTSP endpoint.

I was able to convert the live stream with corrupt packets to a .ts file. And with ffmpeg native, the corrupt packets are indeed still detected by h264. But not PyAV anymore. :-(

Not sure how to create a test case here for live RTPS streaming. Open to suggestion, though...