Pre-channels transcoding?

Channels DVR Server
#1

I've been trying to pre-transcode to feed into channels, specifically so I can have multiple channels dvr systems in docker (to isolate users/give them their own) and allow for shared tuners and only one transcoding tasks per channel.

I can't seem to find a format or encoder to do this job. I can convince ffmpeg to product HLS streams in m3u8 indexes but channels doesn't like this and I can't get xteve or telly to take the m3u8 either.

Anyone implement such a thing before? ffmpeg (or whatever, gstreamer, vlc, done care so long as it can use intel hardware encoders) and output a xteve/telly/other compatible stream to feed into Channels?

#2

You need to output MPEG-TS, not HLS. You're using the wrong container.

#3

I can't seem to find a way to encode ts chunks with a M3U index with ffmpeg.

#4

Channels expects the HDHR source (which xteve, etc., emulate) to be in MPEG-TS. There is no M3U with a transport stream. In your Ffmpeg command line, add -f mpegts just before your output filename. (If the extension of your output file name is .ts, that's not usually necessary. But forcing it with -f is never a bad idea.)

#5

sure, but I need a continuous stream here, so I can't just pump this to a single file. This is my missing piece. I know ffmpeg can output in mpeg-ts, but everything I find assumes I want that in an HLS container. I'd be happy pushing it to an in-memory buffer or something but I can't find a way to do that.

1 Like
#6

You can create a FIFO or socket, and output to there; then have the program on the other end read from that. Or even easier, just pipe the data straight from Ffmpeg to your other program.

Perhaps if you were a bit clearer of what it is exactly you're trying to do, that might help. If your problem is with some other middleware program you're trying to use to feed into Channels, have you sought support from the application itself? They would probably be able to give you more targeted support.

#7

I have an HDHR quad tuner and I want to transcode the stream into h.265 and then have multiple instances of channels see that h.265 source.

HDHR>transcoder>x>channels, x probably being xteve or telly to present as an HDHR.

The end goal here is to have multiple instances of channels dvr running, using that single h.265 HDHR-type source.

Channels isn't multi-user and I really need it to be, multiple instances solves this just fine as I can run them in docker.

So back up to the transcoder component, I have hardware that is capable of encoding about 5-6 h.265 streams from the HDHR with ffmpeg and intel encoder. I was planning on launching the encodes daemonized as to produce a ready to use stream at all times for xteve/telly to read.

A secondary goal is to have faster 'channel tuning' because the channel is already enguaged and channels dvr can use tuner sharing and just point at the stream. ie, better user experience.

#8

So what you're really looking at is multicasting then? Have you looked at the Ffmpeg wiki entry? At the end are directions for streaming to a UDP address. You might be able to try streaming to a multicast IP (and port of your choosing) straight from Ffmpeg, and then use a custom channel pointing to that IP in each Channels instance.

This might also be of interest:

#9

I'll look at that. Wasn't actually my intension though, just multiple unicast streams

#10

Your initial post seems to contradict that:

If multiple instances are going to see the same stream, that type of one-to-many streaming is the definition of multicast.

You may also want to look at H.264 instead of H.265, and hardware transcoders for H.264 are in a better state/faster right now, I think. And for content up to 1080p, there really isn't any difference in size between the two; H.265 doesn't really see any real gains until you start looking at 4K and beyond.

#11

However, you still need to address the larger issue: having your middleware—whatever you use—know when to initiate the stream and start transcoding. Unless you are going to just have the same 4 streams going at all times?

#12

We're mixing multicast contexts here. I don't want to use networking multicast, too problematic.

intel qsv is super solid for h.265 encoding and all my target devices already support h.265. I'm seeing the same 50% reduction in size vs quality using intel qsv to h.265 vs h.264. Maybe libx265/264 has different results.

I actually don't want to 'initiate' the streams via channels or telly etc, I'm just going to fire them up and let them run. ie, that output would be available already, no need to initiate the encoding.

#13

Another option you may to look into is Tvheadend.

Using that as your middleware, you can use its pipe input type to dynamically handle your Ffmpeg transcoding, and serve its M3U playlists directly to your Channels instances. That way you can also set a limit of the number of streams that Tvheadend will allow to be served to other clients.

Thinking on it, that is probably the best option.

#14

Can channels take the m3u from tvheadend as a 'tv' interface? and pull guide data on it?

#15

If that's what you want, then your best option is probably Wowza, Live555, or something similar. Something like: ffmpeg [hwaccel options] -i "http://${HDHR}:5004/tunerN/v#" [codec options] -f mpegts udp://</path/to/local/socket> and then have your RTSP server read from that socket. (I think specifying the specific tuner to use in the Ffmpeg command is best, that way you can ensure which channel each tuner is serving.)

#16

Yes. Channels can read the M3U, and you can assign guide data to it natively within Channels, mapping the playlist/channel entries to the broadcast guide data that Channels will maintain and update.

#17

I'm actually thinking maybe tvheadened via it's 'pipe' function can get me to an acceptable place. M3U input with a pipe to ffmpeg to encode then present that to channels. It would have to initiate the first connection but additional connections to tvheadend would already be 'spin up' so to speak.

#18

I think that might be the most "friction-free" way to get what you want. Tvheadend configuration can be a chore, but once it's setup, it's solid and low on resources. I'm not certain how it will handle multiple requests to the same stream, though. (It's been a few years since I've used it; that was my DVR of choice before Channels.)