ok. i solve this issue this a lot of processors. first decode to mpeg2 , then merge the dvb subs , then recode to h264 ,
works well , even with variable fps (crf=20) , with a final resolution of 850x480 (from 1280x720) in realtime , via an i7 6cores 3.4Ghz.
next week i post the data.
i test some decoders , works best with ffmpeg , but vlc is more stable chopping HLS.
ffmpeg 10.5 only (at least in centos 6.3 64bits), other versions do not work properly selecting streams from dvb multicast udp.
maybe i need to make another post : clues to select reverse-forward ?
on a simple m3u8 list with 8 segments , ever start at the oldest, giving no chance to point to the newest , or at least the subsequent.
theres may be an interesting point . the proccess of encoding takes 99% of processing , while chopping takes only 0.3%
so , with two (or more , via unix tee) you can have (and offer) many m3u8 lists from same "live" HLS with only 9sec of delay (3segments od 3 sec),
or "recorded" HLS from past hour and so on. i tested up to 1440 segments of 1 min , with m3u8 lists of last 60 - 120 - 180 -etc segments .
but i cant jump from segment to another , in order to forward-rewind the "live" HLS.
it is possible?
