log in | register | forums
Show:
Go:
Forums
Username:

Password:

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

Advanced search
Recent discussions
- Elsear brings super-fast Networking to Risc PC/A7000/A7000+ (News:)
- Latest hardware upgrade from RISCOSbits (News:)
- Accessing old floppy disks (Gen:1)
- RISCOSbits releases a new laptop solution (News:4)
- Announcing the TIB 2024 Advent Calendar (News:2)
- RISC OS London Show Report 2024 (News:1)
- Code GCC produces that makes you cry #12684 (Prog:39)
- Rougol November 2024 meeting on monday (News:)
- Drag'n'Drop 14i1 edition reviewed (News:)
- WROCC November 2024 talk o...ay - Andrew Rawnsley (ROD) (News:2)
Related articles
- Newsround
- Easier video playback on RISC OS?
- Video conversion on RISC OS
- Bob and Trev: Resurrection: Just in time
- Monster AI
- Combat
- Visibility and pathfinding
- The level generator
- Static game data
- How to fit a roguelike in 32k
Latest postings RSS Feeds
RSS 2.0 | 1.0 | 0.9
Atom 0.3
Misc RDF | CDF
 
View on Mastodon
@www.iconbar.com@rss-parrot.net
Site Search
 
Article archives
The Icon Bar: News and features: Video Processing on RISC OS
 

Video Processing on RISC OS

Posted by Jon Robinson on 22:00, 11/1/2010 | , , ,
 
One of the frustrating things about being a RISC OS user, is its lack of support for commonly-used video formats, other than its own dedicated Replay system.
 
A few attempts have been made to remedy this situation, but, until recently, they have come to nothing.
 
In the mid-1990s, Innovative Media Solutions produced a range of Acorn readers for PC-format, educational CDs, such as Microsoft Dinosaurs and Dorling Kindersley's The Way Things Work. These readers included dedicated versions of ARMovie, which could convert the CD’s AVI files to Replay format on the fly.
 
Unfortunately, the work that IMS had done, did not result in the release of a souped-up version of Replay, which could play all Quicktime and AVI movies, despite the fact that RISC OS Ltd seem to have done some work in this area about five years ago.
 
But now, with the release of the open-source applications, Murnong and FFMpeg, by Chris Martin, things have started to take a turn for the better.
 
Although RISC OS still does not have a proper media player, which can play all the common video formats, we do now have the next best thing - an application that can capture a YouTube video stream as it arrives, and convert it to an MPEG file, which can be played using KinoAmp.
 

Using Murnong

The first thing to do is to install the latest versions of Murnong, FFMpeg and Mpgtx, if you don't have them already.
 
Now load the !Murnong application, so that its icon appears on the icon bar.
 
Load your favourite web browser up, and navigate to an interesting YouTube video.

This short film about an invasion of giant robots, allegedly made for $300, has won its Uruguyan director a $30 million contract from Sam Raimi, to make a Hollywood sci fi film!

Select Save Web Page from the browser’s menu, but instead of dragging its file icon onto your hard drive, drag it onto the Murnong icon on the icon bar.
 
Murnong will respond by opening a Fetch Video dialogue box, so name the output file, and drag its icon to the disc or directory you wish to save it on.
 
Murnong will now calculate the path to the actual YouTube FLV video, contained in the page, and launch another application called Wget to actually retrieve it. (Incidentally, YouTube keep changing the way their system retrieves these videos, so Chris has already had to update Murnong a couple of times to keep pace with these changes.)
 
Once you have the FLV video saved as a Data file, you can drag it back onto the Murnong icon on the icon bar. This will open a simple conversion window, allowing you to convert just the audio or video content, or both, to an MPEG file and convert from 12 frames a second to 24, if required, to make the video playable in KinoAmp.
 
Although it is fairly easy to make playable versions of YouTube videos this way, there are two common problems with many of them.
 
One is that the videos have rarely been cut out neatly, so there is often distracting material before and after the bit you really want. This not only reduces its impact, it also wastes valuable hard drive space.
 
The other problem, is that material that has been transmitted on television, usually has ugly, black bars around the edges of every frame, and often has a ‘tear’ running along the bottom. This would not have been visible on your television set, but nearly always seems to be present on stuff that was originally recorded on a VHS tape recorder.
 
As long as you are quite happy with what YouTube gives you, there is no need to delve any deeper.
 
But if you wish to extract clean, high-impact clips from whatever you have downloaded, at some point you will need to get your hands dirty, and start to experiment with FFMpeg, the versatile, video-processing program that lies at the heart of Murnong.
 

Using !FFMpeg

This time, I am going to use the FFMpeg application to convert the downloaded FLV Data file, rather than just dragging it back onto the Murnong icon to do it.
 
There are two ways of using FFMpeg:

  1. You can load the application onto the icon bar, and drag the FLV file onto its icon, as you would with Murnong.
  2. you can use an Obey file, which supplies the input file name, along with any conversion options.
For the moment, just load !FFMpeg, then drag the FLV file onto its icon on the icon bar.
 
This opens a task window, which reports on the audio and video contents of the file, and also opens a dialogue box, which allows you to select the conversion options that you require.

Make sure that Quality is set to Same as Input, and Audio to Copy, then drag the output file icon onto your RAM disk, and click on Convert.
 
Also note the Cutting section at the bottom, and the Cropping section on the right - we will be looking at these again later.
 
Once the conversion has completed, select the data file on your RAM disc and set its file type to BF8, before playing it in KinoAmp.
 

Using Obey Files

Although just dragging the FLV file onto the program icon, and filling in the dialogue box, is the easiest way to use FFMpeg, there are two big problems with it:

  1. Because it is multi-tasking, when called from the application front end like this, it will also be slower than it would be, if it were called from an Obey file and run as a single task.
  2. If it is run multi-tasking, and you carry on doing something else while it does the conversion, there is a danger that you could trash your machine, if one of the other programs crashes while FFMpeg is writing to your hard drive.
If you are going to use the front end, it would be best to leave the machine alone while it converts the file, to avoid this danger.
 
If, however, you intend to convert a lot of video files, it would be better to learn how to do it using Obey files.
 
From now on, I will be explaining how to do this, but also showing which options need to be chosen on the front end, in case you are still allergic to using Obey files.
 
The YouTube movie I am going to use, is a collection of vintage adverts dating back to 1969, which can be downloaded from here.
 
To use an Obey file to do a straigtforward conversion to MPEG, as we have just done using the front end, load a text editor such as Zap.
 
The basic forms of the files that you will need, are provided as a zip file, and it is easier to amend these, than it is to create them from scratch.
 
But it IS worth knowing the quick way of entering file names, without having to worry about making mistakes in the file path.
 
We want to create an Obey file that looks roughly like this:
ffmpeg:ffmpeg -i 1969/flv -f mpeg -sameq -acodec copy RAM::RamDisc0.$.1969,BF8
So enter the text above (or load ConvToMpeg from the zip file), but leave (or make) a blank space where the red bits go.
 
Now, the easiest way to enter the path name for 1969/flv, is to find it on your hard drive, hold down the Shift key, then drag its file icon into the Zap window, with the cursor positioned just after the -i (the input file).
 
If the edit window fills up with rubbish, you know you have done something wrong !!!
 
Also, if the path name pushes the rest of the instruction onto a new line, delete the line break, otherwise the Obey file will not run properly.
 
Now drag a small file into the RAM disc, shift-drag its file icon into the Zap window at the end of the line, to put in the path, and change the file name to 1969.
 
Add ,BF8 (without leaving a space on either side of the comma) to the end of the line, to get FFMpeg to set the output file type to MPEG, rather than Data.
 
By now, your Obey file should look like this:
ffmpeg:ffmpeg -i ADFS::HardDisc4.$.1969/flv -f mpeg -sameq -acodec copy RAM::RamDisc0.$.1969,BF8
Save it as an Obey file, with the name ConvToMpeg, and run it to check that it works.
 

Extracting A Shorter Clip

Once we have the basic form of this Obey file, it is fairly easy to modify it to achieve other effects, such as extracting clips from longer sequences, changing the audio or video format within the MPEG container, or cleaning up the edges of the frames, if needs be.
 
The next job is to extract a short clip from the sequence, using the Findus Fish Fingers advert as an example, so make a copy of ConvToMpeg and name it ExtractClip (or use the one provided in the download).
 
Now play the file 1969 in KinoAmp.
 
As soon as you have reached the beginning of the section you want to extract, left-click in the player window to pause it, then middle click and select Film->Info from the menu.

Look up the time code value of the beginning of the clip, next to Playing Time.
 
Make a note of it, then close the dialogue box, and left-click in the player window again to resume play.
 
Left-click once more at the end of the required clip, and look up the Playing Time again, to find the time code value for the end of the clip.
 
Subtract the previous time code value, to calculate its duration.
 
Having obtained the rough -ss and -t values (start time and duration) for the clip, in this case 120.80 and 43.80, load ExtractClip into Zap, then edit it so that it looks something like this:

ffmpeg:ffmpeg -ss 120.80 -t 43.80 -i RAM::RamDisc0.$.1969 -f mpeg -sameq -acodec copy RAM::RamDisc0.$.FishFingers,BF8
(Note: the -ss and -t arguments must come before the -i input file argument, otherwise FFMpeg will throw a tantrum.)
 
In fact, probably because of the poor quality of the original recording, simply running ExtractClip like this, results in a movie in which the sound plays about a second behind the picture. Running ExtractAlf, from the download, will correct this problem, by extracting the audio and video content seperately, a second apart, to bring the two back into sync again.
 
Also, with other files, you will probably have to run the Obey file several times, with slightly different values of -ss and -t, to ‘walk in’ the beginning and end points of the clip, if you really want to get a neat result (or enter the Start Offset and Duration on the Convert screen, if you are using the application’s front end).
 

Cleaning Up The Edges

By this time, you should have an MPEG clip, which starts and stops in the right place, but still has thick black bars around the sides, and often also has a kind of ‘tear’ running along the bottom.
 
If you want to remove these borders and the ‘tear,’ there is a cropping facility within FFMpeg, which allows you to do just that.
 
Allow the movie to play in KinoAmp, until you reach a light-coloured frame, then middle click and select Film->Save Frame.
 
Now examine the resulting sprite file, bump up the Zoom to about 6 to 1, then select white as the painting colour, and draw a single pixel line across the four borders.

Count the pixels to measure the width of the borders, then copy ConvToMpeg again as CropBorders, and change it to look something like this:

ffmpeg:ffmpeg -i RAM::RamDisc0.$.FishFingers -f mpeg -sameq -acodec copy -cropleft 8 -croptop 0 -cropbottom 2 -cropright 8 RAM::RamDisc0.$.FishFingers2,BF8
(Alternatively enter these values in the Cropping section on the Convert screen).
 
Et voila! Once you have run this, you will have a much neater clip with nice, neat edges, whose picture and sound quality is as good as the YouTube original.

Alf Garnett - head of one of Britain’s most famous dysfunctional families!

And once you have ConvToMpeg, ExtractClip and CropBorders, it is a simple enough job to use them again with different input files.
 
To make things easier, download the zip file, which contains a basic form of the three obey files, so you don't spend ages trying to get the syntax right.
 
Just remember to be careful when editing them!
 
Homework: Now use ExtractClip and CropBorders to extract the Cadbury’s Flake or Sunsilk Shampoo adverts from the same sequence.
 

Extracting Sound or Video Only

If you wish to play some of the music that you have downloaded in a CD player, you can extract just the sound component of it, and save it as a WAV file.
 
You can do this from the Convert screen, by selecting Wave as the output format, or with an Obey file like this:

ffmpeg:ffmpeg -i RAM::RamDisc0.$.1969/flv -f wav RAM::RamDisc0.$.SoundOnly,FB1
You can also take advantage of the fact that the audio component of most YouTube videos seems to be encoded in MP3, to quickly extract an MP3-format copy of it.
 
First drag the FLV file onto the FFMpeg icon on the iconbar, to get the program to check that the audio is encoded in MP3 format, then run an obey file like this:
ffmpeg:ffmpeg -i RAM::RamDisc0.$.1969/flv -f wav -acodec copy RAM::RamDisc0.$.MusicOnly,1AD
Another neat trick you might want to do with some videos, is to remove an annoying sound track and save just the video component, using the -an, no sound, option.
ffmpeg:ffmpeg -i RAM::RamDisc0.$.1969/flv -f mpeg -sameq -an RAM::RamDisc0.$.NoSound,BF8

Changing the Frame Rate

Another thing that you often have to do, especially with footage that comes from a digital camera, is to increase the frame rate so KinoAmp can play it.
 
Many of these videos end up being encoded on YouTube, as 15 frames-per-second FLV files, and FFMpeg will not allow a simple conversion on these, because such a slow speed is not permitted under the MPEG file specification.
 
To get around this, you have to encode the file at 24 frames per second, using the -r 24 argument, in front of the output file name:

ffmpeg:ffmpeg -i RAM::RamDisc0.$.Slower/flv -f mpeg -sameq -r 24 RAM::RamDisc0.$.Faster,BF8
A good place to practice this, is with Sophie Wilson’s ‘History of Acorn Computers’ talk, which starts here
 

Extracting a Clip from a DVD

If you look in the VIDEO_TS directory of a home-recorded DVD, you will see a collection of files named something like VTS_01_1/VOB, etc.

These VOB files are the recorded MPEG data created by your DVD recorder.
 
On a full disc, there would typically be five of these, each one over a gigabyte in size, representing about 25 minutes of recording time each, at Standard Quality. So a clip that occurs 40 minutes into the recording, is likely to be in the second VOB file.
 
The first thing to do, assuming you have enough hard drive space available, is to copy the VOB file, containing the clip you want to extract, onto your hard drive.
 
Once you have this, set the file type to BF8 for MPEG, and play it using KinoAmp.
 
As before, once you have reached the beginning of the section you want to extract, left-click in the player window, then middle-click and select Film->Info from the menu.
 
Look up the time code value of the beginning of the clip, next to Playing Time.
 
Make a note of it, then close the dialogue box, and left-click in the player window again to resume play.
 
Left-click once more at the end of the required clip, and look up the Playing Time, to find the time code value for the end of the clip.
 
Subtract the previous time code value, to calculate its duration.
 
Having obtained the rough -ss and -t values (start time and duration) for the clip, create and run an Obey file that looks something like this, but subtract a couple of seconds from the value of -ss and add four to -t, so that the resulting file will have a bit of space on either side of the reqired clip.

ffmpeg:ffmpeg -ss 11.92 -t 130 -i ADFS::HardDisc4.$.VTS_01_1/VOB -f mpeg -sameq -s 'cif' ADFS::HardDisc4.$.MyClip,BF8
The -s 'cif' size arguement produces an output file that is a quarter of the size of the original - 360 pixels by 288, instead of 720 by 576.
 
As an alternative, you can use -s '4cif' which produces a clip of the same dimensions as the original, but on a StrongARM RiscPC this would only play at about one frame a second.
 
Warning: Down-sizing from DVD quality to a quarter size is very processor intensive, and converting one minute of DVD video, on a StrongARM RiscPC, takes about 25 minutes. Do not convert any more than you have to, and if you are planning to extract a long sequence, it might be best to leave it running overnight.
 
We can now treat MyClip as if we have just downloaded it from YouTube.
 
Play it in KinoAmp, to establish the required values of -ss and -t more accurately, and then edit ExtractClip, to ‘walk in’ its beginning and end points, if you really want to get a neat result.
 
By now, you will probably have realised that you can use the time settings of ExtractClip, and the remove border settings of CropBorders in one Obey file, ProcessClip, which will look something like:
ffmpeg:ffmpeg -ss 1.24 -t 124.60 -i ADFS::HardDisc4.$.MyClip -f mpeg -sameq -acodec copy -cropleft 6 -croptop 22 -cropbottom 26 -cropright 6 ADFS::HardDisc4.$.MyClip2,BF8
and will cut the required processing time in half!
 
Please note: DVD+Rs have to be finalised in your DVD recorder, before CDFS will read them properly and allow you to get at the individual VOB files.
 

Splicing Film Sections together using Mpgtx

Another useful utility Chris Martin has ported to RISC OS, is the film splicer Mpgtx, which allows you to join segments of film together into one video.
 
The process of splicing is actually very simple, as long as the segments you want to join have been encoded with identical audio and video settings, and there is no unwanted padding before, or after, any of the required segments.
 
If that is the case, you can simply convert each of the segments seperately, then join them together using an Obey file something like this:

ADFS::HardDisc4.mpgtx -j ADFS::HardDisc4.Seg1 ADFS::HardDisc4.Seg2 ADFS::HardDisc4.Seg3 -o ADFS::HardDisc4.Joined
If the audio and video settings do not match, however, or it is necessary to remove unwanted material before, or after, the different segments, then the job does become more difficult.
 
To explain how we might process different segments to get around these problems, we can take a missing episode of Doctor Who as an example (and make a detour into the history of British television along the way).
 
Over the years, the BBC has ‘lost’ more than a hundred early, black-and-white episodes of Doctor Who!
 
After transmission, the original recordings were transferred from (then very expensive) videotape onto cheaper, celluloid film. The film copies were then gradually thrown out, because the BBC didn’t think anybody would ever want to see them again.
 
They only stopped this practice of ‘junking’ old, black-and-white episodes of classic series around 1978, when the emergence of the home video recorder created a whole new market for vintage British television.
 
The first of these missing episodes, is the first installment of the Marco Polo story, The Roof of the World, broadcast only once in 1964.

The First Doctor, William Hartnell, at his cantankerous best

The first Doctor, William Hartnell, at his cantankerous best!

Luckily, a few early Doctor Who fans were in the habit of recording the show onto audio tape, and there was an enterprising photographer called John Cura, who made a living by photographing his television screen, as programmes were being broadcast, and selling the resulting photos to interested TV producers and actors.
 
Without John Cura, we would have almost no visual record of many early TV programmes, for not only were many ‘junked’ to save space, but many others, like the early episodes of The Avengers, were broadcast live from a studio, and were never actually recorded in the first place.
 
Now, forty years later, a small band of enterprising fans are slowly marrying up the sound recordings of these early, missing Doctor Who episodes with the ‘Cura telesnaps,’ to produce the best representation of these programmes we are ever likely to have . . . at least until somebody takes a DVD recorder back to the 1960s in a home-made TARDIS!
 
These reconstructions are slowly turning up on YouTube, but because of the maximum time limits that they impose on videos, they will usually have been chopped into segments less than ten minutes long. Consequently, a 25-minute programme will have had to have been split into three parts, to get it onto YouTube in the first place.
 
It is, therefore, a good test of Mpgtx and FFMpeg, to see if we can use them to stitch some of these segments back together, and restore The Roof of the World to its former glory!
 
The first thing to do is to download the three sections of the episode, one, two and three, and save them as Marco1, Marco2 and Marco3/flv.
 
Although we could simply join the three segments together, we won’t get a very good result like that.
 
Some of the sections have an advert for BBC Audio at the end, and even once that has been removed, the start of the next segment does not line up precisely with the end of the previous one. So some ‘trimming’ is required to get the three segments to fit together neatly.
 
But there is a more serious problem, which soon becomes apparent if you drag the three FLV files onto the FFMpeg icon, and see what the program makes of them.
 
The audio settings on the first file are 56 Kb/s, mono, on the second, 64 Kb/s, mono and on the third 48 Kb/s, stereo. Also the first two files are 320 by 240 pixels in size, while the third is 352 by 264!
 
The audio paremeters are different in each file, and the last one has a larger frame size than the first two.
 
If we want to produce a joined MPEG file that is actually playable, we will first have to use FFMpeg to process the three files, so that the audio and video parameters are identical.
 
The first thing to do is copy Marco1/flv into your RAM disc and run an Obey file something like this:
ffmpeg:ffmpeg -t 425.44 -i RAM::RamDisc0.$.marco1/flv -f mpeg -sameq -ab 64k -cropleft 2 -cropright 2 -cropbottom 2 RAM::RamDisc0.$.Marco1,BF8
The -t arguement cuts off the advert for BBC Audio at the end, and the -ab 64k adjusts the bit rate of the first segment, so that it matches that of the second.
 
Now shift-drag Marco1/mpg onto your hard drive, copy Marco2/flv on to RAM disc, and run this Obey file:
ffmpeg:ffmpeg -ss 6.4 -t 559.00 -i RAM::RamDisc0.$.marco2/flv -f mpeg -sameq -cropleft 2 -cropright 2 -cropbottom 2 RAM::RamDisc0.$.Marco2,BF8
Shift-drag Marco2/mpg onto your hard drive, and copy Marco3/flv on to RAM disc.
 
We need to cut about 3 seconds from the beginning of this segment, but if we try to do this while converting straight to MPEG, we get a ‘buffer underflow’ error, so we have to shuffle sideways and process this FLV in two stages.
 
To do this, we have to run the scariest Obey file of them all:
ffmpeg:ffmpeg -ss 3.12 -i RAM::RamDisc0.$.marco3/flv -f avi -sameq -ac 1 -ab 64k -cropleft 18 -cropright 18 -cropbottom 14 -croptop 12 -vcodec mpeg1video RAM::RamDisc0.$.Marco3/AVI,FB2
This cuts out the unwanted three seconds, adjust the audio encoding to one channel, 64 Kb/s, like the other two, and saves the movie as an AVI file.
 
(Incidentally, it is a little known feature of KinoAmp that it will also play some AVIs, if the video format within the AVI ‘wrapper’ is CinePak or MPEG. You can actually double-click on this temporary file and play it!)
 
Now we just have to convert from AVI to MPEG:
ffmpeg:ffmpeg -i RAM::RamDisc0.$.Marco3/AVI -f mpeg -sameq -acodec copy RAM::RamDisc0.$.Marco3,BF8
Unfortunately, there are still serious problems with this third and final segment.
 
Not only is there some corruption to the downloaded video, which leads to pixellation and picture breakup, as well as glitches on the sound, but YouTube has also encoded it at a slightly larger frame size, forcing us to crop the edges more severely, in order to get the three segments to join together properly.
 
The corruption may be due to the panning effect, that the video’s creator has applied to the map, at the beginning of the segment, and it suggests that not all of the effects that can be created with video-editing software, will encode properly into YouTube’s FLV format.
 
Having experimented with this, I have found that it is possible to join the first and second segments together successfully, using this obey file:
ADFS::HardDisc4.mpgtx -j ADFS::HardDisc4.Marco1 ADFS::HardDisc4.Marco2 -o ADFS::HardDisc4.Marco12,BF8
But if we join the third segment, the sound starts to slip out of sync with the picture, when KinoAmp starts to play it. Once again, however, there is a way around it.
 
Shift-drag Marco12 and Marco3 into a directory called MarcoPolo.
 
Middle-click on the KinoAmp icon, on the iconbar, select Playlist, then drag the MarcoPolo directory to its input area and save the play list as PlayMarco.

You can now drag PlayMarco onto the KinoAmp icon, to play the whole episode.
 
Because of the bad coding of the third segment, this reconstructed episode is not perfect, but it is still pretty impressive.
 
Luckily, most splicing operations are not nearly as complicated as this, but it should have given you a pretty good idea of what to do, if you encounter problems.
 
And now, several hours after you started, sit back and enjoy The Roof of the World!

Ian and Barbara take in the view

Doctor Who’s first companions, Ian and Barbara, enjoying the view!

Tips & Tricks

  1. If you do not like Obey files, and would rather use the program’s dialogue box to specify the settings, do not carry on using the machine until it has completed the conversion.
    It is not worth risking locking your machine up, while FFMpeg is writing to the hard drive !!!!
  2. Use your RAM disc as much as possible, for input and output, to avoid wear and tear on your hard drive.
  3. The most difficult part of the operation is getting the right values for -ss and -t for the required clip, in the first place.
    If you want to get a really neat cut of your desired clip, run ExtractClip a few times with -t set to 5 seconds and slightly different values of -ss, while you ‘walk in’ the start point of the clip.
  4. If you see the dreaded ‘buffer underflow’ error in the program’s progress window, soon after starting the conversion, cancel it by hitting the Q key.
    The resulting file will be unplayable, so there is no point in wasting time letting it finish. These ‘buffer underflows’ always seem to occur when using the -ss arguement, and seem to be caused by many FLV files having corrupted time codes.
    You can usually get around this problem by converting the whole of the FLV file to AVI first, and then using ExtractClip on the AVI version, rather than the FLV one.
  5. If you produce an MPEG file that either will not play in KinoAmp, or alternatively plays for a couple of seconds and then freezes your machine, use Alt-Break to regain control of it, rather than the On/Off switch.
And finally - many thanks to Chris Martin for actually porting Murnong,
FFMpeg and Mpgtx to RISC OS, and for his help researching this article!

 
  Video Processing on RISC OS
  sa_scott (22:12 11/1/2010)
  filecore (06:25 12/1/2010)
    Lampi (09:09 12/1/2010)
      filecore (11:15 12/1/2010)
        bhtooefr (15:55 12/1/2010)
        pnaulls (17:59 13/1/2010)
          filecore (18:25 13/1/2010)
            Bucksboy (08:12 14/1/2010)
              filecore (09:11 14/1/2010)
                Bucksboy (10:06 14/1/2010)
                  filecore (14:13 14/1/2010)
                    Andy_Hodgson (14:45 14/1/2010)
                    trevj (05:33 13/11/2010)
              bhtooefr (15:17 14/1/2010)
    castlevarich (17:50 12/1/2010)
      filecore (19:52 12/1/2010)
        castlevarich (11:34 13/1/2010)
  trevj (10:39 22/4/2010)
    swirlythingy (17:07 22/4/2010)
 
Stephen Scott Message #112795, posted by sa_scott at 22:12, 11/1/2010
Member
Posts: 73
Wow, a very well researched article. However, this is all a sticking plaster, until it's all wrapped in a nice shiny RISC OS application shell. After all, RISC OS is supposed to be about ease of use?
  ^[ Log in to reply ]
 
Jason Togneri Message #112797, posted by filecore at 06:25, 12/1/2010, in reply to message #112795

Posts: 3868
I would replace this rather hysterical line:

If the edit window fills up with rubbish, you know you have done something wrong !!!
With something a bit more like:

If the edit window fills up with rubbish, then you have made a mistake. Ensure that you are shift-dragging the file, rather than dragging it normally.
Otherwise, an enjoyable if utterly pointless article. Any word on the specs needed to perform this set of actions in anything under a week? Assuming the average machine is a 202MHz StrongARM RPC with 32MB of RAM and 1MB of VRAM, running RO 3.7, would it be able to do it? What test machine was used in this article's writeup? What OS version? Do I need to merge any specific additional modules into !SysMerge first? And so on.
  ^[ Log in to reply ]
 
James Lampard Message #112799, posted by Lampi at 09:09, 12/1/2010, in reply to message #112797
Lampi

Posts: 190
Assuming the average machine is a 202MHz StrongARM RPC with 32MB of RAM and 1MB of VRAM, running RO 3.7, would it be able to do it?
I assume that's your machine wink. I doubt many people use 3.7 anymore.
  ^[ Log in to reply ]
 
Jason Togneri Message #112801, posted by filecore at 11:15, 12/1/2010, in reply to message #112799

Posts: 3868
Nope, it isn't. My machine is a similar vintage, albeit a bit higher spec than that - I was basing this average off the number of "help me resurrect this old machine" and "I just bought this off eBay" threads that keep appearing. People either have an old Arc in the attic or are retro enthusiasts, and this really is the average machine they tend to own, coupled with the fact that sales of these machines were in the heyday of RISC OS and by the time the Iyonix et al were coming into force, the scene had lost a lot of users to Wintel already.

So yes, it's very exiting that you can do this stuff under RISC OS now, but it's of use to only a tiny little subset of active users. And it still isn't clear as to what specs were used for this demo, and what sort of minimum is required. Then again, I suppose it's only the hardcore types who'll be doing this anyway, since you can do the same thing faster and more easily - and under a unified GUI - in Wintel/*nix systems, if the end product is your goal rather than the process itself.

[Edited by filecore at 11:16, 12/1/2010]
  ^[ Log in to reply ]
 
Eric Rucker Message #112802, posted by bhtooefr at 15:55, 12/1/2010, in reply to message #112801
Member
Posts: 337
And, the same FFmpeg tool can do the job much, much faster on a modern PC. Or even a PC from late 2002, when the Iyonix came out.

But, still, not a bad guide for how to do this stuff. Not that I'd bother with it, when a 5 minute YouTube clip took me 30 minutes to transcode using Murnong, on my 233 MHz SARPC.
  ^[ Log in to reply ]
 
Jon Robinson Message #112804, posted by castlevarich at 17:50, 12/1/2010, in reply to message #112797
Member
Posts: 55
The machine I used was a 233 MHz StrongARM, running RISC OS 4.39.

And yes it is SLOW (about half an hour for a
5 minute YouTube video) and yes I probably would use the PC version of FFMpeg if I had a PC (which I don't), but the fact is it is now POSSIBLE for RiscPC users to get to YouTube videos without the need to use one.

Personally I just set the thing to convert while I'm cooking my tea, so it doesn't really matter that it's locked my machine up for a while

Also it's bound to be faster on an Iyo/A9, and will presumably be faster still on a BeagleBoard.

Also the command line options will presumably work with the PC, if you want to take advantage of its greater speed, and you can do nearly all of it from Chris's front end anyway.

Jon Robinson (Leeds)
  ^[ Log in to reply ]
 
Jason Togneri Message #112807, posted by filecore at 19:52, 12/1/2010, in reply to message #112804

Posts: 3868
The machine I used was a 233 MHz StrongARM, running RISC OS 4.39.
The SA suggests a RiscPC, can you give details of RAM and VRAM? It might make a rendering difference.
  ^[ Log in to reply ]
 
Jon Robinson Message #112809, posted by castlevarich at 11:34, 13/1/2010, in reply to message #112807
Member
Posts: 55
It is a StrongARM RiscPC with 2 Mb VRAM and 128 Mb ordinary RAM. The VRAM won't make any difference to FFMPeg, but it might possibly to KinoAmp.

I don't think RISC OS 4.39 or 3.70 will make any difference, but I have got the next slot set to 30 MB, which I think speeds FFMpeg up a bit.

The best thing to do, if you've got a 3.7 RiscPC, is just to download the apps, and see if you can get them working - although if you've got a 'proper' PC as well, you'd be better off running FFMpeg on that.

Jon Robinson (Leeds)
  ^[ Log in to reply ]
 
Peter Naulls Message #112810, posted by pnaulls at 17:59, 13/1/2010, in reply to message #112801
Member
Posts: 317
"I just bought this off eBay" threads that keep appearing. People either have an old Arc in the attic or are retro enthusiasts,"
There haven't been many of those recently, and often they have a newer machine any way. Empirically, the number of hardcore (i.e, active) 3.7-only users is only a very few. The rest would be legacy users who in any case wouldn't be that interested in trying new stuff.

In practice, for all new developments, we should be, and should have been assuming for quite a long time now, RISC OS 4 - it is after all, about 10 years ago. Developers have to draw the line somewhere, and increasingly also it's drawn for post-RiscPC machines.
  ^[ Log in to reply ]
 
Jason Togneri Message #112811, posted by filecore at 18:25, 13/1/2010, in reply to message #112810

Posts: 3868
In practice, for all new developments, we should be, and should have been assuming for quite a long time now, RISC OS 4 - it is after all, about 10 years ago. Developers have to draw the line somewhere
s/RISC OS 4/Windows XP/w
  ^[ Log in to reply ]
 
George Greenfield Message #112812, posted by Bucksboy at 08:12, 14/1/2010, in reply to message #112811
Member
Posts: 91
Otherwise an enjoyable if utterly pointless article
I thought it was both instructive and useful. Just because something can be done in seconds flat on a 3Gig PC doesn't mean there's no point in trying it on a RPC. You might as well say that since a Ferrari will accelerate faster than a vintage MG, there's no point in having one. As to speed, I have an Iyonix, several times faster than a S/A RPC, and no doubt the Beagleboard would be several times faster again. Hopefully someone will do a test at some point.
  ^[ Log in to reply ]
 
Jason Togneri Message #112813, posted by filecore at 09:11, 14/1/2010, in reply to message #112812

Posts: 3868
You might as well say that since a Ferrari will accelerate faster than a vintage MG, there's no point in having one.
Yes, because a RiscPC (or heaven forbid, an Iyonix) is such a beautiful piece of kit that it's worth keeping - despite its lack of speed or any sort of vaguely modern hardware - just to admire its sleek lines and chrome finish?
  ^[ Log in to reply ]
 
George Greenfield Message #112814, posted by Bucksboy at 10:06, 14/1/2010, in reply to message #112813
Member
Posts: 91
What I meant to say was: 1) speed is not necessarily the only factor to be considered; 2) even if it were, faster (hopefully, much faster) and affordable new RO hardware is not far off. Therefore the article (which its author obviously spent a good deal of time and effort researching and writing) was far from pointless.
  ^[ Log in to reply ]
 
Jason Togneri Message #112815, posted by filecore at 14:13, 14/1/2010, in reply to message #112814

Posts: 3868
Therefore the article (which its author obviously spent a good deal of time and effort researching and writing) was far from pointless.
Oh, I'm not belittling the author's obvious commitment and hard work in researching and compiling this article. Good job to him and I'm sure there are plenty of nerdlings out there who'll find this stuff fascinating.

Still, from the standpoint of simple, everyday computing (as the likes of Hodgson would like to see brought back into the modern marketplace), you have to agree that it is, in fact, largely pointless.

Just because it's pointless doesn't mean it isn't interesting or worthwhile, and I praise the author for the fact that he has the enthusiasm to do all this - and I look forward to more of the same smile
  ^[ Log in to reply ]
 
Andrew Hodgson Message #112816, posted by Andy_Hodgson at 14:45, 14/1/2010, in reply to message #112815
Member
Posts: 65
Still, from the standpoint of simple, everyday computing (as the likes of Hodgson would like to see brought back into the modern marketplace)
Did someone call Togneri wink
  ^[ Log in to reply ]
 
Eric Rucker Message #112817, posted by bhtooefr at 15:17, 14/1/2010, in reply to message #112812
Member
Posts: 337
You might as well say that since a Ferrari will accelerate faster than a vintage MG, there's no point in having one.
More like comparing a Ford Fiesta (a modern netbook - I'm in the US, so the Ka isn't the most relevant) to a Model T.

And, yes, the RiscPC is a Model T. MAYBE a Model A.

It might be fun to play with and talk about, but it's completely impractical on modern highways/motorways.
  ^[ Log in to reply ]
 
Trevor Johnson Message #114070, posted by trevj at 10:39, 22/4/2010, in reply to message #112795
Member
Posts: 660
A recent c.s.a thread shows there may be an alternative!
EDIT: How did I miss the feature on Easier video playback on RISC OS?

[Edited by trevj at 11:48, 22/4/2010]
  ^[ Log in to reply ]
 
Martin Bazley Message #114077, posted by swirlythingy at 17:07, 22/4/2010, in reply to message #114070

Posts: 460
EDIT: How did I miss the feature on Easier video playback on RISC OS?
Every time someone mentions TheorARM, it seems to be followed by that sentence. What are we, invisible or something? tongue
  ^[ Log in to reply ]
 
Trevor Johnson Message #115870, posted by trevj at 05:33, 13/11/2010, in reply to message #112815
Member
Posts: 660
...you have to agree that it is, in fact, largely pointless.

Just because it's pointless doesn't mean it isn't interesting or worthwhile, and I praise the author for the fact that he has the enthusiasm to do all this - and I look forward to more of the same smile
Though arguably largely... certainly not completely.
  ^[ Log in to reply ]
 

The Icon Bar: News and features: Video Processing on RISC OS