LE 12b2: IPTV streams stutter when piped with ffmpeg

  • Hello,

    I have a problem concerning my IPTV streams, like with all new major LE releases in the past ;)

    I ffmpeg pipe my TV Provider streams through TV Headend and watch them with the TV Headend Plugin in LE. TVHeadend Server is running on the same machine and is using the provided ffmpeg binary from the plugin.

    It seems that ffmpeg in LE12 (6.0.1) has problems with the TV provider streams. The streams stutter and are extremely choppy. Under LE11 with the older ffmpeg everything is fine.

    Playback via a TVHeadend Client on my smartphone results in choppy/stutter playback too, so it must be the ffmpeg pipe within TVHeadend Server on LE12. DVB-T2 Streams from the same TV Headend Server play fine, both in Kodi and on the Smartphone with the TVH-Client (DVB Streams aren't touched by ffmpeg in any way)

    Edited once, last by ApexDE (April 22, 2024 at 7:55 AM).

  • Would you mind adding a ffmpeg plugin with the 4.4.x ffmpeg version as a alternative?

    There's no info on your hardware/codecs/configuaration or Tvheadend configuration, and no debug logs .. /shrug

    So assuming there is a real problem (not related to client-side drivers) the issue should be reported to Tvheadend devs so it can be investigated. If the problem is in Tvheadend (as you suggest) that's where a fix is required; we have no interest in packaging retro ffmpeg versions for workarounds.

  • Sorry for the missing input. All running on Raspi4B.

    I set up a separate Raspi4B running LE 11.0.6, same TVHeadend-Server version and same IPTV Streams just as a server for TVHeademd. I set up another Raspi4B with LE12b2 just as TV Headend Client. The HTSP streams served from the LE 11.0.6 run fine.

    If i run the same configuration all on LE12b2 with the newer ffmpeg (through TV Headend) the streams are unwatchable: stutter and skipping (even seconds back again and starting over from that point)

    So my guess is that the newer ffmpeg Version on LE12b2 has problems in piping. Could your counter-check that?

    I'll try to provide debug logs and dig deeper.


  • OK, that idea was good, i got a step closer: under LE12b2 the pipe closes after about one second, under LE11 it stays open (as supposed to be) with the following command:

    ffmpeg -loglevel fatal -i -vcodec copy -acodec copy -f mpegts pipe:1 >test.ts

    i guess TVHeadend-Server executes the above command everytime again once ffmpeg exits/closes the pipe, so that explains the extreme problems and stutter. So the problem lies within ffmpeg as i believed. Question now is why ffmpeg 6.0.2 closes the IPTV stream/pipe after 1 second and ffmpeg 4.4.3 works as expected.

  • can you try if it works with the internetstream ?

    pipe://ffmpeg -loglevel fatal -i https://zdf-hls-15.akamaized.net/hls/live/2016498/de/veryhigh/master.m3u8 -vcodec copy -acodec copy -metadata service_name=ZDF\ HD -metadata service_provider=IPTV-DE -mpegts_service_type advanced_codec_digital_hdtv -f mpegts pipe:1

    MAYBE mpegts_service_type helps ?

    FFmpeg Formats Documentation

    also try to set the loglevel to some more verbose setting, maybe there is some hint why it closes

  • piped ffmpeg exits on this stream also, but it takes MUCH longer, about 10-30 seconds.

    I don't get any logs from ffmpeg. Maybe because of piping?

    EDIT: OK, i get logging when i turn on "debug" logging instead of "fatal". Sadly, i don't see warnings or errors. ffmpeg 6.0.1 just closes the connection and exits on the IPTV streams. It says "EOF" in the log, which isn't the case. The stream was not stopped. I'll attach the ffmpeg log.

    I did some further testing on other machines: Synology NAS with ffmpeg 4.4.4 : works, mac mini with ffmpeg 4.4.2: works. LibreElec 11.0.6 with ffmpeg 4.4.3: works.

    Would you mind adding ffmpeg 4 as a option to LibreElec 12?

    Edited 5 times, last by ApexDE (April 22, 2024 at 7:15 AM).

  • OK, thanks.

    These "static" versions fail to establish tcp connections/resolve hostnames on LE12b2

    [tcp @ 0x109fa6e0] Failed to resolve hostname chemnitz.iptv-playoutcenter.de: System error
    https://chemnitz.iptv-playoutcenter.de/chemnitz/chemnitzfernsehen.stream_1/playlist.m3u8: Input/output error

    Edited 2 times, last by ApexDE (April 22, 2024 at 8:55 PM).

  • I tried this my self (at RPi5) works like a charm, recorded 5mins without a problem. Used ffmpeg-tools from repo.

    ffmpeg -i https://zdf-hls-15.akamaized.net/hls/live/2016498/de/veryhigh/master.m3u8 -vcodec copy -acodec copy -metadata service_name=ZDF\ HD -metadata service_provider=IPTV-DE -mpegts_service_type advanced_codec_digital_hdtv -f mpegts pipe:1 > aa.ts

    MAYBE a fs problem ?

  • OK... all my tests here showed that i only get stable streams using ffmpeg 4.x.x versions. I guess i have to dig deeper and learn how to compile a ffmpeg4 package for/with LE 12 myself. This will get very hard i believe ;)

    EDIT: there are two different TVHeadend-Server Addons in the repo, why not a second "legacy" ffmpeg addon? One could choose which to use/install?

    Edited 4 times, last by ApexDE (April 23, 2024 at 8:58 PM).

  • We will drop the 4.2 (and 4.3) version once Tvheadend makes a 4.4 release. Making a 4.4 ffmpeg probably isn't hard, but when there is a single user in our entire userbase reporting an issue, it's not justified.

  • i guess more reports will follow once LE12 is released and more users will upgrade. I was the first reporting IPTV problems several times with new major releases.

    I'll dig myself into Raspberry LibreElec Development/Crosscompiling and try to build a ffmpeg 4.4.x package myself.

    Edited 4 times, last by ApexDE (April 24, 2024 at 9:24 AM).

  • I managed to set up a LibreElec 12 Development system using Ubuntu 22.04 and compiled the ffmpeg addon using 4.4.4 sources. I'm a bit proud ;)

    Best thing is: my IPTV Streams run flawless now with the selfcompiled ffmpeg 4.4.4 like on all other systems i tested which had ffmpeg 4.x on it (macOS, Synology, old LibreElec...)

  • i noticed that 12.0.0 is out on git as a new branch. I guess the changes i made in my local previous checkout will be overwritten/updated when i do "checkout 12.0.0" ?
    Is there a way to keep the changes i made or will have to edit/apply the changes afterwards again?

    The whole LE Development/git is completely new to me but exciting too.

  • i noticed that 12.0.0 is out on git as a new branch.

    LE 12.0.0 is tagged but there is no "libreelec-12.0" release branch yet (so we can still change/retag things if needed).

    The two main rules to avoid git conflict problems are:

    a) Fork our repo to your own GitHub account then clone from your repo (not ours).

    b) Always work in a topic branch, never work in the master branch.

    If you cloned our sources directly from our repo you can always fork it online then reset/change the 'origin' location in your local clone of the repo to be your fork (edit .git/config and change the URL). If you are working in the master branch you can simply checkout a new 'mychanges' branch from master, then you can add an 'upstream' remote, pull changes from upstream/master and then hard reset your local master branch to match upstream/master. Your local changes are still be in the 'mychanges' branch and now you can rebase against the (updated) local master branch before rebuilding an updated image. The process might initially sound complicated and there's some terminology to become familiar with, but it's just a new finger-habit to learn.

    Have a read here: https://wiki.libreelec.tv/development/git-tutorial

  • The EOF Bug of ffmpeg 6.0.1 has been reported/documented by another user now. So i am not the only one having problems.

    ffmpeg 6: HLS sessions don't work (EOF) · Issue #25131 · xbmc/xbmc
    Bug report Describe the bug ffmpeg doesn't provide a continuous stream - the playback stops after a few seconds. Expected Behavior The playback doesn't stop…

    Maybe you can provide an official Addon with 4.4.4 static until it is fixed / update for 6.x is available?

    Edited 3 times, last by ApexDE (May 9, 2024 at 8:04 AM).