<div dir="ltr"><div dir="ltr">On Wed, Nov 23, 2022 at 9:40 AM Jan Ceuleers <<a href="mailto:jan.ceuleers@gmail.com">jan.ceuleers@gmail.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 23/11/2022 18:01, Stephen Worthington wrote:<br>
>> What I'm thinking of instead is to capture/transcode the stream using<br>
>> ffmpeg, but instead of writing it to disk as described in the linked-to<br>
>> article have ffmpeg stream it in a format MythTV can record. So MythTV<br>
>> would record from a stream on the loopback interface. This way also live<br>
>> TV would work (which it would not if the transcoding is done after the<br>
>> initial recording).<br>
> <br>
> That sounds like an interesting idea.  But you really do not want to<br>
> be doing real-time transcoding of video streams if at all possible -<br>
> that pushes even very modern processors beyond the limit.  Video<br>
> codecs typically only run on one CPU core, so your nice 6 (or 8 or 12)<br>
> core CPU is reduced to 1/6th of the speed.  You really need to just be<br>
> copying the streams, and modifying the container if necessary, or<br>
> fixing the timestamps - nothing that touches the content of the video<br>
> stream(s).  And remember that transcoding using any compressing codec<br>
> always reduces the quality of the resulting video, so you want to<br>
> avoid that.<br>
<br>
Understood, and I don't think that this will be a problem in this<br>
instance for the following reasons:<br>
<br>
1. Video doesn't need to be transcoded; that's copied. Only audio needs<br>
to be transcoded. See the ffmpeg incantation in the article I linked to<br>
before. I think ffmpeg probably also sanitises the video somewhat (e.g.<br>
dropping empty mpegts packets) but that seems to be a low-effort job.<br>
<br>
2. The CPU is fairly oomphy: i3-8350K CPU @ 4.00GHz. Easily up to 3x the<br>
job described above with plenty to spare.<br>
<br>
>> I think/hope this would also solve the other problem, whereby the<br>
>> streams generated by each of the three capture devices are sent to the<br>
>> backend on the same port (5004), but different IP addresses, which is<br>
>> something I think I have more flexibility in doing using ffmpeg command<br>
>> line trickery than MythTV probably supports by itself.<br>
> <br>
> Not having actually done it before, I do not see any theoretical<br>
> problem with using the same port and different IP addresses.  Ports<br>
> are always associated with an IP address, in an <IP address, port><br>
> pair.  An IP connection is made between a source pair and a<br>
> destination pair.  So something listening on port 5004 should be able<br>
> to see the source pair in the incoming packets and make separate<br>
> connections depending that.  I would be surprised if the standard<br>
> software for listening on a port did not do that automatically.<br>
<br>
Except that UDP, being a connectionless protocol, does not establish<br>
connections. Anything arriving on port 5004 from whatever source risks<br>
being intermingled unless the application (i.e. myth) is capable of<br>
keeping things apart, in this case based on source IP address. I doubt<br>
that that is the case.<br>
<br>
> It should also be possible to write DNAT rules for the firewall to<br>
> change the destination port number on incoming packets from specified<br>
> addresses, using nftables or iptables.<br>
<br>
Yes, that would be the fallback.<br>
<br>
>>> When the STB channel is changed, I think it would be best to do that<br>
>>> before MythTV starts recording.  The data in the streams may not be<br>
>>> very valid during the channel change period, and that might cause<br>
>>> playback problems due to bad data at the start of the recordings.  So<br>
>>> there should be a delay between when the STB channel change is done<br>
>>> and when MythTV starts recording.<br>
>><br>
>> Any thoughts on how to separate these two events? That is: how to get<br>
>> advance notice of the need to change channels and start streaming before<br>
>> Myth starts recording?<br>
> <br>
> There is an event that happens when a recording is about to start<br>
> (REC_PENDING), and another one when it actually starts (REC_STARTED).<br>
> And a third one when it is confirmed as writing to disk<br>
> (REC_STARTED_WRITING).  So the STB channel change should be done on<br>
> the REC_PENDING event.  I think the REC_PENDING event is around a<br>
> minute before the REC_STARTED event, to allow for a tuner to be<br>
> powered up and the channel changed before the recording starts.  It<br>
> also allows time to spin up the hard drive the recording is going to<br>
> if necessary.<br>
<br>
Thanks, I'll look at that. The REC_PENDING event handler would then<br>
obviously need to have access to the channel number it needs to set the<br>
STB to.<br>
<br>
Cheers, Jan<br></blockquote><div><br></div><div>I just skimmed the discussion here, so I apologize if this idea is not relevant or already discussed...<br></div><div><br></div><div>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. </div><div><a href="https://www.mythtv.org/wiki/ExternalRecorder#Using_the_.22Generic.22_External_Recorder">https://www.mythtv.org/wiki/ExternalRecorder#Using_the_.22Generic.22_External_Recorder</a></div><a href="https://www.mythtv.org/wiki/Example_Configuration_files">https://www.mythtv.org/wiki/Example_Configuration_files</a><br><div><br></div><div>I can aid you in crafting up a conf file if you need it.</div><div><br></div><div>John<br></div></div></div>