Project

General

Profile

Htsp » History » Version 57

sbi -, 2010-12-19 18:39

1 54 Andreas Smas
[[PageOutline]]
2 17 Andreas Smas
= Home Tv Streaming Protocol (HTSP) =
3 1 Andreas Smas
4 17 Andreas Smas
== General ==
5 1 Andreas Smas
6 17 Andreas Smas
HTSP is a TCP based protocol primarily intended for streaming of live TV and related meta data such as channels, group of channels (called tags in HTSP) and electronic program guide (EPG) information.
7 1 Andreas Smas
8 17 Andreas Smas
The transmission and reception of a channel over HTSP is referred to a subscription. A single HTSP session can handle as many concurrent subscriptions as the bandwidth and CPU permits.
9 1 Andreas Smas
10
11 17 Andreas Smas
The HTSP server in tvheadend has a payload-aware scheduler for prioritizing more important packets (such as I-frames) before less important ones (such as B-frames). This makes HTSP is suitable for long-distance transmissions and/or paths with non-perfect delivery.
12
(It has been tested with a server in Stockholm and the client in Berlin).
13
14 56 Andreas Smas
For information about the HTSP wire format please read [wiki:htsmsgbinary HTSMSG binary format]
15
16 52 magnus -
The HTS Showtime client can be found [http://trac.lonelycoder.com/hts/browser/trunk/showtime/src/backend/htsp/htsp.c here].
17 22 Andreas Smas
18 18 Andreas Smas
----
19 17 Andreas Smas
== Communication ==
20
21 23 Andreas Smas
This communication is currently implemented by using htsmsg:s. All strings are encoded as UTF-8.
22
23 17 Andreas Smas
There are two distinct ways for communication within HTSP.
24
25 28 Andreas Smas
Apart from this there is a number of messages that needs to be exchanged during login, see the login section below.
26
27 17 Andreas Smas
=== RPC communication ===
28 1 Andreas Smas
29 18 Andreas Smas
There is a normal RPC way of doing things. I.e. the client sends a request and the server responds with a reply. All the RPC methods are listed below as the 'Client to Server' methods. Apart from all message fields listed within each message type the client can add an additional field:
30
31
RPC request extra fields:
32 17 Andreas Smas
{{{
33 1 Andreas Smas
seq              int  optional   Sequence number. This field will be echoed back by the server in the reply.
34 28 Andreas Smas
username         str  optional   Username, in combination with 'digest' this can be used to raise the privileges
35
                                 for the session in combination with invocation of a method. 
36
digest           bin  optional   Used to raise privileges.
37 1 Andreas Smas
}}}
38 28 Andreas Smas
39
The followings field should be used by the client to match the reply with the request.
40 18 Andreas Smas
All replies are guaranteed to arrive in the same order as the requests.
41
Even so, probably the best way to implement the request-reply client is by taking advantage of the 'seq' field.
42 1 Andreas Smas
43 18 Andreas Smas
RPC reply extra fields:
44
{{{
45 19 Andreas Smas
seq              int  optional   Sequence number. Same as in the request.
46
error            str  optional   If present an error has occurred and the text describes the error.
47 18 Andreas Smas
noaccess         int  optional   If present and set to '1' the user is prohibited from invoking the method due to 
48 19 Andreas Smas
                                 access restrictions. 
49 18 Andreas Smas
}}}
50 1 Andreas Smas
51 18 Andreas Smas
=== Streaming communication ===
52 19 Andreas Smas
53 1 Andreas Smas
For streaming of live TV and various related messages the server will continuously push data to the client.
54
These messages are referred to as asynchronous messages and always have the 'method' field set and never have the 'seq' field set.
55
Also, the client can enable an additional asyncMetadata mode and by doing so it will be notified by the server when meta data changes. (EPG updates, creation of channels and tags, etc). 
56
57
=== Authentication ===
58
59 34 Andreas Smas
In Tvheadend, each method has an associated access restriction. Currently there is only one restriction (Streaming). However, this may change in the future.
60 29 Andreas Smas
61 1 Andreas Smas
Privileges for these restrictions may be granted in two ways: Username + Password and/or Source IP address.
62 29 Andreas Smas
Therefore it is possible to gain permissions to the system without entering a username and password.
63 7 Andreas Smas
While this is really useful it also complicates the authentication schema a bit.
64 29 Andreas Smas
Upon connect the initial privileges will be raised based on the source address.
65 1 Andreas Smas
66 34 Andreas Smas
Before any username / password based authentication has taken place the client must have
67
obtained a challenge (which stays fixed for the session). This is done via the 'hello' method.
68
69 1 Andreas Smas
In principle it's possible to use two different authentication idioms with HTSP.
70
Depending on how your application works one or another may be more suitable.
71
While they do not really differ from a protocol point of view it's worth mentioning a bit about them here:
72
73
=== Initial login authentication ===
74
75
The client performs all of its authentication using the 'login' method.
76
77
It may choose to send:
78
 * Username and password: Privileges will be raised based on these credentials.
79
 * Username only: Privileges will be based on just the source address. The username will be used for various logging purposes.
80
 * Nothing: Privileges will be based on just the source address.
81
82
If no privileges are granted after the login message has been received by the server (i.e. both network and username + password based)
83
the server will reply with 'noaccess' set to 1. A client that only employs initial login should honor this flag and ask the
84
user for a username + password and retry by using the 'authenticate' method. I.e. it should not send the 'login' method again.
85
86
=== On-demand authentication ===
87
88
The client performs all of its authentication when it needs to.
89
90
When using this method, the client will check every RPC reply for the 'noaccess' field.
91
If it set to 1 it whould ask the user for username + password and retry the request but also
92
add 'username' and 'digest' to the original message. (See ''RPC request extra fields'' above)
93
94
Typically it would not send a username or digest during login.
95 29 Andreas Smas
96
----
97
= Client to Server (RPC) methods =
98 34 Andreas Smas
99
100
101
----
102
=== hello ===
103
104
Used to identify the client toward the server and to get the session challenge used to
105
hash passwords into digests. The client can request a different version of the HTSP
106
protocol with this method. If no 'hello' message is sent the server assumes version 1
107
is to be used.
108
109
110
Request message fields:
111
{{{
112
htspversion      int  required   Client preferred HTSP version. If the server does not support this version
113
                                 it will respond with an error and also set the 'invalidversion' field in the reply. 
114
clientname       str  required   Client software name.
115
clientversion    str  required   Client software version.
116
}}}
117
118
119
Reply message fields:
120
{{{
121
htspversion      int  required   The server supports all versions of the protocol up to and including this number.
122
servername       str  required   Server software name.
123
serverversion    str  required   Server software version.
124
challenge        bin  required   32 bytes randomized data used to generate authentication digests
125
invalidversion   int  optional   If set, this means that the server does not understand the requested version.
126
                                 The 'error' field is also set to indicate an error.
127
}}}
128 33 Andreas Smas
129
130
----
131
=== authenticate ===
132
133
This can be used to issue authentication without doing anything else.
134
If no privileges are gained it will return with 'noaccess' set to 1.
135
136
Request message fields:
137
{{{
138
None
139
}}}
140
141
Reply message fields:
142
{{{
143
None
144
}}}
145 10 Andreas Smas
146
----
147
=== enableAsyncMetadata ===
148
149
When this is enabled the client will get continuous updates from the server about channels and tags.
150
This also includes creation and deletion of channels and tags. 
151
152
An interactive application that presents the user with information about channels and tags would probably want to switch to this mode.
153
154
155
Request message fields:
156
{{{
157
None
158
}}}
159
160 1 Andreas Smas
Reply message fields:
161 5 Andreas Smas
{{{
162 1 Andreas Smas
None
163 6 Andreas Smas
}}}
164 23 Andreas Smas
165
166
167
----
168
=== getEvent ===
169
170
Request information about the given event. An event typically corresponds to a program on a channel.
171
172
Request message fields:
173
{{{
174
eventId          int  required   Event ID.
175
}}}
176
177
Reply message fields:
178
{{{
179
start            int  required   Start time of event (Seconds since the epoch, in UTC)
180 6 Andreas Smas
stop             int  required   Ending time of event (Seconds since the epoch, in UTC)
181 47 mdd -
title            str  optional   Title of event.
182
description      str  optional   Description of event. This can be quite huge and may also contain newlines.
183 1 Andreas Smas
channelId        int  required   ID of channel (introduced in HTSP version 4)
184 43 mdd -
nextEventId      int  optional   ID of next event on the same channel.
185 49 mdd -
contentType      int  optional   dvb content code (introduced in HTSP version 4)
186 25 Andreas Smas
}}}
187 1 Andreas Smas
188
----
189 44 mdd -
=== getEvents ===
190
191
Introduced in HTSP version 4.
192
193
Request information about numFollowing events, starting with the given event
194
195
Request message fields:
196
{{{
197
eventId          int   required   Event ID.
198 45 mdd -
numFollowing     int   required   Number of events to add
199 44 mdd -
}}}
200
201
Reply message fields:
202 1 Andreas Smas
{{{
203 45 mdd -
events           msg[] required   List of events, using response message fields from getEvent
204
}}}
205
206
----
207
=== addDvrEntry ===
208
209
Introduced in HTSP version 4.
210
211
Adds an dvr entry for the given eventId.
212
213
Request message fields:
214
{{{
215
eventId          int   required   Event ID.
216 57 sbi -
configName       str   optional   dvr configuration name
217 45 mdd -
}}}
218
219
Reply message fields:
220
{{{
221
success          int   required   1 if entry was added, 0 otherwise
222
error            str   optional   English clear text of error message
223
}}}
224
225
----
226
=== deleteDvrEntry ===
227
228
Introduced in HTSP version 4.
229
230
Delete a dvr entry with the given id.
231
232
Request message fields:
233
{{{
234
dvrEntryId       int   required   dvrEnryId to delete
235
}}}
236
237
Reply message fields:
238
{{{
239
success          int   required   1 if entry was removed
240 44 mdd -
}}}
241
242
----
243 46 mdd -
=== epgQuery ===
244
245
Introduced in HTSP version 4.
246
247
query the epg, optionally restrict to channels/tags/dvb content type
248
249
Request message fields:
250
{{{
251
query            str   required  String to query epg for
252
channelId        int   optional  ChannelId to restrict search to
253
tagId            int   optional  TagId to restrict search to
254
contentType      int   optional  Dvb epg content type to restrict search to
255
}}}
256
257
Reply message fields:
258
{{{
259
eventIds         int[] optional  List of eventIds that match the query
260
}}}
261
262
----
263 8 Andreas Smas
=== subscribe ===
264
265
Request subscription to the given channel. 
266 1 Andreas Smas
267 6 Andreas Smas
Request message fields:
268
{{{
269
channelId        int  required   ID for channel. 
270
subscriptionId   int  required   Subscription ID. Selected by client. This value is not interpreted by the server in any form. 
271 4 Andreas Smas
                                 The value is used from now on in all messages related to the subscription.
272 6 Andreas Smas
}}}
273 5 Andreas Smas
274 1 Andreas Smas
Reply message fields:
275 5 Andreas Smas
{{{
276 1 Andreas Smas
None.
277 5 Andreas Smas
}}}
278
279 1 Andreas Smas
280
----
281 6 Andreas Smas
=== unsubscribe ===
282
283
Stop a subscription.
284
Attributes
285 2 Andreas Smas
{{{
286
subscriptionId   int  required   Subscription ID.
287
}}}
288
289
Reply message fields:
290
{{{
291 12 Andreas Smas
None.
292 2 Andreas Smas
}}}
293 1 Andreas Smas
294 40 Andreas Smas
----
295
=== getDiskSpace ===
296
297
Introduced in HTSP version 3.
298
299
Return diskspace status from Tvheadend's PVR storage
300
Attributes
301
{{{
302
}}}
303
304
Reply message fields:
305
{{{
306
freediskspace   int  required   Bytes available.
307
totaldiskspace  int  required   Total capacity.
308
}}}
309
310
----
311
=== getSysTime ===
312
313
Introduced in HTSP version 3.
314
315
Return system time on server
316
Attributes
317
{{{
318
}}}
319
320
Reply message fields:
321
{{{
322
time            int  required   Seconds since the unix epoch.
323
timezone        int  required   Minutes west of GMT.
324
}}}
325 11 Andreas Smas
326
----
327
328
= Server to Client methods =
329
330
----
331
=== channelAdd ===
332
333 13 Andreas Smas
A new channel has been created on the server.
334 11 Andreas Smas
335
Message fields:
336 12 Andreas Smas
{{{
337 1 Andreas Smas
channelId        int   required   ID of channel.
338
channelName      str   required   Name of channel.
339 42 Andreas Smas
channelNumber    int   required   Channel number. 0 means unconfigured
340 11 Andreas Smas
channelIcon      str   required   URL to an icon representative for the channel.
341
eventId          int   optional   ID of the current (or next to be) event on this channel.
342 1 Andreas Smas
tags             int[] optional   Tags this channel is mapped to.
343 11 Andreas Smas
}}}
344
345
----
346
=== channelUpdate ===
347
348 41 Andreas Smas
A channel has been updated on the server. If a field is not present it has not changed. Most clients can process this and the 'channelAdd' message
349 11 Andreas Smas
with the very same code.
350
351 13 Andreas Smas
Message fields:
352 12 Andreas Smas
{{{
353 3 Andreas Smas
channelId        int   required   ID of channel.
354 41 Andreas Smas
channelName      str   optional   Name of channel.
355 42 Andreas Smas
channelNumber    int   optional   Channel number. 0 means unconfigured
356 11 Andreas Smas
channelIcon      str   optioanl   URL to an icon representative for the channel.
357 1 Andreas Smas
eventId          int   optional   ID of the current (or next to be) event on this channel.
358 11 Andreas Smas
tags             int[] required   Tags this channel is mapped to.
359
}}}
360
361
----
362
=== channelDelete ===
363
364
A channel has been deleted on the server.
365 12 Andreas Smas
366 11 Andreas Smas
This message is only sent if session is in asynchronous mode.
367 1 Andreas Smas
368 11 Andreas Smas
Message fields:
369
{{{
370
channelId        int   required   ID of channel.
371
}}}
372 13 Andreas Smas
373 11 Andreas Smas
----
374
=== tagAdd ===
375
376
A new tag has been created on the server.
377
378 1 Andreas Smas
Message fields:
379 11 Andreas Smas
{{{
380 1 Andreas Smas
tagId            int   required   ID of tag.
381 11 Andreas Smas
tagName          str   required   Name of tag.
382
tagIcon          str   optional   URL to an icon representative for the channel.
383 39 elupus -
members          int[] required   Channels this tag is mapped to.
384 11 Andreas Smas
}}}
385 13 Andreas Smas
386 11 Andreas Smas
----
387
=== tagUpdate ===
388
389
A tag has been updated on the server.
390
391 12 Andreas Smas
Message fields:
392 1 Andreas Smas
{{{
393
tagId            int   required   ID of tag.
394 11 Andreas Smas
tagName          str   required   Name of tag.
395
tagIcon          str   optional   URL to an icon representative for the channel.
396 39 elupus -
members          int[] required   Channels this tag is mapped to.
397 1 Andreas Smas
}}}
398 11 Andreas Smas
399
----
400 1 Andreas Smas
=== tagDelete ===
401 11 Andreas Smas
402
A tag has been deleted from the server.
403 12 Andreas Smas
404 11 Andreas Smas
Message fields:
405 2 Andreas Smas
{{{
406 14 Andreas Smas
tagId            str   required   ID of tag.
407
}}}
408
409
----
410 48 mdd -
=== dvrEntryAdd ===
411
412
A new recording has been created on the server.
413
414
Added in HTSP version 4.
415
416
Message fields:
417
{{{
418
id               int   required   ID of dvrEntry.
419
channel          int   required   Channel of dvrEntry.
420 51 elupus -
start            int   required   Time of when this entry was scheduled to start recording.
421
stop             int   required   Time of when this entry was scheduled to stop recording.
422 48 mdd -
title            str   optional   Title of recording
423
description      str   optional   Description of recording. This can be quite huge and may also contain newlines.
424
state            str   required   Plain english status of recoding {scheduled, recording, completed, invalid}.
425
error            str   optional   Plain english error description (e.g. "Aborted by user").
426
}}}
427
428
----
429
=== dvrEntryUpdate ===
430
431
A recording has been updated on the server
432
433
Added in HTSP version 4.
434
435
Message fields:
436
{{{
437
id               int   required   ID of dvrEntry.
438
channel          int   required   Channel of dvrEntry.
439 51 elupus -
start            int   required   Time of when this entry was scheduled to start recording.
440
stop             int   required   Time of when this entry was scheduled to stop recording.
441 48 mdd -
title            str   optional   Title of recording
442
description      str   optional   Description of recording. This can be quite huge and may also contain newlines.
443
state            str   required   Plain english status of recoding {scheduled, recording, completed, invalid}.
444
error            str   optional   Plain english error description (e.g. "Aborted by user").
445
}}}
446
447
----
448
=== dvrEntryDelete ===
449
450
A recording has been deleted from the server.
451
452
Added in HTSP version 4.
453
454
Message fields:
455
{{{
456
id               int   required   ID of recording to delete.
457
}}}
458
459
----
460 35 Andreas Smas
=== initialSyncCompleted ===
461
462
Sent after all the initial channel and tag messages has been sent when session has been set to async mode.
463
464
Added in HTSP version 2.
465
466
Message fields:
467
{{{
468
}}}
469
470
----
471 14 Andreas Smas
=== subscriptionStart ===
472
473
Message fields:
474
{{{
475
subscriptionId   int   required   Subscription ID.
476
streams          msg[] required   Array of messages with stream information
477 38 Andreas Smas
sourceinfo       msg   optional   Message with strings in it. Each string is a descriptive
478
                                  entity about the source. All strings are optional any should
479
                                  only be thought of as informational.
480 14 Andreas Smas
481
'streams' message:
482
483
index            int   required   Index for this stream
484
type             str   required   Type of stream
485
language         str   optional   Language for stream
486 53 Andreas Smas
width            int   optional   Width of video in pixels (Video components only)
487
height           int   optional   Height of video in pixels (Video components only)
488 14 Andreas Smas
489
490 1 Andreas Smas
Stream types:
491 14 Andreas Smas
    AC3                           AC3 audio
492
    MPEG2AUDIO                    MPEG2 audio (MP2)
493 21 Andreas Smas
    MPEG2VIDEO                    MPEG2 video
494 12 Andreas Smas
    H264                          H264 video
495 37 Andreas Smas
    AAC                           ADTS framed AAC (one AAC packet per ADTS frame)
496 15 Andreas Smas
}}}
497
498
499
----
500
=== subscriptionStop ===
501
502 12 Andreas Smas
Message fields:
503 2 Andreas Smas
{{{
504
subscriptionId   int   required   Subscription ID.
505 15 Andreas Smas
reason           str   optional   Reason for subscription stop.
506
}}}
507
508
----
509
=== subscriptionStatus ===
510
511
Message fields:
512 1 Andreas Smas
{{{
513 2 Andreas Smas
subscriptionId   int   required   Subscription ID.
514 37 Andreas Smas
status           str   optional   English clear text of error status. Absence of this field means that the status is OK. 
515 15 Andreas Smas
}}}
516
517
518
----
519
=== queueStatus ===
520
521
The queueStatus message is sent every second during normal data delivery.
522
523
The transmit scheduler have different drop thresholds for different frame types.
524
If congestion occurs it will favor dropping B-frames before P-frames before I-frames.
525
All audio is recognized as I-frames. 
526
527
Message fields:
528
{{{
529
subscriptionId   int   required   Subscription ID.
530
packets          int   required   Number of data packets in queue.
531 16 Andreas Smas
bytes            int   required   Number of bytes in queue.
532
delay            int   required   Estimated delay of queue (in µs)
533
Bdrops           int   required   Number of B-frames dropped
534
Pdrops           int   required   Number of P-frames dropped
535
Idrops           int   required   Number of I-frames dropped
536
}}}
537
538
----
539 55 Lars Op den Kamp -
=== signalStatus ===
540
541
The signalStatus message is sent every second during normal data delivery.
542
543
The optional fields may not have been implemented or may not be supported by the active adapter.
544
545
Message fields:
546
{{{
547
subscriptionId   int   required   Subscription ID.
548
feStatus         str   required   Frontend status.
549
feSNR            int   optional   Signal to noise ratio.
550
feSignal         int   optional   Signal status percentage.
551
feBER            int   optional   Bit error rate.
552
feUNC            int   optional   Uncorrected blocks.
553
}}}
554
555
----
556 16 Andreas Smas
=== muxpkt ===
557
558
Streaming data.
559
560
Message fields:
561
{{{
562
subscriptionId   int   required   Subscription ID.
563
frametype        int   required   Type of frame as ASCII value: 'I', 'P', 'B'
564
stream           int   required   Stream index. Corresponds to the streams reported in the subscriptionStart message.
565 1 Andreas Smas
dts              int   required   Decode Time Stamp in µs.
566
pts              int   required   Presentation Time Stamp in µs.
567
duration         int   required   Duration of frame in µs.
568
payload          bin   required   Actual frame data.
569
570
}}}