Hello, I thought I'd say a few words about where Cino stands at the moment and how it got here. Those of you who went to the RISC OS South East show in Guildford will probably know much of this already, but others may be wondering.
Cino was a project waiting to happen since October of last year when Castle's pre-production Iyonix included a DVD-ROM drive - personally I suspect this may have been a deliberate ploy on their part! - but we only started working seriously mid-September, ie. about 6 weeks ago.
So, as we repeatedly said at the show, it's early days so there's no need to be worried about the 'frame rate' yet - it will get faster, just as Aemulor did. Nevertheless, we already have:
- a module called DVDATAPI that uses SCSI commands over the ATA bus to the DVD-ROM drive
for authenticating itself with the drive, reading data and issuing commands to control
CD audio playback etc. This is just a 'driver' module that just does the low-level
command sending/receipt. Other driver modules can be written to support SCSI DVD-ROM
drives, or perhaps even USB drives later.
- the DVDFS filing system module that will provide the filing system for CD- and DVD-
media (ISO9660, Joliet extensions - for long filenames - and UDF - for DVDs and multi-
session CDs). The filing system is currently the least-developed part of Cino because
we felt it would be better to have video & audio playback for the show rather than
just being able to read DVD discs.
The DVDFS module also provides the usual CD-related *commands for playback.
- DVDFiler is comparable to CDFSFiler, ADFSFiler etc.. it's a simple Wimp task that
provides the 'starting point' for all CD/DVD access, plus a player for audio CDs
and it will start Cino if you give it a DVD-Video disc.
- the DVDAudio module provides audio output, talking to the existing 16-bit sound
system and/or separate drivers for PCI sound card(s)... see below.
- Cino itself, is the video player application which knows how to unscramble,
decode and decompress the video & audio streams, using all of the above modules.
It will run either full-screen or in a window and can resize the displayed video
to any size/aspect ratio though we deliberately disabled the resizing code for
the show because it's currently being reworked for extra speed now that Cino
uses DMA to accelerate its screen rendering.
What you won't have seen at the show, because it didn't exist then, is an experimental driver for the Emu10k1 audio DSP as used on the SB Live! 5.1 and SB Audigy PCI sound cards.
This is something we've been working on over the past week and we can now output digital stereo PCM to a hi-fi using either of these PCI cards. I haven't managed to get full 5.1 output
going just yet, but I will; need to do more research/study on the card & particularly the DSP.
At the show we demonstrated Cino with audio or video playback since the code presently isn't fast enough to do both, causing the audio to break up whilst the video is being decoded... I've emphasised that because I've already done a lot of work on the video rendering because early tests showed us that rendering was likely to be slow. Decoding hasn't yet received the same attention.
The OS sprite rendering calls, for example, manage only 9 images/second for our 720 x 576 (PAL-DVD) format, and use the whole CPU to achieve just that. Clearly that's unacceptable, so I instead wrote some XScale-tuned code using prefetching to reduce the amount of time the IOP321 spends stalled waiting for data from the SDRAM memory, and tuning the writes to utilise the PCI bus better and that resulted in 35 images/second, but still using the full CPU time.
The IOP321, however, includes two DMA controllers, one of which Cino now uses to render images on the screen since this approach achieves 65 images/second and leaves the XScale core free to operate from its caches and SDRAM, ie. to decode the data.
Cino is currently spending a good percentage of its time waiting for input data from the DVD-ROM, time that could be used for productive work decoding video and audio data instead. This is something we still need to address by replacing/improving the code in the ADFS module for reading from ATA devices. In particular, ADFS currently uses PIO transfers for reading from CD/DVD devices, so we'll need to change this to use DMA. Furthermore we need to implement 'non-blocking I/O' which means that the CPU initiates the read and is then free to do other work whilst the data arrives.
RISC OS doesn't even do this for DMA-enabled hard disk reads at the moment because there's no other work it can do since it can't switch tasks pre-emptively and it can't let the current task continue until all the data has been read.
The version of Cino that we demonstrated at Guildford was actually using some experimental non-blocking input code, but I couldn't get DMA working in time, so it's still spending from 10% to 40% of its time waiting for data. I should point out, though, that it was also dropping 'B-type' pictures (pictures upon which no other picture depends and can thus be safely dropped), which means the time spent waiting for data becomes more significant.
All of that aside, playback of NTSC (region 1) streams (which, ironically we didn't demonstrate!) is not too far from being viewable already, though it breaks up quite badly when the image is changing rapidly.
So, that's where things stand today; clearly I still have a lot of work to do, but just 6 weeks ago Cino was nothing more than a dream and a couple of DVDs that I'd bought to 'force' myself to write a player!
But now I need to put my Aemulor hat back on and sort out the 3 or 4 known bugs that I promised to fix too many weeks ago now...
Informal forum to keep you all informed on development progress
1 post • Page 1 of 1