TVHeadend Raspberry Pi and Transcoding

lord slash · 2014-11-04T22:19:08+00:00

Hi guys, I've setup a TVHeadend back end with my raspberry pi and raspbian, where I stream the italian tv to my home in Germany. The system works perfectly d...

Antonio S

Hi
pipeline is working now, I'm developing on branch: https://github.com/Menion2k/tvheadend/tree/rpi/encoding Still it run serial, so there is no improvement, but now I can move forward to the last two steps
Bye

Morten Gade Sørensen

Really great job. Antonio!
Can't wait to test it...

Broc Miller

This is fantastic! Will this benefit hardware that has no hardware acceleration?

Antonio S

Hi all
I have completed (and committed in my branch) the implementation of the pipeline
Unfortunately I'm in a dead path now

This are the figures from a Rpi3 with standard clocking

1) Decoding SW stage takes betwen 18ms and 35ms
2) Deinterlacing with no resize takes between 35ms and 50ms

3) Encoding HW takes between 8ms and 15ms

So the problem is with the deinterlacing. It's purely done in SW and Rpi3 is too slow for the task (we must stay 100% of the times above 40ms)
There are two problems here: I cannot make the hw accelerated decoder working, I don't know why, probably there is something needed in the codec open. This would lower a little bit the CPU load and give more power to the deinterlacing, BUT, I'm not sure that ffmpeg supports multhread deinterlacing...
If, and only IF, we can fix the HW mpeg decoder and when ffmpeg would implements some MMAL accelerated deinterlacing filter, we may have some success, but for the moment there is nothing we can do for it. I will write a question to libav mailing list for the mmal deinterlacing, chance to get some answer are really low...

Pablo Alone

Hi Antonio,

I know I speak for many reading this thread when I say that your efforts are very much appreciated.

It would indeed appear to be a dead end. Having said that, thank you for taking the time and effort to investigate this to the degree that you have.

Regards
AAA

Matt T

Agreed. Fantastic work on this, and thanks to everyone involved.

I wonder if all is not lost though.

1) Is it possible to not deinterlace and simply leave it for the player to do it? In Australia we broadcast interlaced h264, so it must be a thing...

2) I personally am interested not to much in a live stream but in the final file format. Perhaps this development could be leveraged to allow TVHeadend to record and compress to h264, if not in realtime? It would be nice to have it all built in without having to fuss about with post processing options etc (currently I use post processing to call a bash script which then calls ffmpeg)

Thanks again
Matt

noggin

Matt T wrote:
> Agreed. Fantastic work on this, and thanks to everyone involved.
>
> I wonder if all is not lost though.
>

> 1) Is it possible to not deinterlace and simply leave it for the player to do it? In Australia we broadcast interlaced h264, so it must be a thing...

It should be possible to do this IF you don't scale vertically - i.e. keep 1080i as 1080i or 576i as 576i and keep an identical field-rate.

It IS possible to scale in the interlaced domain too - by simply scaling fields, not frames, but you have to do it in the field domain, which may be tricky with some codecs. You don't get the same quality - but it was how early 'DVE's (Digital Video Effects devices that squeezed or zoomed and repositioned video digitally) worked.

If you try scaling in the frame domain without deinterlacing, you end up with all sorts of nasty artefacts (commonly seen as line-grouping, banding or 'wobbly edged motion) as field 1 motion leaks into field 2 and vice versa.

Morten Gade Sørensen

You've done an amazing job on improving the code!

I was wondering if de-interlacing is neccesarry when the source codec is H.264? So maybe we can still benefit from your improvements when the goal is to transrate (H.264->H.264 with lower bitrate)?

dorin ilut

A big thanks also from me. I would also like what Morten is stating. For me all HD programs are H.264 and those are the ones I would like to transcode. The SD channels are MPEG-2 and those are at an acceptable bandwidth rate.

Dorin

Antonio S

Matt T wrote:
> Agreed. Fantastic work on this, and thanks to everyone involved.
>
> I wonder if all is not lost though.
>
> 1) Is it possible to not deinterlace and simply leave it for the player to do it? In Australia we broadcast interlaced h264, so it must be a thing...
>
> 2) I personally am interested not to much in a live stream but in the final file format. Perhaps this development could be leveraged to allow TVHeadend to record and compress to h264, if not in realtime? It would be nice to have it all built in without having to fuss about with post processing options etc (currently I use post processing to call a bash script which then calls ffmpeg)
>
> Thanks again

> Matt

No, it's not possible, at least it is not possible with the OMX encoder of Rpi3, that woeks only for progressive inputs

Antonio S

dorin ilut wrote:
> A big thanks also from me. I would also like what Morten is stating. For me all HD programs are H.264 and those are the ones I would like to transcode. The SD channels are MPEG-2 and those are at an acceptable bandwidth rate.
>

> Dorin

Hi
I will give a try with the HD channels

noggin

Antonio S wrote:
> Matt T wrote:
> > Agreed. Fantastic work on this, and thanks to everyone involved.
> >
> > I wonder if all is not lost though.
> >
> > 1) Is it possible to not deinterlace and simply leave it for the player to do it? In Australia we broadcast interlaced h264, so it must be a thing...
> >
> > 2) I personally am interested not to much in a live stream but in the final file format. Perhaps this development could be leveraged to allow TVHeadend to record and compress to h264, if not in realtime? It would be nice to have it all built in without having to fuss about with post processing options etc (currently I use post processing to call a bash script which then calls ffmpeg)
> >
> > Thanks again
> > Matt
>

> No, it's not possible, at least it is not possible with the OMX encoder of Rpi3, that woeks only for progressive inputs

Ah - so that means 576/50i and 1080/50i (i.e. all UK TV) would have to be re-encoded either to 25p or 50p (both requiring a deinterlace)... What a pain. (I guess the encoder was designed primarily to compress camera output in a mobile phone-type scenario - which would be natively progressive)

dorin ilut

Hi Antonio,

Do not know if it is relevant but all my HD channels look like this. Check the attachment.

Thibaut monet

As anyone tried the omxtx transcoding option
https://github.com/dickontoo/omxtx

Following the author it should be able to transcode on the pi

https://www.raspberrypi.org/forums/viewtopic.php?f=70&t=25022

Matt T

What about using the hardware MMAL decoder to deinterlace? It is definitely capable of doing it, because my copy of Rasplex (based on Libreelec) does it. So the MMAL could decode, deinterlace, and then send it to the OMX for encoding.

Matt T

And come to think of it, it can probably hardware scale too. I can play a 576i mpg2 video upscaling to 1080p with CPU at like 3%. So the deinterlacing and upscaling must be happening in hardware.

Antonio S

Hi.
MMAL supports deinterlacing, it works and it is used in Kodi for Rpi for example.
The problem is that ffmpeg doesn't support it. It would mean that someone should port the mmal deinterlacing from a SW that use it, such Kodi, VLC, gstreamer, to tvheadend.
And this task requires an amount of time that I simply don't have right now.
Moreover with my pipeline works, I have noticed some problem with the video rate. I suspect that having decoupled the sync between packet input and output requires some change in the internal engines, and this can be only done by some core developers... I'm here if the tvheadend team would talk about it, just don't ask me to use IRC, men we are in the 2016"
, there are better tools for collaboration ;)

Robert Mast

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.

Morten Gade Sørensen

> 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)

Antonio S

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

« Previous Page Next Page »