Jump to content

Emby and TVHeadend play nicely


adwuk

Recommended Posts

Thanks to all the contributions in this community, I have finally been able to get a setup of Emby, TVHeadend and our LG Smart TVs that works really well for me.

 

I had a false start with the Emby TVHeadend plugin, which I am sure is working fine for others - unfortunately for me I couldn't get the TV schedule to update reliably, and sometimes it just went blank. When searching for a fix to these issues I saw a comment from Luke suggesting the use of the M3U tuner option.

 

So here is where I have ended up:

 

1) Latest version of TVHeadend 4.3 tuned to Freesat UK with a DVB-S2 USB tuner on ubuntu 18.04 - TVH 4.3 required because I make use of the MPEG-TS/Spawn streaming profile

2) Hardware/VAAPI encoding streaming profile with FFMPEG - this makes use of the QuickSync encoding available on an Intel NUC with i3-7100 processor

3) Emby server connects to TVH via the M3U tuner options in Emby Live TV

4) A post recording script quickly converts the recorded MPEG-TS files to MP4

 

Details of the setup:

 

1) You can follow the install instructions for TVHeadend.  The key is to install version 4.3 (it is named unstable, but seems pretty stable to me) as I wanted to make use of the Intel's VAAPI/QuickSync hardware encoder.  Once installed, I created a MPEG-TS/Spawn streaming profile called 'mp4-h264-aac' with the following properties:

 

5c4ae1b0250b2_streamprofile.png

 

2) Create a bash script in /home/hts/scripts called h264aac.sh.  Don't forget to make it executable with 'chmod +x h264aac.sh'.  This script uses VAAPI and takes the video stream and english audio stream and converts to H264, Level 4.1, AAC audio, deinterlaces keeping the source frame rate and reasonable quality at the highest compression.  The output container is MPEG-TS which is fed to the Emby server.  It uses VAAPI hardware encoding which is pretty quick, and the CPU rarely gets above 10% usage while it is running.

#!/bin/bash
ffmpeg -loglevel info \
        -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi \
        -i pipe:0 -map 0:v -map 0:m:language:eng -sn \
        -c:v h264_vaapi \
        -quality 0 -compression_level 1 -qp 25 -level 41 \
        -vf 'format=nv12|vaapi,hwupload,deinterlace_vaapi=rate=frame:auto=1' \
        -c:a aac \
        -f mpegts pipe:1

3) In your Emby server, using the Live TV options, add a M3U tuner with the following URL:

http://user:password@server:9981/playlist/channels.m3u?profile=mp4-h264-aac

This will load all the channels from your TVHeadend server using the newly created streaming profile. You will also need to add a TV guide provider, and I find that the new Emby one for the UK works well for me.

 

4) Finally you will need to convert the MPEG-TS files after they are recorded.  MPEG-TS isn't seekable and so if you want to fast-forward or rewind during play, MP4 is more appropriate.  In the DVR section on your Emby server you can define a post processing script.  I set mine to "/var/lib/emby/video/convert.sh", and here is the script:

#!/bin/bash

# break up the input file name
file=$(basename "$1")
base=$(basename "$1" .ts)
dir=$(dirname "$1")

# transcode the file
ffmpeg -y -i "$1" -map 0 -c copy "${dir}/${base}.mp4"

# get the error code
RC=$?
if [ "${RC}" -ne "0" ]; then
	# had an error, so check if the output file exists
	# if so, remove the output file
	if [ -f "${dir}/${base}.mp4" ]; then
		rm -f "${dir}/${base}.mp4"
	fi
else
	# all OK, so check if the output file exists
	# if so, remove the input file
	if [ -f "${dir}/${base}.mp4" ]; then
		rm -f "$1"
	fi
fi

The post-processing script runs in a few seconds after the recording has completed.  It now means that the whole process from selecting the programme to record, to it being listed and ready to play in Emby anywhere, is fully automated and simple enough for anyone to use.

 

Hopefully this lot will prove useful to someone.

  • Like 3
Link to comment
Share on other sites

planetwilson

Do you need to do the new profile for Emby? Can Emby not just consume the straight feed from TVHeadEnd? I was using the plugin but thought I would try this. I am running TVHeadEnd on a raspberry pi so it won't have the quick sync the Intel does. I tried just setting the URL with one of the built in profile names that comes with TVHEadEnd (4.2.6-7)

Link to comment
Share on other sites

Do you need to do the new profile for Emby? Can Emby not just consume the straight feed from TVHeadEnd? I was using the plugin but thought I would try this. I am running TVHeadEnd on a raspberry pi so it won't have the quick sync the Intel does. I tried just setting the URL with one of the built in profile names that comes with TVHEadEnd (4.2.6-7)

 

Emby should work fine with one of the standard streaming profiles.  I found that for best compatibility with our devices (e.g. Chrome browser, LG TVs) I needed H264 Level 4.1 and AAC audio, ideally not interlaced, and the most efficient way of achieving this was to transcode on the TVH server before it got to Emby.

Link to comment
Share on other sites

Q-Droid

Do you need to do the new profile for Emby? Can Emby not just consume the straight feed from TVHeadEnd? I was using the plugin but thought I would try this. I am running TVHeadEnd on a raspberry pi so it won't have the quick sync the Intel does. I tried just setting the URL with one of the built in profile names that comes with TVHEadEnd (4.2.6-7)

 

The default TVH profile is passthru which is the MPEG-2 stream, assuming NA ATSC OTA. The Emby software can handle it but your server hardware and playback devices might not. You'll have to test. The advantage of using TVH to transcode is being able to control the ffmpeg version and fine tune the output formats. The RPi can decode MPEG-2 and encode H.264 in hardware so if it's dedicated to TVH it might be a good way to go. The disadvantage is that you have to muck with it until it works...

Link to comment
Share on other sites

Q-Droid

My RPi is dedicated. Would I need to go away and work out the appropriate ffmpeg for it or will the one above work?

 

I would say start with what you have now and don't worry about ffmpeg unless it's missing something you need. However the above scripts are using VAAPI which is a different API than what RPi supports.

 

https://trac.ffmpeg.org/wiki/HWAccelIntro

 

You'll have to tweak things to get it working. There's lots of info online including the raspberrypi.org forums. I'm not an RPi user so I don't have any useful details for you. In the end your Emby server might be powerful enough to handle transcoding with the RPi acting only as the headend sending raw streams.

 

Keep in mind that RPi used to need a low cost license to activate the MPEG-2 decoder. Not sure if that's still the case.

  • Like 1
Link to comment
Share on other sites

planetwilson

Ah right, sorry I didn't realise that in the case of RPi sending raw streams, Emby could transcode depending on client capabilities? In which case yes, Emby is running in a docker on a 14 core unRAID server :)

 

So I will leave it as raw streams.

Link to comment
Share on other sites

The only downside of raw streams is that there is more to transport on the network.  If you are hardwired, no problem.  I am using WiFi between the TVH and Emby servers, and so wanted to get the streams compressed to something more sensible.  Another point is that my TVH server is dedicated, whereas the Emby server is not.  Its all down to where you want the processing to be done, and how often - for me it made sense to do it once at source rather than for every replay.

Link to comment
Share on other sites

Q-Droid

The only downside of raw streams is that there is more to transport on the network.  If you are hardwired, no problem.  I am using WiFi between the TVH and Emby servers, and so wanted to get the streams compressed to something more sensible.  Another point is that my TVH server is dedicated, whereas the Emby server is not.  Its all down to where you want the processing to be done, and how often - for me it made sense to do it once at source rather than for every replay.

 

Right, gotta do the math and decide. The ATSC OTA pipe is ~20mbps though it's multicast. A 1080i/60 sub-channel is ~12mbps and the lower resolutions are smaller so it all depends on the WiFi capacity and how many tuners/channels will be streamed concurrently plus how many other active WiFi devices are on the network. Wired is preferable but WiFi can work with a little extra planning and prep as you've done.

Link to comment
Share on other sites

Hi,  I have only just started the streaming idea from TVH (did not know that was possible).

I use an unraid server, so my tvh and my emby server are dockers in the same machine.

I have just used the default streaming profile, and my ShieldTV and Roku's can do seek etc.

No lan issue as all in the same server.

I had 17 recordings in progress to try and break this - could not break it.

So I guess I dont need to do anything else? 

Edited by vaise
Link to comment
Share on other sites

Q-Droid

It sounds like you have it working the way you want. I've been using TVH as an m3u tuner for LIve TV since mid last year with no issues. It's pretty seamless without plug-ins.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...