trailerCap - Exerimental Build 3 - (no disk save)

[vhelp]

TOOL: - trailerCap v0.0.1 - BETA -

Note - Non working version until further notice..



Progress/Research/Updates/Notes.. fwiw..

* done - researched Threads and now added into tools performance
* N/A -- researching Streams
* N/A -- resarching best method to store BITMAPS or on-the-fly AVI's.
.
050305 - Experimental Build 3
- added minor cosmetic changes

050205 - Experimental Build 2
- added: capture area fields
- added: copy-to-clipboard
- added: rough fps calculation (works)
- added: frame totals
- added: reset
- added: setting for Interval adjustment

042605 - Experminental Build 1
- update/research other performance techniques, etc.

042405
- birth of trailerCap (non-working version)

I made a trailer capture app today. It's the first, of a very rough
beta/draft version. At least it halfway works. But, I need some help with
a few weak areas (see below)

I realize that there are many out there, and I could just as easily D/L them
(in the TOOLS section, I'm sure) but I wanted to conjure up my very own, in
an effort to learn a few things, and to fullfill a dream I had of this project
some time ago. Plus, I always fear those tools that one D/L 's, as they
sometimes incorporate some form of spyware. And, that was another reason
why I did not bother to D/L a streaming app for this cause. Anyways.

The whole thing, (so far) took maybe an hour to figure out and debug, and to
incorporate into the tool successfully, like:

* capturing - the video from the browser's window
* sizing ---- the capture window
* saving ---- video frame to clipboard
* adding ---- Pause button
* adding ---- take a piture button

There are a few other things to build and add to this tool.
But, a few things could use some fine-tuning and others, to make more
user friendly. For now, it's just a quicky-tool that I conjured up inside
an hour or two, and is working, to an extent

Slight History:

But, it's ben a great since it struck me this afternoon,
right after I had just finished waiting for a long D/L of a
new movie trailer from http://www.apple.com/trailers
Then, my desktop crashed, and my movie had to re-download. I
couldn't figure out why it had to, when it was already D/L 'ed
to begin with. I'm still at a loss. Anyways.
So, I came up with the idea, to just capture the video, and
have my merry little way with it. Save as a set of BMP files
and finally, to an AVI file.. perhaps for a re-encode to a cheap
VCD or something. The imagination just continues

The weak areas ...

During the video capturing, the capture window (when moved by the
user) is a little jiddery. I am using a timer control, and during
the timers interval, (video capturing) and this control is probably
the casue of the jidderyness. I was wondering how to make the forms
window more smooth, when dragged around the users desktop.
.
Does anyone know what is the technique for a smooth drag when a
window being dragged during the timer intervals ??

Thanks,
-vhelp 3297

[gll99]

The tool is a dead link.
The hyper text only contains

http://http://

[vhelp]

Sorry. I was trying to make the tool under a 100k
(it's 383k) and things stopped working.

I'm working on reducing the size (I know I've seen
it somewhere, just can't remember)

I'll try and make it available.
-vhelp 3299

[vhelp]

ok. I just found out that I lost the code that saves the captures
to BMP's ..RaTs !! (I think I didn't save when I closed down
the app - I was on a role) I should have just left things alone in the
first place.

.. My next step was gonna be to figure out how to convert the BMP's to
.. AVI's. But now.. shoot.

I just hope I can remember what I did Back to the drawing board..

Now, my head hurts.
-vhelp 3300

[Baldrick]

don't you make hourly backups?

[vhelp]

don't you make hourly backups?

No. I'm still under window 98 gold
(thanks for your consern and interest)

I found out that my Projects folder is corrupt and crosslinked with
a buntch of files I don't know anything about. It's a mess, and I
have to reboot now, and loose my quicktime trailer inside my browser
that I was using for this tools tests and things ..oh well.

I did a search for a new timer control - freeware and I think
it might help out w/ my window jiddering whenever moved. Plus, I still
have to re-invent the wheel again with saving to BMP's, of which I also
still have to devise a method for my BMP -to- AVI ..and then
there is the audio

But, even though this is a setback, it's been really exciting to develope
this app so quickly, though my brain is drained and I lost my luster
to continue

As of now, (thanks to my problems) the current stage of trailerCap:

* it can only capture the video to the clipboard, and
* save one pic one at a time. (ie, copy, save.. copy save.. etc)

I'll give an update if anything changes later on.

-vhelp 3303

[gll99]

Good to see someone is working on this.
What language are you writing with. I have various vb code that will do screen caps and save to bmp. I also have vb code that will copy bmp to avi originally written by Ray Mercer which I believe he translated from MS C sample code. VBPlanet has a lot of related stuff it just needs to be tied together under one program.

Capturing the audio to a separate wave or mp3 file shouldn't be a problem either but it would probably have to be muxed after capture.

Too bad I never found code in VB6 (or older vb) that would write screen caps straight to avi. I have experimented with it a bit but don't have a working model yet. I just haven't invested the time.

The real issue with these types of programs is keeping a constant frame rate and usually it's hard to get more than 10 to 15 fps. I too experimented with the pause, snap,save to bmp then continue idea. I used the ms player and tested with dvd and avi files instead of streaming video. I wrote a time point on every frame but funny enough even that did not produce a constant number of frames per second. I gave that up for a while due to lack of time but I'lll get back to it one day.

Anyway, that's why I wanted to write to avi right away to eliminate a step.

btw) why would the user move the cap area. I don't start the cap til the user sets the top left and bottom right corners with mouse clicks so that I know what part of the active window to capture.

[vhelp]

What language are you writing with.

Delphi 6, under windows 98 gold.

Capturing the audio to a separate wave or mp3 file shouldn't
be a problem either but it would probably have to be muxed after capture.

The audio is a whole other beast. I could probably find code snips to
capture it, but I think you are right, in that the A/V should be captured
in separtely, and MUXed later. Could be an last step, when A/V is captured
and the user wants to Finalize it ..just ad a progress bar and make
things look busy.

Anyway, that's why I wanted to write to avi right away to
eliminate a step.

Writing to an AVI in one step would be better. But, I'm limited by the
amount of resources I have (knowledge) ..so, saving to BMP's seem like
the logical step. Other ideas could be built upon it or fine-tuned
later.

btw) why would the user move the cap area. I don't start the cap
til the user sets the top left and bottom right corners with mouse clicks
so that I know what part of the active window to capture.

Because sometimes, the user (me) might forget, and start dragging the
window around. There could be a reason to move the window.. like when
trying to make room, or re-orient the desktop. Weather you forget to
stop the capture or not, the jittering shouldn't happen. But, you are
right. It does make sense. First get your coordinates set, THEN begin
the capture. Make things that simple, though it could be looked at as
clumsy. Anyways.

The bottom line here with this project, is seeming to point into one
direction. Streams.

Update ...

I re-invented the wheel again with the BMP's, though the same method
was not applied. I implemented a new one. But, it's sluggish, and
eats up a lot of reasources (or seems to) though, when I close down
the app, and restart it, it fine again. Needs debuggin. But, it works
for the video part (no audio yet)
.
I've also changed/revised/added in, features within trailerCap. So, it
does look a little different than before.

Other problems ...

One thing is for sure. Something is eating at the resource. I used
vdub as the video server platform, and sized a small enough window (no
sense on bogging everything down with a full blown resolution)
but vdub seems to lock onto its own thread, and welds itself to it,
causing my trailerCap to studder. But, if I open notepad w/ some text
in it, and move that window around (w/in my capture window's area) it
flows pretty smooth (about 95% or so) and I can also move trailerCap
around as well during the capturing phase, again (about 95% or so) and
everything is fine. It's only when I use vdub and capture from it, that
things go cookoo.
.
I think I need to create a Thread that locks itself to some resources
and my subroutine to capture and/or save to a Stream.

FWIW.. when I initially started out on this endeavor, I had no intention
of including the audio. I only wanted the video captured. Later, I was
going to add in the audio w/ a separate audio capture app. But, then
I decided that if I'm going to go this distance, then maybe I better
include the audio. I don't know. For now, I'm not going to conentrate
so much on the audio. At least not until I get the Stream and Threads
theory some thought, and figure out how to reduce the sluggishness of
the video capture to files worked out.

I have an idea. (rough-drafted) ...

Program two streams, one for Video, and other for Audio. And capture
both to these streams. Actually, I was throwing this around in my mind
today. I belive that part of the bottle neck is the area of saving
to the BMP files. Too many files are being opened, initialezed and
closed, all during the capturing process. Plus, no ASSEMBLY code is
being used. But, if other apps can be writen in Delphi and C++ in this
area, then surely, I can write something up as well
.
Streams is something new to me. I have very little experience with it.
But, give me a week, and I'll probably write a book on it, in the end :P

So, the process, the way I see it (and add to my limited knowledge) is
something like this:

* Capture Video (screen area)
* Capture Audio (internal thread maybe - needs research)
* Save to Stream, every 1 second, flush out all streams, but hold one
.. or two for continued capturing (as buffers) and swap each set of
.. streams every 1 seconds, for instance, and yada yada..

Two areas I think I need to read up on to help me solve or reduce
the issues inside trailerCap:

* Streams, and
* Threads

-vhelp 3305

[vhelp]

Update..

I did some more research, and after some debugging, I found was able
to make some improvements (based on refining my delphi source code and
adding a new code snip to the algorithem of things) on the capturing of
the video (screen) though it's still not perfect.. it works (captures)
Well, I can't exactly explain it yet, but the code I found (part of delphi) helped
out a little, to a degree. For now, I guess you could say, (at its current
state of progress) the capture is equivalent to that of dropping frames
..but it works. So, I'm making *some* head-way.

I want to try and see how I fair, with capturing a trailer inside my browsers
window as a BETA test run.

-vhelp 3210

[vhelp]

Another UPDATE ...

During my free time, I did some additional research and came up
with some new knowledge.

Streams ...

But, I'm still having trouble with the TStreams syntax and setups 'n things.
Streams have been giving me a big head-acke. There is not much discussion
on the internet on this topic, for Delphi.., so its making things dificult
for me.
It's my opinion that Streams is secondary to Threads, with respect to their
performances, etc.

Threads ...

I found new 'er information through my research, and learnt a new
technique. This was another areas of great dificulty studying and implenting
into trailerCap. But, it proved worthy, and so far, a success. As it turns
out, I was correct about Threads. And, it was one of the hard parts of
setting up via programming code and inserting it properly. But, once my
mouse stopped moving jittery-like, I knew I was on to something, and *very
close* to my goal.

FWIW ...

I can't say for sure, weather the trailerCap 's success will be just that.
It may turn out unsuccessful, though mostly due to the above two items.
I don't think that Assembly Lanauge is necessary here. There's enough
speed/cpu power to handle that job. It's more a matter of code technique
and knowledge of the lanauge and proper sequence of things, that will
prove success or not.

Known Issues ...

When using VirtualDub as the video server/player, if you move trailercap
around it's window, (for whatever crazy purposes - I have many) it may
crash unexpectedly. So, do be wary when menovering trailerCap around
for optimum layout.

NOTE 1: trailerCap does not capture any Overlay window. Only RGB
and VFW type video modes.

NOTE 2: One of the new things I have learnt was how to obtain a
given windows DC number. It's not perfect, and (an assumption here) only
those windows that have an Image associated with it will probably work.
However, I may add in such fields, because not every window will have an
Image associated with it. For instance, vdub has an Image.., and a DC to
go with it. trailerCap can lock onto it, and make use of it, and capture
from it.

NOTE 3: I've also included a pare of x,y fields, *but* the default
"capture area" is set to 640 x 268 for the time being. Try testing a given
app in question, (ie, vdub; browser windows; players; etc) by inputing
it's Caption name at the top. You don't have to spell it completely, but just
enough. Otherwise, you may need to spell it out completly
If it doesn't work, then chances are, it doesn't have an Image DC
associated with it, or it uses another method all-together. These will
require a more direct approach (using the x,y fields I talked about above)
You set your X and Y accordingly as, X = Left / Y = Top coordinates.

NOTE 4 The FPS resporting is based on a calculation, and timer
event. It should be pretty accurate, but I suspect its not a perfect
emplementation for FPS reporting. But, it serves its perpose for now.
Math is not my strong point. And, I had an issue with the proper
calculation for the timer's (Interval to Seconds) math. I do know that
every 1000 Intervals is 1 second past. But, how do you calculate
29 fps (frames) in a second, with relation to the 1000 Intervals ?
At the moment, I don't know

NOTE 5 Pause and Reset stops the capture. Use them interchangeably.

Currently ...

You can D/L an Experimental Test version. Though mostly for debugging
purposes. Note:

* Does not Save nor Copy to anything. In it's current state of
* appearance and operation, its more a strip-down test tune-up tool, just
* to see if it works ok on one's system.

I may add a few more "hack tweaks" for the testing phase to set and fiddle
around with, which may, or may not help in performance or FPS. I left them
out, but only because I'm so tired and exhuasted from all the researching;
coding; testing; debugging; writing notes; etc etc and, so on and so forth
that I have done over the last week. Plus, I lost a couple of days worth
of researching and coding due to "un-necessary need to explain" events
Plus, I have other projects (ie, YUV; 16-235; 0-255; color space; tools;
etc) to work on.
.
I don't have time to continue writing here nor pointing out TIP's n things,
but there are other cosmetics to change or add into trailerCap, but I'm too
tired, and its past my bedtime. Perhaps tomorrow, if I'm up to it, I'll
continue some more. For now, just tinker with it, and do a buch of what-ifs
and things. Experiment with different apps, and just remember that the
current default "capture area" window is approx 640 x 268 or so. Just set
the X,Y coordinates for your Left and Top capture points, and you should
be good to go.
.
Adjust the X,Y during capture (or Pause) modes. You'll figure it out for
yourself, what works for ya.
.
Report anything you like, or suggestions are welcomed. Thanks.

DOWNLOAD ...

--> trailerCap v0.0.0 - Experimental Build 2



-vhelp 3323

[Duck11]

Hi there!! i've recently found screen capture tool that is an easy and fastest way to take video screen captures from Windows screen.Its quite nice tool, i have checked!!! xxxxxxxxxxx

[gll99]

Hi there!! i've recently found screen capture tool that is an easy and fastest way to take video screen captures from Windows screen.Its quite nice tool, i have checked!!! http://www.geovid.com/Screen_VidShot/

How does this shareware help vhelp with his project

I think you're missing the point. There are countless tools like that floating around and some are free. The fun and frustration of researching and programming your own tool is what this is all about.

Now if you released the source code that would be a different matter altogether. 8)