[mythtv-users] Recording from an IPTV source

[Jan Ceuleers]

On 23/11/2022 18:01, Stephen Worthington wrote:
>> 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.

Understood, and I don't think that this will be a problem in this
instance for the following reasons:

1. Video doesn't need to be transcoded; that's copied. Only audio needs
to be transcoded. See the ffmpeg incantation in the article I linked to
before. I think ffmpeg probably also sanitises the video somewhat (e.g.
dropping empty mpegts packets) but that seems to be a low-effort job.

2. The CPU is fairly oomphy: i3-8350K CPU @ 4.00GHz. Easily up to 3x the
job described above with plenty to spare.

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

Except that UDP, being a connectionless protocol, does not establish
connections. Anything arriving on port 5004 from whatever source risks
being intermingled unless the application (i.e. myth) is capable of
keeping things apart, in this case based on source IP address. I doubt
that that is the case.

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

Yes, that would be the fallback.

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

Thanks, I'll look at that. The REC_PENDING event handler would then
obviously need to have access to the channel number it needs to set the
STB to.

Cheers, Jan