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:
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:
The uv data is as follows:
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 - Corrected settings length for protocol versions >= 23096.
Correct typo in message 08 reply >= 21365
16/1/2008 dom / at/ suborbital
/dot/ org /dot/ uk