[mythtv-users] [mythtv] SAT>IP performance

Fri Apr 4 15:01:36 UTC 2025

On Fri, 4 Apr 2025 at 13:46, John <jksjdevelop at gmail.com> wrote:

> On 04/04/2025 10:21, Ken Smith via mythtv-dev wrote:
> > On 04/04/2025 07:16, Stephen Worthington wrote:
> >> On Thu, 3 Apr 2025 21:34:35 +0100, you wrote:
> >>
> >>> On 25/03/2025 17:17, Ken Smith via mythtv-dev wrote:
> >>>> I've adopted Stephen's sysctl settings and that has helped. I've
> >>>> re-enabled my other 4 tuners and I'm getting brief glitches.
> >>> I'm attempting to understand why MythBackend sometimes asks SAT>IP for
> >>> the whole transport stream and at other times asks SAT>IP to provide
> >>> specific pids. For example, listening to a Radio stream via DVB-S the
> >>> whole ts of 50 Mb/s was being consumed by MythBackend. Whereas watching
> >>> a HD TV stream MythBackend requested a specific set of pids and took a
> >>> modest 10 Mb/s.
> >>>
> >>> I've been attempting to trace what's going on here. My Wireshark
> >>> captures confirm that all pids are sometimes requested and at other
> >>> times specific ones are requested from SAT>IP. I've been searching the
> >>> database for where the pids that belong to a ts are stored - any
> >>> clues???. I see the SID's in the channel table. I imagined that the
> >>> pids
> >>> would be in that table as well. I did capture the SQL traffic to the
> >>> database in an attempt to answer that question but I drowned in a
> >>> sea of
> >>> SQL!
> >>>
> >>> I notice that in the legacy HTTP protocol and M3U playlists method the
> >>> M3U playlist specifies the pids associated with the relevant SID.
> >>>
> >>> {Also I noticed that despite configuring "Interactions between Inputs"
> >>> to 1 channel only, sometimes I see that setting change to 3 or 4 -
> >>> why?}
> >>>
> >>> Any pointers most appreciated.
> >>>
> >>> :-) Ken
> >> The normal way a SAT>IP connection works is that first a request is
> >> made for PID 0, which is a stream of packets that provide data to find
> >> other streams and packets that tell what is being transmitted on the
> >> multiplex.  Using the data in those packets, it reads the (PMT?)
> >> packets that describe the channels and finds the service id and PID
> >> numbers.  Then it will request a change to the PIDs it is receiving to
> >> be the ones for the channel that is wanted.  If you look at your
> >> Wireshark captures of the control stream (default port 554), you
> >> should see a set of packet exchanges setting up a PID 0 stream, and
> >> then possibly more packets that capture other administrative streams
> >> to find the PMT packets and anything else needed for the setup, and
> >> then finally more packets that set up the actual PIDs needed for the
> >> recording and cancel the PIDs for most of the administrative streams.
> >> The RTP/RTSP streams that carry the actual data are on different ports
> >> that are negotiated on the control connection and the ports can vary
> >> depending on the configuration of the SAT>IP server. However, they
> >> normally just start at a number specified in the configuration and
> >> increase by 2 for each new connection to the SAT>IP server. Each pair
> >> of ports is the UDP RTP and RTSP ports for one data connection to the
> >> server.  So for minisatip if -P is set to 5500 (the default), then the
> >> first RTP/RTSP pair will be on ports 5500 and 5501 and you can get
> >> Wireshark to capture them to see the data traffic, such as the initial
> >> PID 0 traffic.
> >>
> >> Information on the format of the transport stream packets used on the
> >> data connections can be found here:
> >>
> >> https://en.wikipedia.org/wiki/Program-specific_information
> >>
> >> The satip_specification_version_1_2_2.pdf file that specifies the
> >> current version of the SAT>IP protocol is available from the minisatip
> >> site:
> >>
> >>
> https://github.com/catalinii/minisatip/blob/master/docs/satip_specification_version_1_2_2.pdf
> >>
> >>
> >> It used to be available from the official SAT>IP site, but has been
> >> missing from there for a while now.
> >>
> >> I also have copies of some of the (very detailed) DVB Bluebooks that
> >> define the DVB standards.  I can not remember where I got them from,
> >> but I have put them on my web server if you want them:
> >>
> >> http://www2.jsw.gen.nz/dvb
> >>
> >> The legacy method of recording SAT>IP sends one URL requesting the
> >> PIDs for a channel.  This works with minisatip, but lots of other
> >> SAT>IP implementations (such as TVHeadend) do not accept an all in one
> >> URL, even though it seems to be valid according to the SAT>IP
> >> specifications.  For those sorts of SAT>IP implementations, it seems
> >> that at least separate SETUP and PLAY commands are required. The
> >> all-in-one URLs also require that nothing has changed on the
> >> transmitter, so the PIDs are all still the same.  Using a staged setup
> >> sequence that reads the administrative packets first allows for the
> >> PIDs to have changed, and the channel can still be recorded if it
> >> still exists on different PIDs.
> >>
> > Thank you Stephen, my wireshark captures confirm exactly the sequence
> > you are describing. Initially pid 0 and then a further request for
> > other pids. Oddly I'd read that Wiki page yesterday. Thanks for the
> > DVB info. I have the SAT>IP spec.
> >
> > I'll investigate further, capturing the the PAT table dialogue on
> > ports 55** and see what happens when I tune a radio channel and
> > pids=all gets selected.
> >
> > Thanks
> >
> > Ken
> >
> >
> The thread
>
> https://forum.mythtv.org/viewtopic.php?f=36&t=5701&p=27860&hilit=sat%2Fip#p27860
> <
> https://forum.mythtv.org/viewtopic.php?f=36&t=5701&p=27860&hilit=sat%2Fip#p27860>
>
> may be relevant.
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

See also the code here:
https://github.com/MythTV/mythtv/blob/e1f9afea2d0f9f65193dc554e88b9c9ce5295273/mythtv/libs/libmythtv/recorders/satipstreamhandler.cpp#L272
where the decision to do either pid filtering or do the full transport
stream is made.

If the number of requested pids is more than 32 the complete transport
stream is requested; with 32 or less pids the filtering is done by the
SatIP box.
This is done, as mentioned in the thread, to support the Telebit box; this
box fails when the pid filter has too many pids.
Minisatip does not have this limitation but for now all SatIP servers are
treated equally.

I do however think that the filtering of the pids, or the lack of
filtering, is not the root cause of your problems.
I personally think that your system should be able to handle a full
transport stream of about 40Mbits/seconds when you specify that you
measured your bandwidth to be more than 2Gbit/second.
FYI  the code has been tested a lot, even with full transport streams over
Wifi links, but only with real hardware.

Hope this helps a little, at least with understanding how it works.
Klaas.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20250404/c6626987/attachment.htm>