[markg85]

Hi,

I'm looking through the code to handle an STRM and am ending up in CUrlFile.cpp
Am i correct in assuming that KODI handled http/https url's through Curl?
I'm guessing that the (buffer)data it gets through curl is then passed onto ffmpeg, right?

I'm curious what the technical reason is for this approach - if my assumptions are correct! - as ffmpeg can handle URLs perfectly fine too.
And with that i'm curious if a patch would be considered that rewrites the CurlFile to be handled through ffmpeg instead?

The core reason i'm asking this is because i want to add IPFS support to KODI. This support landed in ffmpeg 5.1.
My thinking is that adding "ipfs://bafybeigagd5nmnn2iys2f3doro7ydrevyr2mzarwidgadawmamiteydbzi" to a .strm file should happily play that data from the IPFS network (this particular example is big buck bunny).

Looking forward to your thoughts!

[izprtxqkft]

my understanding is that kodi handling strm like a playlist is a kodi thing not an ffmpeg thing so ffmpeg wouldnt know what to do with a strm as it might an hls, m3u8 or dash mpd
i would be curious if you traced down the handling for those files where the handling for them lands

if what i understand is correct then you could put a hls where the strm is and it would go to ffmpeg instead (of course hls is http stream and would probably fail if not sent from an http server)

very interesting... ill be watching to see what comes of this

[wsnipex]

curl is used for stuff that ffmpeg doesn't understand, so pretty much what jepsizofye said.

[markg85]

But ffmpeg understands hls on m3u8 and dash perfectly fine.
Here are some examples for you to try out to see that ffmpeg has you covered here:
m3u8 HLS stream: https://demo.unified-streaming.com/k8s/f....ism/.m3u8 (this is the Tears of Steel demo coming from https://ottverse.com/free-hls-m3u8-test-urls/)
mpd (dash) stream: http://ftp.itec.aau.at/datasets/DASHData..._05_09.mpd (from https://dash.itec.aau.at/dash-dataset/)

Play them using ffplay <url> to only use ffmpeg.

I haven't looked into the history here but could it be that CUrlFile class predates FFmpegs handling of http resources?

[izprtxqkft]

yes thats what i at least tried to say
to ffmpeg a .strm file is as good as a .txt file and it doesnt know what to do with it because it doesnt know it as a playlist file like the other 3 i mentioned

[markg85]

yes thats what i at least tried to say
to ffmpeg a .strm file is as good as a .txt file and it doesnt know what to do with it because it doesnt know it as a playlist file like the other 3 i mentioned

Ah right!

I get that ".strm" is kodi specific.
But i mean that the content of that strm file could - and should? - be handled by ffmpeg.
As that content would just be an URL.

This only holds true if a strm file is only supposed to have one line as http resource. Is that the case?

[izprtxqkft]

a url in a single line of a strm file is the most common use of the file but actually it has more use than that, you can add kodi specific properties

https://kodi.wiki/view/Internet_video_and_audio_streams

this post shows how one user was attempting to use it with inputstream - https://forum.kodi.tv/showthread.php?tid=346141

[markg85]

Hmm, interesting!
I need to dive into this deeper to figure out how it works exactly.

Gut feeling is that it's eventually - even the kodiprop entries - passed to appropriate ffmpeg flags.

Question, has there even been an attempt to merge that strm file format to ffmpeg? Imho that would save a lot of hassle on the KODI side, would it not?
But i might not be having the complete picture here

[izprtxqkft]

im not team kodi so i can only speculate but im glad you brought this topic up its giving me ideas

[wsnipex]

if you want to integrate ipfs into kodi, you need to do more then pass it to ffmpeg. Kodi has a pretty extensive virtual file system that abstracts away the details of various backends.
Take a look here: https://github.com/xbmc/xbmc/tree/master...filesystem

[markg85]

if you want to integrate ipfs into kodi, you need to do more then pass it to ffmpeg. Kodi has a pretty extensive virtual file system that abstracts away the details of various backends.
Take a look here: https://github.com/xbmc/xbmc/tree/master...filesystem

Nah, that's not what i'm after

In my thinking the strm files would in their entirety be handled by the build-in inputstream-adaptive addon. There would be no "CurlFile" class anymore.
Technically that approach would allow a strm file to contain anything that ffmpeg can handle.

Only talking about strm files here, not of the wealth of other protocols and filesystems that kodi supports.
It doesn't mean that a strm file, when it can support that much, should. I'd constrain it down to a few formats.

[markg85]

I'd like to discuss the options further. Is there a kodi place where chatting is an option (slack, discord, ...?)?

[izprtxqkft]

@markg85
go to the main page https://kodi.tv and then click on the "Help" drop down, there's an IRC link, within that there is a developer channel

[markg85]

@markg85
go to the main page https://kodi.tv and then click on the "Help" drop down, there's an IRC link, within that there is a developer channel

Sweet! Will do, thanx for the pointer!