Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.sinclair > #2508 > unrolled thread

Re: Speccy video player in C?!!

Back to article view | Back to comp.sys.sinclair

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Speccy video player in C?!! Matthew Westcott <gasman@raww.org> - 2011-02-04 12:29 +0000
    Re: Speccy video player in C?!! "Paul E Collins" <find_my_real_address@CL4.org> - 2011-02-10 21:53 +0000
      Re: Speccy video player in C?!! "Daniel Mandic" <daniel_mandic@hotmail.com> - 2011-02-10 22:29 +0000
    Re: Speccy video player in C?!! Matthew Westcott <gasman@raww.org> - 2011-02-11 00:17 +0000
      Re: Speccy video player in C?!! Matthew Westcott <gasman@raww.org> - 2011-02-13 16:26 +0000
    Re: Speccy video player in C?!! Matthew Westcott <gasman@raww.org> - 2011-02-08 23:04 +0000
      Re: Speccy video player in C?!! BitNaughty <bit-naughty@hotmail.com> - 2011-02-10 05:09 -0800
    Re: Speccy video player in C?!! BitNaughty <bit-naughty@hotmail.com> - 2011-02-08 06:20 -0800

#2508 — Re: Speccy video player in C?!!

On 04/02/2011 10:57, BitNaughty wrote:
> On Feb 4, 10:42 am, Matthew Westcott<gas...@raww.org>  wrote:
>> On 04/02/2011 09:39, BitNaughty wrote:
>
>> The C code on Github is just the converter that runs on the PC, to
>> convert your video to .dvo format which plays on the Spectrum. The
>> player itself is done in assembler:http://divideo.zxdemo.org/player.asm
>
> Could you explain some of the theory behind it? That much of Z80 Asm
> is a bit intimidating! :) I'd *like* to go through the code, but after
> knowing a little of what went into it first.....

It's all explained at the bottom of http://divideo.zxdemo.org/ - it's 
hard to break down the explanation any further than that, because of how 
it all fits together (the file format is designed around the player and 
vice versa) - but the main gist is that you have a series of 'packets' 
each consisting of one audio sample and a sequence of bytes to copy to 
the screen, all carefully arranged so that the audio sample is the right 
one to be played at the specific moment that you get to it.

[toc] | [next] | [standalone]

#2513

"BitNaughty" <bit-naughty@hotmail.com> wrote:

> This sounds amazing! How do you do this?

He's Gasman, he just does it :)

Eq.
 

[toc] | [prev] | [next] | [standalone]

#2525

Paul E Collins wrote:

> He's Gasman, he just does it :)

Chef...


-- 
Daniel Mandic

[toc] | [prev] | [next] | [standalone]

#2519

On 10/02/2011 13:09, BitNaughty wrote:
> On Feb 9, 4:04 am, Matthew Westcott<gas...@raww.org>  wrote:
>> On 08/02/2011 14:20, BitNaughty wrote:
>>
>> 3) Compare that screen with the previous one*, making a list of all the
>> runs of continuous bytes that differ between them (but with some tricky
>> special cases: for example, if you've got two runs that are only a few
>> bytes apart, it's better to treat them as one long run rather than
>> having the extra overhead of reading two data chunks)
>
> OK, so this is something like LZW GIF compression, if I understand it
> correctly, am I right......?

It's a bit simpler than that... LZW is all about building up a 
dictionary of the strings you've encountered so far in the 
compression/decompression, so that if you find a repeating pattern you 
can just refer back to the last place it appeared, rather than storing 
it in full. Here there's nothing like that - the rule is just "only 
store the bits of screen that have changed".

>> keep a
>> rough count of how long it's going to take the Spectrum to process the
>> stuff you're generating, so that you can pick out the right sample from
>> the audio stream that will be played at that point.
>
> This sounds amazing! How do you do this?

Well, this is the point at which the cleverness ends and the tedious 
messy code begins :-) Best to just look at the code - the 
delta_compressor_pack_deltas function in
https://github.com/gasman/divideo/blob/master/c/delta_compressor.c
is where we keep count of timings (in the variable frame_time).

[toc] | [prev] | [next] | [standalone]

#2538

On 12/02/2011 16:17, zxbruno wrote:

> This topic reminded me I have lots of video clips I want to
> convert! :D
> Gasman, any chance we will see a Windows GUI with video preview
> sometime in the near future? An interface similar to Vdub (or a
> DivIDEo plugin for Vdub itself!) would be the awesome.

Not from me...

If and when I do get back to DivIDE hacking (which I would like to, but 
it's not a huge priority for the near future), there are far more 
fundamental improvements to the whole DivIDE user experience which would 
interest me more - top of my list are improvements to hdfmonkey, and a 
decent general-purpose file manager / launcher (which would benefit 
projects like Spectranet and SIF too, not just the DivIDE).

[toc] | [prev] | [next] | [standalone]

#2520

On 08/02/2011 14:20, BitNaughty wrote:
> OK, had a read but..... how do you do the *video* compression?
> The page says you need FFMPEG to build the converter - are you coding
> the video into something MPEG related or something?!!

I'm using FFMPEG to read in the original source video, since it handles 
every video format you're likely to encounter (not just MPEG) and 
returns a list of plain uncompressed images and wave audio. From there, 
the steps are:

1) Resize to 256x192 and adjust brightness / contrast according to the 
settings passed on the command line
2) Convert to Spectrum screen format (by looking at each attribute cell 
and trying every possible pair of colours in turn, dithering down to 
those two colours, measuring how far the result differs from the 
original, and selecting the closest one)
3) Compare that screen with the previous one*, making a list of all the 
runs of continuous bytes that differ between them (but with some tricky 
special cases: for example, if you've got two runs that are only a few 
bytes apart, it's better to treat them as one long run rather than 
having the extra overhead of reading two data chunks)
4) Write those chunks out to the file, while carefully reshuffling them 
so that they don't cross the ends of disk sectors. (This isn't something 
you'd usually worry about in a file format, because normally you'd have 
some low-level routines that check for that every time they read from 
disk... but here we don't have that luxury, because we're doing 
everything as quickly and cheaply as possible.) At the same time, keep a 
rough count of how long it's going to take the Spectrum to process the 
stuff you're generating, so that you can pick out the right sample from 
the audio stream that will be played at that point.

The 'compression' step is step 3, which ensures that we're only storing 
the bits of screen data that change from one frame to the next. This is 
not so much about reducing file size, more about reducing the amount of 
work the Spectrum has to do.



* actually, it's the one before previous, because we're doing 
double-buffering using the 128K's second screen, which means that we're 
updating the screen from two frames ago...

[toc] | [prev] | [next] | [standalone]

#2536

On Feb 9, 4:04 am, Matthew Westcott <gas...@raww.org> wrote:
> On 08/02/2011 14:20, BitNaughty wrote:
>
> 3) Compare that screen with the previous one*, making a list of all the
> runs of continuous bytes that differ between them (but with some tricky
> special cases: for example, if you've got two runs that are only a few
> bytes apart, it's better to treat them as one long run rather than
> having the extra overhead of reading two data chunks)


OK, so this is something like LZW GIF compression, if I understand it
correctly, am I right......?


> keep a
> rough count of how long it's going to take the Spectrum to process the
> stuff you're generating, so that you can pick out the right sample from
> the audio stream that will be played at that point.
>

This sounds amazing! How do you do this?


BitNaughty.

[toc] | [prev] | [next] | [standalone]

#2522

On Feb 4, 5:29 pm, Matthew Westcott <gas...@raww.org> wrote:

> It's all explained at the bottom ofhttp://divideo.zxdemo.org/- it's
> hard to break down the explanation any further than that, because of how
> it all fits together (the file format is designed around the player and
> vice versa) - but the main gist is that you have a series of 'packets'
> each consisting of one audio sample and a sequence of bytes to copy to
> the screen, all carefully arranged so that the audio sample is the right
> one to be played at the specific moment that you get to it.

OK, had a read but..... how do you do the *video* compression?
The page says you need FFMPEG to build the converter - are you coding
the video into something MPEG related or something?!!


BitNaughty.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.sinclair

csiph-web