Proposal to increase A/V demux queues slightly

[dagwieers]

Description

This proposal is based on a change already implemented by @davilla for MrMC which also fixes known issues with specific HLS streams.

Whereas @davilla's changes for MrMC go a lot further than we need to fix the known issues increasing the SetMaxTimeSize of Audio and Video demux queues from a value of 8 seconds to 10 seconds is sufficient. @peak3d proposed 12 seconds for both.

This PR is the same changes as PR #17608 but against the master branch.

Motivation and Context

While these streams have issues, we are in no position to fix those streams. Other tools (ffplay, THEOplayer, Shakaplayer, OMXplayer) behave perfectly fine on these streams as well and with this small fix the streams behave well in Kodi as well.

For Matrix we are looking into a more extensive fix in the player, but while we do not expect large changes in the VideoPlayer in Leia to be accepted and we like to see this fixed in the next release of Leia we are proposing this here.

Relates to:

• MrMC: fix: bump up max demux time and data limits for hdr/atmos
• Fix from @peak3d
• Retrospect: Skipping frames for Vier.be
• VIER-VIJF-ZES: Playback issues (skips in the video) of some streams
• Kodi: Automatic rewind when streaming online content

How Has This Been Tested?

This has been tested by various people over the past 2 years which have suffered from the existing streaming issues and has proven to overcome those.

And this is the default setMaxTimeSize setting for MrMC.

Types of change

• Bug fix (non-breaking change which fixes an issue)
• Clean up (non-breaking change which removes non-working, unmaintained functionality)
• Improvement (non-breaking change which improves existing functionality)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that will cause existing functionality to change)
• Cosmetic change (non-breaking change that doesn't touch code)
• None of the above (please explain below)

Checklist:

• My code follows the Code Guidelines of this project
• My change requires a change to the documentation, either Doxygen or wiki
• I have updated the documentation accordingly
• I have read the Contributing document
• I have added tests to cover my change
• All new and existing tests passed

[FernetMenta]

If you don't adjust calculations based on the buffer times, this will change behaviour, i.e. longer channel switching times for live tv.

[dagwieers]

@FernetMenta The original value was acceptable 10 years ago. I would expect people's internet bandwidth and latency has only improved over that period, a multiple of the 25% increase we propose here.

[a1rwulf]

@dagwieers I think what @FernetMenta wants to tell us, is that if we change those buffersizes we also need to change other stuff that's based on them being this size.

[FernetMenta]

You always have to consider all use cases, not just your own. Receiving a realtime stream and having the buffer filled, i.e. 50% has nothing to do with bandwidth. If you increase the buffer by 25%, you have to wait 25% longer until the buffer is 50% full.

[dagwieers]

@FernetMenta If you are filling buffers when streaming, the time to fill your buffer is directly related to bandwidth and latency (as well as the size of the buffer).

If 10 years ago an 8-seconds buffer was good enough, I would expect a 10-seconds buffer today is filled faster than an 8-seconds buffer 10 years ago. I am sure your bandwidth and latency improved by more than 20% in the past 10 years.

Update: So yes, I didn't get the "live stream" part of the discussion :-)

[popcornmix]

Not for a real-time (live) stream. To fill 10 seconds of buffer will take 10 seconds regardless of network bandwidth.

[a1rwulf]

So we could fill 40% of a 10s buffer instead of 50% of a 8s buffer, right?

[FernetMenta]

in order not to change behavior you need to change all calculations to absolute time rather than percentage

[davilla]

There is also the buffering rate limit clamp to deal with. We removed it long ago and fill buffers as fast as the network can handle. We would rather burst fill than fill too slow and it removes yet another dependency quirk that might or might not be causing issues.

[phunkyfish]

@FernetMenta whereabouts should the calculations based on the buffer times be changed?

[DaveTBlake]

Would prefer not to just bump this though milestones, but unclear on state.
As a "fix" it is still welcome in v19, but op says "For Matrix we are looking into a more extensive fix in the player,... we like to see this fixed in the next release of Leia we are proposing this here." so change was only intended as a workaround in v18 that never made it.

Then there is also the opaque comment from @FernetMenta

in order not to change behavior you need to change all calculations to absolute time rather than percentage

Not expecting answers by tomorrow so going to bump that milestone one more time, but can those that know about the player please clarify what needs to be done or if this should be closed.

[da-anda]

@dagwieers is this PR still valid?

[sschamp]

I had to bump the values to 12.0
My Kodi build has been running for well over a year now and runs flawlessly with that value on an Nvidia Shield.

[phunkyfish]

I had to bump the values to 12.0
My Kodi build has been running for well over a year now and runs flawlessly with that value on an Nvidia Shield.

Thanks for the info. Unless we can figure out where we need to change the calculations to absolute time instead of percentage then I don’t see how this PR could progress.

[jenkins4kodi]

@dagwieers this needs a rebase