Re: Video editing in Linux?

From: Ian Molton (spyro_at_f2s.com)
Date: 11/05/04 

Date: Fri, 05 Nov 2004 11:48:11 +0000

SjT wrote:
>>Just today I had over 600 connections on a single port here (toying with
>>gtk-gnutella).

> But i expect that was using a port in the 7001-7009 range?

Why?

as it happens, 50507 (default is 6346 on gnutella, btw)

>>Excuse me? the Archimedes had 8 channel fully synthesised *logarithmic*
>>stereo sound with around 32 stereo positions minimum (before you did
>>extra work in software - that was the hardwares capability).
>>
>>The amiga had four linear 8 bit channels with fewer stereo positions.
>
> Sorry, i didn't realise you was talking sound 'quality' i thought you
> meant the music was of better quality.. i.e. better artisticly.

Well it was. it was the same tracks, but re-mixed without the
limitations of the amiga sound system. they were cracking tunes too,
despite being about 1 min long at most...

> I
> never really heard the archimedes sound as the ones downstairs weren't
> allowed the speakers on.

thats a shame. despite being 8 bit, you could come surprisingly close to
CD quality, due to it being logarithmic not linear... (ie. more bits
quiet detail, fewer loud detail.)

>>Rubbish. computing was massive already when doom came out and that
>>predated win95.
>
> It was massive at the time yeah, but in comparison it's nothing by
> todays standards.

True but given it wasnt a minority thing then, the current 'success' can
hardly be attributed to M$.

>>>The same with graphics cards, now you had an OS that would take
>>>advantage of the hardware, in fact the jump from Win 3.1 was massive.
>>
>>cobblers.
>
> I don't mean the technology i mean the useability, plug and play was
> the big buzz word and it invited people to a ride of pure hell! :D

Huh? as you JUST said, the usability wasnt there. admittedly this was
*partly* not the fault of windows (ISA and ISAPnP sucked), but it was
certainly not plug and play (plug and pray at best).

win98SE was the earliest M$ OS that could even *remotely* be called plug
and play.

>>>The new breed of games at that time were all made possible due to MS
>>>developing DirectX.
>>
>>Rubbish. Doom and Quake (initially) used some extremely well coded FULLY
>>SOFTWARE rendering. Quake later used OpenGL and THEN DirectX.
>
> Yeah, but the majority of windows based games were using the Directx
> drivers.

Are you suggesting that doom and quake werent the games that broke us
into 3D gaming? the rest came later. indeed the 3DFX card that started
it all was built for quake...

>>Well if you must insist on buying PACEs overpriced junk...
>
> Pfft.. PACE hater :PPPP

With reason. I've never owned a good product made by pace.

>>Gaming pushes 3D video most. as evidence look at the XBOX - a 733MHz
>>Celeron and plays all the latest games fine...
>
> No windows overhead though,

Err...

> in fact only the required components are
> loaded in, add to that a pretty good GFX Card that only has to render
> around the 800x600 mark and it flies along.

Didnt I just say that gaming pushed the GFX side hardest?

> With windows you are forced into upgrading CPU, Memory AND Video card
> every year if you're really into your games.

sure, if you want every last ounce of speed. but the memory and video
card (especially the VC) make most difference BY FAR.

> I had a shock when connecting to my wireless provider through PPPoE, i
> was getting *** performance running straight in through my network
> card into XP, i bought a router and it was clearly so much better..

Thats nothin to do with DSP at all.

> The ISP hasn't a clue why and i wondered then whether there was some
> processing that XP was screwing up on.

possibly but theres really not much overhead in pppoe (or pppoa).

>>You know I do ;-) (actually the vast quantity of morons and "businesses"
>>on the net I blame more, but...)
>
> But can you blame them for using such a standard platform?! I would be
> *** scared to switch over to openoffice and a linux server here, i
> would love to do it to see how it compares, but things like
> compatibility issues with other companies would scare me to death.

Why not use an linux/openoffice system **in parallel** for a bit?

> Yeah, the thing is i paid for SuSE and so want to use it...

Ok...

>>>Build with ALSA 0.9 or better for sound - EEK?!
>>
>>Perhaps you should have googled a little.
>>ALSA == Advanced Linux Sound Architecture. Its the replacement for OSS
>>(Open Sound System) that linux used to use for audio.
>
> So is that a program or a driver or some kind of wrapper?

Kinda both.

the philosophy behind much of the linux kernel is to avoid putting large
(therefore buggy) code into the kernel (where its failure can bring down
the system), and instead put the minimum needed for high performance
into the kernel, and the rest into a library (dll if you like) that
provides a nice interface for applications.

ALSA has a driver component (thats in the kernel) and a library
component (that sits in userspace). Theres also a collection of
utilities that come with the library, the alsa utilities.

> Yeah i did google it, but i'm totally lost. You must appreciate that
> this is an absolute world of difference from windows.

Fair enough. you have to appreciate that 'I looked at this and cant
really understand it, heres where I looked <URL>' will illicit a more
friendly reply than '<name of thing> EEEK! what the ***?'

basic human nature - the former implies some effort, the latter implies
a spoonfeeding request.

> I don't know
> how far up the beginner->advanced ladder this *** is? Maybe i'm
> jumping in too high?! I just want to try out audio apps though..

compiling stuff isnt normally to hard (note we're talking applications
here, not the kernel). Usually a case of

tar [z,j]xvf archive.tar.[gz,bz2]
cd archive_name
./configure
make
make install (you probably want to become the root user first)

the first step unarchives the sourcecode
the second changes the working directory to the freshly unpacked
directory full of source
the ./configure runs a script in the working directory, which detects
all kinds of information about the system - what CPU, OS, what libraries
you have, etc.
make invokes the make program, which builds the package according the
the makefiles created by the configure script
make install copies the components you just built to the right places on
your system.

If you get any problems they will likely be at the configure step - and
almost always will tell you whats wrong like:

'checking for LADSPA... yes'
'checking for ladspa.h... no'
'Error: LADSPA found but has no headers. install the LADSPA development
headers'

so they will at least have given you something to google for, even if
you dont know what 'install the LADSPA development headers' means.

(note: the above is a made up example)

if you get errors during the make phase you are probably SOL unless you
can hack the code yourself.

> Yeah thats what i mean, in windows i would install the ASIO driver for
> my soundcard (Which is the equivalent of LADSPA and JACK) and then
> Cubase (Rosegarden).

Well on linux you'd install the driver for the soundcard, and then
rosegarden...

on a distro [that provides them] both of those would be binary blobs
just like on windows.

>>>3. A quick visit to the ALSA Soundcard Matrix shows me that my card is
>>>supported (woopee!): http://tinyurl.com/5y7b2
>>
>>emu10k1 - sBlive! ?
>
> Nah i use the EMU10K2 - which is audigy2, but they list it as emu10k1
> despite referring to it as the emu10k1, im guessing its just a
> mistake.

Possibly not. on linux we dont supply drivers for 100 different TV
cards, we supply a drievr for the BT878 video input chipset.

since that chipset is used on 100 video cards, we can support them all.

Often drivers will only need some minor tweaks to support several
versions of a given chip or card(s), so rather than duplicate a driver
with only tiny differences, we roll them together into a generic driver.

Performance doesnt suffer (or if it does, the driver is split, although
possibly still sharing some common parts).

linux drivers are typically ver small too, despite their genericness.

>>You seem to read selectively. the paragraph you quoted says "or build
>>them seperately as modules" which is what several people have told you
>>here already.
>
> They seem to suggest that compiling into the kernel is the better
> option though as there are far more links to that?

There is no performance penalty. the only difference is that you dont
need to reboot if you compile the driver as a module.

>>yes this is a potential weak spot, but the programs in use in these
>>areas are all very small and extremely closely scrutinised. no known
>>holes have been discovered for a good while now.
>
> Would it be possible for you to code a piece of software which could
> perform this?

What do you mean?

> Also, does the software discussed above require to know the root
> password? or is it like a one-way ticket straight through, no
> authentication needed?

in theory - you could make a version of 'su' (switch user) that would
simply switch user, no password needed - su runs as root so it can
change user. linux authentication is based on the login / user
swithching programs, and the kernels handling of user privelidges.

> Well you could change the code to fix the problems, run a diff on it,
> save the resulting file.
>
> Then, modify the code to add your malicious code and send that file
> with the original diff file you made previous?

the maintainer is still going to read it though. whay do you think
tacking the malicious bit on the end is any less visible than if it were
part of the patch - patches are plaintext.

> Ok, so it's what i would probably call a windows wrapper? Crude i know
> :)

I'd say 'environment' but yeah, close enough.

> I.e. you run windows executables rather than having a window
> displaying a windows machine, i.e. a windows desktop?

correct - you can even have them use the linux window manager etc.