The Sinclair QL Forum

Hi Stephen,

Really excellent work, getting the demo to run on a QL.

Could an API be written to load in video files?

Derek_Stewart wrote:Hi Stephen,

Really excellent work, getting the demo to run on a QL.

Could an API be written to load in video files?

Well, the code is written with the idea of being more flexible. The encoder program is actually a generic encoding function with a debugging main() calling it with specific parameters. I had originally expected to write a full program which took a set of QL MODE4 screen files and output the m4v format file. Adding sound is more tricky, of course, which is why I had to hard code it in a modified version of the encoder.

As for the decoder side, it's trivial to change it so that it reads the name of the file from the command line as an argument. Everything else comes from the video file.

Now, generating the QL MODE4 screen files isn't *THAT* difficult. FFMPEG can break a video into individual JPEG files which the scripts I've created can make into xbm files, which a program (included) can, with the help of an included Perl script, convert into QL MODE4 screen dumps.

It would take a little effort but any video could be processed. You'd just need a large enough and fast enough storage medium on the QL to play it. (I'm limited by the size of a floppy image and RAM disk.)

Cristian wrote:

mk79 wrote: an area where I am completely clue and talent-less: music!

So, after all, your planet-sized brain is more similar to Mars than to Jupiter

Well, in German there is the word "Fachidiot" (literally "subject idiot", somebody who is very good at one thing and not so good most others). I prefer the loose English translation "nerd" because in my brain at least it doesn't sound so harsh, but the point stands

Cheers, Marcel

mk79 wrote:

Cristian wrote:

mk79 wrote: an area where I am completely clue and talent-less: music!

So, after all, your planet-sized brain is more similar to Mars than to Jupiter

Well, in German there is the word "Fachidiot" (literally "subject idiot", somebody who is very good at one thing and not so good most others). I prefer the loose English translation "nerd" because in my brain at least it doesn't sound so harsh, but the point stands

Cheers, Marcel

There is also "Idiot savant", altough that implies mental impairment with the exception of one area - and that's not the case here.

mk79 wrote:One of the huge advantages that I used compared to your C code is that I fetch the data through low level raw sector access, I don't go through the file system layer.

Aha!

My attempts failed back in 2002 when trying to implement some sort of virtual memory swap file using normal driver access. Decoding progressive JPEGs can take a great deal of memory (each successive scan builds up the spectral and/or resolution, which requires storing the whole image at 24 bits per pixel). Although the scheme worked OK (shunting chunks of memory in/out); QPC2 / SMSQmulator only about 3 times slower than if whole image held in memory, it failed miserably on real QL hardware. I gave up after 15 minutes of constant drive access on a SGC/Qubide system.

I did consider the faster direct sector access route, but it needs to be done through some driver manipulation. I'm guessing that is what you did with QL-SD ? Is it worth considering it as a future SMSQ/E filing system feature?

Silvester wrote:I gave up after 15 minutes of constant drive access on a SGC/Qubide system.

Yeah, the emulators fill the buffers with the speed of the host system, which is a thousand times faster.

I did consider the faster direct sector access route, but it needs to be done through some driver manipulation. I'm guessing that is what you did with QL-SD ?

QL-SD has a low level API for direct access so different file system drivers can be implemented on top of them without interfering with each other.

Is it worth considering it as a future SMSQ/E filing system feature?

Well, generic direct sector access through OS calls already exist. The point of the low level API is not to have an OS stack on top of it.