I have just seen some YouTube videos of screencasting (on a Mac), and I wondered if anything similar was available, or possible, in anyway on the Amiga?
It doesn't need to be as sophisticated as the Mac programs, but this sort of application could be so useful for tutorials, or passing on tips to other Amiga users. We don't have isight cameras, or even proper webcam support, so we can't benefit from those options, but could we record the screen. We already have screengrab, but that is for single screens, and windows. It would be great to record an application on a screen, or a window. This could be useful, even without an editing facility. Would it be possible to stream the display info from the monitor driver/gpu to hard drive?
I remember some developers expressing interest in writing video editing software, possible Hans, but I think his A1 is still halfway accross the oceon, and he has his hands full with his graphic card drivers.
Does anyone more technical than me (so that's probably everyone) think this is doable, or just pie in the sky?
No-one interested? Surely this is worth a discussion?
We have DvPlayer, and MPlayer, so OS4 should be fast enough. We have Tunenet, etc that does streaming. We have screen grab software. We have webview software.
Surely, as a community we have the skills, and expertise to do this?
It would be great if a developer picked this up and ran with it, but what about feasibility.
Just think about it, no more long text based tutorials, no more text based explanations for game solutions, or problem solving. Just record a small video, it doesn't have to be DVD quality, and just post it on YouTube.
In fact what a great way to promote OS4.x.
I am not a programmer (yet!), so I don't really know the technical obsticals involved, but as a concept I think it could be brilliant.
No-one interested? Surely this is worth a discussion?
Nothing like that! It's the visual & information overload from say, Yahoo.com to IMDB.com. and everything you say inbetween! The time factor has got me re-thinking the quality of life these days. Less computer or ... maybe a lot ... or none? The real question for me is what I really need to know and when?
We have DvPlayer, and MPlayer, so OS4 should be fast enough.
With fast codecs with low compression an AmigaOne and a SAM440 may be fast enough for decoding and displaying full screen videos, but they are way too slow for encoding full screen videos in real time. Writing the uncompressed images to HD and encoding a video later isn't possible either, for a 32 bit 1280x1024 60 Hz screen mode that would require writing 300 MB/s to the HD. You can't even read the data from the gfx card RAM that fast ...
I haven't tried it yet, but I think you don't need to be a programmer for such things.
There is some tools that can capture HID events and can play it back. I have a very very old one and it works on OS4 too (except for mui windows), but AFAIK there is others on Aminet. So you can capture mouse movement and keyboard input and can play it back even on another computer. The main obstacle is that there is no identical systems. To create the same environment as on the recorder computer you may use YetAnotherDesk. So I think it is possible to create tutorials that can plays back on any computers (I mean OS4 machines) which needs much smaller footprint than any video codec can create.
It is just an idea. I cannot give you any proof of reliability, but you could try it if you have more time than I have.
With fast codecs with low compression an AmigaOne and a SAM440 may be fast enough for decoding and displaying full screen videos, but they are way too slow for encoding full screen videos in real time. Writing the uncompressed images to HD and encoding a video later isn't possible either, for a 32 bit 1280x1024 60 Hz screen mode that would require writing 300 MB/s to the HD. You can't even read the data from the gfx card RAM that fast ...
Even 640x480 would be good, or maybe just limit it to a window, and mouse pointer. I don't know the practicalities of doing it, I just think it would be a very useful app.
I'm thinking it would be possible to do a section-by-section grab, as moving a window wouldn't necessarily update an entire desktop screen. If there's a quick and dirty way of frame-comparing and only grabbing the changed data, this could be saved out and compiled to anything from mpeg4 to anim7 after the "recording" is done. I've been thinking of doing this myself, so I wouldn't have to stream pal or ntsc data to my windows framegrabber for this sort of thing, but my programming skills aren't that great. I'm thinking worst cast scenario is break the screen up into grids, run a crc check on the data similar to an HDD block check, and only grab the "squares" that fail a "current frame" "previous frame" crc, dump the raw data, and worry about compiling the whole mess afterwards. This along with some tricks, eg. not grabbing the mouse pointer so much as keeping track of its normal/busy state and tracking it's x/y position, and simply add the image in at compile time should be feasable.
Forgot about that, youtube automaticall reduces video anyway unless you use their HD option. That could work as well, and still have comparable quality.
The compositing engine in AmigaOS 4.1 could down-scale and filter the screen from any size to, say, 640x480, and that could be just small enough.
So is screen casting possible on existing OS4 capable hardware, or just down scaling screen grabs? As a developer of some repute, what do you think would be required?
The compositing engine in AmigaOS 4.1 could down-scale and filter the screen from any size to, say, 640x480, and that could be just small enough.
So is screen casting possible on existing OS4 capable hardware, or just down scaling screen grabs? As a developer of some repute, what do you think would be required?
It depends on your definition of "possible".
I haven't done the math, but downscaling a screen to 640x480 is very fast (a few milliseconds). The difficulty is getting the data into main memory for further processing.
Let's say you scale to 640x480x16. That is 614400 bytes per frame. At a target capture rate of, say, 30 FPS, this makes for 18433200 bytes per second (around 17 MB). This is well within the practical bandwidth limits of the AmigaOne and/or SAM440ep.
For 1280x1024, the required bandwidth would be around 78 MB/s (or around 150 for 32 bits). In theory still possible, but in practice, it won't work.
The 640x480 case would probably work, since it would still leave some time free for actually doing something that is worth capturing. Anything else will probably be out of question.
If you want to actually transmit the stuff in real-time, it will be a good deal harder, I don't think that any Amiga currently can encode real-time video. But recording it to a harddisk file and encoding it later might work.
Note this is theory until someone proves or disproves it.
Seriously, if you do want to contact me write me a mail. You're more likely to get a reply then.
If you want to actually transmit the stuff in real-time, it will be a good deal harder, I don't think that any Amiga currently can encode real-time video. But recording it to a harddisk file and encoding it later might work.
Note this is theory until someone proves or disproves it.
That might be how it works on the IMac. The Youtube videos of screenflow, show the screen, and camera being recorded, and the editor automatically being launched afterwards, seemingly as part of the same process. They could be seperate elements of the same program, but they might have to be run that way to encode the raw file to a playable video format, in the way you describe.
Just posting to tell that I've just started working on a program like this.
Currently it just scales the frontmost screen using CompositeTags() at 25 fps and blits it into a window. This only took some minutes to write with the new SDK. Next job will be to remove the window and make it output to a video file on disk instead.
"ScreenCam" can record a screen video, with highly-efficient codec for Program tutorials.
= creates large files if you record yourself playing Quake, creates incredably small files if you record yourself explaining "how to install GCC". However,, I am planning a MPEG function using FFMPEG as post-encoder for the first case.
I dont think this will be fast on OS4, since AGP can read only rediculous 2-4MB/sec, but works very fast on WinUAE.
FWIW I just recorded my first video (640x480 at 12.5 fps). I'm using libxvidcore ported by SpotUp for the encoding.
There are still some small things to fix though: - it doesn't handle high cpu usage very well (the movie will go faster as less frames are recorded per second) - size and frame rate are currently hardcoded in the program - doesn't preserve aspect ratio when scaling
Apart from this it is working well so I might upload a demo version to OS4Depot.
I can't download from the rapidshare site on my A1, but I have downloaded srec.lha, and will have a play. Thanks very much, I like the todo items as well. This could be a really useful peice of software.
"ScreenCam" can record a screen video, with highly-efficient codec for Program tutorials.
= creates large files if you record yourself playing Quake, creates incredably small files if you record yourself explaining "how to install GCC". However,, I am planning a MPEG function using FFMPEG as post-encoder for the first case.
I dont think this will be fast on OS4, since AGP can read only rediculous 2-4MB/sec, but works very fast on WinUAE.
That sounds like a very nice program, I like the idea of using ffmpeg. Can't ewait to have a play.
Nice proggy man, i was thinking doing the same for a while since the compositing engine appeared.Only one small detail:Could you add some sort of scaling from full screen to reduced real pixels around the mouse for better details when doing something.
For instance, you can see a scaled wb when you click on some icons, and when you want to show more detail it makes sort of a magnification lens around the mouse pointer with the wheel mouse.I think that would work properly and give more detail to the viewer when needed be.As if you were zooming with your video camera to some area on the screen to have a more near view of something.
At the time I recorded the video, soundrecording was somewhat broken, but still watchable.
Notice the length of the video (7min) and the file size (5MB) at 1280x1024 with nearly no compression artefacts! or 7min/1.7MB @ 640x512 with slightly reduced color depth.
I just saw that the big video has no sound, wile the other ones have.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
