The Icon Bar: Easier_video_playback_on_RISC_OS: The Icon Bar: Easier video playback on RISC OS?

The Icon Bar: News and features: Easier video playback on RISC OS?

Easier video playback on RISC OS?

Posted by Chris on 14:25, 19/4/2010
Hardware, Open source, Programming, RISC OS, RISC OS Open Ltd, Video

Watching video on RISC OS isn't very easy. We've run an article here on how you can download and convert YouTube videos into a format RISC OS can understand. Though it's very clever, and the tools involved are actively developed, it's not as simple as clicking 'Play' in a browser window.

Improving this situation has been hampered up until now for two main reasons:

RISC OS hardware has been too slow to play back video at an acceptable rate;
RISC OS software hasn't supported popular codecs (formats), some of which are proprietary and expensive to license.

The first of these is already well on the way to being fixed. The Beagleboard is modestly powered in comparison to the average desktop PC, but it's perfectly capable of playing video at a decent rate. The diminutive boards have been shown running 720p video (a high-definition format) while running a Linux distribution - have a look here to see this in action.

The RISC OS port can't quite match that yet. All that might be about to change, though, due to the development of something called Theorarm. This is a library of routines to enable the playing of videos in the Ogg Theora format on ARM-based machines. Ogg Theora is a relatively new format, but it has some interesting features. Perhaps most importantly, it's entirely open source, so videos encoded using the technology can be played back by any suitably-written software. Moreover, Theora is one of the contenders for the [video] tag in the new HTML5 specification. That means that it may become a significant rival to the more common MPEG and Flash videos on the web.

Theorarm is interesting, as it's been optimised for newer ARM chips using hand-written assembly code. This makes it very fast. The developer, Robin Watts (of Warm Silence Software fame) has done some development work on the Beagleboard, with promising results: "With post processing disabled, I can play a PAL DVD sized film (720x576x25fps, 48kHz stereo audio track) in realtime with software YUV2RGB. The limited profiling I've done, along with some back-of-an-envelope maths suggests that we should just about be able to do 720p films if the YUV2RGB process is done by hardware." That means, in English, that DVD-quality film can be played back on a Beagleboard with decent audio too. If some of the complex conversions from YUV colour format to RGB could be carried out in hardware, then higher definition films could be played.

This is pretty exciting stuff for Beagleboard owners. If Theorarm is ported to RISC OS (and there's no reason, other than developer time and effort, why it couldn't be), then we'd have the basis of a fast, native video playback system. Some issues would require addressing, of course, since RISC OS can't handle the Beagleboard's YUV facility - see here for Jeffrey Lee's proposals to fix this - but these are all surmountable.

If anyone is interested in getting involved, then the ROOL project is the place to start. In particular, the proposals for working on the GraphicsV vector need attention from developers with the right level of experience, and the draft API on the ROOL site could do with some more exposure.

A few years ago, RISC OS lacked fast hardware, a half-capable browser and a media player capable of showing popular streaming video formats. The first two are being actively addressed - what are the chances that the last one will be as well?

	Easier video playback on RISC OS?
	swirlythingy (17:29 22/4/2010) arawnsley (18:15 22/4/2010) Chris (10:32 23/4/2010) trevj (14:04 10/5/2010) Phlamethrower (18:20 19/5/2010) trevj (08:12 20/5/2010) Phlamethrower (09:08 20/5/2010) trevj (09:36 20/5/2010) swirlythingy (16:51 20/5/2010) Phlamethrower (17:10 20/5/2010) trevj (15:47 24/5/2010) castlevarich (13:48 28/5/2010) Phlamethrower (10:02 29/5/2010) swirlythingy (10:50 29/5/2010) Phlamethrower (12:34 29/5/2010) castlevarich (11:09 29/5/2010) trevj (13:42 19/1/2011)

Martin Bazley	Message #114079, posted by swirlythingy at 17:29, 22/4/2010
Placenta Mendacium Est Posts: 460	Well, it's a nice thought, but isn't it all a bit dependent upon Ogg Theora becoming the world's video format of choice, as opposed to Flash? (I note Ogg Vorbis has yet to displace MP3, like it was supposed to.) Open source not-for-profit formats, in general, do not have a good record for beating the closed-source, commercial-backed ones, a possible exception being PNG.
	[ Log in to reply ]

Andrew Rawnsley	Message #114080, posted by arawnsley at 18:15, 22/4/2010, in reply to message #114079
R-Comp chap Posts: 600	The only caveat to Martin's (accurate!) comment is that perhaps the continued rise of ARM-based devices might benefit formats with strong ARM support, as/when/if major players (eg. google etc) embrace devices beyond the traditional desktop PC. This does seem to be happening (really slowly), but it is possible that Google's moves into things like mobile phones might pave the way. Desperately trying not to mention iphones, ipads or Apple's anti-flash stance!
	[ Log in to reply ]

Chris	Message #114093, posted by Chris at 10:32, 23/4/2010, in reply to message #114079
Member Posts: 283	True enough, but Ogg Theora is at least a credible contender. Time will tell whether it does well, which I guess partly depends on whether the HTML5 spec achieves widespread use.
	[ Log in to reply ]

Trevor Johnson	Message #114394, posted by trevj at 14:04, 10/5/2010, in reply to message #114079
Member Posts: 660	I take it everyone's already heard about the expected open sourcing of VP8 too?
	[ Log in to reply ]

Jeffrey Lee	Message #114492, posted by Phlamethrower at 18:20, 19/5/2010, in reply to message #114394
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff Posts: 15100	Looks like the VP8 open sourcing rumors were true http://www.engadget.com/2010/05/19/google-launches-open-webm-web-video-format-based-on-vp8/ ARM and TI listed as partners, so with any luck we'll be able to get hold of some optimised VP8/WebM decoders with minimum of effort.
	[ Log in to reply ]

Trevor Johnson	Message #114494, posted by trevj at 08:12, 20/5/2010, in reply to message #114492
Member Posts: 660	ARM and TI listed as partners, so with any luck we'll be able to get hold of some optimised VP8/WebM decoders with minimum of effort. This is great news! Readers have probably already seen the WebM VP8 Decoder page by now. Seeing as ROOL is an ARM Connected Community Member, any subsequent ROOL forum VP8 code suggestions (or similar) might be best covered under a Corporate Contributor License Agreement rather than many Individual Contributor License Agreements. (This is assuming that anyone in the RO community has the time, expertise and inclination to look at the VP8 sources, and that there are further optimisations to be made - not covered by ARM or TI - and such person(s) may of course prefer to be registered as personal contributors anyway... I just think it'd be good for ROOL's profile if they're the body through which any such stuff is channelled. In fact, perhaps ROOL or another RO developer could propose to undertake this work for ARM/TI - on a paid basis? All IMHO etc. etc.) On re-reading this, am I going off on a tangent and is the (unmodified) source code alone all that's needed?
	[ Log in to reply ]

Jeffrey Lee	Message #114496, posted by Phlamethrower at 09:08, 20/5/2010, in reply to message #114494
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff Posts: 15100	On re-reading this, am I going off on a tangent and is the (unmodified) source code alone* all that's needed?* The unmodified source should work fine once we get everything else in place (a compiler with VFP/NEON support, VFP/NEON support code in the OS (i.e. FP context switching), YUV overlay support, etc.) Although those three points are obviously only relevant to OMAP - if there's a version of the codec that's been optimised for ARMv3/4/5 and software floating point then we might be able to get something up and running right away.
	[ Log in to reply ]

Trevor Johnson	Message #114497, posted by trevj at 09:36, 20/5/2010, in reply to message #114496
Member Posts: 660	...off on a tangent... The unmodified source should work fine once we get everything else in place... Thanks for clarifying things.
	[ Log in to reply ]

Martin Bazley	Message #114501, posted by swirlythingy at 16:51, 20/5/2010, in reply to message #114496
Placenta Mendacium Est Posts: 460	a compiler with VFP/NEON support... Doesn't extASM do that, or am I imagining things?
	[ Log in to reply ]

Jeffrey Lee	Message #114502, posted by Phlamethrower at 17:10, 20/5/2010, in reply to message #114501
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff Posts: 15100	Doesn't extASM do that, or am I imagining things? Yes, it does. But I doubt the VP8 source code will be in a format which extASM accepts. The original version of GCC 4.1.1 does contain VFP support, but I'm not sure how much of it is functional in the RISC OS port. I might have a play with it in a day or two to see how much of it works. [edit] A quick play with GCC's command line options suggests that VFP support is currently nonfunctional on RISC OS [Edited by Phlamethrower at 20:06, 20/5/2010]
	[ Log in to reply ]

Trevor Johnson	Message #114538, posted by trevj at 15:47, 24/5/2010, in reply to message #114502
Member Posts: 660	BB, OMAP3, DSP and WebM/VP8 thread (with links) at `beagleboard.org`.
	[ Log in to reply ]

Jon Robinson	Message #114563, posted by castlevarich at 13:48, 28/5/2010, in reply to message #114502
Member Posts: 55	Doesn't extASM do that, or am I imagining things? Yes, it does. But I doubt the VP8 source code will be in a format which extASM accepts. The original version of GCC 4.1.1 does contain VFP support, but I'm not sure how much of it is functional in the RISC OS port. I might have a play with it in a day or two to see how much of it works. [edit] A quick play with GCC's command line options suggests that VFP support is currently nonfunctional on RISC OS [Edited by Phlamethrower at 20:06, 20/5/2010] Talking of virtual floating point support, Chris Martin has been unable to recompile FFMpeg using GCC 4, to take advantage of VFP, because it doesn't support AOF libraries. I only have a very hazy idea of how the GCC system works, but how difficult would it be to sort this problem out ????? Jon Robinson (Leeds)
	[ Log in to reply ]

Jeffrey Lee	Message #114569, posted by Phlamethrower at 10:02, 29/5/2010, in reply to message #114563
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff Posts: 15100	Can you elaborate? 1. VFP stands for Vector Floating Point, not Virtual Floating Point. Are you confusing VFP with GCC's softfloat library? 2. VFP doesn't work on RISC OS yet, as I've said. There are two problems stopping it from working - lack of support in the OS (although now that we have the FPEmulator source I'm hoping I'll have that fixed in a few days time), and lack of support in the RISC OS port of GCC (No idea how long that will take to fix!) 3. AOF support was dropped from GCC for a number of reasons - see here. Although that drobe article hints that AOF support might be re-introduced (see the "Interworking ELF and AOF" section), I'm not sure how much of a priority that is for the GCC team, or whether they're even still planning to do it. My advice would be to update FFMpeg so that it doesn't require AOF support. The only reason I can think of for why he'd need it is because he's linking against a library that's supplied in binary form - in which case there's likely to be no guarantee that the library will work fine on the beagleboard.
	[ Log in to reply ]

Martin Bazley	Message #114570, posted by swirlythingy at 10:50, 29/5/2010, in reply to message #114569
Placenta Mendacium Est Posts: 460	Why does VFP require support in the OS? I thought it was just another instruction set decoded by the Cortex processor, like Thumb2, not a software bodge like the FPEmulator instructions. Of course, support in the Debugger disassembler would be useful.
	[ Log in to reply ]

Jon Robinson	Message #114571, posted by castlevarich at 11:09, 29/5/2010, in reply to message #114569
Member Posts: 55	Can you elaborate? 1. VFP stands for Vector Floating Point, not Virtual Floating Point. Are you confusing VFP with GCC's softfloat library? Yes, you're right, I'm confusing Vector FP and Virtual FP. Rather than cause any more confusion, I'll email Chris directly and make him aware of this thread. I'm sure he'll be able to clarify the problem a lot better than I will. Jon Robinson (Leeds)
	[ Log in to reply ]

Jeffrey Lee	Message #114572, posted by Phlamethrower at 12:34, 29/5/2010, in reply to message #114570
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff Posts: 15100	Why does VFP require support in the OS? I thought it was just another instruction set decoded by the Cortex processor, like Thumb2, not a software bodge like the FPEmulator instructions. Of course, support in the Debugger disassembler would be useful. There are a few bits which the OS needs to do: 1. Turn on the VFP/NEON coprocessors 2. Handle context switching so WIMP tasks, etc. don't clobber each other's registers 3. To deal with "uncommon and exceptional instructions that are not dealt with directly by the VFP coprocessor hardware" (see section 6 of app note 98). Basically to simplify the silicon, sometimes support for certain features is provided in software instead of hardware. This was even the case with the FPA in the ARM7500FE. Luckily ARM provide this support code for us, so we just have to hook it up to the undefined instruction handler.
	[ Log in to reply ]

Trevor Johnson	Message #116239, posted by trevj at 13:42, 19/1/2011, in reply to message #114492
Member Posts: 660	ARM and TI listed as partners, so with any luck we'll be able to get hold of some optimised VP8/WebM decoders with minimum of effort. And the Rockchip RK2918 (Cortex-A8) is the first of many to have WebM hardware decoding.
	[ Log in to reply ]