Tvheadend

Antonio S wrote:

men we are in the 2016"

Happy new year!

Last time I participated in this thread I finally got a bit distracted by building a version of GStreamer-1.0 that supports the RPi-hardware. I now found a spot which mentions a pre-built GStreamer-1.2 version for Raspbian http://blog.gbaman.info/?p=150

I think the http-launch mentioned here: https://www.raspberrypi.org/forums/viewtopic.php?t=113052
is able to set up a http-stream that will work with TVHeadend, as TVHeadend is able to set up streams as well, won't it? When I use TVHeadend and click a channel it sets up a http-stream, which is also used for playing via Kodi.

If you just throw away half of the 1080i50 you keep allmost enough lines for 576p25, which often gets broadcasted and many motion smoothing TV's will get this smoothed back. One of our commercial broadcastproviders only sent duplicate lines resulting in only 288 different lines, and on a 28" screen from 4 meter that didn't even catch the eye. So the lines you'll miss by not deinterlacing but just throwing away half of the frames will be minimal when transcoding down 1080i to 576p.

> I will give a try with the HD channels

Did you have any luck with HD channels that doesn't require interlacing, which apparently is the challenge at the moment? (transrating H.264 -> H.264)

Hi I cannot test it because in Italy the HD channel are 1080i (h264 encoded)....

Hi Antonio...could really use your help if you have the time.

I am trying to build tvheadend by cloning your git.

In terms of ffmpeg I built it and it looks like this:

pi@raspberrypi:~ $ ffmpeg -codecs | grep "\(mmal\|omx\)"
ffmpeg version N-83292-ge65db4c Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 4.9.2 (Raspbian 4.9.2-10)
configuration: --enable-libfreetype --enable-gpl --enable-nonfree --enable-libx264 --enable-libmp3lame --bindir=/usr/local/bin --enable-static --enable-omx-rpi --enable-mmal
libavutil 55. 45.100 / 55. 45.100
libavcodec 57. 75.100 / 57. 75.100
libavformat 57. 66.101 / 57. 66.101
libavdevice 57. 2.100 / 57. 2.100
libavfilter 6. 72.100 / 6. 72.100
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100
DEV.LS h264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 (decoders: h264 h264_mmal ) (encoders: libx264 libx264rgb h264_omx )
DEV.L. mpeg2video MPEG-2 video (decoders: mpeg2video mpegvideo mpeg2_mmal )
DEV.L. mpeg4 MPEG-4 part 2 (decoders: mpeg4 mpeg4_mmal )
D.V.L. vc1 SMPTE VC-1 (decoders: vc1 vc1_mmal )
pi@raspberrypi:~ $

Then I git clone: pi@raspberrypi:~ $ git clone https://github.com/Menion2k/tvheadend.git

and build using: pi@raspberrypi:~/tvheadend $ AUTOBUILD_CONFIGURE_EXTRA=--enable-ffmpeg_static\ --disable-libx264_static\ --disable-libx265\ --disable-libvpx\ --disable-libtheora_static\ --disable-libvorbis_static\ --disable-bintray_cache ./Autobuild.sh

The issue seems to be it is not picking up the h264_omx codec.

Dorin

You are building the internal static ffmpeg, if you want to do it, then you need to modify Makefile.ffmpeg and add the compilation switch.
Otherwise change your compilation command to:

:~/tvheadend $ AUTOBUILD_CONFIGURE_EXTRA=--disable-ffmpeg_static --disable-libx264_static --disable-libx265 --disable-libvpx --disable-libtheora_static --disable-libvorbis_static --disable-bintray_cache ./Autobuild.sh

Antonio ...if you want I can give you access to my system to test the HD channels if you want to have a go at it. We can arrange more on email.

i testet it with ffmpeg with h264_omx in console..

first 1080i only 16fps...

ffmpeg -i http://192.168.1.3:9981/stream/channelid/1259354985 -c:v h264_omx -b 3000k -acodec aac -ab 128k -ar 44100 -ac 2 -f mpegts udp://192.168.1.24:10000

720p same ffmpeg line and i have 40fps but a lot of errors (because of no mpeg licence?)

mpeg2 stream (576i) same ffmpeg line and i get a 4:3 picture (544x578)... but with -s 640x360 its okay

have u better options for me? how many sd channels can u transcode the same time?

Somehow I overlooked this thread:
https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=123876&hilit=real+time+transcoding

It shows in detail how to transcode in real time with TVHeadend.

I'm trying, still no success

Antonio S Sorry to be asking this here, could you have a look on this https://tvheadend.org/issues/3831#note-99??

Antonio S wrote:

I'm trying, still no success

I tried to build TVHeadend from github in Raspbian past weekend. As many older download-links failed finally it came to an end with the newest TVHeadend-commit e5f5a4278949afc96e26d6cd50cf968e0e92d7b6

sudo apt-get install libavformat-dev
sudo apt-get install libssl-dev
sudo apt-get install gettext
sudo apt-get install cmake
. ./configure --enable-libffmpeg_static --disable-libx265 --disable-libx265_static --disable-libvpx --disable-libvpx_static
make

But the version that was finally built couldn't cope stably with my DVB-receiver as it failed scanning muxes. I probably miss some knowledge on configuring kernelmodules or something in Raspbian. When I tried about a year ago the Raspbian-version was less stable than the OSMC/OpenElec versions, but at least I got TVHeadend running then.

In OSMC I have TVHeadend working, just the packaged v4.0.9. I'll try to get the pre-packaged http-launch working on OSMC. It seems to link to it's gstreamer-version. I already bought the MPEG2-license for my new RPi3.
The PiCoolFan (I bought only the fan controller and a chinese fan-case as the rest doesn't fit the RPi3) does it's job of cooling the processor at compiling with make -j4 after customizing via the i2c-connection. The fan runs at 25% and max 34 degrees celcius. That keeps the processor at about max. 60 degrees and when the processor is idle the fan isn't running.

The gstreamer that was available in OSMC misses some functionality, so I'll probably have to compile gstreamer again... That takes 8 hours on a RPi1, but on my RPi3, with a Sandisk Cruzer extreme 32GB as root file system and a fan to be able to make -j4 I expect it to last about an hour or two. I hope I can find a building procedure that provides all components I need. Every missing component means a rebuild.

I succeeded compiling gstreamer, however with some manual steps not with a script.

http-launch however uses a dynamic port, that's unusable over the internet.

This subject shows someone who managed how to do it with gst-launch:
https://tvheadend.org/boards/4/topics/16680?r=16778

It only doesn't contain the RSTP-service to export the transcoded signal to another machine over one port, so that's a missing part. VLC will be able to read an RTSP-stream.

The RTSPSink is not working for gstreamer-1.0, it's still 'in development' and only available on request.

But probably a TCP or UDP sink will be possible?

Here an UDP-example and an experimental OMX-deinterlacer

https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=6852&start=250

That is outdated. Current gsstreamer supports OMX at decoding, deinterlacing and encoding stage, providing very good performance. The problem is with the live dvb-t transcoding (at least). It's doesn't work on my Rpi3, there is some nasty issue with audio extraction that I could not solve yet, and I have so few time these days.
It is so bad that tvheadend doesn't support gsstreamer lib for transcoding. IT is so much more advanced with hw accelerated platforms and the community is very supportive.

It might be fast, but I still haven't got it working. I subscribed to a RPi3-bug:
https://bugzilla.gnome.org/show_bug.cgi?id=767801

Antonio S wrote:

Current gsstreamer ... doesn't work on my Rpi3 ... and the community is very supportive.

After still looking and testing some more I only loose my self in debugging with GStreamer 1.10.3 which doesn't work at all, I'm jumping from one bug patch into another until there isn't any patch available for the next issue.

Gkreidl, one of the RPi-developers that seriously uses GStreamer has used 1.0.0 until 2015, while newer versions often didn't work and he didn't want to waste his time on debugging. So the secret is in finding the right Raspbian-version.

In this thread there is mention of a Jessie-version with a working GStreamer, namely 2016-05-27-raspbian-jessie without GStreamer-updates:
[[https://www.raspberrypi.org/forums/viewtopic.php?f=38&t=123876&hilit=transcoder&start=100]]

by newspeer » Mon Oct 10, 2016 8:44 am
gkreidl wrote:
I suppose on Jessie light most or all the gstreamer-1.0 packages are missing.

That is correct. I installed them via apt-get and it worked flawless on 2016-05-27-raspbian-jessie-lite, but not on 2016-09-23-raspbian-jessie-lite. So maybe there were changes from the May version to the September version.

The important part is, that we shouldn't use the lite version anymore.

I'll just try the transcoding from that 2016-05-27-raspbian-jessie image next.

Robert Mast wrote:

I'll just try the transcoding from that 2016-05-27-raspbian-jessie image next.

I tried it on both RPi1 and RPi3. Both don't contain gstreamer-1.0 completely, I had to apt-get install gstreamer1.0-tools, but something like OMXplayer was present.

I used pre-built versions of TVHeadend, and got the channel scan working, and tested plain video in firefox.

However in both the RPi1 and RPi3 a simple pipeline like
gst-launch-1.0 --gst-debug omx*:5 souphttpsrc location="http://192.168.178.20:9981/play/stream/channel/bb1d1b43ba58356cd04fb708894a0f75?title=4%20%3A%20RTL%204" ! tsdemux name=demux demux. ! queue ! filesink location=localfile.mkv

Did not result in any file content, so gstreamer 1.10.3 on the RPi3 came even further than this.

I guess the only option for me to ever see this working is revert back to gstreamer-1.0.0 on my RPi1. I wonder what image I should use to get this running.

Even converting the audio to hardcoded 0101 with recompiling TVHeadend to include transcoding (as written here:[[https://tvheadend.org/boards/4/topics/16680]] didn't change a thing.

There's still another option: Buying a second hand BCM2836 RPi2 as most of the development and testing of GStreamer is done on the BCM2836 RPi2. The new somewhat silently introduced BCM2837 RPi2 will have the same compatibility-issues as the RPi3, so it has to be second hand.

To be continued...

You have hit my same issue. I don't think it is due to the different hardware. The guy who is developing some http-launch script on the official raspberrypi forums, said he suspect there is a timing issue between the time tvheadend provided the tuned and valid TS file and when gsstreamer wants the audio available. It is of course a issue/limitation of gsstreamer, but that is... Also you have to force the x-raw info in the pipeline before the encoder. Apparently the OMX decoder fails tp set correct frame info

Here I found the instruction, between the lines, to get Gstreamer 1.0.0 with omx running on a RPi1B at the end of 2014.

https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=34250&p=599066&hilit=gstreamer

Here even the 0.1 version:
http://raspberrypi.stackexchange.com/questions/528/how-can-i-install-gstreamer-gst-omx

Antonio S wrote:

The guy who is developing some http-launch script on the official raspberrypi forums, said he suspect there is a timing issue between the time tvheadend provided the tuned and valid TS file and when gsstreamer wants the audio available.

I've possibly read that remark half a year ago when I bought my RPi3 to be able to build gstreamer somewhat faster.
But would that timing-issue also be the case when I even don't request audio from the stream at all?

Apparently not because the problem is with the global demuxer. By the way, it is what the "guy" think about the issue

Antonio S wrote:

Apparently not because the problem is with the global demuxer. By the way, it is what the "guy" think about the issue

GKreidl (Guenter Kreidl) seems one of the most persevering users of GStreamer in his RPi-creations, so he'll probably have a point.
I hope he has filed a clear bug report for the supportive GStreamer-team. There is a sea of NEW bugs in bugzilla for gstreamer, I hope it won't drown there.

I didn't get GKreidl's mumudvb scan my DVB-C channels yet.

By the way, the end of 2014 is a nice milestone for the last time someone reported GST-OMX working, with sufficient instructions and versions, while that was the last moment only the RPi1 BCM2835 existed.

The RPi2 BCM2836 was introduced at the beginning of 2015, so every forumthread mentioning working versions since then could be blurred by hardware incompatibility if the right RPi/chip isn't properly stated.