Remove check for monotonic dts

[uvjustin]

Proposed change

Long running RTSP feeds may encounter overflows of pts/dts values (see PyAV-Org/PyAV#591). The current check of whether the dts is monotonic would then discard all new incoming packets.
The monotonicity check seems to be unnecessary - libav discards out of order packets in the RTP decoder here: https://github.com/libav/libav/blob/master/libavformat/rtpdec.c#L798

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example entry for configuration.yaml:

# Example configuration.yaml

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• The code has been formatted using Black (black --fast homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[probot-home-assistant]

Hey there @hunterjm, mind taking a look at this pull request as its been labeled with an integration (stream) you are listed as a codeowner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[uvjustin]

@hunterjm I didn't find a problem with non-monotonic packets on my end - do you remember if it was an issue previously?

[hunterjm]

Yes, the muxer will not write them and will throw an error if it is passed non-monotonic packets. The issue here is with WiFi cameras or UDP only connections on an unstable network with packet loss. This check was added after initial release because it’s better to miss packets than crash the muxer entirely.

Have you actually run into an overflow issue? I’ve had feeds running for weeks without incident.

[uvjustin]

I've seen the failure on the muxer side when adjusting packet dts such as when creating audio and generating the DTS values manually - sometimes you might round two packets to the same dts and the muxer will crash. I just haven't seen it on the input, and looking at the libav RTP code it looks like out of order packets are taken care of (I didn't see it in the RDT code, but I don't think any cameras use RDT).
We could leave the check in and have it also log an error or warning in case an out of order packet is ever detected. With enough people testing it we should be able to see if it ever really happens.
As for the overflow, I don't think I've had an overflow either. It really depends on what time_base is used and how many bits are used for the timestamp representation. For example, with MPEG-TS streams with a 90k time_base and 33 bits for the DTS/PTS you get an overflow every 26.5 hours: https://tech.showmax.com/2018/04/why-so-serious/ . Of course each extra bit will double the period, so with 64 bit timestamps you'd almost never encounter overflows. The PyAV link above does seem to indicate that some streams will overflow. We could treat this one like the out of order packet and plan for it while just logging an error or warning.

[hunterjm]

We can also treat it like the missing dts and auto-restart the stream by exiting the process?

[uvjustin]

We can also treat it like the missing dts and auto-restart the stream by exiting the process?

Yes, that sounds about right. See the latest commit (I haven't tested it yet).

[uvjustin]

Dumb question...what is the line length to use for black with HA? Default is 88 and PEP8 says 79, but neither work. I keep getting CI errors

[balloob]

Black config is part of the repo and should be picked up automatically. We use black defaults btw.

[uvjustin]

Black config is part of the repo and should be picked up automatically. We use black defaults btw.

I must have messed something up in my dev container. I cloned the repo again and it's fine now.

[balloob]

I checked. We recently updated Black and it changed certain formatting. You must have had an old Black.

[hunterjm]

Latest commit looks good... not sure how to test unless we can force an overflow or out of order packets. Pretty sure I wasn't personally able to test the skip logic anyway. For reference, here is the PR hotfix that added it in the first place. Unfortunately there is not a linked issue. Likely because it was reported in Discord.

#22238

[hunterjm]

@uvjustin - Can we leave this one open to merge as a part of 0.116 or is this fixing a known bug in the current beta? If it can wait, I'd prefer to leave this PR open to make cherry picking bugfix commits into 0.115 easier.

[uvjustin]

No major bug fix, but it's a small PR that won't break anything. I also slipped a line in there that remembers to close the input container before exiting if there is no video stream.
Up to you whether we want to wait until 0.116

[uvjustin]

@hunterjm The errors here https://community.home-assistant.io/t/cannot-stream-onvif-cameras-to-google-home-post-upgrade-to-0-115-or-0-115-1/228050 are interesting. Note how close they are to 2^32. Not sure exactly why they are happening. The ffmpeg source of the error is here https://ffmpeg.org/doxygen/trunk/movenc_8c_source.html#l05431 .

[hioctane61]

Hi, i raised this issue (#41891) and i then came across this here. Are they one and the same? can i close 41891?