Add #EXT-X-DISCONTINUITY support to ffmpeg for IPTV streams such as Stirr and Pluto #57
Comments
|
http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180316/739542e4/attachment.obj https://trac.ffmpeg.org/ticket/5419#comment:9 from: https://forums.whirlpool.net.au/forum/?action=replies&r=66793662 @joshuaboniface @nyanmisaka what do you guys think? the patch has been added for 2 years but it's yet to make it into stable |
|
+1 for interest in hearing if we can handle DISCONTINUITY in JF. |
|
Would also like this |
|
I would love to see this supported as well. It would also also be nice to see inputstream.adaptive from Kodi supported as well to support WideVine DRM like Kodi supports. |
That seems like a massive open door for DMCA issues. |
|
Why would supporting DRM open an issue for DMCA? That makes zero sense. You will still have to pay to use the service and still need a login and password. Kodi officially supports Netflix, Amazon, Disney+ and other plugins. I don't see the problem here. If anything it seems like it would move away from being a product "mostly for pirating" and make it more legitimate since you are supporting legal streaming. |
|
Would love to see this added. Seems it could fix issues with us and Live TV issues. |
|
Can I +1 this? Would also like it to be implemented. Thanks. |
|
Yes I vote for this |
|
You can vote and +1 it all you want, but it's not going to change anything. Someone needs to implement it. |
|
I think someone has but they need to apply it. This or this |
|
https://github.com/jjustman/ffmpeg-hls-pts-discontinuity-reclock This one is a great start just needs to patched to the most current version of ffmpeg since that version looks to be about a 3 year old fork of ffmpeg. Not to mention there are links above to multiple patches to add support for this in ffmpeg. The issue isn't code but the more the dev team applying these patches to their version of ffmpeg. |
|
Would love to see this added. |
|
It seems like the current work is done here: It's possible to apply the patch and build ffmpeg. Since I have no stream that encounters this issue I can't say if the patch fixes every issue. It does however no longer skip EXT-X-DISCONTINUITY. |
If it's that easy, please provide a properly tested patchset as a PR, we are always happy if new people contribute features we don't have the time or interest (we're all just volunteers, doing work we're willing to invest time in) in implementing. |
I do, and I can say it still complains readily about (and freezes with) a |
If it’s legal to do so, please post the m3u8 link to help troubleshoot. |
For testing purposes I was using this list for Pluto, using... whatever channel was airing TV shows, not movies (since Pluto does their own thing with channels, I can't remember, but it shouldn't matter as they all behave the same way, just that they run more ad segments on TV programming) |
|
It is legal for Xumo, Stirr, Pluto and Plex TV streams Pluto TV Vizio Free TV Streaming Here is a whole bunch of free and legal steaming channel and guides here: Should be plenty of legal public streaming TV for anyone to test things out and see the problems. |
|
One of the major issues is that RFC-8216 is not fully supported in FFMPEG https://datatracker.ietf.org/doc/html/rfc8216 #EXT-X-DISCONTINUITY is just one of the things from RFC-8216 that isn't supported properly in FFMPEG. Just look through the RFC and you still see things missing from FFMPEG. |
It might be worth replacing FFmpeg as an m3u8 parser with https://github.com/globocom/m3u8, which is an Expat licensed RFC-8216 player, for now. And then I can work on getting FFmpeg up to compliance without Jellyfin users continuing to be inconvienced. |
|
Not sure what you mean by Expat license for: |
Calling something the 'MIT license' is unclear, as MIT has used several different licenses over time. The more accurate term for the specific one in use by that project is the Expat License, as you can read about at https://www.gnu.org/licenses/license-list.html#Expat |
Shadowghost
added
enhancement
|
Is it possible to bypass #EXT-X-DISCONTINUITY with using TVHeadend? I found this: https://tvheadend.org/boards/5/topics/43052?page=1&r=45733 and it looks promising, but i didn't test it yet. |
|
I can test that later today, to see if we at least have a workaround |
After seeing this message, I attempted to use Cabernet, but it has very little documentation. The best I got was getting the stream to close when the commercials started, and to get it to resume as soon as the commercials ended by pressing play again (A black screen is shown until then, and sometimes it just doesnt load). Here's a sample of my config file:
I also attempted to feed cabernet into tvheadend, then into Antenna and then into jellyfin but it work worse. |
This comment was marked as spam.
This comment was marked as spam.
|
I got this patch applied to a local copy of jellyfin-ffmpeg-v5.1.2-8 (http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180316/739542e4/attachment.obj)
Edit: Figured it out, needed to handle version in my wrapper. Edit 2: Got the patch working and a wrapper that adds the parameter. Streams are definitely more stable now and will continue to play. There are still some streams that seem to have hiccups or just refuse to play. Probably because this only addresses part of the RFC-8216 spec compatibility holes. |
|
Something I discovered while delving into this issue: Now my main question: Now that I have tested the patch and validated that it still works, is this type of patch (adding optional parameter for use by the server) something that should be added to jellyfin-ffmpeg? Edit: Realized we can also set it as a default option (no wrapper needed) if that is something that fits with the goals of jellyfin-ffmpeg. Original Patch Link: http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180316/739542e4/attachment.obj |
Hello, I'm not very savvy with this. Can you explain how to get your patch working step-by-step? |
|
Do we have any updates on this? |
|
There is not much to update on as long as either someone provides a patch working with the current FFmpeg or it is fixed upstream. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
I'm sorry, I don't understand: Jellyfin doesn't use this feature, or the users don't use this feature? |
|
Please stop arguing, that is not helpful. Let me clarify the situation for you, as there may be some misunderstanding. Regarding the "working" patches mentioned, it's important to note that they are not a spec-compliant implementation for streams with discontinuity. Instead, they are more of a hack that overrides all timestamps, and just hope the underlying muxer would smooth the playback for it, which is not considered a proper fix. While this approach might work for some streams, it's not guaranteed to work for all, and it was rejected by upstream ffmpeg for being too hacky. Now, when it comes to supporting certain TV providers like Pluto, simply supporting discontinuity streams is not enough. This is because streams from providers like Pluto often break the HLS RFC spec in various ways, and a spec-compliant HLS demuxer would reject these streams as well. To illustrate, proper support for the In summary, the patch mentioned in this issue is deemed too hacky, and supporting TV providers like Pluto would require more than just an RFC-compliant HLS demuxer. So if you ask why there is no update, because there is no one want to solve all the challenges I mentioned for ffmpeg. The ticket is created for 8 years and the only thing we have now is a hacky patch that was rejected. What can we update with? If someone wants to help, then we can have some updates and that's why we said "PRs are always welcome". I attempted to look at this once, and then I realized that the TV providers are more broken than I previously thought which made my attempt failed. Even if we do have disconituity tag support, malformed manifest update can lead to any kind of playback oddities, such as segments played multiple times, or periods switched before the end of their playback, due to the impossibility of determining the right sequence number and segment to be played. |
|
I apologize, I didn't mean to come off like I was arguing, I just want a better handle on the situation, because it seems wild to me that something would go this long without a fix, and I couldn't really understand why. Your explanation is exactly what I think was needed here, and as I understand it, the blame really rests with the content providers breaking spec, possibly intentionally, to throw a wrench into any efforts to use non-authorized streaming methods. So, if I understand the rest correctly - this ball is in the upstream ffmpeg developer community's court? |
It's in the court of whomever wants to work on this. Either by adding fully functional patches to jellyfin-ffmpeg or contributing them to upstream ffmpeg. I ended up switching to using channelsdvr to act as my iptv management and just pass the streams from channelsdvr to jellyfin. |
"Have you read the other comments? There is no update on this issue because we don't use this feature" not sure why you're speaking for an open source volunteer community, but uhh, you do you bro. Having a go at me when I was willing to take some time to work this out seems entirely childish, it was my first comment on a lengthy thread and tbh you seem needlessly rude, so i'll take a pass on wasting any more time on this issue, I was willing to help though, so nice work man. Edit: gunna go out on a limb here and say, in my time looking in to this issue, I came across a number of reddit threads/and forum posts discussing this issue, generally in relation to Jellyfin - so "we don't use it", is more like, "i don't personally know how to fix it/and don't care to", and its fine to feel that way, but no need to be rude to other users who are otherwise interested in the feature/fixing the bug - and obviously its not like this issue is impossible to solve, given tivimate default player/and a number of other players can handle ad breaks just fine https://i.imgur.com/Iyc4hvA.png. |
|
Look, you come in here complaining about a lack of updates (classic entitled user behaviour, not contributor). You don't mention wanting to contribute, you simply refer to the set of patches that have already been discussed. How is that helpful? I'm sorry that you feel sarcasm is unhinged behaviour (yes, I see the edit). I'm gonna stop replying now, because it's a complete waste of time. If you want to contribute, then do. Actual contributors ask constructive questions and/or create PRs. They don't come in here pointlessly adding to the pile of "omg, no updates?".
It's actually literally "we don't use it". gnattu is the only one on the team that uses a TV provider with ad breaks. We have no real incentive to grab a random set of patches, try to fix them up and then maintaining the mess, and you shouldn't want us to because it's never gonna be any good. |
I am mainly a user yes, but I do have some programming ability, and while I don't want to speak too soon, i MIGHT have found a possible pathway to a solution that uses something ffmpeg adjacent (sorta, will explain if testing pans out) -- I know I said I decided not to help, but I guess I couldn't help myself. At the moment I've gone through about 5-6 ad breaks on a plutotv stream (30 mins so far), and no crashes yet, will update with more details in a bit once I've done some more testing with a few channels. Edit: So I had been going around compiling different IPTV players to see how each of them handles ad breaks/discontinuity and i came across this https://github.com/Roshan-R/termv which is a CLI tool for MPV player --- when i found this earlier i didn't actually know about the main repo for mpv coz i'd never used it before https://github.com/mpv-player/mpv, so i just compiled roshan-r's CLI tool for it (comes with a bunch of the iptv channels by default, handy for testing if you don't have any playlists handy). (I compiled using Ming64 on windows after initially having trouble doing it via windows linux subsystem if anyone else wants to test channels using the CLI tool). dev's or whatever might have heard of MPV player before because mpv shim exists, but as best I can tell, if it was possible to create a web-assembly for it/some kind of wrapper idk, it might be possible to have IPTV in Jellyfin be handled by MPV player instead and have it be server side. To be clear, I haven't begun to imagine how this might be integrated in to Jellyfin/and even if it was, it seems like it might only be useful for IPTV, at this stage just here to confirm that MPV is a much more stable hls player than vanilla ffmpeg/or jellyfin ffmpeg, and if anyone wants to brainstorm how this could be approached, i'd possibly be game to try and help. At the time of writing this, MPV has been streaming several channels for I wasn't sure if trying to integrate MPV would be viable, or perhaps if it'd make sense to try and make Jellyfin FFMPEG offload handling of IPTV by primarily adapting Jellyfin FFMPEG/maybe have run headless window for mpv and have its output sent to ffmpeg which rebroadcasts it (bit of a hacky solution so probs not - but it does have API capabilities through ' JSON IPC API') either way I'm not confident at all that I'd be able to figure that out lol just throwing ideas out there. Also for testing purposes, I couldn't find any ready-made solutions that allow MPV to have its playback viewed in browser, so that would also need to be overcome i guess (i'm assuming lol, idk). Anyway i've updated this comment like 30 times, have conveyed all I've figured out for now, will probably keep tinkering to see how a solution might be applied. Edit 2: https://github.com/video-dev/hls.js is also probably a potential candidate for integration and might make more sense as its already able to handle browser playback/and also has a high level of stability from my testing so far. https://www.hlsplayer.org/ uses it, so im testing a bunch of channels now and if they all work will begin investigating ways to give hls.js as an option for iptv playback. It seems like it'd make sense to try and implement it as an optional way to playback iptv. edit3: oh just realized exo-player is based on hls.js and so is available client side. Also similarly, mpv seems to have an android app as an option for a client side player but it doesn't seem to handle streams at all compared to its pc counterpart. I guess I am trying to envision a server-side solution rather than a client side one that bypasses these issues. Will continue to see if i can come up with some kind of solution/workaround. |
|
Have the same problem with Jellyfin on Linux Mint 21.3. So it seems FFMPEG needs HLS PTS Discontinuity Support? Doesn't look like it's been updated for 6 years. Will it still work with newest FFMPEG? Trying to make Jellyfin a replacement for cableTV for my parents and I'm sure they don't wanna be told to restart the video every 2-7 minutes. |
and others
There are issues with IPTV streams that use the DISCONTINUITY tag in the HLS playlist, causing dropouts, freezing, etc.
Compiling ffmpeg with support for this flag will be an improvement for IPTV users.
See this thread and scroll down to around the May 2020 time frame for a discussion of the issue for Kodi and ffmpeg with Pluto and Stirr:
https://forums.whirlpool.net.au/archive/9nk7ly73
The text was updated successfully, but these errors were encountered: