[mythtv-users] Recording from an IPTV source

[Jan Ceuleers]

On 23/11/2022 14:37, Stephen Worthington wrote:
>> - the signal is not quite standards-compliant in ways that I can't
>> explain but, for example, prevent vlc from playing it as-is. The article
>> I link to below provides an ffmpeg incantation that enables me to
>> capture the stream, minimally transcode it and write it to disk, the
>> result of which is indeed playable by vlc.
> 
> In that case, I think the way to handle that would be to get MythTV to
> record directly to disk, then run a transcode on it afterwards.

What I'm thinking of instead is to capture/transcode the stream using
ffmpeg, but instead of writing it to disk as described in the linked-to
article have ffmpeg stream it in a format MythTV can record. So MythTV
would record from a stream on the loopback interface. This way also live
TV would work (which it would not if the transcoding is done after the
initial recording).

I think/hope this would also solve the other problem, whereby the
streams generated by each of the three capture devices are sent to the
backend on the same port (5004), but different IP addresses, which is
something I think I have more flexibility in doing using ffmpeg command
line trickery than MythTV probably supports by itself.

> Looking at that web page, it looks like the LKV373A devices do not do
> RTSP protocol.  Instead, they are configured to boot up and start
> broadcasting RTP protocol only - they never stop.

That's right: no RTSP. I can make the devices start/stop streaming by
turning RTP and multicast on/off using curl, but that's about it.

>  Which may be a
> problem, as I do not know if MythTV will handle rtp:// URLs.  If so,
> then you would be back to doing what the scripts on this page do:
> 
> https://www.mythtv.org/wiki/IPTV_Encoders_as_a_Capture_Device
> 
> but replacing the curl commands that do HTTP with ffmpeg commands to
> receive RTP protocol.
> 
> So I think you need to test what MythTV can do by creating an IPTV
> source and tuner and setting up a channel with an rtp://<ip address>
> URL and seeing if MythTV will handle that.  Also try udp://<ip
> address> if rtp: does not work.

OK, I'll look at that in more detail. This will require care though,
because I'll have to create a test backend and make very sure that I
don't clobber my production system which lives on the same LAN. (I'd
prefer not also having to set up a test LAN; my switches are unmanaged
and not VLAN-capable).

> When the STB channel is changed, I think it would be best to do that
> before MythTV starts recording.  The data in the streams may not be
> very valid during the channel change period, and that might cause
> playback problems due to bad data at the start of the recordings.  So
> there should be a delay between when the STB channel change is done
> and when MythTV starts recording.

Any thoughts on how to separate these two events? That is: how to get
advance notice of the need to change channels and start streaming before
Myth starts recording?

Thanks, Jan