[mythtv-users] Recording from an IPTV source

[Stephen Worthington]

On Wed, 23 Nov 2022 13:08:45 +0100, you wrote:

>On 23/11/2022 04:12, Stephen Worthington wrote:
>> Your basic problem with using the advice on that page is that your
>> HDMI to IPTV capture devices do not do HTTP output.  Everything on
>> that page is based around using curl to do HTTP connections, so it
>> will not work at all for you.  Fortunately, MythTV does actually do
>> RTP/RTSP UDP protocol - it was originally used for some older network
>> tuners, which are still supported.  And now it is used for SAT>IP
>> connections, which use a specific subset of RTP/RTSP.  So it may be
>> possible to get MythTV to do the capture directly by just giving it a
>> URL in its IPTV channels.
>
>Thanks for your reply and for your constructive input.
>
>> MPEG TS with H.264 video is fully supported by MythTV as that is the
>> format used in many parts of the world for DVB-T(2) transmissions.  So
>> there should be no need to use ffmpeg to convert it - if you capture
>> the stream to disk as is it should just work.
>
>I fear that it may not work because:
>
>- 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.

>- the stream is sent to an IP address of my choosing (so I can direct it
>to the backend) but not to a port of my choosing. So the streams of
>multiple such devices end up being sent to the same IP:port combination,
>and I suspect that Myth won't be able to tell them apart (by source IP
>address). Perhaps some iptables trickery could solve that, but this
>remains to be seen.

The RTP/RTSP protocol tells the receiver what ports it is using as
part of the startup handshake.  The initial connection is an RTSP
connection, which then sets up and controls the actual media stream on
an RTP connection.  The RTP connection uses two UDP ports, one for the
media data stream (RTP protocol) and one for parallel status and
control data (RTCP protocol).  They are always a pair of ports so if
one is on port 8000, the other is on port 8001.  See:

https://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol
https://en.wikipedia.org/wiki/RTP_Control_Protocol
https://en.wikipedia.org/wiki/Real-time_Transport_Protocol

MythTV handles all of that protocol, so port selection for RTP/RTSP is
not a worry unless you have a firewall between mythbackend and the
HDMI to IPTV capture box.  If you do, then you may need to open a
group of UDP ports through that firewall.  Typically, RTP uses ports
starting at 8000.  Since you would only be using one stream at a time
from the HDMI to IPTV converter (because it can only create one stream
at once), you would need to open 8000-8001 for the IP of each of your
HDMI to IPTV converters.  But you would need to find out exactly what
port numbers the converter software uses - it may be selectable, or it
may just used fixed numbers.  You should be able to use tcpdump,
tshark or Wireshark to see the packets if it is not documented
somewhere.

>> The big problem with IPTV channels is setting them up using a .m3u
>> file.  The parts of that page that refer to .m3u creation may help
>> with that.
>
>I fundamentally don't understand why that should be needed in my use
>case (and in fact also in yours): is it not the case that determining
>which channel is sent in the stream is determined out-of-band (in my
>case by sending IR signals to the STB), rather than by visiting some URL?

For SAT>IP, the channel selection is in-band - you have to tell the
source tuner what streams to send for that channel (see the pid= part
of the iptv_channel URL entries I posted).  For your case, where you
have to tell the STB the channel out of band, then you would likely be
using the same URL entry for all the channels, and using the channel
number or service ID from the channel table to select the channel in
the channel change script that talks to the STB.

The .m3u file is loaded into the MythTV database when an IPTV tuner is
"scanned".  It sets up the channel number and service ID values as
well as the URLs, so it really is needed (or some other way of setting
up that data in the database).

>But if it is needed because MythTV's ability to ingest IPTV signals was
>built with another use case in mind, then I suppose we'll have to jump
>through those hoops, and I thank you for your help in this area.
>
>> So exactly what HDMI to IPTV capture hardware do you have?  If it uses
>> a compatible RTP/RTSP protocol, you should be able to just create
>> rtsp:// URLs as I have done.
>
>The devices I have are based on the LKV373A as described here:
>
>https://gist.github.com/Juul/8adc297cf49675d858976f5d10fffc6e
>
>Thanks, Jan

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

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.