Acorn Replay

Who owns the sources to the Acorn Replay video system?

I was asking because A/V media support might be of use in the mobile platforms RISC OS OPEN is being ported to.

Who owns the sources to the Acorn Replay video system?

A twenty second google shows it’s heavily related to Paul Middleton/Uniqueway.

So it would seem :(

So if RISC OS Open can’t use Replay, what media frameworks can it reasonably use? (Noting that Theora and Dirac are both unencumbered)

So if RISC OS Open can’t use Replay, what media frameworks can it reasonably use? (Noting that Theora and Dirac are both unencumbered)

Anything you can find sources for, in principle. But that’s assuming RISC OS hardware will be fast enough for it, which it probably won’t be.

But this is the wrong question – what is the specific goal here, other than the very general “A/V on mobile”, what are some examples?

Sources for an ARM-based fast media player…

http://picard.exceed.hu/tcpmp/test/

This runs on Windows mobile, but as the windows mobile API is so simple, it should be a good template. Supports lots of different media formats too!

Yes, I used this player on my hacked GPS to play movies. But it doesn’t really solve anything by itself – it relies for example on ffmpeg, vorbis, etc which already exist in some form for RISC OS. None of this voids the problem of needing considerable CPU for playback of more modern codecs, or even support for them, since development of TCPMP stopped in 2006.

It would be interesting to see how Robin Watts’ latest effort of hand-optimized ARM assembler performs on an A9 or IYONIX (or an emulator on a fast x86 PC).

See here for his Ogg Theora lib: http://wss.co.uk/pinknoise/theorarm/

The YUV2RGB part would certainly be valuable for many other video decoders.

A twenty second google shows it’s heavily related to Paul Middleton/Uniqueway

Yes and no. The Replay system incorporates a large amount of software. We audited it at Pace, and many third parties were involved in its development:

• Computer Concepts
• Eidos
• ESP
• IMS
• Iota
• Pederson
• Uniqueway
• WSS

However, the list of companies involved in the core technologies that are needed to play back video and audio is much shorter, and as a result ROOL hasn’t ruled out a future release of these parts of the source code.

For the record, Uniqueway’s main contributions are the ARPlayer/AREncode front-ends. These would be a loss, but there’s at least one other player front end available, and the encoding APIs would still be available if anyone seriously still wants to encode video/audio on RISC OS.

I’ve had ARPlayer (as supplied with my Iyonix) working on my Beagle Board, so it may be possible to run it without modification. This still leaves the distribution rights, of course.

What is the current status of Replay 3? I remember that from the Clan beta CD but I don’t recall any sort of formal release. Or was that the front end mentioned above?

Personally, I’d rather see one of the more widely-used standards such as MPEG 4 or H.264 come to RISC OS (as other people seem to be suggesting above). XScale-based PDAs seem to cope with DivX at least, so what is holding back something like the Iyonix? Is it simply a limitation of RISC OS?

Personally, I’d rather see one of the more widely-used standards such as MPEG 4 or H.264 come to RISC OS (as other people seem to be suggesting above). XScale-based PDAs seem to cope with DivX at least, so what is holding back something like the Iyonix? Is it simply a limitation of RISC OS?

There’s no reason why you can’t port an MPEG 4 or H.264 codec to RISC OS. But there would be both hardware and software limitations that would stop you from getting it working well. In terms of software limitations, you’ve got to deal with the lack of non-blocking file I/O in RISC OS, which could eat up valuable CPU time. And since we don’t have any real documentation for the nVidia grahpics cards there’s no way that a video player would be able to make use of the hardware YUV overlay, or any of the other video decoding hardware that may be present. An XScale PDA or personal media player would typically have access to all of the above software/hardware features.

In terms of hardware limitations, you’ve got to put up with the rather poor memory bandwidth available. Some benchmarks I did a while ago suggested that the CPU is only able to write to video memory at about 50MB/s, which in theory allows you to play back video at 800×600 at 30fps, in a 32bpp screen mode. But the reality will be much lower – testing MPEG2 playback with KinoAmp showed that I was only able to get around 2 million pixels per second – i.e. 8MB/s out of the machine

Using DMA to transfer the frames to video RAM will allow you to get better performance, but as mentioned in the above-linked article there’s a bug in the DMA controller/priority levels/audio controller which will cause audio distortion if you use DMA too much. So in the end I was only able to get video playback working nicely at 416×312, 25fps – which isn’t that great when you consider that I’m using a 24” monitor. Luckily the 1Mbps bitrate I was able to get looked OK at that resolution.

Although there’s no guarantee that we’ll be able to play with the real toys available on the OMAP3 (e.g. the DSP coprocessor), I’m hoping that the extra CPU speed, VFP/NEON instruction set, better memory bus, and fancy hardware overlay will make it a much more suitable platform for video playback than the Iyonix.

For reference, included below is the documentation posted by Sophie Wilson to comp.sys.acorn.programmer. (This can be migrated to a wiki page if appropriate.)

Definition of the moving blocks data stream 
=========================================== 

The data stream should be considered as a stream of bits with the least 
significant bit arriving first. The extracted codes from this stream 
construct a new frame from data which may be from the data stream, 
or the previous frame. The new frame is constructed as an array of 4x4 
pixel blocks, with each pixel block constructed in a number of ways: 

* Generate a new 4 x 4 pixel block from data in the stream 

* Copy a 4 x 4 pixel block from the previous frame 

* Copy a 4 x 4 pixel block from the previous parts of this frame 

* Construct a 4 x 4 pixel block in sub-blocks of 2 x 2 pixel blocks. Each 
2x 2 pixel block may be a copy previous parts of this frame, or 
constructed from data in the stream. 

A frame is scanned from top left to bottom right so that when a copy of a 
pixel block from this frame is triggered the source must be from existing 
pixels. That is, the source must be non-overlapping and above or to the 
left of the new block. 

A 4 x 4 pixel block of data is supplied in YUV format with 4 x 4 Y values 
and 1 x 1 U and V values. The Y, U and V values are each 5 bits long. 
This means that 90 bits are supplied for the data in a 4 x 4 pixel block. 

A 2 x 2 pixel block of data is supplied in YUV format with 2 x 2 Y values 
and 1 x 1 U and V values. The Y, U and V values are each 5 bits long. 
This means that 30 bits are supplied for the data in a 2 x 2 pixel block. 

A 4 x 4 pixel block copy from the frame being constructed could, in 
theory, come from any 4 x 4 area already constructed. In practice it is 
only worth providing encodings for close positions. As the source must 
not overlap the destination only 8 source positions are provided for: 
        x offset        y offset 
        2 left          4 up 
        1 left          4 up 
        none            4 up 
        1 right         4 up 
        2 right         4 up 
        4 left          none up 
        4 left          1 up 
        4 left          2 up 

Similarly when a 2 x 2 area is being generated by copying from the frame 
under construction the following offsets are given encodings: 
        x offset        y offset 
        2 left          2 up 
        1 left          2 up 
        none            2 up 
        1 right         2 up 
        2 right         2 up 
        2 left          1 up 
        2 left          none 
        3 left          none 

Here's how the encoding works: 

Note: binary numbers are written big endian (ie lsb first). This is show 
the bit which is interpreted first to the left so . 

At the top level: 
1       4 x 4 data 
00      4 x 4 move case 
01      4 x 4 treated as four 2 x 2 cases 

4 x 4 data is encoded as: 
YYYYYYYYYYYYYYYYUV 
where each Y, U and V is 5 bits. The Ys are supplied in this order: 
         1  2  3  4 
         5  6  7  8 
         9 10 11 12 
        12 14 15 16 

The four 2 x 2 cases are encoded as: 
1       2 x 2 data 
0       2 x 2 move case 

2 x 2 data is encoded as: 
YYYYUV 
Where each Y, U and V is 5 bits. The Ys are supplied in this order: 
         1  2 
         3  4 

A move case (both 4 x 4 and 2 x 2) is encoded as follows: 
00              temporal copy from same place 
01xxx           temporal copy from a place where max(x dist, y dist)=1 
10xxxx          temporal copy from a place where max(x dist, y dist)=2 
11xxxxxx        temporal copy from a place where max(x dist, y dist)=3 or 
4, 
                OR spacial copy 

temporal copy = copy from previous(time) frame. 
spacial copy = copy from previous(position) places in current(time) 
frame. 

[T](x,y) specifies a temporal copy of (x,y) distance 
[S](x,y) specifies a spacial copy of (x,y) distance 
  x < 0 specifies the source is to the left of the destination 
  y < 0 specifies the source is above the destination 

In detail the copies are defined as: 

01xxx 
  0               [T](-1,-1) 
  1               [T](0,-1) 
  2               [T](1,-1) 
  3               [T](-1,0) 
  4               [T](1,0) 
  5               [T](-1,1) 
  6               [T](0,1) 
  7               [T](1,1) 

10xxxx 
  0              [T](-2,-2) 
  1              [T](-1,-2) 
  2              [T](0,-2) 
  3              [T](1,-2) 
  4              [T](2,-2) 
  5              [T](-2,-1) 
  6              [T](2,-1) 
  7              [T](-2,0) 
  8              [T](2,0) 
  9              [T](-2,1) 
  10             [T](2,1) 
  11             [T](-2,2) 
  12             [T](-1,2) 
  13             [T](0,2) 
  14             [T](1,2) 
  15             [T](2,2) 

11xxxxxx 

  0            [T](-4,-4) 
  1            [T](-3,-4) 
  2            [T](-2,-4) 
  3            [T](-1,-4) 
  4            [T](0,-4) 
  5            [T](1,-4) 
  6            [T](2,-4) 
  7            [T](3,-4) 
  8            [T](4,-4) 
  9            [T](-4,-3) 
  10           [T](4,-3) 
  11           [T](-4,2) 
  12           [T](4,2) 
  13           [T](-4,1) 
  14           [T](4,1) 
  15           [T](-4,0) 
  16           [T](4,0) 
  17           [T](-4,1) 
  18           [T](4,1) 
  19           [T](-4,2) 
  20           [T](4,2) 
  21           [T](-4,3) 
  22           [T](4,3) 
  23           [T](-4,4) 
  24           [T](-3,4) 
  25           [T](-2,4) 
  26           [T](-1,4) 
  27           [T](0,4) 
  28           [T](1,4) 
  29           [T](2,4) 
  30           [T](3,4) 
  31           [T](4,4) 
  32           [T](-3,-3) 
  33           [T](-2,-3) 
  34           [T](-1,-3) 
  35           [T](0,-3) 
  36           [T](1,-3) 
  37           [T](2,-3) 
  38           [T](3,-3) 
  39           [T](-3,-2) 
  40           [T](3,-2) 
  41           [T](-3,-1) 
  42           [T](3,-1) 
  43           [T](-3,0) 
  44           [T](3,0) 
  45           [T](-3,1) 
  46           [T](3,1) 
  47           [T](-3,2) 
  48           [T](3,2) 
  49           [T](-3,3) 
  50           [T](-2,3) 
  51           [T](-1,3) 
  52           [T](0,3) 
  53           [T](1,3) 
  54           [T](2,3) 
  55           [T](3,3) 

               4 x 4 case:      2 x 2 case: 
  56           [S](-2,-4)       [S](-2,-2) 
  57           [S](-1,-4)       [S](-1,-2) 
  58           [S](0,-4)        [S](-2,-1) 
  59           [S](1,-4)        [S](0,-2) 
  60           [S](2,-4)        [S](1,-2) 
  61           [S](-4,0)        [S](2,-2) 
  62           [S](-4,-1)       [S](-2,0) 
  63           [S](-4,-2)       [S](-3,0) 

Now that the SharedSound release is sorted (and at risk of being a PITA), is there any more news on the Replay decoder, please? Thanks.

Now that the SharedSound release is sorted (and at risk of being a PITA), is there any more news on the Replay decoder, please?

It’s true, our discussions with ESP also covered the Replay sound code that they wrote. As such, we’ve now cleared the last legal hurdle to making a release of a usable subset of the Replay codebase. It’s now just a question of finding time to process them all for release – please understand, we’re talking about a large body of source code here, similar in scope to the “batches” we used to do a few years back.

we’ve now cleared the last legal hurdle

Do you drink champagne?

finding time to process them all for release – please understand […] large body of source code

I think most of us here are a patient bunch :-)