HD Video & Still Transmission

GLXP Requirements

This is a summarisation of the rules by LeeBegg, see the actual rules on the GLXP site.

All requirements are after processing.

Stills

• Clearly show what they are meant to show
• >= 8 bit/colour
• SNR 50:1 at albedo approximately equal to 0.1
• =< 0.3 milliradians/pixel (0.017 degrees) - the earth will be about 100 pixels wide
• In colour and colour corrected
• "Reasonable" illumination and contrast
• In "Detail" images all logos clearly ledgable

Video

• Clearly show what they are meant to show
• Must show dynamic content (movement, camera changes)
• Framerate appropriate for action (smooth motion)
• In colour and colour corrected
• Near real-time (NRT) video
  • High priority communication, early as possible
  • At least 320x240
• HD Video
  • 1280 x 720 progressive scan (720p)
• HD and NRT videos can be the same transmission, as long as all requirements are met
• HD must arrive before the end of the mission

Arrival Mooncast

• Detailed content plan required 180 days before launch for GLXP
• Show arrival/initial exploration of the surface
• 8 minutes of video (same videos in NRT and HD)
• Panoramic photo(s) 360 degrees, at least 60 degree vertical view (centred near horizon)
• At least one recognisable "Detail" self-portrait of the craft and any secondary vehicle(s)
• "Detail" images of logo cluster and GLXP payload
• Pre-recorded video (with audio), email and text messages by GLXP (total 10MB)

Completion Mooncast

• Detailed content plan required 180 days before launch for GLXP
• Show exploration and completion of GLXP requirements
• 8 minutes of video (same videos in NRT and HD) including some when vehicle is in motion
• Panoramic photo(s) 360 degrees, at least 60 degree vertical view (centred near horizon), at the end of 500m
• At least one recognisable "Detail" self-portrait of the craft and any secondary vehicle visible
• "Detail" images of logo cluster and GLXP payload

Round Trip Data

• Approx 10MB data to be sent from earth to craft and back

Communications requirements

• All GLXP data must be encrypted and decryption keys given to GLXP

Capture Size and Raw Data size

Images

• Panorama (min, no overlap): 21176x3529, 224190312 bytes (213MB)
• Detail pictures: Depend on distance from logos, size of logos, etc

Video

• 8 minutes of video
  • Each frame: 1280x720, 2764800 bytes (2MB)
  • NRT: 320x240, 230400 bytes (225KB)
  • Frame rate: variable, dependent on speed of rover/camera movement and distance (and angle) from moving items

Other data

• Prerecorded media: 10MB
• Round Trip media: 10MB

GLXP as indicated that the total mooncast size should be around 500MB (total 1GB).

Possible Hardware

• BeagleBoard
• Surveyor camera (based on Blackfin processor)

Approach

There are two components to this problem. One is the capture of the images/video. The other is how to get them to earth.

For the first part, it is suggested that we use JPEG2000. It is a high quality compression format with some neat properties, such as many progressive transmit/display modes (low quality first or low resolution first, for example). There is also a related video format called Motion JPEG2000. This allows one capture and storage format, which is relatively fast and light. The NRT video can be culled directly from the higher quality version without decompression and recompression.

The second part requires data management and protocol/communications systems. This is usually performed by the IHU, Integrated Housekeeping Unit - the main computer of the space craft. Being able to full utilise the communications bandwidth and have high priority information be not subject to high latency requires priority queuing and other protocol features.

Sending video

Since video is a series of frames, a failure in one frame doesn't affect the next in Motion JPEG2000 and will quickly be replaced by the next frame. For the full quality video, it should be drip feed down, and any frames with errors are requested again and are send when bandwidth allows. This is similar to TCP, but retransmissions are lower priority and do not change the rate of transmission. A mechanism similar to rsync or Bit torrent can be used to detect errors and trigger the retransmissions. Good communications protocols and encoding will lower the rate of errors.

(Draft) Component diagram for the IHU:

Plan

The plan calls for two streams of work which eventually merge.

Video Processing

• Research JPEG2000 and MJPEG2000 standards - A few minor changes to the final committee draft have been noted.
• Develop Proof of Concept (POC) culling program - Done for jp2 files with SOP markers http://github.com/llnz/poc_decimator/tree/master
• Analyse performance of POC program
• Investigate/develop/test asynchronous tasklet-like processing outside of IHU
• Develop culling tasklet

IHU

• Identify major common functional blocks
• Design interfaces for the functional blocks
• Develop Linux architecture support (mainly for testing)
• Develop core functional blocks
• Develop sample tasklets and applications
• Develop ARM architecture support (or likely flight platform)