MediaMVP Protocol

Ports Used

The Windows server listens to the following ports:

Protocol Port
Purpose
TCP
5906
Gui Protocol
TCP
6337
Media Protocol
UDP
16868
bootp
UDP
16869
tftp
UDP
16881
Service locator

The tftp and bootp protocols are perfectly standard, and can be found documented in the relevant RFCs.

Booting the MVP

The Mediamvp initially makes a bootp probe, this is sent out on two ports, port 67 (the traditional location) and port 16867. This permits the MVP to work even when a bootp server is not available on the network.

Following the bootp query, the mediamvp tftp's the file dongle.bin (which contains the linux kernel and a compressed ramdisk). After initialisation of the hardware, we move onto:

Finding the servers

The MediaMVP sends out a UDP broadcast message on port 16881, the message is 52 bytes long, the server responds with a 52 byte message with connection details. These messages obey the following message format:

Byte offsets
0
1
2
3
4
5
6
7
0
Unknown (0x0001) ID1 (0xbabe) ID2 (0xfafe)
8
Mac address Padding
16
Client IP address Client reply port Padding
24
GUI Server Address GUI Server Port Pad
32
Media Server Address Media Server Port Pad
40
Padding Remote console Address
48
Remote console port Padding

Example of client message:
0000 0001 babe fafe XXXX XXXX XXXX 0000 
c0a8 9b19 41f2 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000
Example of server message:
0000 0001 fafe babe 0000 0000 0000 0000 
c0a8 9b19 0800 0000 c0a8 9b25 16ae 0000
c0a8 9b25 18c1 0000 0000 0000 c0a8 9b25
41f6 0000
Note that ID1 and ID2 are swapped around in the server reply.

Note, it's unknown what purpose the remote console parameters serve.

GUI Protocol

The protocol used for the GUI is based on the RFB (VNC protocol). However, Hauppauge defined several new message types which are of interest to us.

RDC Media - message type 04: server to client

The seventh byte indicates the length of payload.

RDC_REQUEST - message type 0401

This message type is used to trigger a request for a media file by the MediaMVP.

Format (pre 21365):
0401 0000 0000 0000 XX00 [Path to filename]
Format (post 22012):
0401 0000 0000 0000 XX00 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 [Path to filename]

Where XX is the length of the filename.

Example (pre 21365):
0401 0000 0000 0000 0800 7465 7374 2E6D 7033

Is the trigger to request the file test.mp3.

RDC_PAUSE - (0402)

This message type is used to toggle pausing the current media on the MediaMVP.

Format (pre 21365):
0402 0000 0000 0000 0000
Format (post 22012):
0402 0000 0000 0000 0000 0000 0000 0000 
0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_STOP - (0403)

This message is used to stop playing media files.

Format (pre 21365):
0403 0000 0000 0000 0000
Format (post 22012):
0403 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_REWIND - (0404)

Format (pre 21365):
0404 0000 0000 0000 0000
Format (post 22012):
0404 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_FORWARD (0405)

Format (pre 21365):
0405 0000 0000 0000 0000
Format (pre 21365):
0405 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_VOLUP (0406)

Format (pre 21365):
0406 0000 0000 0000 0000
Format (post 22012):
0406 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_VOLDOWN (0407)

Format (pre 21365):
0407 0000 0000 0000 0000
Format (pre 21365):
0407 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_MENU (0408)

The display must be turned off in order for a video to be visible.

Turn menu off (pre 21365):
0408 0000 0000 0000 0200 0100
Turn menu off (post  222012):
0408 0000 0000 0000 0200 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0100
Turn menu on (pre 21365):
0408 0000 0000 0000 0200 0000
Turn menu on (post 22012):
0408 0000 0000 0000 0200 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_MUTE (0409)

This message will toggle mute on the client.

Format (pre 21365):
0409 0000 0000 0000 0000
Format (post 22012):
0409 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000 0000

RDC_SETTINGS (040A)

It's possible to send a temporary settings state to the client (using test settings), and thus change the TV mode between NTSC and PAL dependent on the format of the video you wish to play.

Get settings (pre 21365):
040A 0000 0000 0000 0C00 0000 0000 0000 0000 0000 0000
Get settings (post 22012):
040A 0000 0000 0000 0C00 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000
Get settings (post 23096?):
040A 0000 0000 0000 2000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000

NB. There are additional settings available here (undocumented at present) Test settings (pre 21365):
040A 0000 0000 0000 0C00 01TT PPFF AA00 0000 0000 0000
Test settings (post 22012):
040A 0000 0000 0000 0C00 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 01TT PPFF AA00 0000 0000 0000
Test settings (post 23096?):
040A 0000 0000 0000 2000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 01TT PPFF AA00 0000 0000 0000 SSSS
0000 MM00 0000 0000 0000 0000 0000 0000
0000

Cancel settings (pre 21365):
040A 0000 0000 0000 0C00 0200 0000 0000 0000 0000 0000
Cancel settings (post 22012):
040A 0000 0000 0000 0C00 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0200 0000 0000 0000 0000 0000
Cancel settings (post 23096?):
040A 0000 0000 0000 2000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0200 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000

Save settings (pre 21365):
040A 0000 0000 0000 0C00 03TT PPFF AA00 0000 0000 0000
Save settings (post 22012):
040A 0000 0000 0000 0C00 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 03TT PPFF AA00 0000 0000 0000
Save settings (post 23096?):
040A 0000 0000 0000 2000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 04TT PPFF AA00 0000 0000 0000 SSSS
0000 MM00 0000 0000 0000 0000 0000 0000
0000

Where TT is the TV mode and takes the following values:
Value
Meaning
00
NTSC
01
PAL

Where PP is the output mode and takes the following values:
Value
Meaning
00
RGB Detected
01
SVideo
02
Composite
03
RGB/Composite

Where FF is the flicker mode and takes the following values:
Value
Meaning
00
None
01
Low
02
Medium
03
High

Where AA is the aspect ratio and takes the following values:
Value
Meaning
00
4:3
01
16:9

Where SSSS is the screensaver timeout in milliseconds.

Where MM is the screensaver mode and takes the following values:
Value
Meaning
00
Disabled
01
Logo
02
Blank

RDC Ack - message type 7 (client to server)

Following the sending of message type 4, the client responds with message type 7 which is an acknowledgement for the initial message. This message obeys the same format as RDC_MEDIA, with the seventh byte indicating the payload length, the payload is only used for the reply to the settings command.

Ping Message - message type 08

This message is two bytes long and is sent by the MediaMVP to ensure that the server is still available. Failure to respond to this message will result in the connection being closed and attempts to reconnect to a server:

Client Message:
0800
Server Reply:
0800

Progress Message - message type 09 (client to server)

This 10 byte message appears to contain status information related to the position within the current media file.

Format (post 23096):
0409 ???? ???? ???? ????

Screen Encoding Types

The MediaMVP accepts a yuv surface as a screen update, there are several different formats, depending on the dongle version. All data blocks are zlib compressed. A rectangle encoding type is used, each rectangle has a header of the format:

Byte Offsets
0
1
2
3
4
5
6
7
0
Encoding Type
Length of compressed update
8
0
2

The compressed update follows. Multiple rectangles can be supplied in an update message, however the MediaMVP tends to have issues placing its on-screen-icons if a rectangle doesn't encompass the whole screen.

Encoding Type 7 (pre 22317)

The update consists of a compressed run of yuv. Each 4 uncompressed bytes represents two pixels:

Byte
0
1
2
3
Meaning
y1
v
u
y2

The u and v values are shared by the two pixels.

Encoding Type 8 (post 22317)

This encoding type supports sending an alpha channel. There appears to be a limitation on the amount of the display visible i.e. 480 lines from the top of the framebuffer. This effectively limits the resolution to around about 400 - 440 visible lines.

0000 0009 LLLL LLLL 0000 0002 compressed yvu data...
MMMM MMMM 0000 0002 compressed alpha data...

The yvu data is in the same format as per encoding type 7. Alpha values are available on a per pixel basis, and is the following format:
Byte
0
1
Meaning
a1
a2

Encoding Type 9 (post 22317)

In this encoding type, the y components are separated from the uv components, this achieves a better compression and hence improves the responsiveness. The format of this update is as follows.

0000 0009 LLLL LLLL 0000 0002 compressed y data
MMMM MMMM 0000 0002 compressed uv data

Where LLLL LLLL is the length of the compress y data, and MMMM MMMM is the length of the compressed uv data.

The y data is as follows:
Byte
0
1
Meaning
y1
y2

The uv data is as follows:
Byte
0
1
Meaning
v
u
Once more, the uv value is shared between two pixels.

Key Codes

Key presses from the remote control are sent back using the standard RFB key message, the codes transmitted map onto the remote keys as follows:


Code
Remote Key (original)
Remote Key (new)
0x01
0
0
0x02
1
1
0x03
2
2
0x04
3
3
0x05
4
4
0x06
5
5
0x07
6
6
0x08
7
7
0x09
8
8
0x0a
9
9
0x0d
OK
OK
0x0e
Rewind
Rewind
0x0f
Forward
Forward
0x10
Vol-
Left
0x11
Vol+
Right
0x12
Ch+
Up
0x13
Ch-
Down
0x14
Power
Power
0x15
Mute
Mute
0x19
Play
Play
0x1a
Record
Record
0x1b
Stop
Stop
0x1c
Pause
Pause
0x1e
Menu
Menu
0x20
Back
Back
0x23
Go
Go
0x24
Red
Red
0x25
Green
Green
0x26
Yellow
Yellow
0x27
Blue
Blue
0x28
Blank
Blank
0x29
Full
Full
0x2a
Replay
Replay
0x2b
Skip
Skip
0x2c
-
TV
0x2d
-
Videos
0x2e
-
Music
0x2f
-
Pictures
0x30
-
Radio
0x31
-
Vol+
0x32
-
Vol-
0x33
-
Ch+
0x34
-
Ch-
0x35
-
PrevCh
0x36
-
*
0x37
-
Subtitles

Media Protocol

The MediaMVP expects to all of these message types, typically bouncing back the same message will satisfy it.

Byte ordering

All 16 and 32 bit numbers are sent in network byte order (MSB first). 64 bit numbers are split into two 32 bit words with the least significant word placed first. Thus given the 64 bit number 0x0102030405060708, the serialised bytes would be 0506070801020304

Open Media - message type 02

Request (pre 21365):
0200 0000 0000 0000  0000 0000 0000 0000
0000 0000 xxxx 0000 [nul terminated filename follows]
Request (post 21365):
0200 0000 0000 0000  0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 xxxx 0000 [nul terminated filename follows]
Where xxxx is the length of the filename.

The client then expects a response:

Response (pre 21365) - successful open of video file:
0200 0000 0100 FF00  wwww hhhh 0000 bbbb
0000 iiii xxxx 0000
Response (post 21365) - successful open of video file:
0200 0000 0100 FF00  wwww hhhh 0000 bbbb
llll llll llll llll rrrr rrrr rrrr rrrr
0000 iiii xxxx 0000
Response (pre 21365) - successful open of audio file:
0200 0000 0200 0000  0000 0000 0000 0000
0000 iiii xxxx 0000
Response (post 21365) - succesful open of video file:
0200 0000 0200 0000  0000 0000 0000 0000
llll llll 0000 0000 0000 0000 0000 0000
0000 iiii xxxx 0000
Response (pre 21365) - unsuccessful open of a file:
0200 0000 0000 0000  0000 00000 0000 0000
0000 0000 xxxx 0000
Response (post 21365) - unsuccessful open of a file:
0200 0000 0000 0000  0000 00000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 xxxx 0000
Where wwww is the horizontal size of the video, hhhh is the vertical size of the video, bbbb is the rate of the video, llll llll llll llll is the size of the video file (a 64 bit number with the lowest 32 bits in network order placed first, and the highest following), rrrr rrrr rrrr rrrr is the resume position and iiii is the file id (an incrementing counter for each request works well).

Stop Media - message type 03

Request (pre 21365):
0300 0000 0000 iiii  0000 0000 0000 0000
0000 0000 0000 0000
Request (post 21365):
0200 0000 0000 iiii  0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000

Request Block - message type 04

Request (pre 21365):
0400 0000 0000 iiii  llll llll 0000 0000
0000 0000 0000 0000
Request (post 21365):
0400 0000 0000 iiii  llll llll 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
Where llll llll is the maximum block length to return.

Response (pre21365):
0400 0000 0000 iiii  llll llll nnnn nnnn
0000 0000 0000 0000 [media data follows]
Response (post 21365):
0400 0000 0000 iiii  llll llll nnnn nnnn
nnnn nnnn 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000 [media data follows]
Where llll llll is the length of the block (if llll llll is 0, then the file has ended) and nnnn nnnn nnnn nnnn is the offset within the file.

Step - message type 05

This message requests the server to step forwards/back an I-frame in the media stream. The server may of course interpret the step as being of more than one I-frame!

Request (pre 21365):
0500 0000 0000 iiii  00dd 0000 0000 0000
0000 0000 0000 0000
Request (post 21365):
0500 0000 0000 iiii  00dd 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
Where dd is the direction is the direction (00 = backwards, 01 = forwards)

Response (pre 21365):
0500 0000 0000 iiii  00dd 0000 llll llll
nnnn nnnn 0000 0000 [stream data follows]
Response (post 21365):
0500 0000 0000 iiii  00dd 0000 llll llll
nnnn nnnn nnnn nnnn 0000 0000 0000 0000
0000 0000 0000 0000 [stream data follows]
Where llll llll is the length of the following data and nnnn nnnn nnnn nnnn is the offset within the file.

???? - Message type 06

This message type has never been seen!

Media Seek - Message type 07

Request (pre 21365):
0700 0000 0000 iiii  ssss ssss 0000 0000
0000 0000 0000 0000
Request (post 21365):
0700 0000 0000 iiii  ssss ssss ssss ssss
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
Where ssss ssss (ssss ssss) is the desired position within the file.

Request (pre 21365):
0700 0000 0000 iiii  ssss ssss 0000 0000
0000 0000 0000 0000
Request (post 21365):
0700 0000 0000 iiii  ssss ssss ssss ssss
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000
Where ssss ssss (ssss ssss) is the actual position within the file.

Media ???? - Message type 8

I'm not too certain what purpose this message serves. It is sent prior to the the request for the file being made. Bouncing the message back to the MediaMVP keeps it happy.

Request (post 21317):
0800 0000 0000 0000  0000 0000 0000 0000
0000 0000 0000 0000
Request (post 21365):
0800 0000 0000 0000  0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000

Response (post 21317):
0800 0000 0000 0000  0000 0000 0000 0000
0000 0000 0000 0000
Response (post 21365):
0800 0000 0000 0000  0000 0000 0000 0000
0000 0000 0000 0000 0000 0000 0000 0000
0000 0000 0000 0000

The End

This should describe fully the protocol as used by all Hauppauge versions of dongle.bin to date (last inspected version was 23104). If you have any questions, corrections or any more information then don't hesitate to mail me!

Changes


16/1/2008 dom / at/ suborbital /dot/ org /dot/ uk