[mythtv-users] Recording from an IPTV source

[John P Poet]

On Wed, Nov 23, 2022 at 9:40 AM Jan Ceuleers <jan.ceuleers at gmail.com> 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.
>
> >> 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
>

I just skimmed the discussion here, so I apologize if this idea is not
relevant or already discussed...

You could write a custom "external recorder" for mythtv, but the included
`mythexternrecorder` application might be able to do what you want. It uses
configuration files to tell it  how to obtain a valid transport stream and
that is fed into mythbackend.
https://www.mythtv.org/wiki/ExternalRecorder#Using_the_.22Generic.22_External_Recorder
https://www.mythtv.org/wiki/Example_Configuration_files

I can aid you in crafting up a conf file if you need it.

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20221123/f6952c09/attachment.htm>