Remote m3u playlist does not play about ffplayout

[jb-alvarado]

Hello @JunioCalu,
ffmpeg does not support m3u directly, so ffplayout can't play them to. In the frontend is only one option to convert a m3u list to a playlist that is supported by ffplayout, but I don't think that works in your case.

To your last question: A HLS playlist like: https://example.org/stream.m3u8 should work, but I don't think one from youtube. But I never test it.

Have you an example m3u Playlist?

[JunioCalu]

Some steps are necessary to use the file:

python3 -m pip install --upgrade git+https://github.com/back-to/liveproxy.git
sudo add-apt-repository ppa:tomtomtom/yt-dlp
sudo apt update
sudo apt install yt-dlp
liveproxy --host 0.0.0.0 --port 5555 --loglevel DEBUG &

epgm3u.txt

to test if it works:

mpv epgm3u.txt
or
vlc epgm3u.txt

Shell script used to generate the playlist:

 echo -e -n "Enter streaming link: "
            read -r link
            base64_string=$(echo "yt-dlp $link" | base64 | tr -d '[:space:]')
            playlist="$(yt-dlp -O "#EXTINF:%(duration)s, %(title)s, %(channel)s," $link)\nhttp://127.0.0.1:5555/base64/$base64_string/"
            
            echo -e "#EXTM3U\n$playlist" >> epgm3u.txt

[jb-alvarado]

Ok, it could work, I only see that it takes a bit time between opening and playing, that could be a problem.

You could try to use the m3u importer from frontend. Or you change your script to create a json playlist, like:

/var/lib/ffplayout/playlists/2023/06/2023-06-21.json:

{
    "channel": "Test 1",
    "date": "2019-03-05",
    "program": [{
            "in": 0,
            "out": 120,
            "duration": 647.68,
            "source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9S1QxcjR5Vmw2Z2cK/"
        }, {
            "in": 0,
            "out": 130,
            "duration": 149,
            "source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9SjNPRUduSDV4OGcK/"
        }
    ]
}

Of course you have to set the correct out and duration.

[JunioCalu]

Thank you for your attention, I will implement this solution. And another question, how does the in and out parameters work?

[jb-alvarado]

Thank you for your attention, I will implement this solution.

Before you put to much effort in it, you should test it good, if it works well.

And another question, how does the in and out parameters work?

Let say you you have a clip, that is 600 seconds long and you would like to start in on second 10, and stop it on second 500, then you parameters would look like:

"in": 10,
"out": 500,
"duration": 600,
"source": "path/to/source.mp4"

If you do not want to seek in, and set a new out, then in has to be 0, and out needs to have the same value then duration. These three values are mandatory.

[JunioCalu]

Before you put to much effort in it, you should test it good, if it works well.

I will do that as soon as I resolve a minor setback.

[JunioCalu]

{
"channel": "Test 1",
"date": "2019-03-05",
"program": [{
"in": 0,
"out": 120,
"duration": 647.68,
"source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9S1QxcjR5Vmw2Z2cK/"
}, {
"in": 0,
"out": 130,
"duration": 149,
"source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9SjNPRUduSDV4OGcK/"
}
]
}

It didn't work, or I'm not able to test it, the playback controls aren't working properly for me for some reason.

[JunioCalu]

{
"channel": "Test 1",
"date": "2019-03-05",
"program": [{
"in": 0,
"out": 120,
"duration": 647.68,
"source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9S1QxcjR5Vmw2Z2cK/"
}, {
"in": 0,
"out": 130,
"duration": 149,
"source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9SjNPRUduSDV4OGcK/"
}
]
}

With ffplayout update 18.4 this works. But there is something new to be implemented, the title name of the remote video source is not recognized, the "name" field is blank after the remote source is added to the playlist. And this implies another problem, ffplayout is not adding more than one video source with the same blank name, it is treating it as a duplicate and discarding it, this problem can be circumvented by manually creating the playlist's JSON file. And Maybe the ultimate solution is to implement a "name" field to the remote fonts import option, and maybe it's also a good idea to allow adding fonts with duplicate names in sequence.

[jb-alvarado]

The naming will be "fixed" in 0.19.0, but I put fixed in quotes because it is not exactly a fixed bug. Officially restreaming of remote sources is not supported, and will not in future. It is interesting that it some how works, but that is something user have to deal by them self. For me this is to unstable and I can not guarantee that it always work. I'm not even sure that is legal in all countries.

For 24/7 streaming the most recommended way is to use a local/network storage.

[JunioCalu]

It is a case to be analyzed, the ant-media server (community version) allows the insertion of remote sources, but in more restricted formats.

[jb-alvarado]

Videos from http sources are also supported: https://github.com/ffplayout/ffplayout/blob/master/docs/remote_source.md

But you try to use media from YouTube, that is a bit different 😉.

[JunioCalu]

yes it is supported, I meant extending support to more types of remote sources.

[JunioCalu]

{
"channel": "Test 1",
"date": "2019-03-05",
"program": [{
"in": 0,
"out": 120,
"duration": 647.68,
"source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9S1QxcjR5Vmw2Z2cK/"
}, {
"in": 0,
"out": 130,
"duration": 149,
"source": "http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9SjNPRUduSDV4OGcK/"
}
]
}

I noticed some difference in running ffplayout on different ubuntu versions:

On ubuntu 20.04 with ffmpeg 4.4.2-0ubuntu0.22.04.1 I get the following errors:

http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9S1BneVBKUEgzaU0K/ESC[0mESESC[22m
[2023-06-26 16:13:53.03187] [DEBUG] Delta: ESC[33m1460.902ESC[0m, shifted: ESC[33m-32574.032ESC[0m
[2023-06-26 16:13:53.03193] [ERROR]

Clip is less then 1 second long

Clip begin out of sync for ESC[33m1472.428ESC[0m seconds. Stop playout!

[33m1472.428ESC[0m seconds. Stop playout!
[2023-06-26 16:13:42.50575] [DEBUG] Stop all child processes

ffplayout.service: Killing process 9830 (ffmpeg) with signal SIGKILL.

As for usability, playback controls are slower on ubuntu 22.04.

As for video playback, when a remote video reaches its end, the ffplayout daemon is stopped due to video synchronization failure, then the daemon is automatically restarted by the system, then the last sequences of the same video are played again, and this previous process repeats in a loop.

-On ubuntu 23.04 with ffmpeg 5.1.2-3ubuntu1 the following errors are displayed:

2023-06-26 18:26:38.11958] [ERROR] [Encoder] [http @ 0x56255329e100] Stream ends prematurely at 386962590, should be 18446744073709551615

[2023-06-26 18:26:38.11984] [ERROR] [Encoder] http://127.0.0.1:5555/base64/eXQtZGxwIGh0dHBzOi8vd3d3LnlvdXR1YmUuY29tL3dhdGNoP3Y9S1BneVBKUEgzaU0K/: input/output error
[2023-06-26 18:26:38.16587] [DEBUG] Delta: -18,797, shifted: -40539,166

[2023-06-26 18:26:38.16824] [ERROR] Clip begin out of sync for -18.797 seconds. Stop playout!

[2023-06-26 18:26:39.16984] [DEBUG] Stop all child processes

[2023-06-26 18:26:39.17217] [ INFO] Playout done...

[2023-06-26 18:26:40.72813] [DEBUG] Start ffplayout v0.18.4, status file path: /nonexistent/.ffp_status

[2023-06-26 18:26:40.73039] [ERROR] Unable to write to status file /nonexistent/.ffp_status: No such file or directory (os error 2)

[2023-06-26 18:26:40.74372] [ERROR] Unable to write status file: No such file or directory (os error 2)

[ERROR] Unable to write to status file /nonexistent/.ffp_status: No such file or directory (os error 2)

[jb-alvarado]

I will try to explain you, why this kind of streaming will not really work stable and for that I can not officially support it:

ffplayout is made for creating a 24/7 internet TV. For that you have for every day a playlist and from start time/length setting and duration from each clip it calculate the correct starting time. Then it tries everything to stay in sync with that time. The debug message delta shows you how close the playlout is on the exact time when a clip should start. When the delta reaches a specific threshold, the playlout thinks something is not working correctly, for example a file is damaged etc. in that case it will stop and the systemd service will start the playout again and seek to the right time.

But because you are using restreamed sources from youtube, the playout can not jump fast enough to the right positing and play the clip correctly in sync with the time. So you will have all kinds of unusual error. It can happen that for some hours it will work, but one time I will guarantee you that the playout will stop an restart.

[JunioCalu]

Thanks for the explanation. As for this type of restreamed sources, I think that the software should not offer any guarantees, the system's behavior in this type of situation is a matter of curiosity.