Support Kodi VFS resources

[garbear]

Description

Allow adaptive resources to be read through Kodi's VFS in addition to HTTP(S). Because I want to play file::// URLs.

AI use:

Extend URL resolution to support Kodi VFS schemes, including file:// URLs and URNs (such as potential v23 magnet: links in xbmc/xbmc#23696) across nested playlist, init and segment URLs.

Extend CUrl so HTTP(S) keeps the existing CURL path while other schemes use kodi::vfs::CFile. Byte ranges use the existing HTTP Range header for HTTP(S), or seek and bounded reads for VFS resources.

Update adaptive segment downloads to use the transport-independent range handling.

Motivation and context

InputStream Adaptive currently opens adaptive resources through Kodi's CURL interface, which limits playback to HTTP(S)-style resources.

This allows manifests and their referenced resources to be loaded from Kodi VFS URLs such as file://, and enables VFS providers such as Kodi's magnet: filesystem to be used by InputStream Adaptive without adding transport-specific code to the add-on.

How has this been tested?

Tested on macOS ARM64 with Kodi 22 development builds.

• Added tests for generic URI detection and nested VFS URL resolution, including preservation of magnet query identity.
• Added tests for local VFS reads, bounded and open-ended byte ranges, EOF handling, failed seeks, and preservation of the existing HTTP path.
• Added adaptive-stream tests for VFS byte ranges and stopped downloads.
• Full InputStream Adaptive test suite passes: 83/83.
• Tested end-to-end with a local CMAF/HLS presentation using file://.
• Kodi loaded the modified InputStream Adaptive add-on, opened the master and child playlists, initialization fragments and media segments, decoded 3840x2160 H.264 with E-AC-3 Atmos audio, and played the approximately 20-second presentation to normal EOF.

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)

[CastagnaIT]

I would like to have something like m_isVfs instead of m_isHttp so that its more clear that code is for VFS protocols (here and in all other code changes)

[CastagnaIT]

Of course, if we don't have information about the download speed,
this will make it impossible to manage automatically the stream quality in "adaptive" streams
this should be documented, more likely on Wiki

It will need to be documented that also headers cannot be handled either,
they are usually important for most streaming services
I’m not familiar with VFS protocols, but i imagine that VFS sources are custom streams (?) and don’t require http headers but it’s best to point this out also this one on Wiki

[garbear]

I'll see what we can do about download speed. I only tested with file:// URLs, in which case download speed isn't really an issue. So VFS support was initially for testing. But I want to use it with magnet:?xt=urn:btih:... URNs as well. Later I'll research this use case more, and come back with changes.

[CastagnaIT]

I've just taken a quick look
I'll review in the coming weeks since there's no rush with this feature

[garbear]

I'll review in the coming weeks since there's no rush with this feature

No rush, my ultimate use case is to combine this with xbmc/xbmc#23696, which definitely isn't a v22 feature and far from being done.