Tvheadend

no debs attached, at least, i don't know how to get them, thanks!

What does work? Live transcoding with the PI? Software or Hardware transcoding?

Just software transcoding. Both live TV and recorded programs.
There are still a couple of things I'm trying to get working;
Sending to Chromecast using TVHClient fails "Failed to load video", maybe a codec thing. The web-player is unwatchable due to long pauses. Smooth video though on Android phone and the Desktop through VLC. This is even for HD channels on DVB-T2. I've even set up a VPN server and I can connect and watch on external WiFi & 4G.
I've tried re-attaching the debs - hopefully it'll work this time.
I haven't tried this on my Pi2, so your millage may vary. Pi3 is definitely seems powerful enough.

Hi Tony,

I have tried your dep files, but unfortunately live SD channel transcoding does not work well for me. The pictures disappears and so on, with VLC. I have tried all build-in transcoding profiles with different results, but non of them are good enough on a Pi3. Could you please let me know what profile works for you?

I can see from top that the pi3 only uses less then ~160% cpu, perhaps there is a way to tell tvheadend to use all the cores while transcoding?

HI there,
I would also like to see this working. Very encouraging that the Pi3 can handle it, although the post above me seems to have issues with it. I am currently running on Pi2, but plan to get a pi3 in the next few weeks.

@Tony Brook, please give us details of the transcoding profile you are using...

OK after extensive testing, it still appears to be a little flakey. It definitely seems to work better for some channels than others.
I've used default settings for MKV, but as far as I can remember, the only thing I changed was I switched both audio and video codecs to Copy.
I think this may also depend a little on the source of your TV. In the UK, I'm using a DVB-T2 stick which, I believe, is already H264.
TBH, I haven't had a play with it in a while, so I'll try and do some more tweaking and get back to you all.

DVB-S = MPEG-2 (experimental H.264)
DVB-T = MPEG-2 (experimental H.264)
DVB-S2 = mostly H.264, sometimes MPEG-2
DVB-T2 Europe = H.264
DVB-T2 Germany = H.265

These settings seem to work for me.
The picture's not the best, but it's OK for streaming across 4G or the internet.
I would recommend, you disable transcoding if you're on the local network to improve picture quality. Just change codec to Copy codec type.

thanks for this. Good to know that it works.

RPi 3 ordered and awaiting delivery. This will be handy for me as I am travelling down to south of France in our campervan and my intention is to access my home DVB-T/DVB-S tvheadend in a Pi2. I have it working fine for SDTV and tested over 4G, but my home uplink is limited to 5Mbps. Currently I can get 98% of my channels except for 2 DVB-T Irish main channels (RTÉ 1 & RTÉ 2) which are broadcast in HD only. It all depends on the French campsite wifi quality, but I can log in to my home system and adjust that bitrate if it is poor. I am hoping for somehting in the region of 4096 which is within the bounds of my very reliable uplink.

I read about a vorbis stream of 800 kbps with 100% CPU at the beginning of this thread and the lack of support for the TV-Headend-client, so you will have to fiddle with streams anyway, so how about trying to stream through the hardware-codecs?

https://www.raspberrypi.org/forums/viewtopic.php?t=113052 promises a recoded 2000 kbps stream without much processor load.

I just ordered the MPEG2-license for my RPI3.

By the way, the matroska-aac-settings hardly reach 800 kbps, and the screen often inverses color in VLC. (I however use TVHeadend 4.09 as compiled with OSMC)

I received my MPEG2-licence, but didn't see it work yet on my TV-Headend 4.09 as plugin available on OSMC 2016.06-2 as TVHeadend collapsed.

The 401-issues I get are somewhat like in this thread: https://tvheadend.org/boards/13/topics/17238

with strange workarounds like https://tvheadend.org/boards/5/topics/5319

In the log of OSMC, which isn't in /var/log/syslog anymore
https://discourse.osmc.tv/t/no-var-log-syslog/676/7

I found another issue, of which I don't know whether it is related:
https://discourse.osmc.tv/t/automatic-fsck-of-root-filesystem-on-start-stop/9163/4

Do you have a clue what version of TVHeadend on what OS is stable nowadays for the RPi3?

I somewhat struggled further and found a version that's stable enough to be able to zap between channels without freezing: Openelec 6.0.3 with TVHeadend 4.0.8 and OSCam from the 'unofficial addons'.

It's the only version I tried that's actually able to start the VLC-stream clicking the links in TVHeadend.

I saw the Omx-hardware-decoder run in Kodi with my MPEG2-license. However, a HD-channel was still not showing completely fluent on a SDTV during a panning camera, which appeared to be the default NTSC setting of the RPi. When I altered it to SDTV_mode=2 the issue disappeared.

From this point we could look further for transcoding a channel.

Tony Brook wrote:

These settings seem to work for me.
The picture's not the best, but it's OK for streaming across 4G or the internet.
I would recommend, you disable transcoding if you're on the local network to improve picture quality. Just change codec to Copy codec type.

This did not work for me at all. RPi 3 latest Raspbian. CPU running at 350%, picture falling to pieces on SD & HD, DVB-T/T2 & DVB-S/S2.

To try this I had to build gstreamer and plugins. However, the standard case of the RPi3 appeared not to be sufficient for keeping out heat-issues and the RPi3 broke. I returned it and am now studying cross-compilation, as I think this 2000 kbit stream should even be possible on a RPi1 as it doesn't seem to take much processing power. But first: Let's try.

Hi,

my current setup as follows:

HW:
Raspberry Pi 3
DVB-T USB (RT2832)

SW:
ArchlinuxArm
linux-raspberrypi 4.4.17-1
raspberrypi-firmware 20160810-1
tvheadend-git 4.1.r2159.g258c913-1
ffmpeg 3.1.2-1

I rebuild ffmpeg with --enable-mmal and --enable-omx-rpi (since ffmpeg 3.1 laplace) in PKGBUILD which results in h264_omx encoder available so I can select it in tvheadend's stream tab. I also need to alter tvheadend's plumbing/transcoding.c as h264_omx does not support the profile option.

Recording works great. Tvheadend consumes ~140% cpu where software transcoding with libx264 consumes ~400%. Playing the recording with Kodi 16.1 / Tvheadend plugin works also.
The following command show 80% cpu load of ffmpeg:
tzap -p -c /home/alarm/build-repos/tvheadend-git/src/dvb-scan-tables/channels-conf/dvb-t/de-Berlin -o - zdf | ffmpeg -i pipe:0 -codec:v h264_omx -b:v 1m -codec:a aac -b:a 192k -muxrate 1m zdf.mp4

I could need some help in getting live transcoding to work with Kodi / Tvheadend plugin. I set the profile in the plugin settings to custom webtv-h264_omx-aac-mpegts but I don't get any video - just black screen and high load on client side.

Any hints?

Hi Alexander,

Could you please provide me your ./configure command line ?

Did you use ffmpeg static ?

I try to update tke MakeFile.ffmpeg with --enable-mmal and --enable-omx-rpi

I had issue to use you deb file; so I need the same way for compiling to try debug you version.

regards
ZACHARIE Joseph

I added --enable-mmal and --enable-omx-rpi to the MakeFile.ffmpeg as well, it built without a problem, but there's no h264_omx in tvheadend now? Anything else that's needed to be done?

Thanks

I do not use the built-in version of ffmpeg in tvheadend.

Yes there is. You need to rebuild tvheadend with ffmpeg you have built. The one with your altered MakeFile.ffmpeg. If you use built-in version of ffmpeg make sure it is the correct version.

Live transcoding works with browser and url tuned to: http://<rpi>:9981/play/stream/channel/<id>?profile=webtv-h264_omx-aac-mpegts.

Hi all
I'm trying to setup a live transconding on a RPi3.
I have read this topic and seems that Alexander make it. Still I have some questions

1) Alexander, you wrote that you had to alter transcoding.c since h264_omx doesn't support profile. Is still valid with latest git? Can you share the patch?
2) I have compiled a trial tvheadend on a bananapi (compatible CPU but no hardware support for omx). I have used this autobuild options:

AUTOBUILD_CONFIGURE_EXTRA="--disable-libvpx --prefix=/usr --disable-libvpx_static --disable-bintray_cache
--enable-hdhomerun_client --enable-ffmpeg --enable-libffmpeg_static" ./Autobuild.sh

and altered Makefile.ffmpeg such:

CONFIGURE := FFMPEG_PREFIX=$(EPREFIX) \
PKG_CONFIG=$(ROOTDIR)/support/pkg-config.ffmpeg \
./configure --prefix=/ffmpeg --enable-static --disable-shared --enable-mmal --enable-omx-rpi

I have also installed libomxil-bellagio-dev
Compilation worked fine, the deb package is marked "dirty", installed it, but in the transcoding profile I still not see any h264_omx, this is what I can see in stream:

Apparently I see nvenc profile (which I had not when compiling without --enable-ffmpeg-static)
Actually I don't know if tvheadend polls from ffmpeg the available codecs/profile or if this are statically set in the tvheadend code (and if ffmpeg check the hardware capabilities before reporting if omx is available or not). Also, h264_omx is a ffmpeg profile, so why the profile should be disabled in transcoding.c?
Bye

Hi Antonio,

I'am currently working on it with the raspbian distribution provided by the raspberrypi Foundation. I do not have the ArchLinux SD Image anymore, because the tweaks were small.
But, h264 provides profiles that are different from ffmpeg's codec profiles. It is more like the presets you show in the second screenshot - for tuning the codec.

https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Profiles

So, the line that I needed to alter was the tuning parameter (profile) for h264_omx, as ffmpeg does not support that profile for OpenMaX (As of time of the last Post I wrote). This seems true for current tvheadend git master. The line is #1351 in src/plumbing/transcoding.c. Maybe a newer Version (> 3.1.2) of ffmpeg supports this option now. This tweak was only needed to get the actual transcoding to start, not to enable it in the list of video codecs in tvheadend.

1) The only change I made is to comment line #1351 in src/plumbing/transconding.c!

I did not used the static version of ffmpeg that is built internally by tvheadend. ArchLinux's AUR provided a PKGBUILD that I added the --enable-mmal and --enable-omx-rpi to, built it and pointed tvheadend to that artifacts.

I think tvheadend probes ffmpeg for available audio/video codecs as you can do by calling ffmpeg directly. Also look at the tzap command. You can test ffmpeg for the codec, even the static built one of tvheadend - I think.

Happy new year

Hi Alexander
I will work on raspian as well.
I'm doing some experiment on a banana pi in preparation.
Apparently it's possible to put a plain text in the "Video codec: " row (first picture) in tvheadend stream webui tab and it will be sent to the function

static AVCodec *
transcoder_get_encoder(transcoder_t *t, const char *codec_name)

in

src/plumbing/transconding.c

and converted to the AVCodec. So creating a stream profile with video codec set to "h264_omx" should be ok.
The only problem is to build an ffmpeg (either static or not) supporting omx. I have realized that the make clean (performed by Autobuild.sh) doesn't clean the ffmpeg build, so changing the Makefile.ffmpeg doesn't trigger ffmpeg rebuild, you have to go through make distclean.
So, RPi3 should come tomorrow, and I'll try to setup everything as soon as possible.
Joseph here https://tvheadend.org/issues/3869#change-19299 apparently got some result, even if the CPU is overkilled.
I have sent an email to him, because when doing mpeg2 to h264 transcoding, another the other important stages that could overkill the GPU are the mpeg2 decoding, the resizing and eventually the deinterlacing. And as you know, hardware mpeg2 decoding is locked on RPi3, you have to buy a (cheap) license for that.
Having said so, what it is not clear to me is how the mpeg2 to h264 encoding is handled by ffmpeg and OpenMax IL
Is the mpeg2 decoded to YUV first? If so, than probably the mpeg2 license is required. And does TVHeadend/ffmpeg takes the best decoder automatically? Or the GPU directly transcode mpeg2 into h264?
There are still some aspect to check, so Alexander, let's keep in touch, ok?
Bye

P.S. there is also a branch "codecs" on the Lekma fork of tvheadend that is aiming to focus on transcoding and codec configuration (there is a webui specific tab for it). But from what I can see, he has implemented a direct OpenMAX transcoding engine, without relying on ffmpeg, so I don't know if it's a still valid path, I cannot contact him for checking this topic.

Hi Antonio

Thanks for joining the cause - giving your background as a Linux embedded SW engineer I'm sure we can get this nailed!
I am also trying to get live transcoding working using OMX, but I get stuttering and high CPU load, so I'm a bit stuck now.

I'm no expert, but I used the following options to make the h264_omx profile to show as an option, instead of libx264:

AUTOBUILD_CONFIGURE_EXTRA=--enable-ffmpeg_static\ --disable-libx264\ --disable-libx265\ --disable-libvpx\ --disable-libtheora_static\ --disable-libvorbis_static\ --disable-bintray_cache ./Autobuild.sh

In Makefile.ffmpeg I added:

--enable-mmal \
--enable-omx \
--enable-omx-rpi \
--enable-decoder="h264_mmal" \
--enable-encoder="h264_omx" \

And altered the file to fetch the newest ffmpeg version (not sure it makes a difference, but includes the latest code):

FFMPEG         = ffmpeg-3.2.2
FFMPEG_TB      = $(FFMPEG).tar.bz2
FFMPEG_URL     = http://ffmpeg.org/releases/$(FFMPEG_TB)
FFMPEG_SHA1    = 1fdf3a0e5f1700067ab8b8f0c77c5a4e4505b606
#FFMPEG_SHA1    = aac4876d1bc4d2cd8d9833b20649c3eed984f6ef

In src/plumbing/transcoding.c:

-      // All modern devices should support "high" profile
-      av_dict_set(&opts, "profile", "high", 0);
+      if (0 != strcmp(ocodec->name, "h264_omx"))
+         {
+        // All modern devices should support "high" profile
+        av_dict_set(&opts, "profile", "high", 0);
+      }

Not sure if my stuttering/high CPU is caused by MPEG2 decode (and lack of license to hardware decode), as my DVB-C provider broadcasts almost everything in h.264.

I'm ready to test stuff

- Morten Gade Sørensen

Hey,

discovered the same for ffmpeg rebuild. Cloned again and building now. Without libx265 and libvpx as that crashes the compiler with "corruption or double free" on raspbian @ RPi Foundation.

You could be right on decoding MPEG. I don't know how ffmpeg is doing that. They are said to have MPEG license, but HW (ARM -> CPU -> NEON, VC IV -> GPU -> OpenMaX) or SW (pure ARM) is another question. Commonly YUV should be the "raw" format with pixel and color information in a plane, but there could be another way. I really don't know because I'am not an engineer nor a multimedia expert.

One other thing is that there is omxplayer that utilizes the GPU at least for h264 and with license code even for mpeg and wmv (?). That's maybe the way Lekma is going.

Next point is HD, which is h264 and at least true for DVB-S2. This will drive the Pi at it's limit I think. h265 could be possible, but nothing tried in that direction.
There is even more, gstreamer. They've implemented OMX before ffmpeg did.

Let's keep in touch.

Hi Morten
So you are trying to transcode h264 into a lower bitrate h264 stream, right?
There are two things here, that we need to understand: what's the stream provided to the encoder, the DVB untouched stream or the decoded one? If I look at the function:

static int
transcoder_init_video(transcoder_t *t, streaming_start_component_t *ssc)

it then looks for decoder and encoders, so I suspect that the decoder is explicit set by tvheadend, with this helper function

static AVCodec *
transcoder_get_decoder(transcoder_t *t, streaming_component_type_t ty)
{

But what I see in this helper function is a call to streaming_component_type2codec_id which body is:

enum AVCodecID
streaming_component_type2codec_id(streaming_component_type_t type)
{
  enum AVCodecID codec_id = AV_CODEC_ID_NONE;

  switch(type) {
  case SCT_H264:
    codec_id = AV_CODEC_ID_H264;
    break;
  case SCT_MPEG2VIDEO:
    codec_id = AV_CODEC_ID_MPEG2VIDEO;
    break;
  case SCT_VP8:
    codec_id = AV_CODEC_ID_VP8;
    break;
  case SCT_VP9:
    codec_id = AV_CODEC_ID_VP9;
    break;
  case SCT_HEVC:
    codec_id = AV_CODEC_ID_HEVC;
    break;
  case SCT_AC3:
    codec_id = AV_CODEC_ID_AC3;
    break;
  case SCT_EAC3:
    codec_id = AV_CODEC_ID_EAC3;
    break;
  case SCT_MP4A:
  case SCT_AAC:
    codec_id = AV_CODEC_ID_AAC;
    break;
  case SCT_MPEG2AUDIO:
    codec_id = AV_CODEC_ID_MP2;
    break;
  case SCT_VORBIS:
    codec_id = AV_CODEC_ID_VORBIS;
    break;
  case SCT_DVBSUB:
    codec_id = AV_CODEC_ID_DVB_SUBTITLE;
    break;
  case SCT_TEXTSUB:
    codec_id = AV_CODEC_ID_TEXT;
    break;
 case SCT_TELETEXT:
    codec_id = AV_CODEC_ID_DVB_TELETEXT;
    break;
  default:
    codec_id = AV_CODEC_ID_NONE;
    break;
  }

  return codec_id;
}

now, I'm not sure how the AVCodecID pickup the correct decoder (hardware/software) but maybe this is one of the problems here

Hi
I'm reading some document on ffmpeg. From what I can see the hardware acceleration subsystem for decoding in FFMPEG is MMAL. Then I'm not sure at all that it's possible to select the hardware accelerated AVCodec * based on the AVCodecID.
I still don't have the RPi3 but can anyone of you check the list of supported decoders and encoders from your ffmpeg built with --enable-mmal and --enable-omx-rpi? Should be something like "ffmpeg -codecs"
Maybe we have to get (somehow) che correct decoder with the API

AVCodec *     avcodec_find_decoder_by_name (const char *name)

passing the mmal decoder (h264_mmal, mpeg2_mmal, mmal or?)
Bye