[mythtv-users] Recording from an IPTV source

Stephen Worthington stephen_agent at jsw.gen.nz
Wed Nov 23 17:01:02 UTC 2022

On Wed, 23 Nov 2022 17:08:09 +0100, you wrote:

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

That sounds like an interesting idea.  But you really do not want to
be doing real-time transcoding of video streams if at all possible -
that pushes even very modern processors beyond the limit.  Video
codecs typically only run on one CPU core, so your nice 6 (or 8 or 12)
core CPU is reduced to 1/6th of the speed.  You really need to just be
copying the streams, and modifying the container if necessary, or
fixing the timestamps - nothing that touches the content of the video
stream(s).  And remember that transcoding using any compressing codec
always reduces the quality of the resulting video, so you want to
avoid that.

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

Not having actually done it before, I do not see any theoretical
problem with using the same port and different IP addresses.  Ports
are always associated with an IP address, in an <IP address, port>
pair.  An IP connection is made between a source pair and a
destination pair.  So something listening on port 5004 should be able
to see the source pair in the incoming packets and make separate
connections depending that.  I would be surprised if the standard
software for listening on a port did not do that automatically.

It should also be possible to write DNAT rules for the firewall to
change the destination port number on incoming packets from specified
addresses, using nftables or iptables.

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

I do this sort of thing using a VirtualBox virtual PC.  You can set up
VirtualBox virtual PCs with their own IP address on the same subnet
that the host PCs is on - the virtual PC is bridged onto the host PC's

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

There is an event that happens when a recording is about to start
(REC_PENDING), and another one when it actually starts (REC_STARTED).
And a third one when it is confirmed as writing to disk
(REC_STARTED_WRITING).  So the STB channel change should be done on
the REC_PENDING event.  I think the REC_PENDING event is around a
minute before the REC_STARTED event, to allow for a tuner to be
powered up and the channel changed before the recording starts.  It
also allows time to spin up the hard drive the recording is going to
if necessary.

More information about the mythtv-users mailing list