Tvheadend

Jaroslav Kysela wrote:

The problem is the libav/mpegts muxer - the elementary stream reconfiguration is not handled in the code. It means when something changes in the broadcasting (A/V parameters), the HTTP streaming will fail and the client should reconnect to get new stream (with new parameters). It should be fixed for mpegts output where these changes are allowed.

Further, I am not sure why tvheadend IPTV mux stream does not reconnect but it just says not available. I am forced to setup the stream profile to restart in order to reconnect. There should be e retry when the source fails.

You replied yourself. The "input backends" does not handle the recovery at all. The higher level code (subscription scheduler) does this job and it's configured from the streaming profile parameters.

OK, so it must be a built-in container in order to handle better the recovery when data is bad. It would be better if mpegts was also built-in as a better for transcoding via iptv.

Anyway, I just employed Motroska mkv container using the libav to continue using transcoding h264/h265, it is working better on recovery, but it runs in the following issue:

2017-09-19 15:25:17.832 libav: Application provided invalid, non monotonically increasing dts to muxer in stream 0: 13224060 >= 13220460

2017-09-19 15:25:17.832 iptv: libav: Error muxing packet: Invalid argument

Sometimes when this happens it does not recover at all.

Sometimes it does recover see:
2017-09-19 15:20:17.334 libav: Application provided invalid, non monotonically increasing dts to muxer in stream 0: 63658800 >= 63655200

2017-09-19 15:20:17.334 iptv: libav: Error muxing packet: Invalid argument

2017-09-19 15:21:08.637 subscription: 0002: service instance is bad, reason: No input detected

2017-09-19 15:21:10.753 subscription: 0002: restarting channel A-M TV

If the stream profile is set to restart if no incoming stream for few seconds, then tvheadend eventually freezes and needs to be restarted (the webui freezes), but working channels continue working and no other user can connect.

Just to clarify:

The setup on this is the tvheadend1 has DVB-C cards, and for better recovery as in the post suggests, transcodes the stream via Motroska mkv built-in using libav to do h264/h265 (to lower the bitrate), and then the stream is picked up by tvheadend2 via http/iptv with a/v enabled in the muxer and with Stream profile Motroska mkv built-in with libav (of courses it goes as passthrough for streams that are already h264/h265). The tvheadend2 does have two DVB-S tuner cards and they work beautiful, but because of some channels that are not available via sat, tvheadend1 server is used to bring the unavailable channels to this remote area.

I must add that when the stream does not recover the user is stuck in "Running" state infinitely until I kick the user out under "Connections" tab to free the lockup of the channel as even otherusers when they attempt to connect to it can't watch the locked up channel.

In order to overcome signal discontinuation in the DVB-C source, I have been using MOI PRO with DVB-C only to pass traffic to the transcoding HP G6 server to transcoder from MPEG2VIDEO/H264 to Motroska/builtin container with video codec H265 and preset ultrafast at 596kbps and audio AAC at 40kbps, then on the distribution server located in a remote area (linked via 40mbps microwave link) where a contanerchange is applied via pipe with -re option.

This setup seems to work ok, with two issues:
DTS and PCR big difference and Kodi stops playing the audio altogether (probably dropping the packets)
When another subscriber starts viewing the same channel, it causes interruption to the stream. I tried enabling Spawn for the pipe but it does not make much difference.

The problem with this would help with one solution:

Have transcoding (Stream profile) to use a built-in Mpegts and output with correct container to the other tvheadend server so the other machine does not have to use A/V library to change container, and maybe even support some other transport protocol such as udp to other tvheadend to reduce overhead that http generates.

The requirement for this is of course to have stable connection as Wireless links can break mpegts packets with buffers and jitter.

Jaroslav Kysela wrote:

If you do transcode, you must work with the elementary stream (thus demuxing to elementary streams -> transcode -> muxing elementary streams to a container). The build-in mpeg-ts muxer just forwards the input mpeg-ts stream (with little changes - rewrite only internal ID numbers). The 'pass' name really means that it's data pass-through only.

The easiest solution is to implement the streaming reconfiguration for libav/mpeg-ts muxer.

Dvblast is what takes the elementary stream or raw data via RTP, and then goes to tvheadend that does transcoding with Motrostka container (I am forced to use this as it better handles data discontinuation or errors), and then after stream has been transcoded to a manageable bitrate it is passed to distribution tvheadend where frontends connect.

So of course, to have a native feature to interconnect multiple tvheadends would be a good feature with protocols that works best for tvheadend (i.e. users and stream profiles built for tvheadends).

Further, using A/V libraries (option at muxer) seem to crash tvheadend easier when there are multiple users with transport errors (tvheadend-tvheadend transport issues such as bad link or bad DVB-C data).

Last, EPG sharing among tvheadends would be another important factor. When one tvheadend is connected to other tvheadend it would be important to be able to get the EPG data from the EPG source (DVB-C/T/S).

Toni Ber wrote:

Jaroslav Kysela wrote:

If you do transcode, you must work with the elementary stream (thus demuxing to elementary streams -> transcode -> muxing elementary streams to a container). The build-in mpeg-ts muxer just forwards the input mpeg-ts stream (with little changes - rewrite only internal ID numbers). The 'pass' name really means that it's data pass-through only.

The easiest solution is to implement the streaming reconfiguration for libav/mpeg-ts muxer.

Dvblast is what takes the elementary stream or raw data via RTP, and then goes to tvheadend that does transcoding with Motrostka container (I am forced to use this as it better handles data discontinuation or errors), and then after stream has been transcoded to a manageable bitrate it is passed to distribution tvheadend where frontends connect.

MPEG-TS is a container. The elementary stream is raw stream binary stream necessary to carry video or audio data like H264, AAC etc..

Last, EPG sharing among tvheadends would be another important factor. When one tvheadend is connected to other tvheadend it would be important to be able to get the EPG data from the EPG source (DVB-C/T/S).

Use XMLTV (TVH can export and import XMLTV). See appendix 1 in the help.

Jaroslav Kysela wrote:

Toni Ber wrote:

Jaroslav Kysela wrote:

If you do transcode, you must work with the elementary stream (thus demuxing to elementary streams -> transcode -> muxing elementary streams to a container). The build-in mpeg-ts muxer just forwards the input mpeg-ts stream (with little changes - rewrite only internal ID numbers). The 'pass' name really means that it's data pass-through only.

The easiest solution is to implement the streaming reconfiguration for libav/mpeg-ts muxer.

Dvblast is what takes the elementary stream or raw data via RTP, and then goes to tvheadend that does transcoding with Motrostka container (I am forced to use this as it better handles data discontinuation or errors), and then after stream has been transcoded to a manageable bitrate it is passed to distribution tvheadend where frontends connect.

MPEG-TS is a container. The elementary stream is raw stream binary stream necessary to carry video or audio data like H264, AAC etc..

Last, EPG sharing among tvheadends would be another important factor. When one tvheadend is connected to other tvheadend it would be important to be able to get the EPG data from the EPG source (DVB-C/T/S).

Use XMLTV (TVH can export and import XMLTV). See appendix 1 in the help.

Understood, but regarding EPG it was not working by just enabling XMLTV, and as far as I know XMLTV must be configured as it does not seem to pick the EPG automatically from connection to other TVH.

Another issue with transcoding, we are unable to filter transcoded AAC audio codec and it transcodes again. Video Codec has the option to filter out non H264, but Audio Codec does not filter out AAC.

transcode: 016E: 1:HEVC > Passthrough

transcode: 016E: 2:AAC-LATM > AAC (aac) (it transcodes already transcoded audio stream).

transcode: 016E: 1:HEVC > Passthrough

transcode: 016E: 2:AAC-LATM > AAC (aac) (it transcodes already transcoded audio stream).

There should be an option to transcode only MPEG2AUDIO

You're trying to hijack this issue with a lot of other things. If you like, create another bug for each problem you have. And yes, XMLTV must be configured like any other source on the client side. If you set to match with the service / channel name and you have unique service names on the server, everything should be straight. Or you can use channel numbers.

• VIDEO: mpeg2ts -> h264_qsv
• AUDIO: aac_latm -> aac_latm (copy)

It will be fixed ver 4.4?
I have found h264_qsv was removed from latest git version.

Any possibilities h264_qsv will be restoerd in version 4.4?

lethis kwsk wrote:

I have found h264_qsv was removed from latest git version.

Any possibilities h264_qsv will be restoerd in version 4.4?

Check your driver installation