Date: Wed, 29 Jan 2003 19:51:40 -0500
Reply-To: Charles_S_Patridge <Charles_S_Patridge@PRODIGY.NET>
Sender: "SAS(r) Discussion" <SAS-L@LISTSERV.UGA.EDU>
From: Charles_S_Patridge <Charles_S_Patridge@PRODIGY.NET>
Subject: Re: Filming HASUG Meetings - Help
Content-Type: text/plain; charset=us-ascii
Sorry, I missed your comments on this topic.
Yes, I have tried a number of formats - AVI, MOV, Flash, MPEG-1, WMV and finally
VHS (not really digital).
In addition, I have the ability to reduce frame rates, image sizes, and lower
audio quality, and finally, to use a number of Video and Audio CODECs but none
of them give me all the best when it comes to reducing the size of an output
movie and still keep it under less than 3 megs as well as maintaining decent
If I had plenty of web space, say 200 or more megs, than I might be tempted to
try going forward with what equipment and software I have but I also have to
worry about bandwidth. Currently I am limited to 7.5 gigs of traffic on my web
site per month.
In the month of September of 2002, I made a 2.5 minute video in memory of 9/11
and this movie took about 20 megs of space. I did not advertise the existence
of this movie very much, and in two weeks time, I had about 4.5 gigs of traffic
- primarily due to this one file. As a result, I had to take it down or I would
have had to pay additional charges (like $30-50 more per month) to handle the
traffic. And since I knew I would be taking that movie down within a month, I
decided it was not worth the extra expenses to make it available.
And to make HASUG sessions available on the web for people to see - I estimate I
would need at least another 150 megs of storage plus 15 gigs of traffic
bandwidth per month to do all this. And since I would most likely make it free
- the extra expense would have to come out of SCONSIG's charitable funds which I
did not think was appropriate.
So, I will continue to do more testing and research on compressing digital
movies as well as reviewing newer cameras/camcorders/software etc to see what
the future technology can offer the small guys like me. If I had the resources
such as SAS, then it would be a done deal <grin> and no problems! Heck, I could
probably create a new SAS product for sale - PROC USERGROUPS On-Line <grin>.
And at the normal going rate of $40K, then I could easily afford the extra
webspace and bandwidth.
Still keep those comments and suggestions coming - it makes for an interesting
exercise to see if I can implement them.
DKVJ Cons Co UK wrote:
> Aye, there's the rub.
> There are some presentation issues here. When you reduce an image in size,
> some process will vote on which pixels to accept, and which to ignore. To
> see what I mean, you could draw the capital letter 'E' on a piece of graph
> paper. One cell height for each line, two cells height for each line
> spacing. You will now have a structure that is seven cells high. Now
> reduce that to four cells high. No matter how you calculate it, you either
> lose one of the bars, or collapse two of them together. This is an artefact
> of digitising in a lossy format. By reducing the size of the image, you
> must lose information, and reducing the size of the image will cause
> information to be lost.
> If all you did was lose bits, that may be acceptable. Unfortunately,
> because objects are moving in relation to the camera, the rendering of a
> shape will keep changing. You've seen this on television when someone wears
> a striped garment in the background, and the garment appears to move and
> shift as the camera perspective shifts. It's less obvious in film, but when
> film is digitised for television the stripes move between the area where
> they are, and then are not captured. So the garment appears to strobe.
> When you do this with a presentation, you're likely to lose parts of words
> on the display, or make a highly unwatchable picture.
> By the way, when I capture my DV material, it is first rendered in full AVI.
> In this format, 13 minutes of video takes more than 1GB of disk space. As
> it is rendered in MPEG-3 losses are introduced, and a piece of software
> makes a decision about a clump of pixels that may render them all in the
> same colour. The result is that my pan shot across the lake at last years
> SUGI looks fine in native DV and AVI, but gradually becomes more indistinct
> as the available space for image information is filled and pieces of my
> picture are thrown away. MPEG-1 is substantially more lossy, even though it
> did render my pan in a file that easily fit in a small part of a CD!
> It's a frustration Charles seems to have experienced as well.
> By the way, some of us use another video system called Phase Alternate Line
> (PAL). While NTSC is based on 60 fields per second of 525 lines, PAL is
> based on 625 line images at 50 fields per second ("more, less often" as my
> Californian friend might remark). They also have different colour burst
> frequencies, which led to some wag suggesting NTSC is a mnemonic that makes
> a derogatory remark about NTSCs colour rendering ability. One must ask
> though, how many people are still using 640*480 display sizes? And how many
> will be happy watching a picture one quarter of that size? It might work
> for bouncing babys, for entirely different reasons, but live video is
> another matter. I come back to the question implicit in my first reply;
> what are you trying to convey, what are you trying to achieve, and what is
> the limitation of the medium?
> Kind regards
> Date: Tue, 28 Jan 2003 19:17:20 -0700
> From: Jack Hamilton <JackHamilton@FIRSTHEALTH.COM>
> Subject: Re: Filming HASUG Meetings - Help
> Did you try AVI or any other formats besides MPEG?
> 320*240 is small, but you don't have to get much bigger. A standard
> NTSC signal is only 525 lines high.
> Manager, Technical Development
> METRICS Department, First Health
> West Sacramento, California USA
Charles S. Patridge
172 Monce Road
Burlington, CT 06013
Email: Charles_S_Patridge at prodigy dot net