Acorn Replay

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

How would playing replay movies be in any way visually impressive in the 21st century, where we (on other systems) have 4K 60Hz playback with high quality codecs? And decoding object-based surround sound formats at the same time instead of 16bit stereo that Replay supported?

Replay was surely impressive in its day – it showed what a slow processor without dedicated video hardware could do. So it was impressive software, but I don’t remember the result being impressive in the late 90s. Remember, the late 90s had PCs with Voodoo accelerator cards and games like Unreal. Now that was impressive.

Yep. On the other hand, it exists. Can manage some very classic compression methods. Could be used for small animations included in software. But needs an encoder :) More important: some old software use it.

I have one or two music videos in a higher quality replay format promoted by Eidos. I not have codecs for RISC OS (my RISC PC could not play) only for WIN. In the past I have try to get any information from Eidos but I get nothing only any good wishes. As I remember Replay is a Escape-Codec. For WIN was a Escape-Player (?) aviable. Long time ago…

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.

I agree, especially if it got us closer to the experience of watching videos in a browser or provided us with a generic video framework that could be expanded with different multi-tasking codecs; akin to what Omniclient does for networking.

Bump +1

I agree, especially if it got us closer to the experience of watching videos in a browser or provided us with a generic video framework that could be expanded with different multi-tasking codecs;

You know, there’s already a port of MPlayer. It’s not so recent, but given the <=1GHz machines can just about cope with a 320×240 DivX non multitasking, it shows exactly how hard it is going to be decoding video purely in software (without GPU assistance). Now, it might be possible to speed up MPlayer if the maths part was rewritten to use NEON. Maybe then we’d get 640×480?

FWIW, my animé these days is 1280×720 with subtitles overlaid on the fly. That’s not going to be possible without a hell of a lot of stuff that RISC OS doesn’t have.

Maybe instead of reviving long-dead codecs, it might be better to look at the feasibility of faking enough of Linux to get kernel modules running?

Acorn Replay is a dead end. There’s only a tiny amount of AR-encoded source material to watch, and no means to generate any more. And even if there were an encoder, why would any more than half a dozen people use it? It’s already possible to watch low definition video in a few current codecs.

Acorn Replay is a dead end.

Not true. It’s a container. While there is no easy way to generate some encodings, some others are very classic.

Some are uncompressed data. Still useful today:
https://multimedia.cx/AE7doc.txt

Some use light compression… and are documented:
http://www.chiark.greenend.org.uk/~theom/riscos/docs/apps/AcornReplayMovingBlocks.txt

akin to what Omniclient does for networking.

That’s exactly what the Replay format and tools are.
You can even use this format to make shortcuts to other containers (as MPEG).

Other links…
http://www.chiark.greenend.org.uk/~theom/riscos/docs/apps/ReplayFormat.txt
https://bitbucket.org/dboddie/replay/src/50ff28a76cc2c86d5d559608d8db04f462ef2af2/documents/?at=default
https://groups.google.com/forum/#!msg/comp.sys.acorn.programmer/tRE8fFkOBlQ/uN7OLmU66jsJ

Nota:
https://groups.google.com/forum/#!topic/comp.sys.acorn.apps/mEtzuKgB_R0

“The only way to do itm, that I know of, is to use the latest version of CineWorks, which had codecs for AVI, MPEG Quicktime, but as far as I know, this was never updated to work with RISC OS 4.”

So perhaps Henrik Bjerregaard Pedersen (still active user) could find some source files on its backups.
Or information on how to implement a coder/decoder for Replay.

Of course, all of this would need a fresh 32bit compilation of Replay (the one I have is mainly for Iyonix).

Still useful today:
https://multimedia.cx/AE7doc.txt

That document is giving it’s age away referring to “winchester” discs, and the insanity of allocating a hundred compression type IDs to each interested party.

Frankly, the simplest solution to preserve old video might to to play it on an emulator that is also running some sort of screen capture utility, to convert the video into something like DivX or H.264.

BTW, didn’t Eidos use the Replay system for their Tomb Raider 2 insert videos? I don’t recall that it was something based upon Replay as it could do effective looking video on fairly crappy hardware…

This is the program that we need it was called Cineroma i think https://www.dropbox.com/s/8mfh9uxfj3ptk6n/cineromademo1.mpg?dl=0 or https://www.dropbox.com/s/gnc9d6f6o41jyby/cineromademo2.mpg?dl=0

Edit not the best way to put them on the forum sorry

Hehe, there’s a document that talks about making Replay video…

The problem here is that VHS is a bit rubbish, and for a very long time was unable to produce a good static pause picture. The reason for this is purely technical – as it is an M wrap system, there simply isn’t enough tape in contact with the heads. When proper freeze became available, it was often a digitised sample that was switched in place of the data coming from the heads. One might have noticed the colours were a bit “flatter” in pause, but then VHS was pretty rubbish so maybe not.

My Betamax decks, on the other hand, could manage perfect still frames. This is because the C wrap (remember all those grinding noises as the deck threaded a tape) placed enough of the tape around the heads that as one transitioned off the tape, the other was already in position to pick up data. The problem with Betamax was how good it was at stepping forwards. My Sanyo could be unpaused and paused again, skipping around 1/3 second. My Sony had a frame step button, which did exactly what it promised. I made a naff version of the original C4 logo by recording each frame from a Beta recording (HCCS Vision digitiser), shrinking the frames with ChangeFSI, then just plotting the sprites quickly one after the other.

Hi8 could also do decent still frames, but this might have been due to such devices having a heck of a lot of on board processing. Do you remember the days when video cameras had loads of gimmicks? Like being able to take a 1bpp snapshot of something, giving it a colour like bright magenta, then overlaying it on the video from the imager in a way that looked so utterly naff. There was a TV programme with the bloke from Red Dwarf where he gave lots of tips on how to use your video camera. It wasn’t cringe making embarrassing, no, not at all. ;-)

How do I know so much about still frames? Those of a certain age might remember a TV programme hosted by… God, what was her name? Something like Aleks Krotosky… And some other less cute people. Well, they had a novel way of providing information at the end of the programme in a pre-internet way but something that might need to have a bit more of a data dump than some teletext pages. They played a series of information pages at the end of the programme, for a couple of seconds each. The idea was that you’d tape the show, then just hit pause when the info came up. Probably the only programme self aware enough to recognise that people would tape it, and not freak out over the fact that it was being taped.
When you have various VCRs at your disposal, you learn to pity the poor sods that had to use basic VHS hardware…

You know, there’s already a port of MPlayer. It’s not so recent, but given the <=1GHz machines can just about cope with a 320×240 DivX non multitasking, it shows exactly how hard it is going to be decoding video purely in software (without GPU assistance). Now, it might be possible to speed up MPlayer if the maths part was rewritten to use NEON. Maybe then we’d get 640×480?

Yes, NEON would almost certainly make things faster (and I’d expect some of the codecs to already contain NEON optimisations, it’s just a case of working out how to build a suitably recent version of the sources).

Also don’t forget that a large amount of time will be spent doing the YUV → RGB conversion. A few months ago (while trying to work out which of the hundred high-priority things on my todo list I should actually be doing) I had a look at what was necessary for YUV overlay support in RISC OS and concluded that there weren’t any major blockers preventing the implementation. All that’s needed is some design work for the high-level (Wimp) and low-level (GraphicsV) APIs, followed by an initial implementation for one of the platforms (once it’s working on one platform I’d expect implementations for the other platforms to follow fairly quickly)

(And then of course you have to wait for movie players to be updated to make use of it… or as is the case with many things in RISC OS land, if you want something done, you usually have to do it yourself)

I think there are two ways of looking at this:

Replay was technically interesting and has retro-appeal. As DF has said, it is a container system (like QuickTime or AVI) with multiple codecs. First was Moving kits, then we had interesting ones like ESCaPE and MovingBlocks. Remember MovieFS, which added support for typical ‘industry standard’ codecs? It might be interesting if it was all available again. More modern codecs could be added.

But looking ahead, isn’t it simpler to use MPlayer? It covers the key modern formats, doesn’t it? And presumably could even be extended to support MovingBlocks or MovingLines? (Didn’t someone already do this?)

IMHO, both could exists.

Acorn Replay is a dead end.

Not true. It’s a container.

Yes, it is a container. It is still a dead end. Because it is no longer a useful container. There are other well-supported containers around like avi, mov, mp4, DivX or Ogg. With a lot of available tools that can be easily ported. Which overall provides much more functionality than any of the Replay tools ever had.

What are those valuable tools to work with the Replay containers, let alone the Replay-specific codecs? There are possibly a few from the 1990s (like Cineworks or the Irlam stuff or the Videodesk tools which are tied to a special podule), but why exactly would it be worth to resurrect them? Does it help the platform in any way other than to give you the warm fuzzy nostalgic feeling? Most of the stuff is firmly stuck in 26bit world, some does not even work with a StrongARM.

I dimly remember Sophie trying to get together interested parties to add support for common codecs to Replay – possibly back in 1995 (MPEG1 was the first targetted video codec IIRC). It never happened. Back then, it might have been sensible. Today, it is not. Today, we need to embrace the available open source stuff to keep development time and cost as low as possible.

What he said. We need less containers, not more. I mux a lot of my stuff to mkv because it copes with embedded subtitles and such (mp4 is unreliable for this).
With my satellite receiver, I now have mts files to deal with. Handbrake and SMPlayer cope, but it takes forever to transcode HD to a smaller size H.264 video…

How about Smart Containers that could hopefully accommodate anything a user could throw at it. Having usable multicores could help to deal with any hang ups ( this stupid auto correct tried to change ‘hang ups’ to ‘hangovers’ – I’ll have a beer and cool off, much better than swearing).

I was mostly interested in playing old Replay movies and converting them into other formats when I started collecting links to documentation and example files. Sadly, like other popular formats on RISC OS, the quantity of freely available files on the Internet is not enough to make it compelling to work on software to read them, especially if you don’t have any personal investment in the format. So, it’s interesting to try and play the “classic” Star Trek NG intro, and the Levi’s and Guinness adverts, but possibly an activity that can wait until retirement. ;-)

Unfortunately, it’s the same with Artworks and Sibelius files. For what were supposedly killer apps for the platform, there aren’t really a lot of files out there to play with. :-(

but why exactly would it be worth to resurrect them? Does it help the platform in any way other than to give you the warm fuzzy nostalgic feeling?

No. But let’s face it: RISC OS is a nostalgic-retro-past-thing.

Anyway, I do not say we should stick on Replay. But since Replay is available on the Iyonix, it could be compiled for ARMv7 strict mode. When, use it or not. We don’t need less choice.

I have around 800 MB Replay files collected from different places, that I could put online.

I don’t know if I would advise you to put them online unless you are OK hosting them yourself or uploading them to archive.org. Anyway, it’s good to know who to ask if I want to look at Replay files. :-)

Anyway, it’s good to know who to ask if I want to look at Replay files. :-)

Here are a few still online: http://ftp.uni-stuttgart.de/pub/systems/acorn/riscos/graphics/replay/

Archive.org has a few CD images (Acorn User Cover CDs with a few movies, and the Acorn Replay Demonstration Disc).

Thanks! I should probably go looking for the CDs. I found the Stuttgart files a while ago, and Drobe’s mirror of them.

So, the sources for ARPlayer, AREncode and ARWork were released back in early December, and pre-built versions are included in the Bonus Binaries. With that in mind, are there still any major factors blocking the release of ARMovie as well?

Closed source codecs?

I see two possible solutions here:
1. Provide at least one open source codec
2. Provide the others as closed source binary

I understand that Iyonix came with ARMovie, and later conversations suggested it needed to support Gamma.

So, it is good to see the signs of it being resurrected and released at some point. Under the circumstances, perhaps worth the wait.