log in | register | forums


User accounts
Register new account
Forgot password
Forum stats
List of members
Search the forums

Advanced search
Recent discussions
- Aemulor (Gen:7)
- GMail and POP (Gen:2)
- !DualHead in use (News:6)
- RISC OS on GitHub (News:1)
- I'm back... (Gen:12)
- R-Comp release !DualHead (News:1)
- August news round-up (News:)
- Revisting the old Acorn magazines online (News:4)
- Jason Tribbeck's code library released (News:13)
- Installing the new ROM release for your Titanium (News:2)
Related articles
- Video conversion on RISC OS
- Newsround
- Aemulor Pro-gress
- Easier video playback on RISC OS?
- Video Processing on RISC OS
- RISC OS on OMAP - the future?
- Building the Dream 4 - Random city basics
- Building the Dream 3 - Random map generators, redux
- Bob and Trev: Resurrection: Just in time
- Monster AI
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
Site Search
Article archives
The Icon Bar: News and features: Video conversion for RISC OS

Video conversion for RISC OS

Posted by Jeffrey Lee on 20:50, 5/12/2006 | , , , , ,
If you've got a lot of TV programmes or other video clips on a PC, chances are you'll be wanting to be able to play them on RISC OS as well. This article will explain how to use free tools to convert them to a suitable format for playback on RISC OS. Furthermore the process can be fully automated, so is ideal for processing large collections.

Know your enemy

Until Cino or Cineroma get released, the only realistic video playback solution for RISC OS is !KinoAMP. KinoAMP can only play MPEG1/2 files, using a software decoder. However it does support some hardware acceleration, either by using Geminus or Thomas Milius's free IntelDMA module. An unaccelerated Iyonix only appears to be capable of playback at 2 million pixels/sec, but by using the IntelDMA module the pixel rate can be increased to 5 million/sec. The pixel rate, in case you're wondering, is calculated using the following formula:
pixel rate = width * height * fps
This means that, for a pixel rate of 5 million/sec, you can watch a 512x384 video at 25fps. Unfortunately it isn't as simple as this, as Adrian Lees discovered some time ago. The Iyonix's onboard sound processor suffers from distortion when large amounts of data are sent through the memory bus. This means that although you can play video at 512x384, it won't sound very nice. After a fair bit of experimenting I've found that the maximum pixel rate that appears to avoid sound distortion is 3.25 million pixels/sec. This gives a resolution of 416x312 for 4:3 programmes, and 480x270 for 16:9 widescreen (Both at 25fps). Even at this pixel rate there are occasionally some audio problems, but stopping and starting the video or moving the window around the screen seems to fix it - like it's some kind of precise timing issue.
Of course pixel rate isn't the only factor that affects playback. Video and audio bitrate, as well as the media source (hard disc, RAM, network, etc.) will all have an effect. If you were to encode at 512x384x25fps, you'd find that the maximum video bitrate that can be decoded is around 1000kbps. For me this resulted in 98% of frames displayed; increasing it to 1300kbps gave 91%; and 2000kbps gave 83%. However since we aren't encoding at 512x384x25fps due to sound issues, you should be able to use bitrates higher than 1000kbps if you want. I find that 850kbps looks fine at 416x312x25fps, so to try and conserve my disc space I'm sticking to that.
Audio rate has much less of an impact, so it's more a question of how much disc space you want to use and what quality you can stand. In this article I'm using 48khz audio encoded at 128kbps. The lowest I'd recommend you go for general use is 96kbps - any lower than that and the quality will drop considerably.
Due to the low total bitrate (around 1000kbps), the filing system you're using won't make much of a difference to an Iyonix. I've successfully streamed from RAM, hard disc, and network (via NFS) without any problems.
A StrongARM RiscPC, on the other hand, will have a much tougher time. I found that 288x216x25fps, with 250kbps video and 48khz audio at 96kbps would result in around 95% of frames displayed in a 16bpp mode, with NFS as the video source. Playing from hard disc increased the value to 97% - and RAM gave 100%. Increasing the bitrate or pixelrate only lowered the performance, as did switching to a 32bpp mode. This would suggest that the maximum pixel rate is around 1.5M.
Currently, for an A9Home I'd expect the values to be somewhere inbetween the performance of an unaccelerated Iyonix (Which can display at 320x240x25fps) and that of a StrongARM. However when KinoAMP or Geminus support use of the A9's DMA controller I suspect the performance will improve, perhaps to that which I'm using on my Iyonix, as the A9 (hopefully) won't be held back by sound distortion.
If you want to experiment yourself, remember that the MPEG video width and height must be a multiple of 2 pixels, and that framerate conversion will generally produce bad results.

The source

For me, all my source videos are MPEG2 files recorded using the Digital TV card in my PC. This means that they're typically 720x576 (interlaced) at 25fps, with video bitrates of around 2500kpbs, and 48khz MP2 format audio at bitrates of 128kbps and above. Trying to play them back on an Iyonix (streaming the files over NFS) results in a measly 35% of frames being displayed, giving a 9fps slideshow. Reducing to 50% scale only makes matters worse, as it prevents IntelDMA from being used. Things may be different for Geminus users, but I doubt 100% framerate can be achieved at any reasonable resolution (If at all).
Most of the rest of this article (in particular the script at the end) will assume your source video is in the same format as mine. Changing the script to work with other formats should be relatively simple, however.

The destination

There are two output formats that my script uses. These can easily be changed in the script itself:

  • MPEG1 video at 416x312x25fps, 850kbps, with 48khz MP2 audio at 128kbps
  • MPEG1 video at 480x270x25fps, 850kbps, with 48khz MP2 audio at 128kbps (for 16:9 widescreen programmes. For a StrongARM, you'd want 328x184x25fps)
Conversion to MPEG2 is also possible, which will allow you to use interlaced output and (in theory) increase the resolution of the video. However I haven't been able to find find a free encoder that supports interlaced output.

The tools

I'm using 4 tools running on my Windows PC to perform the conversion. However these are all cross-platform, so should be readily available on Linux or MacOS.

  • ffmpeg
    This is the main workhorse. Available for Windows, Linux and MacOS, ffmpeg can decode and encode a plethora of audio and video formats. Unfortunately the builtin MP2 encoder produces very poor output at low bitrates, which is why I use toolame instead.
  • toolame
    Toolame is an MP2 encoder, in a similar vein to the 'lame' MP3 encoder. Windows versions are available on the sourceforge pages, but Linux or MacOS users may have to compile their own. Just make sure you get version 0.2k instead of 0.2l - the 0.2l output appears to be broken and won't work with Winamp or ffmpeg.
  • Perl
    I'm using Perl to automate the conversion process. A script scans my input folder and converts the vieos, storing them in the output folder.
  • mpgtx
    mpgtx is a small app that can report on the format of MPEG files. It's used by the Perl script to identify what output resolution to use. I think it's possible to do away with this and use ffmpeg to report the file information, but it's something I haven't tried.

The process

My Perl script uses a 6-stage process on each file it converts:

  1. Run mpgtx on the file, to identify the picture format (4:3 or 16:9). This dictates the output resolution (416x312 or 480x270)
  2. Run 'ffmpeg -i INPUTFILE -vcodec mpeg1video -r 25 -s RESOLUTION -b 850k -acodec copy temp.mpg' to encode the video. '-acodec copy' causes ffmpeg to merely copy the source audio - this is so that it can later be extracted and run through toolame.
  3. Run 'ffmpeg -i temp.mpg -ar 48000 temp.wav' to extract the audio from the output file to a .wav. I'm using the output file instead of the source file in an attempt to maintain A/V sync, as it's feasible that the timeline has been altered a bit by the video conversion process (dropping frames, correcting timestamps, etc.) So far it seems to have worked, but I haven't tried using the source file as the audio source, so it's possible that my fears are unfounded.
  4. Run 'toolame -s 48 -b 128 temp.wav temp.mp2' to encode the audio
  5. Run 'ffmpeg -i temp.mpg -i temp.mp2 -vcodec copy -acodec copy -map 0:0 -map 1:0 OUTPUTFILE' to replace the original audio with the new stream.
  6. Delete the temporary files
If you aren't using MPEG1/2 as input, then you may find that the '-acodec copy' in step 2 will fail, as your input audio format isn't valid for placing in the resultant MPEG1 file. To solve this you can get ffmpeg to do the audio conversion for you (resulting in poor quality), or it may be possible to use an AVI file as temporary output. Or, have ffmpeg only output video in stage 2, and have toolame operate on audio extracted from the source file.

The script

The Perl script below will automate the above process, examining each file in the input folder and converting them to files in the output folder if a copy doesn't already exist. It also performs the audio conversion as a seperate step - this is because before getting toolame working, I merely left the audio at the source bitrate. The Perl script therefore accounts for this by checking the audio bitrate of each output file, and fixing the bitrate on any files which haven't been converted yet.
I also discovered that some files weren't accepted by mpgtx as valid input, so have manually added their names and output resolution to an array at the top of the file. These files could be failing either because the TV card or Mpg2Cut2 wrote bad headers (Mpg2Cut2 is a GOP-based editor I've been using to remove ads from programmes. GOPchop is a similar program available for Linux)
mpgconv.pl (plain text version)

The result

82GB of movies and TV programmes converted to 30GB of Iyonix friendly MPEG1 files. On my 2GHz PC, an hour of TV footage can be converted in about 15-20 minutes using the above script.
When watching videos using KinoAMP, make sure you use DiskSample as the audio decoder, to avoid A/V desyncs and crashes when seeking through files. Also, when using the IntelDMA module, don't worry about the setting of the 'Scaler' option - IntelDMA will be used no matter what you choose (providing you watch at 100% scale).

As you can see above, you've also got to watch out for video decoding errors in KinoAMP. Note the phantom finger in the frame on the left, and the blurryness of the leg. These artifacts then vanish on the following frame (an I frame, shown on the right). The constant appearance and disappearance of these errors can be annoying - but both Winamp and my Zaurus play the videos fine, so I can only assume it's a problem with KinoAMP.


A brief Q&A with some fellow TIB staff:

Q.Why not just watch them on the PC? Presumably you have to have it on to access the file anyway, so you could watch it in higher resolution straight away without having to wait for it to be converted.
  1. My PC and Iyonix share their monitor, so I can't watch a video while using RISC OS.
  2. I can always copy the files from the PC to my Iyonix, thus absolving me of the requirement of having the PC turned on.
  3. If I were to just watch them on the PC, then I wouldn't be writing this informative article, would I?
Q.What about Google Video?
A.There seem to be two formats available from Google: Some quasi-propriatary Google Video format, and straight MPEG4. We can't play MPEG4 on RISC OS (for now, at least), but it can be converted to MPEG2 via ffmpeg.
Q.What about video conversion on RISC OS?
A.As evidenced by this newsgroup thread, there is a (rather old) port of ffmpeg for RISC OS. In the interests of SCIENCE I decided to have a go at using it to convert some of my videos. The first one I tried, it wasn't able to detect the input format, despite the file working fine with the latest PC version. The second one I tried was an MPEG4 from Google Video - it did detect the format, but then promptly told me it was unsupported. Then I tried another MPEG2, and this one worked - except it was encoding at a rate of about 25 frames every 10 minutes, and spitting out hundreds of errors. After an hour or so StrongED crashed, but the taskwindow kept running... until a while later when processing seemed to stop. The resulting MPEG1 file was almost entirely corrupt, only the audio track beared some resemblance to the source.
There is hope, however - apparently ffmpeg is part of the GCCSDK autobuilder, so if you can put up with ludicrously slow conversion rates you should be able to grab the latest source and run it throug the autobuilder (Which will require a Unix-like environment, one which will typically come with a meaty PC, one which would be far better suited to doing video conversion than a RISC OS machine).
Q.What about VideoCD?
A.VideoCD uses a video resolution of 352x288 for PAL, and a bitrate of 1150kbps, with 224kbps MP2 audio. A quick test using a video encoded with those settings shows that (with help from IntelDMA/Geminus), an Iyonix can easily decode VideoCD quality video. All that remains is for the required software to be written to provide a frontend to the VCD filesystem structure.
Q.What about your Zaurus?
A.The 'better performance than an Iyonix' that I've initially touted only took into account the speed of an unaccelerated Iyonix. I haven't worked out the exact limits, but I do know that 384x288x25fps at 500kbps works fine, but 416x312x25fps at 850kbps is too much. 384x288x25fps is 2.8Mp/s; so for widescreen you'd want 432x240x25fps. It may be possible to increase the bitrate above 500kbps, but file size is more precious on such a small device.

  Video conversion for RISC OS
  ksattic (21:11 5/12/2006)
  Chris (14:14 6/12/2006)
    Phlamethrower (00:23 8/12/2006)
      richcheng (10:50 8/12/2006)
        Phlamethrower (11:13 8/12/2006)
          Phlamethrower (13:15 8/12/2006)
          adrianl (19:16 8/12/2006)
            Phlamethrower (21:48 12/12/2006)
Simon Wilson Message #95387, posted by ksattic at 21:11, 5/12/2006
Finally, an avatar!

Posts: 1288
KinoAMP really needs to be patched for the Iyonix to do colourspace conversion and scaling in hardware. I know in principle how to do it and have a bit of code on my computer for it, but I think it would take a lot of time to do.

What you do is set up an overlay surface on the graphics card to convert from the video's source colourspace (i.e. YUV422) to the destination frame buffer (i.e. RGB888 ) and then write your pixel data directly into that source buffer.

I believe Cineroma does this. I also bet Adrian Lees could vastly improve the algorithms to do the MPEG decoding. Also, one day we will discover the holy grail of doing portions of the MPEG decoding in hardware. :)
  ^[ Log in to reply ]
Chris Message #95424, posted by Chris at 14:14, 6/12/2006, in reply to message #95387
Posts: 283
Interesting article. Geminus really does make a difference, according to those figures. Would the version for the A9 make things similarly quicker? If so, I might look into getting a copy.

I do wish Cineroma would emerge - I reckon people would quickly forgive any quirks or rough edges if the playback was better than KinoAmp.
  ^[ Log in to reply ]
Jeffrey Lee Message #95563, posted by Phlamethrower at 00:23, 8/12/2006, in reply to message #95424
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
OK, it looks like my comments about IntelDMA not working on my machine are a complete lie. I was merely confused because an 'IntelDMA' option didn't appear in the settings window when the module was loaded.

As it turns out, as long as you have the module loaded, KinoAMP will make use of it whether you choose the internal or system scaler.

So now, I'll do some more messing around and update the article once I've found the upper limits. And re-encode all my files, I guess.

But otherwise: Yay!
  ^[ Log in to reply ]
richard cheng Message #95581, posted by richcheng at 10:50, 8/12/2006, in reply to message #95563

Posts: 649
Hmm... I'm not following this. Is it the case that using either Geminus or the IntelDMA module will improve speed, and in which case, which is better?

Or can they both be used in concert?
  ^[ Log in to reply ]
Jeffrey Lee Message #95583, posted by Phlamethrower at 11:13, 8/12/2006, in reply to message #95581
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
They can't be used together, and according to the KinoAMP docs, IntelDMA is better.
  ^[ Log in to reply ]
Jeffrey Lee Message #95590, posted by Phlamethrower at 13:15, 8/12/2006, in reply to message #95583
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
As regards the A9 - depending on the details of the graphics chipset, Geminus may/may not be able to provide generic acceleration for it. As I undertsand it, the current version doesn't provide acceleration.

But as long as there's a user-programmable DMA controller available (Which I guess there must be), I can't think why KinoAMP can't be modified to use that to copy the output to screen (like it does with IntelDMA).

Of course someone with knowledge of the A9's hardware would be able to say for certain :)
  ^[ Log in to reply ]
Adrian Lees Message #95605, posted by adrianl at 19:16, 8/12/2006, in reply to message #95583
Posts: 1561
They can't be used together, and according to the KinoAMP docs, IntelDMA is better.
There shouldn't be any significant difference between Geminus's DMA acceleration and that provided by the IntelDMA module, the speed being dependent upon a hardware operation. There may be some difference in the rendering code that KinoAMP uses in these two cases, though.

If I ever get around to finishing it, my Blitz library should be an improvement upon either of the above options, providing a means of DMA plotting/scaling from a number of output buffers and optionally synchronising the plotting with the VSync(s) to avoid tearing. It will also cache DMA descriptors to avoid repeated logical->physical address translations and make use of whatever DMA hardware is present - IOP321 or the S3C2440 (A9home), if any.

The plan was to release it in a form that allows it to be easily plugged into apps such as KinoAMP, PicoDrive, Cino (where the code originates from) and maybe even something like Avalanche.
  ^[ Log in to reply ]
Jeffrey Lee Message #95714, posted by Phlamethrower at 21:48, 12/12/2006, in reply to message #95605
PhlamethrowerHot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff

Posts: 15055
The article and conversion script have now been updated with my findings after using IntelDMA.
  ^[ Log in to reply ]

The Icon Bar: News and features: Video conversion for RISC OS