Alpha testing on Pi

ROOL are working on the RPi disc image behind closed doors for the time being. There’s a load of messing about and checking things which isn’t the sort of thing we want affecting end users until we’re ready to make the release. You should get the full, proper RISC OS on the RPi release in a few weeks but until then, you’ll probably have to track changes in CVS yourself (or merge the autobuilt ROMs and Disc stuff to your own setup).

So presumably what appears will be the Beta release.

Some requests.

The image to be as small as possible, using packman to to get additional software.

As much included stuff to be managed by packman as possible.

The ADFS part of the image and the DOS parts of the image to be available as separate downloads to allow manual upgrades or setups.

The ADFS part to be generic, to supersede the current hard disk image.

(Hopefully you’ve already thought of all of these anyway.)

I’m gonna be patient and wait for the first proper release. It will be worth it :-D

Will RISC OS support the mpeg-2/VC-1/H.264 hardware en/decoding?
http://www.raspberrypi.org/archives/1839

Will RISC OS support the mpeg-2/VC-1/H.264 hardware en/decoding?
http://www.raspberrypi.org/archives/1839

Probably not. If you look, it is some sort of licence unlock key (that you can buy) hardwired to the Pi’s unique ID. So we’re looking at some sort of semi-secure binary blob to talk to the DSP/GPU; the chance of that appearing on RISC OS at this time is a number very close to zero.

The lack of mention of (less encumbered) H.263 (DivX/XviD family) is perhaps because this sort of stuff is more openly available. But, again, my Beagle struggles to play H.263 videos under RISC OS ’cos it is a purely software decode. We need graphics assist for this to work nicely, but this sort of stuff being all trade-secret and such, if somebody is smart enough to write a module capable of loading Linux system modules, we might have a kludgechance. Otherwise…

[it’s the same thing that ultimately killed the attractiveness of the Neuros OSD (digital video recorder). Not only was the SoC datasheet under NDA (and TI refusing to entertain talking to little people), but all of the hardware access was a pile of pre-built closed-source binaries. So we hacker types could mess with the UI, fiddle with the kernel, write some basic software (I got Brandy BASIC running on mine), but anything more involved with what the device is supposed to be is met with a brick wall. You know, the ancient YouTube player works by requesting the MP3/H.263 version of the FLV (the 240p looks-like-hell version) which it then, in realtime, strips apart to rebuild as MP3 and H.263 streams to feed to the playback codec – for that’s the way to get it done if the codecs are closed source. The hardware could play a variety of simpler (pre H.264) types of video, but we’re restricted to those supported by the codec library. Could it play Acorn Replay? In theory. Could we write a codec? No. The interfacing and API is…closed.

Sadly, graphics hardware is like this. For no sane reason (for those knock-off shops probably employ people smart enough to trace the device’s operation at real low levels), a lot of graphics stuff is locked down tight. Broadcom originally weren’t even going to release so much as a datasheet. That position softened slightly, but it is a very scant document (given the chip in the Beagle runs to around 3,700 pages (and that too doesn’t go into much detail on the graphics side)).

I would like to believe that companies will soften up and start to reconsider this, at least as far as describing the API to the GPU), but with Apple recently proving that patents don’t even need to be valid to be upheld ¹ then I’m not so sure things aren’t going to take a step backwards.

¹ Though, did anybody really expect a case held in the same town as Apple’s HQ to find in favour of some skanky Asian outfit? What with the sales ban being granted before hearing, and Apple permitted to display sufficient “witnesses” to cause the judge to ask “are you on crack?”, while Samsung’s evidence was curtailed by a rather arbitrary measure, this case had “fix!” written all over it. Such is the price of doing business in The Land Of The FreeNameYourPrice.

If you look, it is some sort of licence unlock key (that you can buy) hardwired to the Pi’s unique ID. So we’re looking at some sort of semi-secure binary blob to talk to the DSP/GPU; the chance of that appearing on RISC OS at this time is a number very close to zero.

If the Pi used a traditional CPU/GPU architecture I’d agree with you. But the GPU is entirely non-traditional – it’s running a binary blob that is effectively an entire operating system. This means the ARM is able to interact with it via a high-level interfaces (similar to BSD sockets) instead of doing things at the register level like you normally would. This means all the secret sauce is in the GPU firmware, and by open-sourcing all the ARM side bits (which I believe is Broadcom’s intention) they won’t be giving away any trade secrets.

But, again, my Beagle struggles to play H.263 videos under RISC OS ’cos it is a purely software decode. We need graphics assist for this to work nicely, but this sort of stuff being all trade-secret and such, if somebody is smart enough to write a module capable of loading Linux system modules, we might have a kludgechance. Otherwise…

AFAIK the GPU in the beagle is actually a pretty poor choice for video decoding. What you want to use instead is the full-fledged C64x DSP coprocessor, which is very well documented, and has free dev tools available (I think… it may turn out you need a Code Composer Studio license for them, I’m not sure, but if you can’t afford that you can roll your own compiler since the instruction set is fully documented). I’m not sure what the situation is with codec binaries though – i.e. whether they’re reliant on closed source components or not. Maybe the open source ones are pretty decent by now, I dunno.

And although I’ll probably die of old age before I get round to writing a linux system module loader (thus allowing us to use whatever video decode features the GPU may or may not have), we can at least make use of the fully-documented YUV overlays to offload some of the more mundane aspects of video playback to the hardware. All we need is for more programmers to start doing work on the OS instead of just moaning on the forums ;-)

Perhaps we should buy André Timmermans a Pi and decoder licence and see what happens :) His media player work is excellent.

AFAIK the GPU in the beagle is actually a pretty poor choice for video decoding.

Seemed to work okay under Angstrom. It might not fly as hard as it could, but, you know, if it gets the job done…

What you want to use instead is the full-fledged C64x DSP coprocessor

Yes, my PVR has something like that inside [looks at blog] a C5409. Given the ARM is clocking 200MHz and the DSP is clocking 100MHz, it is astonishing how much it can get done – namely recording SD video in realtime as H.263 (XviD-like) with 128kbps AAC audio. I record at 640×480 usually at 1200kbps. It can also do 640×512, and up to 2500kbps for the video. Not quite enough grunt for doing a full 720×576 (and no point as it looks like the initial video input is set to 720×288 for some reason – but being a closed source thing (see my earlier whinge) you can’t tweak this to see what effect it may have). Anyway, VGA MPEG4 video, realtime, on some seemingly underpowered kit. Pretty impressive.

But, then, a known DSP as the GPU is perhaps not “sexy enough” when APIs are looking less at decent video decode and more at blitting fancy effects to the screen, like moving bits of windows around, blurring behind semi-transparent toolbars… the some of CPU intensive rubbish that can be tasked off to the graphics unit.

And although I’ll probably die of old age before I get round to writing a linux system module loader

Well, it isn’t as if its an “easy” thing to do, right? I mean, step one, “fake being Linux”. Step 2, load module. I think most people would do a doubletake at step one; especially given as it’ll be a heap of lowish-level module code to deal with something low-level for a completely different operating system!

All we need is for more programmers to start doing work on the OS instead of just moaning on the forums ;-)

I tell you, I would have done video stuff already if I wasn’t a complete dunce at maths (dyscalculia); but pretty much anything over and above RLE leaves me stuck. Way back when, when I wrote a 1K GIF decoder, I got the idea of how GIFs work after drawing a big (as in, it covered eight sheets of A4) chart with lots of colours and stuff, and reducing all of the calculations to binary logic. I can understand maths that I can see. So, sorry, moaning on a forum is a lot more productive than having me silenced for years as I try to wrap my head around something like octrees (eight legged slimy trees; sort of daddy-triffids)!

Jess: His DigitalCD software is top notch, well I’ve no problem in giving him a pi with the codecs enabled if he would find it useful ;-)
I think anyone who is willing to get any hardware acceleration even attempted on the pi deserves a free one, with full acceleration integrated in the OS it would be kick ass.
I have a spare one, but I think the kids managed to mangle it in the TV door stand, and it doesn’t seem to boot :-( [the case came one day too late]

He also works on Kinoamp which is very good, (which is why I was non specific.)

Kinoamp doesn’t seem to work on the Pi though, something about internal timers..But yeah another reason to get him one :-D

KinoAmp works pretty well on the BB xM, with Alignement Exceptions turned off. Blazing fast for an “arc”

I find that financing André Timmermans so that he can continue work on KinoAmp and Digital CD is indeed excellent. Does he read this forum ?

He does. My comment was more to point out that he is the person with the right skills, than any statement of whether he needs a Pi or not. (Though if he did, I’m sure there would be no shortage of contributions.)

I’m constantly amazed how good DCD sounds (Iyonix plus Altec Lansing speakers.) The Mac and PC don’t come near.

If RISC OS on Pi had what my Iyonix has in the way of media support (with a frams speed boost) plus hardware decoding support, the need for a media player version of linux to be used would be rare, I think.

Kinoamp doesn’t seem to work on the Pi though, something about internal timers..But yeah another reason to get him one :-D

Within the !KinoAmp application there is a file named RunKino.

Try modifying the last line in the file from

Run Kino:Kino -fKinoChoices:Choices %*0

to

Run Kino:Kino -fKinoChoices:Choices —ostime %*0

This will force KinoAmp to use the standard low resolution timers instead of relying on the TimerMod module till the developers resolve the problem.

Kinoamp doesn’t seem to work on the Pi though

Err, I’ve certainly had it working! Used it to play the Big Buck Bunny movie that is used as a demo of the ARMini. For info, the Pi can’t quite manage to play that smoothly, stutters now and again.

Cheers Andre, That explains a lot. I tried it again and it randomly worked! I was wondering why.
I try to keep my disc image up to date, so looks like one of the recent updates has fixed it.
Just downloading Big Buck Bunny now, I’m amazed that even play’s without any acceleration on the Pi.
Mplayer is pretty terrible even with low res movies. If it out performs mplayer I’d be gob smacked.

I get sound, but no movie.
I noticed that Use IntelDMA and Use Geminus are ticked. So I figured they were causing the issue.
However clicking on OK in the configuration window gives me a “Kinoamp Configuration has gone wrong”
Unrecoverable Error in Runtime system not enough memory, malloc failed, (heap overwritten).
I tried increasing the next and heap memory to no avail.

This could be my franken-build image though…

I’ve reinstalled my image, and don’t think it’s that, or not my alterations specifically.
Changing the configs works, but only once… strange!
I’m downloading an alternate version of the mpg, maybe I downloaded an incompatible version!

Can’t seem to get the video working at all…
Deleting the config in !Boot allows you to set the settings (once) strangely enough

I’ve worked out how to update the pi image properly now, and have reinstalled it.
What ever weirdness that was causing the error with saving has gone, doesn’t play video on that Big Buck Bunny.
I’ll have a look for a standard mpg video when I get chance.

Just to keep up, until the beta image appears, I have updated the 8 Aug 2012 alpha distro to the latest firmware (18 Sep 2012), harddisc image (18 Sep 2012) and ROM (22 Sep 2012). Sound now seems to work again. I have added !Store from RComp – a utility to allow free (and, later, paid for) software to be downloaded but otherwise unchanged from 8 Aug 2012 version.

Are just the updaes available?

Are just the updaes available?

That would make sense – I’ll work on it.

Thanks, you could just put up the contents of the ADFS area in one zip file (apart from the image file), and the DOS partition in another file.

Thanks, you could just put up the contents of the ADFS area in one zip file (apart from the image file), and the DOS partition in another file.

It is more complicated than that. After six hours’ work I have an update file for the 8Aug2012 alpha image here which has an obey file to delete those files that are no longer there now that the latest HardDisc4 image is used. It also has a directory containing all the files that have changed (including the ROM and firmware). Plus another directory with all the new files. Use at your own risk. (The CMOS settings for the new ROM may not suit you – or they may be wiped on first use. The ‘delete files’ obey file may fail if you have added files to directories that are now to be deleted. The monitor setting may not suit you etc. etc.)

I tried it and it worked successfully, except that digitalcd now locks the system solid. (Nice to now have a lot of RAM)

And here is an update file to go from 24Sep2012 (which uses the 18Sep2012 HardDisc4 image) to 1Oct2012 (new ROM and HardDisc4 image).