Replay codec sources
Philip Pemberton
I'm mucking about writing an Acorn Replay demuxer / decoder (yes, I'm
really THAT bored), and I noticed an interesting comment in one of the
Replay API docs:
====
http://acorn.riscos.com/riscos3/37/37DiscImage/!Boot/Resources/!ARMovie/Documents/codecIf
The total replacement of !ARMovie.Player is a very large task; it is
much
easier to provide a new video decompressor only and rely on the
!ARMovie.Player program doing the rest of the work. Acorn currently
provide
10 video decompressors using this interface and many of them are
provided
with source.
====
Question: does anyone know if the source code for these decompression
engines still exists, and if so, where I might be able to get a copy?
I'm guessing this was in the Replay Starter Kit, but finding a copy of
that seems to be a bit like finding the Holy Grail...
Also, does anyone know if there's a mirror of ROL's mirror of Acorn's
old FTP site? The 37DiscImage directory is throwing a 403 error
instead of producing a directory listing...
Thanks,
Phil.
Ste (news)
<58441086-2406-4769...@s11g2000yqh.googlegroups.com>,
Philip Pemberton <phi...@gmail.com> wrote:
> I'm mucking about writing an Acorn Replay demuxer / decoder (yes, I'm
> really THAT bored)
If you're really THAT bored, can I suggest you take a quick look at the
following pages?
https://www.riscosopen.org/wiki/documentation/pages/RISC+OS+Roadmap
https://www.riscosopen.org/wiki/documentation/pages/Cortex-A8+port+status
https://www.riscosopen.org/forum/forums/2
Something there might take your interest and at least the fruits of your
labour would probably be more broadly applicable.
Ta,
Steve
--
Steve Revill @ Home
Note: All opinions expressed herein are my own.
Theo Markettos
> Also, does anyone know if there's a mirror of ROL's mirror of Acorn's
> old FTP site? The 37DiscImage directory is throwing a 403 error
> instead of producing a directory listing...
Try:
http://www.drobe.co.uk/archives/index.php?directory=/acorn.riscos.com/
or
http://www.drobe.co.uk/archives/index.php?directory=/ftp.acorn.com/
Theo
trevj
> If you're really THAT bored, can I suggest you take a quick look at the
> following pages?
>
>
> Something there might take your interest and at least the fruits of your
> labour would probably be more broadly applicable.
And, specific to Replay, there's also:
Theo Markettos
> Question: does anyone know if the source code for these decompression
> engines still exists, and if so, where I might be able to get a copy?
>
> I'm guessing this was in the Replay Starter Kit, but finding a copy of
> that seems to be a bit like finding the Holy Grail...
I think there might have been something on one of the Clan CDs or another CD
sent out by Acorn. When they say 'source', I think all the examples are
written in assembler so the source doesn't help you that much. But I think
I've seen some files of BASIC assembler kicking around somehow.
<digs around hard drive a bit>
I have a !Boot which is numbered 0.67 (23-Feb-1998) in !boot.!help. Is that
from 3.7? Anyway, there's source in
!Boot.Resources.!ARMovie.DecompN.MakeDecomp
when N is small (4,5,6 etc)
Theo
Philip Pemberton
+n...@chiark.greenend.org.uk> wrote:
> I have a !Boot which is numbered 0.67 (23-Feb-1998) in !boot.!help. Is that
> from 3.7? Anyway, there's source in
> !Boot.Resources.!ARMovie.DecompN.MakeDecomp
> when N is small (4,5,6 etc)
I think that's pretty much what I've got. Sources to the YUV codecs,
but nothing for Moving Blocks or Moving Lines (which is really what
I'm after).
Apparently the libavcodec guys are going after the Eidos ESCAPE codec,
but nobody's touched MB/ML AIUI. There's certainly enough info about
ESCAPE on wiki.multimedia.cx...
But it's MB and ML that I'd really like to get working...
Philip Pemberton
> from 3.7? Anyway, there's source in
> !Boot.Resources.!ARMovie.DecompN.MakeDecomp
> when N is small (4,5,6 etc)
Yeah, I found those files kicking around an old RISC OS disc image
CD... There's the full ARM ASM source for the YUV decoders, but
nothing for Moving Blocks or Moving lines.
What I'd really like to find is some details on how Mblks and Mlines
work...
Thanks,
Phil.
Theo Markettos
> Yeah, I found those files kicking around an old RISC OS disc image
> CD... There's the full ARM ASM source for the YUV decoders, but
> nothing for Moving Blocks or Moving lines.
>
> What I'd really like to find is some details on how Mblks and Mlines
> work...
You could always ask Sophie Wilson direct... after all she invented them.
Also have a look at patents... a quick search of the GB database found
EP0569207 and US5497434 (under Wilson, Alun R.). There may well be more, if
you poke the various patent databases (she has lots of 2000-era architecture
stuff under Sophie, including one published last Thursday).
Theo
Sophie Wilson
news:fjz*5P...@news.chiark.greenend.org.uk:
I thought that there was documentation out there on how it works...
Anyway, try this. Codecs are always documented in terms of what the
decoder understands - encoding it is a different problem! Moving Blocks
is outright better than Moving Lines.
--Sophie
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)
Philip Pemberton
> I thought that there was documentation out there on how it works...
>
> Anyway, try this. Codecs are always documented in terms of what the
> decoder understands - encoding it is a different problem! Moving Blocks
> is outright better than Moving Lines.
I figured as much -- pretty much all the Acorn documentation says that.
"Don't use Moving Lines, Moving Blocks is sooooo much better!"
Was Moving Lines ever used for anything significant? I'd like to
implement a decoder for it (for the sake of completeness) but it seems
pointless if there aren't any videos floating around in that format.
> Definition of the moving blocks data stream
> ===========================================
>
(snip)
Thanks for that, Sophie!
It'll probably take me three or four attempts to figure that out. On the
plus side, it certainly beats trying to understand the (packed?) BASIC
source code for the compressor (or worse -- the disassembled version of
the decompressor).
I'm still trying to figure out what the various undocumented patch-table
opcodes (6, 7, and a few others) do, and how the temporal/spatial data is
passed to the decoder. The decoder documentation is a bit skimpy on that
part... Looks like it only covers Opcode 0, and I haven't seen anything
in there about temporal/spatial data. Maybe I need to read it a bit more
closely.
It's a shame the Replay decoder interface isn't part of the ROOL source
release...
Thanks again,
--
Phil.
usen...@philpem.me.uk
http://www.philpem.me.uk/
If mail bounces, replace "10" with the last two digits of the current year
Ben Avison
<usen...@philpem.me.uk> wrote:
> It's a shame the Replay decoder interface isn't part of the ROOL source
> release...
Don't give up hope, it may yet be. There have been some discussions going
on
in the background again in the last few weeks that may overcome the
remaining
legal hurdle to doing so.
Ben