[mythtv-users] Recording from an IPTV source

[Stephen Worthington]

On Wed, 23 Nov 2022 18:39:24 +0100, you wrote:

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

Yes, as long as you are not touching the video data, almost any CPU
will do the job.

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

UDP may be a "connectionless" protocol, but it still follows the rules
about how the ports work.  Streams from multiple addresses can arrive
on a port and are easily distinguished.  The problem would be with
whether MythTV is set up to be able to do that.  I suspect this sort
of operation was not in the minds of the developers when that bit of
code was written.

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

See here:

https://www.mythtv.org/wiki/SYSTEM_EVENT_(Myth_Protocol)

The REC_PENDING event has the chanid available to it.  So in setting
up the event do this:

rec_pending_event.sh %CHANID%

to get the chanid passed to the script.