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 :-)

I suspect we’ll see the sources someday, in the meantime.

Is it possible to make available a working copy of Acorn’s Replay?

The part of it that allowed you to display multiple videos in their respective windows. I strongly believe that such a release would make an appealing demo.

This was called Replay 3 I have a copy on my old system but it will need to be updated to work on the latest hardware as far as I know it used pollidle to display more than one video.

I’ve checked with CJE website and it’s in stock on a CD from Acorn World 97. Perhaps it will work with the aid of Aemulor and a RISC OS version without zero pain ( You never know your luck until you try).

The part of it that allowed you to display multiple videos in their respective windows. I strongly believe that such a release would make an appealing demo.

Appealing to who, exactly?

Let’s face it – anything in Replay is likely to be 20+ years old, and without a distributable version of the encoding tools you’re going to be stuck with 20+ year old videos. Having a working version of Replay would be nice, but it’s not going to impress your average joe on the street who wants to be able to watch DVDs/Blu-Rays/YouTube.

While RISC OS is currently moving forward, it’s still not exactly the Bees Knees is it. It would be nice to reopen some other avenues of interest which might get sponcership from this very website to update Replay3.

So many things of more importance than an ancient video codec only compatible with itself (can MPlayer do Replay?).
Let’s see… Multi core? Better memory protection? Bluetooth? WiFi? A network stack dating from this century? And that’s just your starter for ten.

So many things of more importance than an ancient video codec only compatible with itself

Ah, but didn’t you know, we are basically a retro community. So Replay is at least as important as RISC OS 3.1 compatibility.

So Replay is at least as important as RISC OS 3.1 compatibility.

;-)

FWIW, these days I generally consider RISC OS <5 compatibility to be a happy accident, and as for 3.1…….

Appealing to who, exactly?

Anyone. IMHO it would be an impressive thing to see working again.

Let’s face it – anything in Replay is likely to be 20+ years old, and without a distributable version of the encoding tools you’re going to be stuck with 20+ year old videos. Having a working version of Replay would be nice, but it’s not going to impress your average joe on the street who wants to be able to watch DVDs/Blu-Rays/YouT

Not quite. I recall a friend of mine seeing my (Kinetic) RISC PC for the first time. He had never seen one, so I gave him a demo of its capabilities – dragging and dropping of pictures into !TechWriter, a demo of !Replay 3, amongst other things.

He didn’t comment on the media I was playing, but was so impressed by what he was seeing. I had to take the lid off the RISC PC for him. His expression said it all, he couldn’t believe it! He thought I must have a massive graphics card in there and a similarly large heat-sink on the CPU. Sadly he was disappointed that none of those things were present!!!

And I agree, having a working version of Replay would be good. Has anyone at least tried to re-compile the Replay 3 player for 32bit machines?

So many things of more importance than an ancient video codec only compatible with itself (can MPlayer do Replay?).
Let’s see… Multi core? Better memory protection? Bluetooth? WiFi? A network stack dating from this century? And that’s just your starter for ten.

True, but none of them are visually impressive and good demos pull in punters.

Ah, but didn’t you know, we are basically a retro community. So Replay is at least as important as RISC OS 3.1 compatibility.

True again, but without access to retro software like !Eureka,… where would we be now!

BTW I’m in no way suggesting that what might turn out to be just a re-compilation, is anywhere near as important as multi-core, emulation for 26bit software, WiFi, etc.

Are any of those things likely to attract a crowd or spark a new conversation?

RISC OS5 – RISC OS <5 – RISC OS 3.1 ( and + whatever) lets not make the mistake of always ’ throwing out the baby with the bath water ’ , just for the ‘new’ and political correctness. If I had the funds, I would gladly donate £ whatever to see Replay3 updated with the latest feature sets as found on the likes of Linux and/or Windows 10.
By the way has any non £1000 contributor discovered/ hinted what RCOMP and allies at what new/revamped feature sets/applications could ( in the next 12 months ) be added to RISC OS. I suppose this is a question that shouldn’t be asked.

Has anyone at least tried to re-compile the Replay 3 player for 32bit machines?

There is PinPlay by Druck which is a player for Replay 3 and apparently 32bit compatible:
https://armclub.org.uk/free/

I don’t remember if there was the Replay decoding stuff for IYONIX, without which the player is really useless.