IPTV is a name for a collection of technologies used to stream Television over the Internet. Essentially, it's the protocols RTC/RTCP or RTSP for streaming the video & audio, and SAP/SDP to announce the streams, all operating over UDP multicast.

+

{{Wikipedia}}

+

'''IPTV''' is a name for a collection of technologies used to stream Television over the Internet. Essentially, it's the protocols RTC/RTCP or RTSP for streaming the video & audio, and SAP/SDP to announce the streams, all operating over UDP multicast.

** can not be recorded directly. Some can be remuxed by VideoLAN on demand into SPTS and fed into the backend.

+

* any other media streaming via IP Networks (basically stuff that does not fit into a MPEG2 SPTS, like ShoutcastTV)

+

** can not be recorded directly. Some can be transcoded by VideoLAN on demand into SPTS and fed into the backend.

+

+

Video (and Audio) on demand can be split similarly into

+

*DVB/MPEG conformant services

+

*Services that can be repackaged into DVB/MPEG (many podcasts)

+

*Services that are completely different (many video hosting sites)

+

**MythNews supports Youtube feeds.

== Emulation ==

== Emulation ==

−

Currently, there are a few implementations of SAP/SDP and RTP/RTCP that can be used to emulate being on an IPTV system. The most advanced version of this would be [http://www.videolan.org VideoLAN], which will take any kind of file it can open and will stream it over RTP/RTCP or RSTP (In version 8.3+), with automatic announcement over SAP/SDP.

+

Currently, there are a few implementations of SAP/SDP and RTP/RTCP that can be used to emulate being on an IPTV system. The most advanced version of this would be [http://www.videolan.org VideoLAN], which will take any kind of file it can open and will stream it over RTP/RTCP or RTSP (In version 8.3+), with automatic announcement over SAP/SDP.

A SAP announcement looks like this (Taken from the [http://www.faqs.org/rfc/rfc2974.txt RFC]):

+

A SAP announcement looks like this (Taken from the [http://www.faqs.org/rfcs/rfc2974.html RFC]):

<pre>

<pre>

0 1 2 3

0 1 2 3

Line 151:

Line 169:

== RTP/RTCP ==

== RTP/RTCP ==

[http://www.faqs.org/rfcs/rfc1889.html RTP/RTCP]

[http://www.faqs.org/rfcs/rfc1889.html RTP/RTCP]

−

== RSTP ==

+

== RTSP ==

−

[http://www.faqs.org/rfcs/rfc2326.html RSTP]

+

[http://www.faqs.org/rfcs/rfc2326.html RTSP]

+

+

{{Note box|The [[FreeBox]] patch that's in {{Ticket|1704}} uses RTSP to receive IPTV streams from an ADSL box. However, this version uses a PLS "Playlist" provided by the box to discover channels, not SDP/SAP, thereby still needing a STB to tune. If we can make a version that uses SDP/SAP Discovery, this requirement will not be needed, and the "Tuner" can be made into a more generic "IPTV tuner".}}

Revision as of 05:44, 12 August 2012

IPTV is a name for a collection of technologies used to stream Television over the Internet. Essentially, it's the protocols RTC/RTCP or RTSP for streaming the video & audio, and SAP/SDP to announce the streams, all operating over UDP multicast.

can not be recorded directly. Some can be remuxed by VideoLAN on demand into SPTS and fed into the backend.

any other media streaming via IP Networks (basically stuff that does not fit into a MPEG2 SPTS, like ShoutcastTV)

can not be recorded directly. Some can be transcoded by VideoLAN on demand into SPTS and fed into the backend.

Video (and Audio) on demand can be split similarly into

DVB/MPEG conformant services

Services that can be repackaged into DVB/MPEG (many podcasts)

Services that are completely different (many video hosting sites)

MythNews supports Youtube feeds.

Emulation

Currently, there are a few implementations of SAP/SDP and RTP/RTCP that can be used to emulate being on an IPTV system. The most advanced version of this would be VideoLAN, which will take any kind of file it can open and will stream it over RTP/RTCP or RTSP (In version 8.3+), with automatic announcement over SAP/SDP.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| V=1 |A|R|T|E|C| auth len | msg id hash |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
: originating source (32 or 128 bits) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| optional authentication data |
: .... :
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
| optional payload type |
+ +-+- - - - - - - - - -+
| |0| |
+ - - - - - - - - - - - - - - - - - - - - +-+ |
| |
: payload :
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V: Version Number. The version number field MUST be set to 1 (SAPv2
announcements which use only SAPv1 features are backwards
compatible, those which use new features can be detected by other
means, so the SAP version number doesn't need to change).
A: Address type. If the A bit is 0, the originating source field
contains a 32-bit IPv4 address. If the A bit is 1, the
originating source contains a 128-bit IPv6 address.
R: Reserved. SAP announcers MUST set this to 0, SAP listeners MUST
ignore the contents of this field.
T: Message Type. If the T field is set to 0 this is a session
announcement packet, if 1 this is a session deletion packet.
E: Encryption Bit. If the encryption bit is set to 1, the payload of
the SAP packet is encrypted. If this bit is 0 the packet is not
encrypted. See section 7 for details of the encryption process.
C: Compressed bit. If the compressed bit is set to 1, the payload is
compressed using the zlib compression algorithm [3]. If the
payload is to be compressed and encrypted, the compression MUST be
performed first.
Authentication Length. An 8 bit unsigned quantity giving the number
of 32 bit words following the main SAP header that contain
authentication data. If it is zero, no authentication header is
present.
Authentication data containing a digital signature of the packet,
with length as specified by the authentication length header
field. See section 8 for details of the authentication process.
Message Identifier Hash. A 16 bit quantity that, used in combination
with the originating source, provides a globally unique identifier
indicating the precise version of this announcement. The choice
of value for this field is not specified here, except that it MUST
be unique for each session announced by a particular SAP announcer
and it MUST be changed if the session description is modified (and
a session deletion message SHOULD be sent for the old version of
the session).
Earlier versions of SAP used a value of zero to mean that the hash
should be ignored and the payload should always be parsed. This
had the unfortunate side-effect that SAP announcers had to study
the payload data to determine how many unique sessions were being
advertised, making the calculation of the announcement interval
more complex that necessary. In order to decouple the session
announcement process from the contents of those announcements, SAP
announcers SHOULD NOT set the message identifier hash to zero.
SAP listeners MAY silently discard messages if the message
identifier hash is set to zero.
Originating Source. This gives the IP address of the original source
of the message. This is an IPv4 address if the A field is set to
zero, else it is an IPv6 address. The address is stored in
network byte order.
SAPv0 permitted the originating source to be zero if the message
identifier hash was also zero. This practise is no longer legal,
and SAP announcers SHOULD NOT set the originating source to zero.
SAP listeners MAY silently discard packets with the originating
source set to zero.

RTP/RTCP

RTSP

Note: The FreeBox patch that's in #1704 uses RTSP to receive IPTV streams from an ADSL box. However, this version uses a PLS "Playlist" provided by the box to discover channels, not SDP/SAP, thereby still needing a STB to tune. If we can make a version that uses SDP/SAP Discovery, this requirement will not be needed, and the "Tuner" can be made into a more generic "IPTV tuner".