Tvheadend

I don't think you'll have too much trouble.. Well, I think you won't if you are using the pre-built debs.

I've installed tvheadend from repo, so tvheadend brings it's own ffmepg with it?

Regards

BoxSon

The most of pre-built tvh packages do include ffmpeg.

I think most every distro has Tvheadend packaged using its in statically linked ffmpeg, not the system version of ffmpeg. (I believe Arch uses the system ffmpeg dynamically linked, but they may be the only one.)

So, installing ffmpeg from your distro's repo should have no effect whatsoever on Tvheadend, unless you are using pipe:// URLs with ffmpeg, or perhaps the new Pass Spawn profile with ffmpeg.

thank you for the explanation. I need to use a pipe url to get a stream from the cams

For example:

pipe:///usr/bin/ffmpeg -loglevel fatal -i rtsp://camIP:554/ch0_0.h264 -vcodec copy -acodec copy -metadata service_provider=XiaomiCam -metadata service_name=BabyCam -f mpegts -tune zerolatency pipe:1

This would be a problem?

Regards
BoxSon

No problem. Just that the ffmpeg callled from the pipe:// is the system ffmpeg, not Tvheadend's ffmpeg.

I've installed ffmpeg now but i cannot get it to work with TVHeadend :(.

The following command at the console works and generates a output "out.ts"

/usr/bin/ffmpeg -loglevel fatal -fflags +genpts -i rtsp://ipcam.fritz.box:554/11 -vcodec copy -acodec copy -metadata service_provider=IPCAMS -metadata service_name=ENTRANCE -f mpegts -tune zerolatency out.ts

I've created a new IP TV Network and a new Mux in that network.
For the URL parameter i've set:

pipe:///usr/bin/ffmpeg -loglevel fatal -fflags +genpts -i rtsp://ipcam.fritz.box:554/11 -vcodec copy -acodec copy -metadata service_provider=IPCAMS -metadata service_name=ENTRANCE -f mpegts -tune zerolatency pipe:1

at tv headend i can see the following error at the console:

iptv: libav: Could not open input 'pipe:///usr/bin/ffmpeg -loglevel fatal -fflags +genpts -i rtsp://ipcam.fritz.box:554/11 -vcodec copy -acodec copy -metadata service_provider=IPCAMS -metadata service_name=ENTRANCE -f mpegts -tune zerolatency pipe:1': Protocol not found

Any Idea why tvheadend states "*Protocol not found*" ?

Regards

Boxson

Which version of Tvheadend are you running? Does it have pipe:// support?

I'm running HTS Tvheadend 4.3-363~ge1ad234.

Installed on a Ubuntu 16.04.3 LTS server from the following repo:

https://dl.bintray.com/tvheadend/deb xenial stable

How can i check if TVHeadend has pipe:// support?

Regards

BoxSon

Hi! I'm a brand new Tvheadend user (set it up just yesterday) and I had the exact same issue. I found the problem to be libav that's throwing the "protocol not found" error in regards. to the "pipe://" instruction. No idea why...

In either the network settings or the mux settings I turned of the option to use A/V Library and it now works just fine.

Thanks! That made the trick! Now it works like a charm.

Thank you again. Did you find a solution for filling the EPG data for a pipe - Sources?

Regards

BoxSon

No, not yet... I'm slowly working through the EPG stuff.

Note to self - add info to docs regarding this..
<doc>

Just FYI, on Ubuntu Server I always use the static build from https://johnvansickle.com/ffmpeg/, specifically the release: x86_64 build (currently at https://johnvansickle.com/ffmpeg/releases/ffmpeg-release-64bit-static.tar.xz). It seems to be updated every three or four months, and I just use Midnight Commander to open the downloaded archive and then just copy the executable files into the /usr/local/bin directory, since it's already in my path. Then if I do "which ffmpeg" from the command prompt, it shows that it's at /usr/local/bin/ffmpeg

In my personal experience this is the most stable version you can get, at least if you are running a standard desktop type machine with a 64-bit processor. I cannot speak to the reliability of the other versions, particularly the one that is supposed to run on the Raspberry Pi (seems like I had some problem with that one in the past, but can't recall what exactly), but the stable x86_64 build has proven very reliable for me in several different types of usage situations, including using it in a pipe url in an IPTV mux. YMMV.