Help: Visual Basic Setup Problems
in [Visual Basic]
|
From: Searcher7 on 3 Feb 2010 23:58 On Feb 3, 5:25 am, "Schmidt" <s...(a)online.de> wrote: > "Searcher7" <Search...(a)mail.con2.com> schrieb im Newsbeitragnews:9c09a747-e594-4df8-b980-b902955efd98(a)b10g2000yqa.googlegroups.com... > > > I'm trying to stay away from compression. And not > > concerning myself with DirectX or OpenGL. > > These "modern" technologies didn't always > > exist and I'm trying to make this as simple as possible. > > Without any compression you are limited with > your available input-sources, since there's probably > no "video-stream-file" out there nowadays which > contains "uncompressed RawData". > > And there's also lesser performance, if you work > without compression - although that seems a bit > contradictory at the first sight. > But reading/writing uncompressed RawData > (for 640x480 pixel resolution this means 20-30 > MB per second) from/to disk is often slower than > the combination of a fast (only CPU-bound) > codec and the reduced disk-IO. > > But your choice of course - I've already given my > recommendation for "plain C" (if you really want > to work near to the hardware) - and most C- > Compilers support also some sort of Inline-Assembler, > in case you're badly in need for tuned routines, which > bypass the already very good optimization-tricks of the > modern C-Compilers. > > Olaf Well, my idea involved having all the raw image data on the hard drive. In ram will be loaded the instructions needed for pulling specific sequence of images, along with the specific changes in their size, movement direction and speed. The change in sequences will be determined by specific key presses in combination with what the previous and/or present sequences are/were run. The instructions for the small temporary edits to these running clips will also be stored in ram. Very little data will be written back to disk. It'll just basically be disk to monitor. Anyway, this is why I would like to bypass a lot of the garbage and work close to the machine code. Nevertheless, this is just one project, and VB of course is not the way to go. Thanks. Darren Harris Staten Island, New York.
From: Dee Earley on 4 Feb 2010 09:57 On 03/02/2010 05:36, Searcher7 wrote: > On Feb 2, 1:37 pm, "Schmidt"<s...(a)online.de> wrote: >> "dpb"<n...(a)non.net> schrieb im Newsbeitragnews:hk9r00$qfh$1(a)news.eternal-september.org... >> >> [Video-Processing]> This is hardly what I would term a "simple edit". I'm not a >>> video processing type but this ain't gonna' be a trivial app >>> no matter what it's written in and to attack it from the ground >>> up as an assembly-coded app is a non-starter to ever >>> getting anything functional in any reasonable amount of time. >> >> Exactly - not to mention, that fast decompressing is done >> nowadays over Codec-Interfaces (which on Windows are >> DirectShow...COM-Interfaces) > > I'm trying to stay away from compression. And not concerning myself > with DirectX or OpenGL. These "modern" technologies didn't always > exist and I'm trying to make this as simple as possible. "As simple as possible" is why newer technology exists! -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems
From: Dee Earley on 4 Feb 2010 10:02 On 04/02/2010 04:58, Searcher7 wrote: > Well, my idea involved having all the raw image data on the hard > drive. In ram will be loaded the instructions needed for pulling > specific sequence of images, along with the specific changes in their > size, movement direction and speed. Ok, take a small 320x240 video for 5 minutes seconds 320 wide x 240 high x 24bpp x 25fps x 60s x 5 You already have 1.7GB of image data, ignoring any framing and data structure. -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems
From: Dee Earley on 4 Feb 2010 10:04 On 03/02/2010 10:57, Mike Williams wrote: > "Andrew Morton" <akm(a)in-press.co.uk.invalid> wrote in message > news:7ssuguFq1kU1(a)mid.individual.net... > >> It sounds like you'll want something like >> "VideoCog .NET Control: Add digital video to any .NET application > > It sounds like you need to take your friend Darren, or whatever his real > name is, and go play with him somewhere else - perhaps at your next > dotnet evangelist meeting where you can sing your dotnet songs and have > your wet dreams about Micro$oft in a more suitable atmosphere. The entries thread has been cross posted to both, equally irrelevant groups. -- Dee Earley (dee.earley(a)icode.co.uk) i-Catcher Development Team iCode Systems
From: Ralph on 4 Feb 2010 10:04
Searcher7 wrote: > > Anyway, this is why I would like to bypass a lot of the garbage and > work close to the machine code. > Well, no arguing with that. There always seems to be a lot of garbage getting in the way of providing simple solutions. Especially so-called 'higher-level' languages. Bypassing them is the most obvious solution. Wish I had thought of that. > Nevertheless, this is just one project, and VB of course is not the > way to go. > Again I heartily agree. You will be most unhappy with VB or VB.Net - far too much garbage. Drop us line in a year or so and let us know how you are doing. -ralph |