Tvheadend

Also will be nice to add that feature for http mpegts stream too

This has been discussed before and adding HTTP receiving of MPEGTS would be relatively trivial. However more than that is outside of the scope for TVH at the moment (i.e. m-jpeg, etc...)

Adam

+1 for http mpegts/webm,matroska as input source.

That would be a great and easy way to get output channels from one tvheadend as input channels on another tvheadend over internet..

The only way to do it atm it to setup ffmpeg vlc or simular on tvheadend server 2 to download the http stream from tvheadend server 1 24/7 and broadcast it as rtp/udp, thats a 24/7 option, making tvheadend be able to use http sources as input would make that transparent and on demand

Actually I did start on a better approach for that using HTSP, however I'm currently in the middle of rewriting the entire DVB core (which includes IPTV) and I actually do have HTTP based input to allow me to use TVH as a test input

So hopefully someone will improve/extend that and this will appear in the near(ish) future.

Adam

Great to hear, that does sound like a much better approach for linking channels betweem tvheadend servers..
Untill then ive sucssessfully written a little script that parse the tvheadend log looking for subscribe/unsubscribe lines, that will start ffmpeg downloading the stream and broadcasting it as udp for tvheadend to pick up. Works pretty good, a little delay when starting a channel but nothing besides that

danny skjodt wrote:

Great to hear, that does sound like a much better approach for linking channels betweem tvheadend servers..
Untill then ive sucssessfully written a little script that parse the tvheadend log looking for subscribe/unsubscribe lines, that will start ffmpeg downloading the stream and broadcasting it as udp for tvheadend to pick up. Works pretty good, a little delay when starting a channel but nothing besides that

Hi Danny, would you be able to share that script? - sounds like it would do exactly what I would like it to do (i.e. grab MP2 audio streams from DABBar- having to manually stop and start VLC Mutlicast proxys is a bit rubbish)) until such time that TVHeadend has native support.

Sure, its not complete yet, no support for 2 clients watching the same channel, but here it goes..

#!/bin/bash
tail -f /tmp/tvh.log | while read -r f1 f2 f3 f4 f5 f6 f7 f8 f9 g1 g2 g3 g4 g5 g6 g7 g8 g9 h1
do
if [[ "$f6" == "subscription:" ]]; then
var=`echo $g8 $g9 | sed 's/\,/\n/g' | sed -n 1p | sed 's/\,//g' | sed 's/\"//g' | sed 's/ //g'`
fi

if "$var" "TV2Charlie" ; then
if "$g6" "subscribing" ; then
echo "$g6 $var"
ffmpeg -i "http://link/to" -vcodec copy -acodec copy -vbsf h264_mp4toannexb -f mpegts -re "udp://239.0.0.1:1234?ttl=1&pkt_size=1316" &
TV2CHAR_pid=$!
elif "$g6" == "unsubscribing" ; then
echo "$g6 $var"
kill -9 $TV2CHAR_pid
fi
fi
done

My channel name in tvheadend is TV2 Charlie, you might need to transcode the audio or video stream to be compatible with tvheadend.

Hm seems like something got striped when pasting it here :/

Adam,
is the "debug" feature of http input in the master repository? If not can we get it elsewhere please?

Yes this would be a nice feature. I want to use a DVB card with CI module. The only software supporting this is DVBlast and MuMuDVB. DVBlast only supports multicast but MuMuDVB also supports unicast (HTTP). If no HTTP support in TVH, is it possible to include some "trigger" in TVH to start a multicast stream like post 8 ?

Bengt Madeberg wrote:

Yes this would be a nice feature. I want to use a DVB card with CI module. The only software supporting this is DVBlast and MuMuDVB. DVBlast only supports multicast but MuMuDVB also supports unicast (HTTP). If no HTTP support in TVH, is it possible to include some "trigger" in TVH to start a multicast stream like post 8 ?

Just do as I did hook up the logfile

1. run tvheadend like this ./tvheadend 2> /tmp/tvh.log
2. save this paste as tvhli.sh http://webzi.dk/140
3. and this paste as channel.sh http://webzi.dk/141
4. then chmod both +x and run screen -dmS tvhli ./tvhli.sh
5. add the channel names from channel.sh as iptv channels in tvheadend, use any random multicast ip and lo as interface and port 5501 as port
6. and then you need to run this as root :
ifconfig lo multicast
ip route add 224.0.0.0/4 dev lo src 127.0.0.1

7. install ffmpeg and cvlc and thats it.

However aint setting up oscam with your ci module, and using tvheadends build in cwt to contact oscam better for your stuff ?

danny skjodt wrote:

However aint setting up oscam with your ci module, and using tvheadends build in cwt to contact oscam better for your stuff ?

Now I'm out of the topic for this thread but....
I'm not sure about the configuration for this. Today I use oscam with a phoenix card reader. Some channels here in Sweden are not possible to decode with "softcam" (HD channels and some H264 SD channels) so I need a HW Cam for this. According to some other forums it's possible to use PC-cards with CI and a CAM with a proper card (which I have). But do really oscam support this ? Or how do I control the HW CAM without DVBlast or MuMuDVB ?

Bengt Madeberg wrote:

danny skjodt wrote:

However aint setting up oscam with your ci module, and using tvheadends build in cwt to contact oscam better for your stuff ?

Now I'm out of the topic for this thread but....
I'm not sure about the configuration for this. Today I use oscam with a phoenix card reader. Some channels here in Sweden are not possible to decode with "softcam" (HD channels and some H264 SD channels) so I need a HW Cam for this. According to some other forums it's possible to use PC-cards with CI and a CAM with a proper card (which I have). But do really oscam support this ? Or how do I control the HW CAM without DVBlast or MuMuDVB ?

Viasat ?? You can't decode those without a Viasat HD Reciever, or well you can get an old non updated reciever, firmware 1.12 i think, and extract the ekpair and hwkey, and use then together with newcs or oscam, but its quite complicated..
The same goes for any hw cam, it will still need hwkey and ekpair.

Not Viasat, Boxer...they don't use receiver pairing......

Is there any news about HTTP_input_module ?

Regards.

Hi,
I'm currently working on it using the code from Adam's repository. I'm busy this week but I have it working already (just need to correctly close the stream and clean up the code a bit). It should be ready during the next week.

It supports only MPEG TS over HTTP and it should not break UDP multicast support. I'm going to make a patch for the current stable 3.4 release.

Zdenek

Hi,
sorry, none of these links points directly to the MPEG TS stream. They points to m3u playlists which are not supported (at least not yet). You can get direct links by opening them in VLC and then looking at the real links (tools -> media info -> at the bottom), but right now none of these works for me in VLC so I cannot test them. I'm afraid that direct links to the TS streams are changing so you'll need to update them in TVH quite often.

Someone would have to implement m3u playlist support to get these work.

Thanks for replying Zdenek

The .ts streams are changing as they are live HLS streams. I haven't looked at the code in detail but from what you've said TVH would need to know when to grab the m3u again and know which .ts file to get next (in the same way that a HLS player would do), otherwise you would get a break in the stream when it ran out of .ts files in the first playlist.

What kind of streams should I be looking for to work with your patch? Just a single .ts file over HTTP (not referenced in a playlist). Do you have any example?

Yes, you need single .ts file over HTTP. There are some local IPTV providers which stream regular TV channels this way (that's why I needed this). And also it can be useful when you need to get a stream from another application to TVH (e.g. from another instance of TVH running elsewhere).

Hey your patch works quite good, but its not that prone to errors, tvheadend can easily hardlock and have to be killed if the http link gives unexpected data.

I think manny wanted this to be able to link channels from one tvheadend server onto another, and by not supporting auth user:pass@host in the links, thats not posible without wide open auth.

There is some processing errors, ive got quite a few h264 aac mpegts streams that wont have audio with this, but using ffmpeg, vlc, tsplay or simular to broadcast the same stream as udp tvheadend picks up the audio fine.

Hi,
I'll definitely look at the hardlock problem as this shouldn't happen.

The auth support could be added later (or anyone else can implement it) but it isn't priority for me now, sorry.

Regarding the sound problem. I've noticed that too when using the default mkv muxer. It actually affects all channels not only h264 and seems to get worse with higher bitrate. But it works fine when I use "?mux=pass" appended to the link so I'm not sure if the problem could be in my code or in the mkv muxer. What output protokol do you use: HTS, HTTP (MKV) or HTTP (TS/pass)?

I only use mux pass over http, as that seems to be extremely fast.
Using mux pass you will get a steady flow of data, using matroska/webm you wont, try with wget

It seems like the hardlock happends when the tvheadend server I take a channel from over http says no adapters available to the http client from the tvheadend running your patch.

And thanks for doing this, its some sweet ass code, ive been using other method to achive the same, but this is verry fast, channels taken from http starts just as fast in xbmc as channels tuned from iptv or sat..

Now I'm a bit confused. So do you use Tvheadend with XBMC (HTS protocol) or via HTTP protocol (MKV or PASS muxer)? From what I've observed:
When I use my patched Tvheadend to recieve H264 TS stream and re-stream it via HTTP in Matroska I get those sound problems you describe.
When I do the same but re-stream via HTTP in TS (?mux=pass) then it works fine.

The source of the stream is of course always in TS and it doesn't matter if it's from VLC or another instance of Tvheadend.

I'll look at this in more detail.

I use xbmc as client, connected with htsp to 1 fast tvheadend server, that tvheadend server pulls its channels by http mux=pass from serveral other tvheadend servers

I never use the mkv parser.

The channels I have problems with are taken in as mpeg2 through a transcoder unit and then broadcasted again as h264 with aac mpegts udp transports, thats where my problem comes from, it works perfect if i set up a tvheadend to pick up those transcoded channels from udp and serve them to clients by htsp.

But trying to pull http mux=pass or mux=mpegts for that sake, into a tvheadend running your patch from the first tvheadend that can tune the transcoded udp channels, that is when the stream gets fucked, missing audio, and lagging video.

To understand what I precisely mean, think this, my goal is to pull channels from serveral tvheadend servers into 1 big fast tvheadend server, that then serves clients by htsp

Does anyone knows if it's possible to fetch a stream from MuMuDVB with this patch ? (http unicast)
Is this patch included in later versions of TVH ? Or is is just 3.4 ?

I haven't tested this with MuMuDVB but it SHOULD work (both http unicast and udp/rtp multicast).

The patch is for the latest stable 3.4.27 only (https://github.com/tvheadend/tvheadend/archive/3.4patch1.tar.gz). As far as I know the 4.0 is going to have the core rewritten so this will become obsolete.

There are reported some bugs though. When the source (MuMuDVB) doesn't send correct data Tvheadend may crash. I'm going to fix this but doesn't have time right now.

Ok, thanks for fast answer. I have one machine running 3.2.18 so I will upgrade and do some tests later on...

I tried to apply the patch for the TVH version posted here.
All was OK until I did './Autobuild.sh -t precise-amd64'
I got 'dpkg-buildpackage:: error: version number does not start with digit' for

Zdeněk Kopřivík wrote:

Hi,
user Paradox reported a bug in iptv_input_v2.patch which causes segfault in certain conditions so here is a fixed version.

Zdenek

Is this patch already implemented on 3.4.28~geb79aee~trusty ?

It's been a while when this has been touched, so let me as again if there is a chance to "re"think of HLS streams to be supported?

I can only speak for myself, but honestly for me this is the only thing that I miss from TVH. I use DVB-T, DVB-S, IPTV multicast, UDP over HTTP streams, but some of the channels I'm really longing to watch are only available in HLS format.

HLS has been long ago accepted as industry standard, is there something I can help in order to help this R&D?

Levente Cseh wrote:

HLS has been long ago accepted as industry standard, is there something I can help in order to help this R&D?

Use latest v3.9 tvh and pipe:// in IPTV URL - https://tvheadend.org/projects/tvheadend/wiki/Custom_MPEG-TS_Input . You may convert the HLS stream to standard MPEG-TS using ffmpeg/avconv on-the-fly...