Help: Visual Basic Setup Problems

[Karl E. Peterson]

Ralph wrote :

I was a tad offended at first, but then I noticed he qualified his statement
with "reall".

I'm not sure I have ever written any reall VB6 or reall VB.Net code. so by
my very uncertainity, he is probably correct.

That's what they do down in the bayou, right?

 

[Searcher7]

Searcher7wrote:

...


If you were serious in the comments re: assembler I think that day is a
long way in the future...





...

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.

I'd think there would already be app's that could do this in existence
in the open source community which would be where I'd think you ought to
start.

--

And it seems so simple on the surface.

Perhaps I should just write my own language.

Anyway, this project,or the simple explanation of it is definitely not
for open source.

Darren Harris
Staten Island, New York.

 

[Searcher7]

[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) ... and the Video-output
needs to deal with Color-Spaces efficiently (usually the
faster Decoder-Outputs end up in YUV or UYVY/YUY2
Color-spaces when we talk about Video-Codecs) + the
then following high performant and high-quality Stretching
of such decoded Output-Buffers (+ additional Lightening/
Darkening) is then performt over DirectX or OpenGL directly
in the graphics-card hardware, meaning you nead another
"HighLevel"-API to address these devices over their
appropriate API-Interfaces on your platform of choice.

You will "go nuts", if you try all that in plain Assembler.

I'd think there would already be app's that could do this
in existence in the open source community which would
be where I'd think you ought to start.

Yep - and the language of choice in most OpenSource-
Projects is C (close enough to Assembler IMO), directly
followed by C++.
Maybe looking at the Sources of VirtualDub (just google
for it), is a good start.

Olaf

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.

Thanks.

Darren Harris
Staten Island, New York.

 

[Mike Williams]

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.

What's your real name Darren?

Mike

 

[Andrew Morton]

I would like to create an app that will allow "simple" edits on full
screen video on the fly. Sequential edits initiated via the key board
so a GUI would not be needed while it is running.

It sounds like you'll want something like
"VideoCog .NET Control: Add digital video to any .NET application instantly.
The VideoCog control is a Windows Forms control that simplifies digital
video processing for the developer."
http://www.cogitance.com/videocog-overview.htm

Although a quick look didn't reveal the price to me. You could google for
"vb.net video processing" for others.

 

[Schmidt]

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

 

[Mike Williams]

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.

Mike

 

[Searcher7]

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.

 

[Searcher7]

So Darren, did you ever get Visual Basic Express 2008 installed?

No. I'll just have to try another language.

Thanks.

Darren Harris
Staten Island, New York.

 

[Dee Earley]

[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]

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]

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.

 

[Ralph]

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

 

[Searcher7]

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 ([email protected])
i-Catcher Development Team

iCode Systems

Actually, I'm aiming for 30fps full screen and DVD quality. And all
the video would amount to about 7 minutes max.

But what do I know? I was thinking I could start with a single video
frame(image) and seeing how far I can progress from there.

VB was supposed to be my intro, but I guess not.

Darren Harris
Staten Island, New York.