|
|
|
date: Tue, 22 Jul 2008 09:26:56 +0200,
group: microsoft.public.win32.programmer.directx.video
back
Re: Firewire Device ID
The March Hare [MVP] wrote:
> On Wed, 23 Jul 2008 09:51:12 -0600, The March Hare [MVP] wrote:
>
>> You may want to look at C:\Windows\inf\msdv.inf too (I checked for this
>> file on a standard Vista Ultimate install after finding it on Code Center
>> Premium).
>
> Was this helpful, Johan?
>
Well, to some extent....
The following are firewire ID:s of devices (as reported by Dirext/X)
that I have handy:
(I have a Canon camcorder also, but evidently it has had its firewire
port "fried", not uncommon unfortunately. Always run your PC from a
grounded power outlet!!)
804580005d5c34b1 = Panasonic NV-GS11
1460008f8926301 = Sony TRV-900
14600088c8f1303 = Sony DCR-HC14E
1112000b140014 = Canopus ADVC-55 (analog to DV/firewire converter)
I haven't been able to figure out how to decode these strings correctly.
XP does not display the vendor name for Canopus, but Panasonic and Sony
are displayed correctly, so evidently that data is in there...
I have not spent so much time on this problem lately. I have been busy
testing a system (DV based) for timing/photofinish for greyhound racing.
The Swedish Championships were held here all of last week, and my system
performed well. Organizers and participants were very pleased.
Conventional wisdom may have it that you need a fullblown slot-camera
system for this kind of work.
Practical experience now shows that you don't.
A DV camera (actually I use 2, one at the goal line and one for "split
timing") using a short shutter time and de-interlaced will give you
sufficient precision at a fraction of comparable cost!
/Johan
date: Tue, 29 Jul 2008 11:52:56 +0200
author: Johan Stäck
Re: Firewire Device ID
The March Hare [MVP] wrote:
>
> Good! I'm not sure how they're coming up with the 2011 from the Canopus id
> but since they're doing it for you, you can just look for the ven_XXXX
> string, I guess.
I also don't really understand how it´s done, but I will use the output
anyway. It is not critical to the application, but is is nice to be able
to display what is detected at each firewire input.
>
>>> [13 quoted lines suppressed]
>> Timing and track records etc. for greyhound racing is done to a 1/100th
>> of a second.
>> The basic timing resolution between two deinterlaced (PAL) fields is 2/50.
>> However, it is very easy to adjust the timing and add 1/100 to a dog if
>> needed. Not so easy to describe in words, but if you see two fields you
>> will understand what I mean...
>
> That's a good idea. You have the advantage of PAL here :) With NTSC it
> would be harder to translate to 1/100 units.
Yes, and also with NTSC there are fewer pixels to work with and I need
all of them..
Actually, I use rotated cameras in order to put the available picture
area to its best use. The area of interest (the goal line) has a
"portrait" orientation as opposed to "landscape" that you get with the
camera in default orientation.
>
>> During the whole week, we never failed once to determine the winners.
>
> Congrats! How do you get the starting time of the race? Is there a
> starter's pistol which you record onto the DV stream?
>
Before the heat start the dogs are put into boxes.
When the box gates opens (reaching a 45 degree angle), a simple electric
switch sends a pulse to the timing equipment.
/Johan
date: Wed, 30 Jul 2008 08:06:43 +0200
author: Johan Stäck
Re: Firewire Device ID
The March Hare [MVP] wrote:
>
> Are you using widescreen mode too? Many of the new miniDV camcorders use
> this mode. I wonder if the HDV camcorders would help you with clarity.
No, I have not tried widescreen.
As for HDV, I doubt (but need to confirm) that a HDV stream is useful
for my purposes. A DV stream (as we both know) contains frames that can
be stored/decoded/displayed one-by-one due to the non-temporal
compression used.
A HDV stream uses a temporal compression and will probably be very
difficult to use the way I use DV.
>
>> When the box gates opens (reaching a 45 degree angle), a simple electric
>> switch sends a pulse to the timing equipment.
>
> Does the timing equipment inscribe the timing onto the video? That's what
> I've seen for track races in the US.
>
The way my system works is as follows.
When the start pulse is received, I retrieve a millisecond timer from
Windows (using TimeGetTime). This is stored in the file header.
As each DV frame is received from Direct/X I retrieve the same kind of
timestamps, and these are inserted into the DV frame itself before
storing it. A DV frame has plenty of room for placing your own data,
since the DV metadata block (timecode etc) is repeated all over the
frame. I leave the first one untouched, but use the second one for my
own purposes.
During capture, I don't show any preview of the video, so the CPU load
is low (decompressing/de-interlacing/rotating/blitting is rather
CPU-intensive..), and I never seem to loose a frame.
Also, capture is a two-stage process, first capture to a memory buffer
and secondly writing to disk.
(The dogs passes the goal line in a few seconds)
When reading the frames back, it is easy to use the stored time-stamps
to calculate the elapsed time for every frame/field. I do not overlay
the video itself with this information so I don't have to recompress.
I use a proprietary file format that starts with a big XML based file
header followed by DV frames. The format allows for easy appending of DV
frames, since there is no need for an index as in AVI files.
/Johan
date: Wed, 30 Jul 2008 10:33:48 +0200
author: Johan Stäck
Re: Firewire Device ID
On Wed, 30 Jul 2008 10:33:48 +0200, Johan Stäck wrote:
> No, I have not tried widescreen.
Depending on the speed of the dogs, if it works with your 1/100
interpolation, it might give you a better picture with the newer
camcorders. I'm guessing that their sensors are optimized for widescreen
since that is the default format.
> A HDV stream uses a temporal compression and will probably be very
> difficult to use the way I use DV.
It may be worth investigating. I don't know if the HDV format drops any
frames as part of its compression.
> The way my system works is as follows.
> When the start pulse is received, I retrieve a millisecond timer from
> Windows (using TimeGetTime). This is stored in the file header.
How do you account for the delay between the video and receiving the DV
samples? I have observed about a 1/4 second delay before they are processed
in my app using a "real-time" preview.
> As each DV frame is received from Direct/X I retrieve the same kind of
> timestamps, and these are inserted into the DV frame itself before
> storing it. A DV frame has plenty of room for placing your own data,
> since the DV metadata block (timecode etc) is repeated all over the
> frame. I leave the first one untouched, but use the second one for my
> own purposes.
That's clever use of the DV header :)
> During capture, I don't show any preview of the video, so the CPU load
> is low (decompressing/de-interlacing/rotating/blitting is rather
> CPU-intensive..), and I never seem to loose a frame.
I'm guessing you're not using Vista. It seems to spawn all kinds of junk
even if you turn off every conceivable service. Not that XP is a RTOS, but
it isn't nearly as bad as Vista in this respect.
> Also, capture is a two-stage process, first capture to a memory buffer
> and secondly writing to disk.
> (The dogs passes the goal line in a few seconds)
That helps :)
> I use a proprietary file format that starts with a big XML based file
> header followed by DV frames. The format allows for easy appending of DV
> frames, since there is no need for an index as in AVI files.
Yeah, DV frames are much easier to work with than most others since they
are fixed size.
--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution
date: Wed, 30 Jul 2008 13:05:20 -0600
author: The March Hare [MVP] erland
Re: Firewire Device ID
The March Hare [MVP] wrote:
> On Wed, 30 Jul 2008 10:33:48 +0200, Johan Stäck wrote:
>
>
> How do you account for the delay between the video and receiving the DV
> samples? I have observed about a 1/4 second delay before they are processed
> in my app using a "real-time" preview.
This does not seem to be a problem.
My capture graph is very basic: capture/sample grabber/nullrender.
No preview or any other CPU-intensive work going on when capturing.
Therefore, it is only a question of data-transport at a rate that is
very easy on the hardware.
I have also seen noticeable delays on both my own (and other peoples)
apps (watching a drummer on the jumbo-display at a concert, clearly
out-of-sync with the sound...), but then there is much more processing
going on.
Later, we will run a test with my system in parallel with a
"professional" slot-camera based timing system, and that will be
interesting...
>
>
> I'm guessing you're not using Vista. It seems to spawn all kinds of junk
> even if you turn off every conceivable service. Not that XP is a RTOS, but
> it isn't nearly as bad as Vista in this respect.
I have been using Vista, but my list of "things that go better with
Vista" is *very* short...
Right now, I have reverted to XP for my development machine.
I also always recommend XP if at all possible.
Even such a basic feature as DV camera preview is missing in Vista....
But since almost all new computers these days come with Vista, I have to
try and cope with it, and it does seem to work.
/Johan
date: Thu, 31 Jul 2008 10:30:52 +0200
author: Johan Stäck
Re: Firewire Device ID
On Thu, 31 Jul 2008 10:30:52 +0200, Johan Stäck wrote:
> This does not seem to be a problem.
> My capture graph is very basic: capture/sample grabber/nullrender.
> No preview or any other CPU-intensive work going on when capturing.
> Therefore, it is only a question of data-transport at a rate that is
> very easy on the hardware.
You're at least 0.02 out of sync with live since you're getting the two
fields, unless you're compensating for that :)
I expect there is some other latency without a decoder even with 100 Mbps
transport. I will be interested to hear what you find in comparison to the
slot camera.
The problem as I see it is that since Windows is not an RTOS there could be
concern with the accuracy. Of course, if you're not dropping frames and
the camcorder can produce exactly 50 field/s, all you need is the accurate
start time. I wonder if anyone has done tests to see how accurate the fps
are in consumer level DV camcorders.
> I have also seen noticeable delays on both my own (and other peoples)
> apps (watching a drummer on the jumbo-display at a concert, clearly
> out-of-sync with the sound...), but then there is much more processing
> going on.
Yes, I've seen this but I haven't measured this delay precisely either
since it has not been a cause for customer complaints.
> I have been using Vista, but my list of "things that go better with
> Vista" is *very* short...
I think security is better even if you have UAC off.
I like the new UI and the text seems better. Stability has been great. I
have Ultimate and I like that the business and MCE features are combined.
The new backup with full computer backup has worked well so far. I was
using Acronis, which works great on XP, but it's nice to have it built-in.
> Right now, I have reverted to XP for my development machine.
> I also always recommend XP if at all possible.
My experience Vista runs well given the appropriate hardware. I recommend
4 GB and a quad core processor, if possible (dual core seems okay but, as I
remarked earlier, the OS tends to spawn lots of junk). I have never
recommended someone upgrade an XP machine to Vista.
> Even such a basic feature as DV camera preview is missing in Vista....
> But since almost all new computers these days come with Vista, I have to
> try and cope with it, and it does seem to work.
Yes, the preview is missing which is odd. There are other minor annoyances
and a few major ones but not enough to make me want to go back to XP for my
main dev machine.
--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution
date: Fri, 1 Aug 2008 01:23:59 -0600
author: The March Hare [MVP] erland
Re: Firewire Device ID
The March Hare [MVP] wrote:
> On Thu, 31 Jul 2008 10:30:52 +0200, Johan Stäck wrote:
>
>
> You're at least 0.02 out of sync with live since you're getting the two
> fields, unless you're compensating for that :)
I have worked out a very simple but (I believe) very accurate method for
compensation of any timing offsets in my system.
This however, I dont't want to discuss in public. If you just make your
e-mail adress known to me (you have my adress from my postings) I will
show you how it's done!
>
>
> The problem as I see it is that since Windows is not an RTOS there could be
> concern with the accuracy. Of course, if you're not dropping frames and
> the camcorder can produce exactly 50 field/s, all you need is the accurate
> start time. I wonder if anyone has done tests to see how accurate the fps
> are in consumer level DV camcorders.
<"Windows is not an RTOS">
True (sort if...). While discussing various aspects of this on some
swedish fora, I have been told of all the terrible things that would
happen to me and my system if I ever tried it.
*None* of this has come true (yet..).
I have been doing some tests on the accuracy of the frame rate of some
consumer camcorders. My findings are that although they do drift away
after hours, the accuracy is more than what is needed.
>
>> I have also seen noticeable delays on both my own (and other peoples)
>> apps (watching a drummer on the jumbo-display at a concert, clearly
>> out-of-sync with the sound...), but then there is much more processing
>> going on.
>
> Yes, I've seen this but I haven't measured this delay precisely either
> since it has not been a cause for customer complaints.
It is fairly well known that it is much easier to fool a persons eye
that his ear. This means that if a musician (e.g. drummer) has sound
and picture out-of-sync, most people will notice. Take the sound out of
the picture (unintentional pun) and things get much easier...
>
>
> Yes, the preview is missing which is odd. There are other minor annoyances
> and a few major ones but not enough to make me want to go back to XP for my
> main dev machine.
>
I had to set up a new development machine for hardware reasons (I
wanted a motherboard that can drive 2 separate displays as-is).
With only 1 Vista licence, I decided to take XP again...
Vista is of course here to stay, whether we like it or not...
/Johan
date: Sun, 03 Aug 2008 10:02:53 +0200
author: Johan Stäck
Re: Firewire Device ID
On Sun, 03 Aug 2008 10:02:53 +0200, Johan Stäck wrote:
> I have worked out a very simple but (I believe) very accurate method for
> compensation of any timing offsets in my system.
> This however, I dont't want to discuss in public. If you just make your
> e-mail adress known to me (you have my adress from my postings) I will
> show you how it's done!
Okay, thanks :)
> <"Windows is not an RTOS">
> True (sort if...). While discussing various aspects of this on some
> swedish fora, I have been told of all the terrible things that would
> happen to me and my system if I ever tried it.
> *None* of this has come true (yet..).
It would certainly be a concern if I were attempting this. Since you have
found a way to empirically test your results, that's great.
> I have been doing some tests on the accuracy of the frame rate of some
> consumer camcorders. My findings are that although they do drift away
> after hours, the accuracy is more than what is needed.
I wouldn't have expected that they are designed for accuracy to the 100ths
of seconds over a significant period.
> It is fairly well known that it is much easier to fool a persons eye
> that his ear. This means that if a musician (e.g. drummer) has sound
> and picture out-of-sync, most people will notice. Take the sound out of
> the picture (unintentional pun) and things get much easier...
I see this sync problem mentioned on WMTALK which has discussions on
streaming problems.
> I had to set up a new development machine for hardware reasons (I
> wanted a motherboard that can drive 2 separate displays as-is).
> With only 1 Vista licence, I decided to take XP again...
> Vista is of course here to stay, whether we like it or not...
Have you looked at the MS Partner Program or Empower Program? I will send
more details in the email I send you :)
--
Please read this before replying:
1. Dshow & posting help: http://tmhare.mvps.org/help.htm
2. Trim & respond inline (please don't top post or snip everything)
3. Benefit others: follow up if you are helped or you found a solution
date: Mon, 4 Aug 2008 10:11:05 -0600
author: The March Hare [MVP] erland
|
|
