Best Practice to access a FREE stream?

[malvinas2]

Description

What is the best way to access a normal stream that is freely available and not "protected" in any way (tokens etc.)?

Option Nr. 1: Direct call using ffmpeg:

pipe:///usr/bin/ffmpeg -loglevel fatal -i https://bitcdn-kronehit.bitmovin.com/v2/hls/playlist.m3u8 -vcodec copy -acodec copy -metadata service_name=Kronehit\ TV -metadata service_provider =IPTV-AT -mpegts_service_type advanced_codec_digital_hdtv -f mpegts pipe:1
Works perfectly in conjunction with tvheadend (in case of 'Kronehit'), but some streams do not call up the maximum possible resolution as stored in playlist.m3u.

Option Nr. 2: Access via streamlink

pipe:///home/arg/myenv/bin/streamlink --stdout --default-stream best --url https://bitcdn-kronehit.bitmovin.com/v2/hls/playlist.m3u8
Works, but 'continuity counter errors' occur. If you call up the stream with VLC Player, you won't notice anything. On the other hand, unfortunately, Kodi reacts extremely sensitively to such disturbances, either there are image freezes for some seconds or the stream freezes completely.

Option Nr. 3: Combination of Streamlink and ffmpeg

/home/arg/myenv/bin/streamlink --stdout "best" https://bitcdn-kronehit.bitmovin.com/v2/hls/playlist.m3u8 | ffmpeg -loglevel fatal -i pipe:0 -vcodec copy -acodec copy -scodec dvbsub -mpegts_service_type advanced_codec_digital_hdtv -f mpegts pipe:1
This combination can be found on a wide variety of websites, although I've never understood why Streamlink first passes the signal to ffmpeg and not directly to TVHeadend.
Although neither streamlink nor tvheadend report any errors, there is occasional stuttering for the first two to three minutes in VLC Player, after which it keeps running forever. Best option?

To top it all off, I have the impression that the optimal method depends on the particular stream.
For example, at http://live-edge01.telecentro.net.ar/live/smil:musictop.smil/playlist.m3u8 with ffmpeg only the lowest resolution is selected (as described above), but it works with streamlink without continuity errors (as they appeared in case of the Kronehit stream).

[bastimeyer]

HLS stream discontunities are unsupported.
See #4535

[malvinas2]

Mmmh, none of the two example streams contains a discontinuity tag, see below.
But actually these two provider just served as an example.

==> Which of the proposed three options is considered the best to open a stream?
So far I have assumed that all options deliver the same result in theory.
But that doesn't seem to be the case (?).

Playlist.m3u of Kronehit:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=378000,RESOLUTION=320x180
chunklist_b378000.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=628000,RESOLUTION=640x360
chunklist_b628000.m3u8
....

Content of their chunklist.....m3u8:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-TARGETDURATION:4
#EXT-X-MEDIA-SEQUENCE:722351
#EXTINF:4.0,
media-u0fews32f_b1228000_722351.ts
#EXTINF:4.0,
media-u0fews32f_b1228000_722352.ts
#EXTINF:4.0,

Playlist.m3u of MusicTop:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-STREAM-INF:BANDWIDTH=364000,RESOLUTION=320x180
chunklist_w1156434036_b364000_sleng.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=964000,RESOLUTION=640x360
chunklist_w1156434036_b964000_sleng.m3u8

Their chunklist:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-ALLOW-CACHE:NO
#EXT-X-TARGETDURATION:21
#EXT-X-MEDIA-SEQUENCE:265545
#EXTINF:15.72,
media_w2017243205_b2028000_sleng_265545.ts
#EXTINF:5.64,

[bastimeyer]

Works, but 'continuity counter errors' occur.

none of the two example streams contains a discontinuity tag

Because those are live streams, so a discontinuity tag can appear at any time. What you're seeing is just the current playlist data.

You were talking about continuity counter errors, which means that the bitstream was invalid when your player read it.

https://datatracker.ietf.org/doc/html/rfc8216#section-3

Each Media Segment MUST carry the continuation of the encoded bitstream from the end of the segment with the previous Media Sequence Number, where values in a series such as timestamps and Continuity Counters MUST continue uninterrupted. The only exceptions are the first Media Segment ever to appear in a Media Playlist and Media Segments that are explicitly signaled as discontinuities (Section 4.3.2.3). Unmarked media discontinuities can trigger playback errors.

If the server doesn't include discontinuity tags and there are discontinuities due to different MPEG-TS streams being concatenated, then it's an invalid HLS stream and not even a proper HLS client that could signal a state-reset to the player's demuxer/decoder could handle this gracefully.

Either way, both situations are unsupported.

[malvinas2]

When using what I called "option 2 - streamlink" the log of tvheadend shows the following:

2023-05-29 16:09:41.926 TS: music/pipe_tv_music.m3u - Kronehit/{PMT:4095}: AAC @ #257 Continuity counter error (total 1)
2023-05-29 16:09:44.875 TS: music/pipe_tv_music.m3u - Kronehit/{PMT:4095}: H264 @ #256 Continuity counter error (total 1)
2023-05-29 16:09:52.880 TS: music/pipe_tv_music.m3u - Kronehit/{PMT:4095}: AAC @ #257 Continuity counter error (total 4)
2023-05-29 16:09:56.879 TS: music/pipe_tv_music.m3u - Kronehit/{PMT:4095}: H264 @ #256 Continuity counter error (total 4)

That's what you and I call a "continuity error", right?

When using "option 3 - streamlink piping into ffmpeg" no error is shown. Why? Does ffmpeg (unintentionally) make a correction?

At the moment I'm on the verge of checking for each stream individually which method I use to call it. With ~20 streams a bunch of work that I would like to avoid.

[bastimeyer]

tvheadend

Out of scope.

Streamlink simply writes the concatenated segment data to its output, without any remuxing of the content streams. If there is further processing required by whatever application you're using when consuming the stream data, then you'll have to ask there.

tvheadend implements its own MPEG-TS demuxer and the warnings are coming from here:

• https://github.com/tvheadend/tvheadend/blob/18effa8ad93e901f3cdaa534123d910f14453d1f/src/input/mpegts/tsdemux.c#L60
• https://github.com/tvheadend/tvheadend/blob/18effa8ad93e901f3cdaa534123d910f14453d1f/src/input/mpegts/tsdemux.c#L119

When using "option 3 - streamlink piping into ffmpeg" no error is shown. Why?

Because you're remuxing the stream where you also set a different MPEGTS service type flag.

-mpegts_service_type advanced_codec_digital_hdtv -f mpegts

• https://ffmpeg.org/ffmpeg-formats.html#mpegts-1
• https://github.com/FFmpeg/FFmpeg/blob/n6.0/libavformat/mpegtsenc.c#L68-L78
• https://www.etsi.org/deliver/etsi_en/300400_300499/300468/01.17.01_60/en_300468v011701p.pdf (Table 89)

Whether the service type is actually relevant, I don't know. You are however altering Streamlink's output stream (the concatenated segments) with FFmpeg and it probably changes the PID offsets and other transport stream data. I don't know enough about that.

Either way, this is out of scope.

[malvinas2]

I get it, thanks anyway for the detailed explanations!

In the meantime I've tried out a number of streams and the good old KISS principle ('Keepi it simple, stupid!') for the interaction of TVHeadend and Streamlink has also proven its worth here:
If the playlist of a free and legal stream is available, simply integrate it via pipe...ffmpeg. Theoretically, Streamlink could offer an advantage here, e.g. by using the buffer, but in practice I could not observe any advantage.
If Streamlink is absolutely necessary for extracting the actual stream, specifying Streamlink alone is sufficient, without the use of ffmpeg ('Option 2'). I cannot understand why the combination of both can be found on many websites. This may have been necessary in previous versions of Streamlink, but definitely not now.
If neither option works, option 3 remains as a last resort. See the example above with 'MusicTop'.

[malvinas2]

To warm up the topic again:
Unfortunately the setup has a crucial influence here. In my case I originally had a 'big' server for TVHeadend. In addition to receiving foreign TV channels, there were also some Raspberry PIs that also ran TVHeadend, Streamlink and a VPN. The signal was requested on the Raspberries from Streamlink and then forwarded from their TVHeadend to the TVHeadend installed on the server. In theory this should work. In practice, there were constant dropouts in some streams. I solved this problem by banning the Raspberries and now running the VPN on the server in Docker containers.

https://github.com/malvinas2/openvpn-privoxy