Thread: [libdc] Corrupted frames under OS X - libdc1394 2.0.1
Capture and control API for IIDC compliant cameras
Brought to you by:
ddouxchamps,
gordp
From: Mark <mar...@go...> - 2008-02-26 21:00:38
|
Hi all, when displaying video from an AVT Pike or AVT Marlin under OS X 10.5.2 I am getting corrupted frames as soon as I do some other activity, e.g. open a document, copy files. Particularly, when opening QuickTime movies in QuickTime Player this happens ~80% of the times. The corruption is a fully saturated horizontal line, most of the times around 1/4 to 1/2 the frame width. Here's a sample (the color comes from the debayering): http://www.dvd-memories.de/screenshot_01.jpg At lower frame-rates this happens less frequently. There are no other devices connected to the Macs (tested with iMac and MacPro). Is this supposed to happen, how reliable is FW? Is anybody else seeing this on Linux / OS X? Cheers Mark |
From: David M. <dcm@MIT.EDU> - 2008-02-26 21:26:47
|
On Tue, 2008-02-26 at 22:00 +0100, Mark wrote: > Hi all, > > when displaying video from an AVT Pike or AVT Marlin under OS X 10.5.2 > I am getting corrupted frames as soon as I do some other activity, > e.g. open a document, copy files. Particularly, when opening QuickTime > movies in QuickTime Player this happens ~80% of the times. > > The corruption is a fully saturated horizontal line, most of the times > around 1/4 to 1/2 the frame width. Here's a sample (the color comes > from the debayering): http://www.dvd-memories.de/screenshot_01.jpg > At lower frame-rates this happens less frequently. There are no other > devices connected to the Macs (tested with iMac and MacPro). This type of corruption seems unusual to me. I usually see missing chunks of the image, rather than saturated pixels. There are certainly failure modes of the IIDC protocol that can cause various types of image corruption. I'm not sure if this is one of those cases or a software bug. It would be helpful if you could post an image with some typical image content so it's easier to judge the nature of the corruption. Ideal would be a "correct" image followed by the same scene with corruption. Thanks, David |
From: Mark <mar...@go...> - 2008-02-26 21:45:13
|
On 26.02.2008, at 22:26, David Moore wrote: > On Tue, 2008-02-26 at 22:00 +0100, Mark wrote: >> Hi all, >> >> when displaying video from an AVT Pike or AVT Marlin under OS X >> 10.5.2 >> I am getting corrupted frames as soon as I do some other activity, >> e.g. open a document, copy files. Particularly, when opening >> QuickTime >> movies in QuickTime Player this happens ~80% of the times. >> >> The corruption is a fully saturated horizontal line, most of the >> times >> around 1/4 to 1/2 the frame width. Here's a sample (the color comes >> from the debayering): http://www.dvd-memories.de/screenshot_01.jpg >> At lower frame-rates this happens less frequently. There are no other >> devices connected to the Macs (tested with iMac and MacPro). > > This type of corruption seems unusual to me. I usually see missing > chunks of the image, rather than saturated pixels. > > There are certainly failure modes of the IIDC protocol that can cause > various types of image corruption. I'm not sure if this is one of > those > cases or a software bug. > > It would be helpful if you could post an image with some typical image > content so it's easier to judge the nature of the corruption. Ideal > would be a "correct" image followed by the same scene with corruption. The image was taken with the lens cap so the corruption is easier to see. The camera is sending in RAW format, debayering is done afterwards. Would a RAW frame perhaps be better than a debayered? Mark |
From: David M. <dcm@MIT.EDU> - 2008-02-26 22:10:54
|
On Tue, 2008-02-26 at 22:45 +0100, Mark wrote: > The image was taken with the lens cap so the corruption is easier to > see. The camera is sending in RAW format, debayering is done > afterwards. Would a RAW frame perhaps be better than a debayered? > Either one is fine. I mainly want to see if data is missing from the image, tearing, or merely corrupted. That's why it's helpful that there is a background scene. -David |
From: Mark <mar...@go...> - 2008-02-27 16:56:09
|
Here are some more screenshots of corrupted frames. http://www.dvd-memories.de/1.jpg http://www.dvd-memories.de/2.jpg http://www.dvd-memories.de/3.jpg http://www.dvd-memories.de/4.jpg http://www.dvd-memories.de/5.jpg http://www.dvd-memories.de/6.jpg http://www.dvd-memories.de/7.jpg http://www.dvd-memories.de/8.jpg AVT Marlin, FW400, Format 7 Mode 0, packet size DC1394_USE_MAX_AVAIL. Shutter is set at 20ms => 50fps (camera max is ~53fps). Should I perhaps try other packet sizes? Any recommendation for FW400 and FW800. Thanks Mark On 26.02.2008, at 23:10, David Moore wrote: > On Tue, 2008-02-26 at 22:45 +0100, Mark wrote: > >> The image was taken with the lens cap so the corruption is easier to >> see. The camera is sending in RAW format, debayering is done >> afterwards. Would a RAW frame perhaps be better than a debayered? >> > > Either one is fine. I mainly want to see if data is missing from the > image, tearing, or merely corrupted. That's why it's helpful that > there > is a background scene. > > -David > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: David M. <dcm@MIT.EDU> - 2008-02-27 20:39:27
|
On Wed, 2008-02-27 at 17:55 +0100, Mark wrote: > Here are some more screenshots of corrupted frames. > > http://www.dvd-memories.de/1.jpg > http://www.dvd-memories.de/2.jpg > http://www.dvd-memories.de/3.jpg > http://www.dvd-memories.de/4.jpg > http://www.dvd-memories.de/5.jpg > http://www.dvd-memories.de/6.jpg > http://www.dvd-memories.de/7.jpg > http://www.dvd-memories.de/8.jpg > Frames 1, 3, and 7 are pretty typical of what happens when a packet is dropped due to bus traffic. In the future, I hope to detect some of these cases in libdc1394 and drop the corrupted frames instead of passing them through to the application. Frames 2, 4, 5, 6, and 8 are much more unusual. It appears that a few pixels are merely corrupted rather than missing. I haven't seen this type of failure mode before. Assuming that the camera didn't actually send the data already corrupted, the only cause I can think of would be a software bug that overwrites some of the existing image data. It is not possible for the image data to be corrupted on the bus, since there are checksums to verify the integrity of each packet. If this is indeed some type of bug, it would have to be in the Mac OS firewire stack, libdc1394, or your display application. -David |
From: David M. <dcm@MIT.EDU> - 2008-02-28 02:01:00
|
On Wed, 2008-02-27 at 15:39 -0500, David Moore wrote: > It is > not possible for the image data to be corrupted on the bus, since there > are checksums to verify the integrity of each packet. > Ah, I am wrong there! I went back and looked at the OHCI specs, and in fact the CRC is checked, but the packet data is passed to us even if it has been detected to be corrupt. We are responsible for looking at the error codes for _each_ packet and making sure they are valid. For obscure reasons, this only applies to Mac OS. The technique Linux uses for capturing packets _does_ automatically discard them if they are corrupt. That's why I hadn't seen this before. So in fact, these corruptions you are seeing are probably a result of bus traffic, just like the skipped packets. I can weed these out by checking the error codes for each packet, which I am currently ignoring. I will whip up some code for this and check it into SVN hopefully later tonight. This change will only apply to Mac OS. -David |
From: Mark <mar...@go...> - 2008-02-28 08:01:06
|
On 28.02.2008, at 03:00, David Moore wrote: > On Wed, 2008-02-27 at 15:39 -0500, David Moore wrote: >> It is >> not possible for the image data to be corrupted on the bus, since >> there >> are checksums to verify the integrity of each packet. >> > > Ah, I am wrong there! > > I went back and looked at the OHCI specs, and in fact the CRC is > checked, but the packet data is passed to us even if it has been > detected to be corrupt. We are responsible for looking at the error > codes for _each_ packet and making sure they are valid. > > For obscure reasons, this only applies to Mac OS. The technique Linux > uses for capturing packets _does_ automatically discard them if they > are > corrupt. That's why I hadn't seen this before. > > So in fact, these corruptions you are seeing are probably a result of > bus traffic, just like the skipped packets. I can weed these out by > checking the error codes for each packet, which I am currently > ignoring. > > I will whip up some code for this and check it into SVN hopefully > later > tonight. This change will only apply to Mac OS. Are bad packets automatically re-transmitted or does that mean that from now on a frame with bad packets will be just dropped? If the later is the case, it would be great to know that somehow - maybe capture_dequeue could just deliver the bad frame with a return code of DC1394_BAD_FRAME instead of DC1394_SUCCESS. Mark |
From: Mark <mar...@go...> - 2008-02-27 21:55:53
|
Hello David, thanks once again for taking a look. On 27.02.2008, at 21:39, David Moore wrote: > On Wed, 2008-02-27 at 17:55 +0100, Mark wrote: >> Here are some more screenshots of corrupted frames. > Frames 1, 3, and 7 are pretty typical of what happens when a packet is > dropped due to bus traffic. In the future, I hope to detect some of > these cases in libdc1394 and drop the corrupted frames instead of > passing them through to the application. Allow me a newby question: I noted that I get these bad frames mostly when there is access to to the local hard drive. Doing CPU intensive tasks or transferring data over ethernet do not seem to cause corruption. So is it normal that packets are dropped when there is bus traffic, or is this caused due to poor hardware design? > Frames 2, 4, 5, 6, and 8 are much more unusual. It appears that a few > pixels are merely corrupted rather than missing. I haven't seen this > type of failure mode before. Assuming that the camera didn't actually > send the data already corrupted, the only cause I can think of would > be > a software bug that overwrites some of the existing image data. It is > not possible for the image data to be corrupted on the bus, since > there > are checksums to verify the integrity of each packet. > > If this is indeed some type of bug, it would have to be in the Mac OS > firewire stack, libdc1394, or your display application. I'm not modifying the libdc buffers is any way, they are just copied to an OpenGL buffer and then processed. To be sure, I did some tests without OpenGL processing: the RAW data coming from libdc is already corrupted. I also tested this on the app I had developed before switching to libdc - the app uses Apple's IIDC VDIG through the QuickTime Sequence Grabber. Interestingly the corruption appears there too. So libdc is not the cause. Is there anything I should try out before contacting Apple? Cheers Mark |
From: Damien D. <ddo...@is...> - 2008-02-28 01:33:48
|
Hi Mark, David, On Wed, 2008-02-27 at 15:39 -0500, David Moore wrote: > On Wed, 2008-02-27 at 17:55 +0100, Mark wrote: > > Here are some more screenshots of corrupted frames. > > > > http://www.dvd-memories.de/1.jpg > > http://www.dvd-memories.de/2.jpg > > http://www.dvd-memories.de/3.jpg > > http://www.dvd-memories.de/4.jpg > > http://www.dvd-memories.de/5.jpg > > http://www.dvd-memories.de/6.jpg > > http://www.dvd-memories.de/7.jpg > > http://www.dvd-memories.de/8.jpg > > > > Frames 1, 3, and 7 are pretty typical of what happens when a packet is > dropped due to bus traffic. In the future, I hope to detect some of > these cases in libdc1394 and drop the corrupted frames instead of > passing them through to the application. Note that the dropped packet happens just after a little strip of "bad data" in the three images. Not sure what to do with that info yet ;) > Frames 2, 4, 5, 6, and 8 are much more unusual. It appears that a few > pixels are merely corrupted rather than missing. I haven't seen this > type of failure mode before. Assuming that the camera didn't actually > send the data already corrupted, the only cause I can think of would be > a software bug that overwrites some of the existing image data. It is > not possible for the image data to be corrupted on the bus, since there > are checksums to verify the integrity of each packet. > > If this is indeed some type of bug, it would have to be in the Mac OS > firewire stack, libdc1394, or your display application. On frame 8, the bad data line on the left shows more than just bad data: a small area around each white spot is completely black, without noise. This contrasts with the noisy black region of the building's window. Similar artefacts are present on other images too. oh wait, this is a JPG! That explains a lot ;) As you suggested before, can you post RAW data as PGM? It probably won't change much but I want to be sure. Another thing to try: use an interface card (cardbus, etc) with an external power supply and see what happens. The fact that there is a correlation between a heavy use of other PC's ressources (HDD, QT) and the appearance of bad data makes me thing that there may be EMI when using the integrated chipset. I have seen this before on cheap PCs ;) -- Damien 高原 Douxchamps Assistant Professor, Image Processing Laboratory, NAIST http://damien.douxchamps.net/ |
From: Mark <mar...@go...> - 2008-02-28 13:17:49
|
> oh wait, this is a JPG! That explains a lot ;) As you suggested > before, > can you post RAW data as PGM? It probably won't change much but I want > to be sure. Here are some more samples as tiff - 8bit, gray, no compression, no processing. http://www.dvd-memories.de/raw_frame_520.tiff http://www.dvd-memories.de/raw_frame_763.tiff http://www.dvd-memories.de/raw_frame_1398.tiff http://www.dvd-memories.de/raw_frame_1614.tiff http://www.dvd-memories.de/raw_frame_1685.tiff Mark |
From: Ulf-Erik W. <ulf...@hh...> - 2008-02-28 08:01:30
|
Hi, > Frames 1, 3, and 7 are pretty typical of what happens when a packet is > dropped due to bus traffic. In the future, I hope to detect some of > these cases in libdc1394 and drop the corrupted frames instead of > passing them through to the application. It is not clear that this happens on the firewire bus: I just have a nice problem here with a std. PC: Packages get lost with one 1394b camera and a PCI-e card, but not when using a PCI-64 card. I think you are using raw images that get de-bayering in your application, right? The interesting mosaic-artefacts are looking like a expensive algorithm (edge-sensing with wrong pattern caused by missing pixels). > Frames 2, 4, 5, 6, and 8 are much more unusual. It appears that a few > pixels are merely corrupted rather than missing. I haven't seen this > type of failure mode before. If you are doing the de-bayering in your application I am wondering about these artefacts - very bright and very dark pixels close together, but only very little color artefacts. Is it possible to get an uncompressed image - so we can see what colors are from jpeg compression and what are from de-bayering? Or even some raw images? Gruessle, Ulf. |
From: Mark <mar...@go...> - 2008-02-28 10:05:26
|
>> Hi Ulf, >> Frames 1, 3, and 7 are pretty typical of what happens when a packet >> is >> dropped due to bus traffic. In the future, I hope to detect some of >> these cases in libdc1394 and drop the corrupted frames instead of >> passing them through to the application. > > It is not clear that this happens on the firewire bus: I just have a > nice problem here with a std. PC: Packages get lost with one 1394b > camera and a PCI-e card, but not when using a PCI-64 card. Just talked to AVT Support:) We will try out using a PCIe card on the MacPro - maybe it does work. > I think you are using raw images that get de-bayering in your > application, right? The interesting mosaic-artefacts are looking > like a > expensive algorithm (edge-sensing with wrong pattern caused by > missing pixels). It's a variation of AHD. >> Frames 2, 4, 5, 6, and 8 are much more unusual. It appears that a >> few >> pixels are merely corrupted rather than missing. I haven't seen this >> type of failure mode before. > > If you are doing the de-bayering in your application I am wondering > about these artefacts - very bright and very dark pixels close > together, > but only very little color artefacts. AHD will choose the debayering direction with highest homogeneity, maybe thats why we have few color artifacts. Besides, the screenshots also had sharpening, so the contrast of the bad pixels was enhanced. What's weird is that the stepping of bad pixels seems to follow a patters....and I think it's odd so it's just some R, G or B pixels that get corrupt. I'll check that out. > > Is it possible to get an uncompressed image - so we can see what > colors > are from jpeg compression and what are from de-bayering? Or even some > raw images? I'm doing some changes to my app so I can capture the RAW stream as images. Cheers Mark |
From: David M. <dcm@MIT.EDU> - 2008-02-28 08:34:09
|
On Thu, 2008-02-28 at 09:00 +0100, Mark wrote: > On 28.02.2008, at 03:00, David Moore wrote: > > I will whip up some code for this and check it into SVN hopefully > > later > > tonight. This change will only apply to Mac OS. > > Are bad packets automatically re-transmitted or does that mean that > from now on a frame with bad packets will be just dropped? If the > later is the case, it would be great to know that somehow - maybe > capture_dequeue could just deliver the bad frame with a return code of > DC1394_BAD_FRAME instead of DC1394_SUCCESS. > Alright, code is now checked into SVN that should detect corrupted frames on Mac OS and drop them. Could you try that out? It should produce copious warnings to stderr for each packet that has an error. I can tune these down once I'm sure it's working. I'm curious to see a sample of these warnings output from your machine. These changes touched a lot of code, so keep an eye out for any regressions as well. I think the best way to inform the app of these drops is to add a new function, something like: dc1394_capture_get_drop_count (camera, &num); You could call this after every dequeue to see if any new frames were dropped. Does that seem reasonable? I don't really like adding a DC1394_BAD_FRAME return code because that would imply that the dequeue somehow failed, when it did not. -David |
From: Stefan R. <st...@s5...> - 2008-02-28 08:48:41
|
> On Thu, 2008-02-28 at 09:00 +0100, Mark wrote: >> Are bad packets automatically re-transmitted or does that mean that >> from now on a frame with bad packets will be just dropped? Retry mechanisms only exist for asynchronous I/O but not for isochronous I/O. Isochronous has to deliver data in time or not at all. -- Stefan Richter -=====-==--- --=- ===-- http://arcgraph.de/sr/ |
From: Mark <de...@ci...> - 2008-03-10 17:29:27
|
Hi all, just a little update on this: for about 10 days ago we installed a IOI FWB-PCIE10 - FW800 PCIe board. That solved the corrupted frames problem and also solved a all sorts of errors when sending commands to the camera. Looks like the MacPro's built in FW800 interface is far from perfect (maybe the new MacPro's are better in this regard since FW is now connected internally over PCIe). Unfortunately that did not solve the "Could not create LocalIsochPortInterface" problem. In 2 weeks I'll have access to the computer this is happening and will try my luck with the FW SDK debug kernel extensions - hopefully that will shed some light into what is going on. In the meantime I found that reducing the number of DMAs allocated for capture reduces the likeliness of the error. Going from 64 to 16 DMAs made the error appear once every 3-4 days (instead of every few hours). Cheers Mark On 28.02.2008, at 09:33, David Moore wrote: > On Thu, 2008-02-28 at 09:00 +0100, Mark wrote: >> On 28.02.2008, at 03:00, David Moore wrote: >>> I will whip up some code for this and check it into SVN hopefully >>> later >>> tonight. This change will only apply to Mac OS. >> >> Are bad packets automatically re-transmitted or does that mean that >> from now on a frame with bad packets will be just dropped? If the >> later is the case, it would be great to know that somehow - maybe >> capture_dequeue could just deliver the bad frame with a return code >> of >> DC1394_BAD_FRAME instead of DC1394_SUCCESS. >> > > Alright, code is now checked into SVN that should detect corrupted > frames on Mac OS and drop them. Could you try that out? > > It should produce copious warnings to stderr for each packet that > has an > error. I can tune these down once I'm sure it's working. I'm curious > to see a sample of these warnings output from your machine. These > changes touched a lot of code, so keep an eye out for any > regressions as > well. > > I think the best way to inform the app of these drops is to add a new > function, something like: > dc1394_capture_get_drop_count (camera, &num); > > You could call this after every dequeue to see if any new frames were > dropped. Does that seem reasonable? > > I don't really like adding a DC1394_BAD_FRAME return code because that > would imply that the dequeue somehow failed, when it did not. > > -David > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: Mark <mar...@go...> - 2008-02-28 09:50:21
|
> I think the best way to inform the app of these drops is to add a new > function, something like: > dc1394_capture_get_drop_count (camera, &num); > > You could call this after every dequeue to see if any new frames were > dropped. Does that seem reasonable? > > I don't really like adding a DC1394_BAD_FRAME return code because that > would imply that the dequeue somehow failed, when it did not. I'm just thinking about a way to still get the corrupted frame - maybe for debugging purposes. When I reported the issue the first thing you asked me for was screenshots of the bad frames... I'll try out the changes - thanks! Mark |
From: Mark <mar...@go...> - 2008-02-28 13:52:37
|
Hi David, just tried to compile it, but I'm getting some errors. Did all changes make it to SVN? /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:146: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:148: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:151: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:153: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:156: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:158: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:167: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:195: error: 'BUFFER_CORRUPT' undeclared (first use in this function) /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:195: error: (Each undeclared identifier is reported only once /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:195: error: for each function it appears in.) /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:229: error: 'packet_info' undeclared (first use in this function) /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:237: warning: comparison between signed and unsigned /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:261: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:261: error: syntax error before ')' token /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:267: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:268: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:273: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:278: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:279: error: 'struct _buffer_info' has no member named 'pkts' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:423: error: 'struct __dc1394_capture' has no member named 'last_dequeued' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:424: error: 'struct __dc1394_capture' has no member named 'last_enqueued' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c: In function 'platform_capture_stop': /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:610: error: 'struct __dc1394_capture' has no member named 'last_dequeued' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:610: error: 'struct __dc1394_capture' has no member named 'last_dequeued' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:620: error: 'BUFFER_CORRUPT' undeclared (first use in this function) /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:640: error: 'struct __dc1394_capture' has no member named 'last_dequeued' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c: In function 'platform_capture_enqueue': /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:663: error: 'struct __dc1394_capture' has no member named 'last_enqueued' /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:675: error: 'BUFFER_CORRUPT' undeclared (first use in this function) /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:678: error: 'BUFFER_ENQUEUED' undeclared (first use in this function) /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third-Party/ libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/macosx/ capture.c:685: error: 'struct __dc1394_capture' has no member named 'last_enqueued' On 28.02.2008, at 09:33, David Moore wrote: > On Thu, 2008-02-28 at 09:00 +0100, Mark wrote: >> On 28.02.2008, at 03:00, David Moore wrote: >>> I will whip up some code for this and check it into SVN hopefully >>> later >>> tonight. This change will only apply to Mac OS. >> >> Are bad packets automatically re-transmitted or does that mean that >> from now on a frame with bad packets will be just dropped? If the >> later is the case, it would be great to know that somehow - maybe >> capture_dequeue could just deliver the bad frame with a return code >> of >> DC1394_BAD_FRAME instead of DC1394_SUCCESS. >> > > Alright, code is now checked into SVN that should detect corrupted > frames on Mac OS and drop them. Could you try that out? > > It should produce copious warnings to stderr for each packet that > has an > error. I can tune these down once I'm sure it's working. I'm curious > to see a sample of these warnings output from your machine. These > changes touched a lot of code, so keep an eye out for any > regressions as > well. > > I think the best way to inform the app of these drops is to add a new > function, something like: > dc1394_capture_get_drop_count (camera, &num); > > You could call this after every dequeue to see if any new frames were > dropped. Does that seem reasonable? > > I don't really like adding a DC1394_BAD_FRAME return code because that > would imply that the dequeue somehow failed, when it did not. > > -David > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Mailing list for libdc1394-devel > lib...@li... > https://lists.sourceforge.net/lists/listinfo/libdc1394-devel |
From: Mark <mar...@go...> - 2008-02-28 14:18:32
|
Ignore this please - compiled fine. Will test the changes now. On 28.02.2008, at 14:52, Mark wrote: > Hi David, > > just tried to compile it, but I'm getting some errors. > Did all changes make it to SVN? > > > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:146: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:148: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:151: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:153: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:156: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:158: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:167: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:195: error: 'BUFFER_CORRUPT' undeclared (first use > in this function) > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:195: error: (Each undeclared identifier is reported > only once > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:195: error: for each function it appears in.) > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:229: error: 'packet_info' undeclared (first use in > this function) > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:237: warning: comparison between signed and unsigned > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:261: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:261: error: syntax error before ')' token > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:267: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:268: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:273: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:278: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:279: error: 'struct _buffer_info' has no member > named 'pkts' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:423: error: 'struct __dc1394_capture' has no member > named 'last_dequeued' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:424: error: 'struct __dc1394_capture' has no member > named 'last_enqueued' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c: In function 'platform_capture_stop': > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:610: error: 'struct __dc1394_capture' has no member > named 'last_dequeued' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:610: error: 'struct __dc1394_capture' has no member > named 'last_dequeued' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:620: error: 'BUFFER_CORRUPT' undeclared (first use > in this function) > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:640: error: 'struct __dc1394_capture' has no member > named 'last_dequeued' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c: In function 'platform_capture_enqueue': > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:663: error: 'struct __dc1394_capture' has no member > named 'last_enqueued' > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:675: error: 'BUFFER_CORRUPT' undeclared (first use > in this function) > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:678: error: 'BUFFER_ENQUEUED' undeclared (first use > in this function) > /Users/maolimu/Documents/Projekte/DVD-Memories/Development/Third- > Party/libdc1394/libdc1394-2.0.1-framework/../libdc1394_svn/dc1394/ > macosx/capture.c:685: error: 'struct __dc1394_capture' has no member > named 'last_enqueued' > > > > > On 28.02.2008, at 09:33, David Moore wrote: > >> On Thu, 2008-02-28 at 09:00 +0100, Mark wrote: >>> On 28.02.2008, at 03:00, David Moore wrote: >>>> I will whip up some code for this and check it into SVN hopefully >>>> later >>>> tonight. This change will only apply to Mac OS. >>> >>> Are bad packets automatically re-transmitted or does that mean that >>> from now on a frame with bad packets will be just dropped? If the >>> later is the case, it would be great to know that somehow - maybe >>> capture_dequeue could just deliver the bad frame with a return >>> code of >>> DC1394_BAD_FRAME instead of DC1394_SUCCESS. >>> >> >> Alright, code is now checked into SVN that should detect corrupted >> frames on Mac OS and drop them. Could you try that out? >> >> It should produce copious warnings to stderr for each packet that >> has an >> error. I can tune these down once I'm sure it's working. I'm >> curious >> to see a sample of these warnings output from your machine. These >> changes touched a lot of code, so keep an eye out for any >> regressions as >> well. >> >> I think the best way to inform the app of these drops is to add a new >> function, something like: >> dc1394_capture_get_drop_count (camera, &num); >> >> You could call this after every dequeue to see if any new frames were >> dropped. Does that seem reasonable? >> >> I don't really like adding a DC1394_BAD_FRAME return code because >> that >> would imply that the dequeue somehow failed, when it did not. >> >> -David >> >> >> ------------------------------------------------------------------------- >> This SF.net email is sponsored by: Microsoft >> Defy all challenges. Microsoft(R) Visual Studio 2008. >> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >> _______________________________________________ >> Mailing list for libdc1394-devel >> lib...@li... >> https://lists.sourceforge.net/lists/listinfo/libdc1394-devel > |
From: Mark <mar...@go...> - 2008-02-28 15:20:26
|
>>> Alright, code is now checked into SVN that should detect corrupted >>> frames on Mac OS and drop them. Could you try that out? >>> >>> It should produce copious warnings to stderr for each packet that >>> has an >>> error. I can tune these down once I'm sure it's working. I'm >>> curious >>> to see a sample of these warnings output from your machine. These >>> changes touched a lot of code, so keep an eye out for any >>> regressions as >>> well. Seems to be working fine - wasn't able to spot any corrupted frames. But they are there: 2008-02-28 15:58:36.106 SharpScan 2[2766:fb03] ERROR: packet 34 had error status 8445 2008-02-28 15:58:41.076 SharpScan 2[2766:fb03] ERROR: packet 0 had error status 8445 2008-02-28 15:58:41.077 SharpScan 2[2766:fb03] ERROR: packet 149 had unexpected sync (b8c00a1) 2008-02-28 15:58:43.253 SharpScan 2[2766:fb03] ERROR: packet 57 had error status 8445 2008-02-28 15:58:45.213 SharpScan 2[2766:fb03] ERROR: packet 15 had error status 8445 2008-02-28 15:58:51.686 SharpScan 2[2766:fb03] ERROR: packet 27 had error status 8445 2008-02-28 15:58:53.706 SharpScan 2[2766:fb03] ERROR: packet 104 had error status 8445 2008-02-28 15:58:55.844 SharpScan 2[2766:fb03] ERROR: packet 45 had error status 8445 2008-02-28 15:58:57.903 SharpScan 2[2766:fb03] ERROR: packet 20 had error status 8445 2008-02-28 15:58:59.963 SharpScan 2[2766:fb03] ERROR: packet 29 had error status 8445 2008-02-28 15:58:59.964 SharpScan 2[2766:fb03] ERROR: packet 149 had unexpected sync (b8c00a1) 2008-02-28 15:59:01.644 SharpScan 2[2766:fb03] ERROR: packet 86 had error status 8445 2008-02-28 15:59:03.426 SharpScan 2[2766:fb03] ERROR: packet 128 had error status 8445 2008-02-28 15:59:03.427 SharpScan 2[2766:fb03] ERROR: packet 129 had error status 8445 2008-02-28 15:59:05.506 SharpScan 2[2766:fb03] ERROR: packet 67 had error status 8445 2008-02-28 15:59:05.507 SharpScan 2[2766:fb03] ERROR: packet 149 had unexpected sync (b8c00a1) 2008-02-28 15:59:07.247 SharpScan 2[2766:fb03] ERROR: packet 30 had error status 8445 2008-02-28 15:59:07.267 SharpScan 2[2766:fb03] ERROR: packet 108 had error status 8445 2008-02-28 15:59:11.919 SharpScan 2[2766:fb03] ERROR: packet 80 had error status 8445 2008-02-28 16:00:26.596 SharpScan 2[2766:fb03] ERROR: packet 73 had error status 8445 2008-02-28 16:00:39.326 SharpScan 2[2766:fb03] ERROR: packet 114 had error status 8445 2008-02-28 16:00:39.329 SharpScan 2[2766:fb03] ERROR: packet 115 had error status 8445 2008-02-28 16:00:50.155 SharpScan 2[2766:fb03] ERROR: packet 94 had error status 8445 2008-02-28 16:00:50.156 SharpScan 2[2766:fb03] ERROR: packet 95 had error status 8445 2008-02-28 16:01:25.078 SharpScan 2[2766:fb03] ERROR: packet 51 had error status 8445 2008-02-28 16:01:25.078 SharpScan 2[2766:fb03] ERROR: packet 52 had error status 8445 2008-02-28 16:01:25.098 SharpScan 2[2766:fb03] ERROR: packet 65 had error status 8445 2008-02-28 16:01:25.099 SharpScan 2[2766:fb03] ERROR: packet 66 had error status 8445 2008-02-28 16:01:27.018 SharpScan 2[2766:fb03] ERROR: packet 109 had error status 8445 2008-02-28 16:01:42.856 SharpScan 2[2766:fb03] ERROR: packet 126 had error status 8445 2008-02-28 16:01:46.302 SharpScan 2[2766:fb03] ERROR: packet 6 had error status 8445 2008-02-28 16:01:46.303 SharpScan 2[2766:fb03] ERROR: packet 149 had unexpected sync (b8c00a1) 2008-02-28 16:01:47.647 SharpScan 2[2766:fb03] ERROR: packet 28 had error status 8445 2008-02-28 16:01:47.648 SharpScan 2[2766:fb03] ERROR: packet 29 had error status 8445 2008-02-28 16:01:52.339 SharpScan 2[2766:fb03] ERROR: packet 39 had error status 8445 2008-02-28 16:01:54.101 SharpScan 2[2766:fb03] ERROR: packet 54 had error status 8445 2008-02-28 16:01:58.793 SharpScan 2[2766:fb03] ERROR: packet 137 had error status 8445 2008-02-28 16:01:58.794 SharpScan 2[2766:fb03] ERROR: packet 138 had error status 8445 2008-02-28 16:02:03.663 SharpScan 2[2766:fb03] ERROR: packet 132 had error status 8445 2008-02-28 16:02:06.633 SharpScan 2[2766:fb03] ERROR: packet 134 had error status 8445 2008-02-28 16:02:06.653 SharpScan 2[2766:fb03] ERROR: packet 69 had error status 8445 2008-02-28 16:02:10.375 SharpScan 2[2766:fb03] ERROR: packet 25 had error status 8445 2008-02-28 16:02:10.711 SharpScan 2[2766:fb03] ERROR: packet 119 had error status 8445 2008-02-28 16:02:10.889 SharpScan 2[2766:fb03] ERROR: packet 71 had error status 8445 2008-02-28 16:02:11.048 SharpScan 2[2766:fb03] ERROR: packet 17 had error status 8445 2008-02-28 16:02:11.049 SharpScan 2[2766:fb03] ERROR: packet 145 had error status 8445 2008-02-28 16:02:11.186 SharpScan 2[2766:fb03] ERROR: packet 105 had error status 8445 2008-02-28 16:02:11.187 SharpScan 2[2766:fb03] ERROR: packet 106 had error status 8445 2008-02-28 16:02:11.366 SharpScan 2[2766:fb03] ERROR: packet 17 had error status 8445 2008-02-28 16:02:11.366 SharpScan 2[2766:fb03] ERROR: packet 149 had unexpected sync (b8c00a1) |
From: David M. <dcm@MIT.EDU> - 2008-03-12 04:14:05
|
On Thu, 2008-02-28 at 10:50 +0100, Mark wrote: > > I don't really like adding a DC1394_BAD_FRAME return code because that > > would imply that the dequeue somehow failed, when it did not. > > > I'm just thinking about a way to still get the corrupted frame - maybe > for debugging purposes. When I reported the issue the first thing you > asked me for was screenshots of the bad frames... > I'm changing my mind about the corrupted frame detection. I think I'd like to return the corrupted frame data from dc1394_capture_dequeue() just like a normal frame. However, there will be a new function: dc1394bool_t dc1394_capture_is_frame_corrupt (dc1394camera_t *, dc1394video_frame_t *); which can be used to test if a frame is corrupt or not (after it has been dequeued). The main reason for this is that when using select() on juju or Linux, the file descriptor becomes readable as soon as a frame is available, whether it is corrupt or not. At this point, dc1394_capture_dequeue() is expected to run without blocking and return some data. Thus, to keep this working properly, it makes sense to return the data and let the user test for corruption if they are so included. An alternative option is to set frame=NULL from dequeue if the frame is corrupt. Anyone have thoughts? -David |
From: Damien D. <ddo...@is...> - 2008-03-12 04:34:47
|
On Wed, 2008-03-12 at 00:13 -0400, David Moore wrote: > On Thu, 2008-02-28 at 10:50 +0100, Mark wrote: > > > I don't really like adding a DC1394_BAD_FRAME return code because that > > > would imply that the dequeue somehow failed, when it did not. > > > > > > I'm just thinking about a way to still get the corrupted frame - maybe > > for debugging purposes. When I reported the issue the first thing you > > asked me for was screenshots of the bad frames... > > > > I'm changing my mind about the corrupted frame detection. I think I'd > like to return the corrupted frame data from dc1394_capture_dequeue() > just like a normal frame. > > However, there will be a new function: > > dc1394bool_t dc1394_capture_is_frame_corrupt (dc1394camera_t *, dc1394video_frame_t *); > > which can be used to test if a frame is corrupt or not (after it has > been dequeued). > > The main reason for this is that when using select() on juju or Linux, > the file descriptor becomes readable as soon as a frame is available, > whether it is corrupt or not. At this point, dc1394_capture_dequeue() > is expected to run without blocking and return some data. > > Thus, to keep this working properly, it makes sense to return the data > and let the user test for corruption if they are so included. > > An alternative option is to set frame=NULL from dequeue if the frame is > corrupt. > > Anyone have thoughts? IMHO if we received data we should give it to the user. Using a specific function also allows us to integrate other data verification in the future (such as an image CRC provided by some manufacturers). -- Damien 高原 Douxchamps Assistant Professor, Image Processing Laboratory, NAIST http://damien.douxchamps.net/ |
From: Mark <de...@ci...> - 2008-03-12 13:59:35
|
On 12.03.2008, at 05:13, David Moore wrote: > On Thu, 2008-02-28 at 10:50 +0100, Mark wrote: >>> I don't really like adding a DC1394_BAD_FRAME return code because >>> that >>> would imply that the dequeue somehow failed, when it did not. >> >> I'm just thinking about a way to still get the corrupted frame - >> maybe >> for debugging purposes. When I reported the issue the first thing you >> asked me for was screenshots of the bad frames... >> > > I'm changing my mind about the corrupted frame detection. I think I'd > like to return the corrupted frame data from dc1394_capture_dequeue() > just like a normal frame. > > However, there will be a new function: > > dc1394bool_t dc1394_capture_is_frame_corrupt (dc1394camera_t *, > dc1394video_frame_t *); > > which can be used to test if a frame is corrupt or not (after it has > been dequeued). That looks very good to me. Still, I believe most of us (at least on Mac) would be calling this function for every frame so returning DC1394_BAD_FRAME from dc1394_capture_dequeue seems a bit easier to me. I'm not sure though if changing that is a problem for existing apps. > An alternative option is to set frame=NULL from dequeue if the frame > is > corrupt. I don't like this as when using DC1394_CAPTURE_POLICY_POLL we can then no longer differentiate drops from "no frame available". Mark |
From: David M. <dcm@MIT.EDU> - 2008-03-17 03:13:44
|
On Wed, 2008-03-12 at 00:13 -0400, David Moore wrote: > However, there will be a new function: > > dc1394bool_t dc1394_capture_is_frame_corrupt (dc1394camera_t *, dc1394video_frame_t *); > > which can be used to test if a frame is corrupt or not (after it has > been dequeued). > This is checked in now. You can use dc1394_capture_is_frame_corrupt() on all platforms to check if an image is corrupt. Currently, only Mac OS will ever return DC1394_TRUE. Other platforms are just hard coded to return DC1394_FALSE at the moment. Eventually, there will be a Linux juju implementation of this. Linux video1394 will never have this capability due to kernel limitations. Some testing would be greatly appreciated, especially on Mac OS. I suggest we sit on this for a few days, and if no problems come up, I am ready for 2.0.2 to be released. I will update the NEWS file with a list of the new functions available. Damien, don't forget to update the library versioning when you release 2.0.2. Since current:revision:age for 2.0.1 was 22:1:0, it should become 23:0:1 for release 2.0.2. And of course it's always a good idea to double check that the SO major version is still 22 after doing a compile. Regards, David |
From: Dr. D. C. M. <do...@mo...> - 2008-03-19 03:18:04
Attachments:
testTriggering.cc
|
I am stumped on why our BumbleBee2 cameras run at a slower rate than the hardware trigger input. If I run the attached test program without any parameters it does not enable hardware triggering, and I receive 20 frames per second from the camera, which is their maximum speed at the 1024x768x2 stereo bayer pattern. If you pass the test program any parameters it enables hardware triggering. Our trigger signal is 80% high, 20% low running at 6Hz. We are using falling edge triggering. However, the test program receives frames at 2Hz. We have looked at the waveform in the past and it has always been nice and square. Is there any stringent requirements on the trigger waveform that I should know about? If I slow the trigger signal down to 1 Hz, the test program receives frames at 1Hz. When I set it to 2Hz, I get frames at 2Hz. But, if the trigger signal is any faster than 2Hz, I just receive frames at 2Hz. We have had intermittent problems with the cameras running at 1/2 speed when we triggered at 5Hz, and now they seem to run at 1/3 speed when we trigger at 6 Hz. In the past, the problem always magically went away when we tried to debug the issue. Switching to the final release of libdc1394-2 seems to have made it a persistent issue for us. I have attached a minimal test file. I build it using: g++ testTriggering.cc -ldc1394 I am running on an up to date Fedora Core 8 machine. Dual core x86. The standard FC8 libdc1394 from yum is installed: > rpm -qi libdc1394 Name : libdc1394 Relocations: (not relocatable) Version : 2.0.1 Vendor: Fedora Project Release : 3.fc8 Build Date: Sat 19 Jan 2008 06:38:38 PM EST Install Date: Fri 29 Feb 2008 11:06:14 AM EST Build Host: xenbuilder1.fedora.redhat.com Thanks for any suggestions or ideas you might have, Doug -- Douglas C. MacKenzie, Ph.D. Mobile Intelligence Corporation 13620 Merriman Road Livonia, MI 48150-1814 mailto:do...@mo... http://www.mobile-intelligence.com |