# Patent

## Title
Capture device movement compensation for speaker indexing

## Abstract

Embodiments of the invention compensate for the movement of a meeting capture device during a live meeting when performing speaker indexing of a recorded meeting. In one example, a first position of a capture device is determined. A second position of the capture device is determined after the capture device has been moved from the first position to the second position. The movement data associated with movement of the capture device from the first position to the second position is determined. The movement data is outputted and used in speaker indexing of the recorded meeting.

## Background
BACKGROUND
Meetings are often conducted using videoconferencing systems. A meeting may be conducted using one or more capture devices, such as a video camera and microphone. The meeting may also be recorded and viewed at a later time by the meeting participants or by those who were unable to attend the live meeting.
A meeting recording may be indexed by slides and speaker sites (e.g., conference room 1, remote office 1, remote office 2, etc.). Another method of indexing the meeting recording is by speakers within a conference room (e.g., speaker 1, 2, 3, etc.). To index speakers, a cluster analysis on the sound source localization directions from a microphone array may be performed to determine location and number of speakers in the conference room in reference to a capture device. In one instance, speaker indexing assumes speakers don't change seats or walk around the room during a meeting. Today's speaker indexing works well when the capture device is fixed in place, such as when a video camera is attached to a conference room table.
However, if the capture device is moved during a meeting (e.g., rotated), then the speaker indexing performed on the meeting recording may have flaws. The speaker indexing after the capture device movement may not match the speaker indexing before the capture device movement. Current videoconferencing systems fail to determine when capture device movement occurs and fail to compensate for the capture device movement in speaker indexing.
SUMMARY
The following presents a simplified summary of the disclosure in order to provide a basic understanding to the reader. This summary is not an extensive overview of the disclosure and it does not identify key/critical elements of the invention or delineate the scope of the invention. Its sole purpose is to present some concepts disclosed herein in a simplified form as a prelude to the more detailed description that is presented later.
Embodiments of the invention compensate for the movement of a capture device during a live meeting when performing speaker indexing of a recorded meeting. In one embodiment, a vision-based method is used to detect capture device movement. Vision-based methods may use image features, edge detection, or object modeling to detect capture device movement. In another embodiment, a hardware-based method is used to determine capture device movement. Hardware-based methods include using accelerometers and/or magnetometers at the capture device. Movement data associated with capture device movement may be applied to speaker indexing.
Many of the attendant features will be more readily appreciated as the same become better understood by reference to the following detailed description considered in connection with the accompanying drawings.



BRIEF DESCRIPTION OF THE DRAWINGS
Like reference numerals are used to designate like parts in the accompanying drawings.
FIG. 1 is a block diagram showing translational movement of a capture device in accordance with an embodiment of the invention.
FIG. 2 is a block diagram showing azimuthal movement of a capture device in accordance with an embodiment of the invention.
FIG. 3 is a block diagram of a distributed meeting system in accordance with an embodiment of the invention.
FIG. 4 is a user interface for an archived meeting client in accordance with an embodiment of the invention.
FIG. 5 is a block diagram of a speaker indexing system in accordance with an embodiment of the invention.
FIG. 6 is a block diagram of cluster analysis in accordance with an embodiment of the invention.
FIG. 7 is a flowchart showing the logic and operations of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 8 is a flowchart showing the logic and operations of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 9 shows an example of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 10 shows an example of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 11 is a flowchart showing the logic and operations of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 12 shows an example of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 13 shows an example of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 14 is a flowchart showing the logic and operations of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 15 shows an example of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 16 shows a capture device in accordance with an embodiment of the invention.
FIG. 17 is a flowchart showing the logic and operations of capture device movement compensation in accordance with an embodiment of the invention.
FIG. 18 is a block diagram of an example computing device for implementing embodiments of the invention.



DETAILED DESCRIPTION
The detailed description provided below in connection with the appended drawings is intended as a description of the present examples and is not intended to represent the only forms in which the present examples may be constructed or utilized. The description sets forth the functions of the examples and the sequence of steps for constructing and operating the examples. However, the same or equivalent functions and sequences may be accomplished by different examples.
Overview of a Distributed Meeting System with Capture Device Movement Compensation
Turning to FIGS. 1 and 2, examples of capture device movement that may occur when a capture device 104 is recording a live meeting will be discussed. FIGS. 1 and 2 show top views of a table 102 surrounded by six chairs in a conference room 101. Capture device 104 is on top of table 102 for capturing audio and video of a meeting conducted in conference room 101. In one embodiment, capture device 104 includes an omni-directional camera and at least one microphone for capturing audio and video. An example capture device is described below in conjunction with FIG. 16.
In FIG. 1, capture device 104 is moved translationally while capturing a meeting. Video capture device 104 is moved from a first position (shown by (X1, Y1)) to a second position (shown by (X2, Y2)). It will be appreciated that translational movement may also include a Z-direction. It will also be appreciated that capture device movement may also include tilting of video capture device 104. In FIG. 2, video capture device 102 is moved azimuthally from azimuth θ1 to azimuth θ2, where the azimuth is measured in reference to reference point 106 on capture device 104. In another example, only the camera portion of capture device 104 is moved, but the base of capture device 104 remains stationary.
Turning to FIG. 3, a distributed meeting system 300 in accordance with embodiments of the invention is shown. One or more computing devices of system 300 may be connected by one or more networks. System 300 includes a meeting room server (e.g., a PC, a notebook computer, etc.) 302 connected to capture device 104. Capture device 104 captures the audio and video of meeting participants in room 101. Live meeting clients 304 and 305 are also connected to meeting room server 302 when a meeting is conducted. Live meeting clients 304 and 305 enable remote users to participate in a live meeting. Audio and video from capture device 104 may be sent to live meeting clients 304 and 305 by server 302 during the live meeting. Video and/or audio of users at live meeting clients 304 and 305 may be sent to meeting room server 302 using capture devices (not shown) at live meeting clients 304 and 305. Meeting room server 302 may record the audio/video captured by capture device 104. Meeting room server 302 is connected to archived meeting server 306. Archived meeting server 306 may archive the recorded meeting.
Meeting room server 302 may perform video post-processing including speaker indexing with capture device movement compensation as described herein. In alternative embodiments, other computing devices, such as archived meeting server 306 or capture device 104, may perform capture device movement compensation as described herein. An example computing device for implementing one or more embodiments of the invention is discussed below in conjunction with FIG. 18.
In system 300, archived meeting clients 307 and 308 may connect to archived meeting server 306 for viewing a recorded meeting. The recorded meeting may have received post-processing which may include speaker indexing. The speaker indexing may use embodiments of capture device movement compensation as described herein.
Turning to FIG. 4, an embodiment of an archived meeting client User Interface (UI) 400 is shown. UI 400 may be used to view a recorded meeting. UI 400 includes speaker video 402, playback controls 404, meeting timeline 406, whiteboard image 408, whiteboard key frame table of contents 410, and panoramic view 412. Live meeting clients 304 and 305 have UIs similar to UI 400 during the live meeting except they may not include meeting timeline 406 and whiteboard key frame table of contents 410.
Speaker video 402 shows video of the current speaker in the video recording. This video may have been captured by capture device 104 in room 101, by another capture device in room 101, or a capture device at a remote live client 304.
Playback controls 404 allow the user to adjust the playback of the recorded meeting, such as fast forward, rewind, pause, play, play speed (e.g., 10×, 1.5×, 2.0×), volume control and the like. In one embodiment, when play speed is increased, the speaker's voice is played without changing the speaker's voice pitch. In another embodiment, the play speed may be selected on a per-person basis (e.g., whenever speaker 1 speaks, play speed is 10×, but whenever speaker 2 speaks, play speed is 1.5×). In yet another embodiment, time compression may be applied to the recorded meeting to remove pauses to enhance the playback experience.
Whiteboard image 408 shows the contents of a whiteboard in room 101. Pen strokes on the whiteboard are time-stamped and synchronized to the meeting audio/video.
Key frames for the whiteboard are shown in whiteboard key frame table of contents 410. Panoramic view 412 shows video captured by capture device 104.
Meeting timeline 406 shows the results of speaker segmentation. Speakers at the meeting are segmented and assigned a horizontal line (i.e., an individual speaker timeline) in meeting timeline 406. Speakers can be filtered using checkboxes so only the selected speakers will playback. Playback speed for each individual speaker may also be selected. Also, a separate line in meeting timeline 406 may show special events such as key frames, annotations, projector switch to shared application, and the like. A user may click on a position in meeting timeline 406 to jump the playback to the selected timeline position. Speaker segmentation in meeting timeline 406 is producing using speaker indexing. Speaker indexing uses speaker clustering techniques to identify the number of speakers at a meeting and the speaker locations in relation to a video recording. The speaker segmentation in meeting timeline 406 has been adjusted for capture device movement during the live meeting using embodiments as described herein.
In FIG. 5, a speaker indexing system 500 is shown that uses cluster analysis. An Active Speaker Detector (ASD) 506 receives real-time video footage 502 and real-time Sound Source Localization (SSL) 504 as input. SSL 504 analyzes the microphone array audio captured during the meeting and detects when a meeting participant is talking. SSL 504 may be input as a probability distribution function. ASD 506 analyzes video 502 and SSL 504 and determines when each meeting participant is talking.
Virtual Cinematographer (VC) 508 takes the determination made by ASD 506 and applies further analysis and cinemagraphic rules to compute a speaker azimuth 510 for each speaker, where the speaker azimuth is referenced from capture device 104. VC 508 is used for real-time speaker control. Cluster analysis is performed during post processing. As shown in FIG. 5, audio/video information is stored in a file 512 by VC 508. In post-processing, cluster analysis module 514 may use file 512 to perform cluster analysis for use in playback of the recorded videoconference. File 512 may include information for performing capture device movement compensation as described in embodiments herein.
FIG. 6 shows an embodiment of cluster analysis. User 621 is at azimuth 0 degrees from capture device 104 and user 622 is at azimuth 90 degrees from capture device 104. By analyzing the recorded audio and video, the cluster analysis algorithm finds a cluster of speaking near azimuth 0 degrees, as shown at 630. Another cluster of speaking is found near azimuth 90 degrees, as shown at 634. The cluster analysis algorithm determines that user 621 is at azimuth 0 degrees and user 622 is at azimuth 90 degrees from capture device 104. This speaker indexing may then be used to produce the speaker segmentation in meeting timeline 406 of UI 400.
However, if capture device 104 is rotated 30 degrees to the right during the live meeting, then the speaker indexing after the device movement will be 30 degrees off. This will cause problems in the video playback in UI 400. Embodiments of the invention compensate for such device movement to provide users a robust and high-quality playback experience.
Turning to FIG. 7, a flowchart 700 shows the logic and operations of capture device movement compensation for speaker indexing in accordance with an embodiment of the invention. Vision-based and hardware-based implementations of flowchart 700 are discussed below. In one embodiment, at least a portion of the logic of flowchart 700 is performed during post-processing of a recorded meeting. In alternative embodiments, capture device motion compensation as described herein may be conducted during a live meeting.
Starting in block 702, the initial position of the capture device is determined. Proceeding to block 704, capture device movement occurs. Next, in block 706, the current position of the device is determined. Next, in block 708, movement data associated with the movement of the capture device from the initial position to the current position is determined. This movement data may indicate a change in the translational position of the capture device (e.g., ΔX, ΔY, and/or ΔZ), a change in the azimuth of the capture device (e.g., Δθ), and/or a change in camera tilt angle. Proceeding to block 710, the movement data is outputted.
Next, in block 712, the movement data is applied to speaker indexing. In one embodiment, the movement data may be applied to audio/video that occurs after the capture device movement. For example, if the capture device rotated 30 degrees, then speaker indexing after the device movement may be corrected by 30 degrees. It will be appreciated that this correction technique may lead to integration error (i.e., compounding of multiple errors) when multiple movements of the device occur during a recorded meeting.
In another embodiment, the clustering analysis of the recorded meeting may be restarted after the movement of the device is detected. This correction technique may reduce integration errors in video playback, but may be computationally expensive. In restarting the cluster analysis, the resulting speaker segmentation may be used to generate multiple timelines corresponding to each time the capture device is moved (e.g., if the capture device was moved once during a live meeting, then restarting the cluster analysis may result in two timelines). The results may be displayed as two separate timelines in UI 400. For example, if the capture device moved at time t1, then meeting timeline 406 may show a new set of speakers starting at time t1. Alternatively, the results may be merged into a single timeline in UI 400. To merge the timelines, movement data may be used to correlate speaker 1 in timeline1 to the same speaker 1 in timeline 2. For example, if the movement data indicates capture device 104 rotated 45 degrees clockwise, then the logic may use this movement data to match speakers from the two timelines.
Vision-Based Movement Detection
Turning to FIG. 8, a flowchart 800 shows the logic and operations of capture device movement compensation in accordance with an embodiment of the invention. In one embodiment, at least a portion of the logic of flowchart 800 may be implemented by computer readable instructions executable by one or more computing devices. At least a portion of the logic of flowchart 800 may be conducted during the post-processing of a recorded meeting.
Starting in block 802, feature points in an image captured by capture device 104 are detected. Continuing to block 804, one or more stationary points of the feature points are selected. The stationary points are selected from the feature points that do not move over a period of time.
Next, in block 806, device movement occurs. Device movement may be detected from the image because during device movement there are no stationary points. Next in block 808, current stationary points are detected and matched to the last stationary points before device movement. Matching of current C(i) and last L(i) stationary points may be conducted using a Hough transform and a rotation (i.e., azimuth) camera motion model. For example, to determine if point C(i) matches point L(j) let




  
    M
    ⁡
    
      (
      
        i
        ,
        θ
      
      )
    
  
  =
  
    {
    
      
        
          
            1
            ⁢
            
              
            
          
        
        
          
            
              if
              ⁢
              
                
              
              ⁢
              
                
                
                  
                    R
                    ⁡
                    
                      (
                      
                        
                          L
                          ⁡
                          
                            (
                            i
                            )
                          
                        
                        ,
                        θ
                      
                      )
                    
                  
                  -
                  
                    C
                    ⁡
                    
                      (
                      j
                      )
                    
                  
                
                
              
            
            <
            T
          
        
      
      
        
          0
        
        
          otherwise
        
      
    
  




for some distance threshold T with points L rotated by θ. The Hough transform is then arg maxθ ΣjΣjM(i,θ).

Proceeding to block 810, movement data is determined from the comparison of the last and current stationary points. The movement data is then output, as shown in block 812.
In one embodiment, flowchart 800 assumes mostly azimuthal (i.e., rotational) movement of capture device 104, but limited translational movement (e.g., less than approximately 20 centimeters translational movement of the device). One skilled in the art having the benefit of this description will appreciate that flowchart 800 may be extended to include translation and camera tilt/orientation movement in the Hough transform.
Turning to FIG. 9, an example of determining capture device movement using stationary feature points is shown. In the last stationary image 904, stationary feature points have been identified in the image. For example, a corner of the whiteboard, shown at 905, has been identified as a stationary point. Last stationary image 904 has a reference azimuth of 0 degrees.
At 902, the current image after capture device movement has occurred is shown. Also at 902, stationary feature points from current image 902 have been aligned with stationary features points from last stationary image 904. As shown at 903, the corner of the whiteboard has been used as a stationary point for aligning the images. Hough transform results, shown at 906, indicate the capture device azimuth has changed to 300 degrees (i.e., the device has been turned 60 degrees to the left).
Turning to FIG. 10, an example of determining capture device movement using stationary feature points is shown. In last stationary image 1004, stationary feature points have been identified in the image. For example, a door knob, shown at 1005, has been identified as a stationary point. Image 1004 has a reference azimuth of 0 degrees.
Image 1002 shows the current image after movement has occurred. Stationary points from current image 1002 have been aligned with stationary points from the last stationary image 1004. As shown at 1003, the doorknob has been used as a stationary point for aligning the images. Hough transform results, shown at 1006, indicate the capture device azimuth has rotated to 035 degrees (i.e., the device has been rotated 35 degrees to the right).
Turning to FIG. 11, a flowchart 1100 shows the logic and operations of capture device movement compensation using a correlation based technique (as opposed to a feature based technique) in accordance with an embodiment of the invention. In one embodiment, at least a portion of the logic of flowchart 1100 may be implemented by computer readable instructions executable by one or more computing devices. At least a portion of the logic of flowchart 1100 may be conducted during the post-processing a recorded meeting.
In one embodiment, flowchart 1100 assumes azimuthal camera motion and little translational motion. One skilled in the art having the benefit of this description will appreciate that flowchart 1100 may be extended to include translation and camera tilt/orientation movement to the Hough transform.
Starting in block 1102, the edges in an image are detected and an edge image is produced. In one embodiment, an edge detector (such as Canny edge detection) is used as a feature detector. The edges are filtered over time to detect stationary edges and spatially smoothed. Next, in block 1104, the stationary edges are selected from the edge image. Proceeding to block 1106, capture device movement occurs. During device movement, there are no stationary edges. Next, in block 1108, stationary edges in the current edge image (after capture device movement) are matched to the stationary edges in the last stationary edge image. In one embodiment, a Hough transform is used to determine the best azimuth that minimizes image correlation error. Proceeding to block 1110, from this matching, movement data for the capture device is determined. Next, in block 1112, the movement data is outputted.
It will be appreciated that edge detection in flowchart 1100 may be distinguished from using feature points as described in flowchart 800.
Turning to FIG. 12, an example of determining capture device movement using stationary edges is shown. The current camera image 1202 is shown. The current edge image 1204 has been derived from camera image 1202. The last stationary edge image 1206 is compared to the current edge image 1204 (as shown by alignment image 1210). Hough transform results, shown at 1208, indicate the least correlation error at azimuth 300 degrees. Thus, the capture device has been rotated to 300 degrees (i.e., the device has been turned 60 degrees to the left).
Turning to FIG. 13, an example of determining capture device movement using stationary edges is shown. The current camera image 1302 is shown. The current edge image 1304 has been derived from camera image 1302. The last stationary edge image 1306 is compared to the current edge image 1304 (as shown by alignment image 1310). Hough transform results, shown at 1308, indicate the least correlation error at azimuth 030 degrees. Thus, the capture device has been rotated to 030 degrees (i.e., the device has been turned 30 degrees to the right).
Turning to FIG. 14, a flowchart 1400 shows the logic and operations of capture device movement compensation using object modeling in accordance with an embodiment of the invention. In one embodiment, at least a portion of the logic of flowchart 1400 may be implemented by computer readable instructions executable by one or more computing devices. At least a portion of the logic of flowchart 1400 may be conducted during the post-processing of a recorded meeting.
In one embodiment, the logic of flowchart 1400 determines the size and orientation of the meeting room table that the capture device is positioned on. The capture device learns a table model parametrically and then fits the model to the table during the meeting or during post-processing, including table orientation and table position. Tests show robust results in normal lighting conditions and with 50% random occlusions of the table in the image (e.g., the open laptop of a meeting participant may partially block the capture device's view of the table).
Starting in block 1402, an object model is learned from an image of a stationary object in the meeting room captured by the capture device. Proceeding to block 1404, the object model is fit to the stationary object. Next, in block 1406, capture device movement occurs. Device movement may be detected by comparing the model parameters of the current and previous frames.
Continuing to block 1408, the current object model is matched again to the corresponding stationary object. The current object model position is matched to the last object model position. Next, in block 1410, movement data is determined from the change in object model positions. Then the movement data is outputted, as shown in block 1412.
Turning to FIG. 15, an example of object modeling using a conference room table is shown. It will be appreciated that embodiments of stationary object modeling are not limited to modeling tables. In FIG. 15, a real image from the capture device is shown at 1502. At 1504, an edge map has been extracted from the real image. The edge map includes noise (i.e., edges of other objects such as people, doors, etc.) in addition to the edges of the table boundaries of the table of interest. To filter the edge map, it is observed that most conference tables are bilaterally symmetric. This symmetry is used to filter out the noise.
The filtering operation uses a symmetry voting scheme to filter out the noise in the edge map. After applying the filtering operation to the edge map shown at 1504, a symmetry-enhanced edge map is produced, as shown at 1506.
A fitting algorithm is used to fit the symmetry-enhanced edge map to the table in the edge map shown at 1504. In one embodiment, a trigonometry fitting is used. Points on two of the four table edges are used. As shown in 1506, a first section of table is between cut and cut′′ and a second section of table is between cut and cut′′. A limitation of the trigonometry fitting is that it assumes a rectangular table. In another embodiment, a quadratic fitting is used. The quadratic fitting does not assume the shape of the table. In quadratic fitting, two quadratic curves are used to fit the table edge points.
The result of a fitting algorithm is shown at 1508. A table model 1510 (shown as a dotted-line curve) has been fit to the table in the edge map. After device movement occurs, table model 1510 may be re-aligned to the table in the current edge map. The difference between the last stationary table model position and the current table model position may be used to determine the movement of the capture device.
It is noted that under some conditions, such as low-lighting or insufficient visual texture (e.g., a mostly white room), vision-based motion detection methods may have limitations. Still, under such conditions, the vision-based methods may detect that the capture device has moved, but may not necessarily be able to determine the movement data. In such cases, the speaker indexing may be reset when motion has been detected and the cluster analysis will be restarted.
Hardware-Based Movement Detection
Turning to FIG. 16, an embodiment of a capture device 1600 is shown. As will be discussed below, capture device 1600 may include a magnetometer and/or an accelerometer for use in device movement compensation for speaker indexing. It will be appreciated that capture device 1600 is not limited to the design shown in FIG. 16.
Capture device 1600 includes a base 1602 coupled to a neck 1608 which in turn is coupled to a head 1610. Base 1602 includes a speaker 1604 and one or more microphones 1606. Capture device 1600 may be powered using power cord 1614. A cable 1612 (e.g., USB, IEEE 1394, etc.) may connect capture device 1600 to another computing device, such as meeting room server 302. Alternatively, capture device 1600 may connect to another computing device wirelessly. Head 1610 may include an omni-directional camera that captures 360 degrees of video. The omni-directional camera may have several individual cameras. The images from each camera may be stitched together to form a panoramic view.
Capture device 1600 may include one or more accelerometers and/or one or more magnetometers. In the embodiment of FIG. 16, head 1610 includes a magnetometer 1622 and base 1602 includes an accelerometer 1624. In one embodiment, magnetometer 1622 is a 2-axis magnetometer and accelerometer 1624 is a 3-axis accelerometer.
Turning to FIG. 17, a flowchart 1700 shows the logic and operations of capture device movement compensation in accordance with an embodiment of the invention. In one embodiment, the movement data is determined and output by the logic of flowchart 1700 during the live meeting. The logic of flowchart 1700 may be performed at device 1600, at a computing device coupled to device 1600, or any combination thereof. The movement data may be stored with the recorded meeting (such as in file 512) and then used for device motion compensation during post-processing of the recording.
Starting in decision block 1702, the logic waits for detection of movement of the capture device by the accelerometer. Once movement is detected, the logic proceeds to block 1704 where the magnetometer measures a start azimuth. In one embodiment, the measurement in block 1704 happens very quickly (e.g., <100 microseconds). In another embodiment, the measurement may be updated slowly before block 1702 and the last measurement made before block 1702 may be used as the measurement for block 1704. The last measurement made before block 1702 should be about the same (very close) to an actual measurement in block 1704. Continuing to decision block 1706, the logic uses the accelerometer to determine when the capture device motion has stopped.
Once the capture device motion has stopped, the logic proceeds to block 1708. In block 1708, the magnetometer measures a stop azimuth. Next, in block 1710, the translational difference is determined by the accelerometers and an azimuth change is determined by the accelerometers.
Proceeding to block 1712, the translation change of the capture device is outputted. Next, in decision block 1714, the logic determines if the azimuth change detected by the magnetometer is substantially equal to the azimuth change detected by the accelerometer. If the answer is no, then the logic proceeds to block 1716 where the accelerometer azimuth difference is outputted. If the answer to decision block 1714 is yes, then the magnetometer azimuth difference is outputted.
It will be appreciated that the magnetometer may provide a more reliable azimuth measurement than the accelerometer because the accelerometer may experience integration errors over time after several device movements. However, the magnetometer measurements are cross-checked with the accelerometer azimuth measurement (in decision block 1714) because the magnetometer is susceptible to error from artificial magnetic field changes, such as from a local Magnetic Resonance Imaging (MRI) machine.
Alternative embodiments of the invention may use only a magnetometer or only an accelerometer for detecting capture device movement. For example, a magnetometer may be used to measure device rotation while other means, such as vision-based models discussed above, may be used to determine translational movement. In an accelerometer only example, translation as well as azimuth changes may be detected and measured by one or more accelerometers.
CONCLUSION
Embodiments of the invention provide capture device movement compensation for speaker indexing. Vision-based techniques may use images captured by the capture device itself and hardware-based techniques may use magnetometers and/or accelerometers at the capture device. Embodiments herein provide reliable speaker indexing that in turn results in more robust speaker segmentation for viewing recorded meetings in a client UI.
It will be appreciated that vision-based techniques and/or hardware based techniques may be combined as desired for capture device movement compensation. Techniques may be combined to cross-check device movement data and consequently enhance the user experience. For example, movement data determined using stationary feature points may be compared to movement data determined using stationary edges in edge images. If the movement data determined by the two techniques differs by a threshold, then the techniques may be repeated or a different technique, such as object modeling, may be applied to ensure accurate speaker indexing.
Example Computing Environment
FIG. 18 and the following discussion are intended to provide a brief, general description of a suitable computing environment to implement embodiments of the invention. The operating environment of FIG. 18 is only one example of a suitable operating environment and is not intended to suggest any limitation as to the scope of use or functionality of the operating environment. Other well known computing devices, environments, and/or configurations that may be suitable for use with embodiments described herein include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile devices (such as mobile phones, Personal Digital Assistants (PDAs), media players, and the like), multiprocessor systems, consumer electronics, mini computers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
Although not required, embodiments of the invention are described in the general context of “computer readable instructions” being executed by one or more computing devices. Computer readable instructions may be distributed via computer readable media (discussed below). Computer readable instructions may be implemented as program modules, such as functions, objects, Application Programming Interfaces (APIs), data structures, and the like, that perform particular tasks or implement particular abstract data types. Typically, the functionality of the computer readable instructions may be combined or distributed as desired in various environments.
FIG. 18 shows an example of a computing device 1800 for implementing one or more embodiments of the invention. Embodiments of computing device 1800 may be used to implement meeting room server 302, archived meeting server 306, client machines, or capture device 104. In one configuration, computing device 1800 includes at least one processing unit 1802 and memory 1804. Depending on the exact configuration and type of computing device, memory 1804 may be volatile (such as RAM), non-volatile (such as ROM, flash memory, etc.) or some combination of the two. This configuration is illustrated in FIG. 18 by dashed line 1806.
In other embodiments, device 1800 may include additional features and/or functionality. For example, device 1800 may also include additional storage (e.g., removable and/or non-removable) including, but not limited to, magnetic storage, optical storage, and the like. Such additional storage is illustrated in FIG. 18 by storage 1808. In one embodiment, computer readable instructions to implement embodiments of the invention may be in storage 1808. Storage 1808 may also store other computer readable instructions to implement an operating system, an application program, and the like.
The term “computer readable media” as used herein includes computer storage media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions or other data. Memory 1804 and storage 1808 are examples of computer storage media. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, Digital Versatile Disks (DVDs) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by device 1800. Any such computer storage media may be part of device 1800.
Device 1800 may also include communication connection(s) 1812 that allow device 1800 to communicate with other devices. Communication connection(s) 1812 may include, but is not limited to, a modem, a Network Interface Card (NIC), an integrated network interface, a radio frequency transmitter/receiver, an infrared port, a USB connection, or other interfaces for connecting computing device 1800 to other computing devices. Communication connection(s) 1812 may include a wired connection or a wireless connection. Communication connection(s) 1812 may transmit and/or receive communication media.
The term “computer readable media” may include communication media. Communication media typically embodies computer readable instructions or other data in a “modulated data signal” such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, infrared, Near Field Communication (NFC), and other wireless media.
Device 1800 may include input device(s) 1814 such as keyboard, mouse, pen, voice input device, touch input device, infrared cameras, video input devices, and/or any other input device. Output device(s) 1816 such as one or more displays, speakers, printers, and/or any other output device may also be included in device 1800. Input device(s) 1814 and output device(s) 1816 may be connected to device 1800 via a wired connection, wireless connection, or any combination thereof. In one embodiment, an input device or an output device from another computing device may be used as input device(s) 1814 or output device(s) 1816 for computing device 1800.
Components of computing device 1800 may be connected by various interconnects, such as a bus. Such interconnects may include a Peripheral Component Interconnect (PCI), such as PCI Express, a Universal Serial Bus (USB), firewire (IEEE 1394), an optical bus structure, and the like. In another embodiment, components of computing device 1800 may be interconnected by a network. For example, memory 1804 may be comprised of multiple physical memory units located in different physical locations interconnected by a network.
In the description and claims, the term “coupled” and its derivatives may be used. “Coupled” may mean that two or more elements are in contact (physically, electrically, magnetically, optically, etc.). “Coupled” may also mean two or more elements are not in contact with each other, but still cooperate or interact with each other (for example, communicatively coupled).
Those skilled in the art will realize that storage devices utilized to store computer readable instructions may be distributed across a network. For example, a computing device 1830 accessible via network 1820 may store computer readable instructions to implement one or more embodiments of the invention. Computing device 1800 may access computing device 1830 and download a part or all of the computer readable instructions for execution. Alternatively, computing device 1800 may download pieces of the computer readable instructions, as needed, or some instructions may be executed at computing device 1800 and some at computing device 1830. Those skilled in the art will also realize that all or a portion of the computer readable instructions may be carried out by a dedicated circuit, such as a Digital Signal Processor (DSP), programmable logic array, and the like.
Various operations of embodiments of the present invention are described herein. In one embodiment, one or more of the operations described may constitute computer readable instructions stored on one or more computer readable media, which if executed by a computing device, will cause the computing device to perform the operations described. The order in which some or all of the operations are described should not be construed as to imply that these operations are necessarily order dependent. Alternative ordering will be appreciated by one skilled in the art having the benefit of this description. Further, it will be understood that not all operations are necessarily present in each embodiment of the invention.
The above description of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the embodiments to the precise forms disclosed. While specific embodiments and examples of the invention are described herein for illustrative purposes, various equivalent modifications are possible, as those skilled in the relevant art will recognize in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification. Rather, the following claims are to be construed in accordance with established doctrines of claim interpretation.

## Claims

1. A method, comprising:
determining a first position of a capture device;
determining a second position of the capture device after the capture device has been moved from the first position to the second position;
determining movement data associated with movement of the capture device from the first position to the second position; and
applying the movement data to speaker indexing.

2. The method of claim 1 wherein the first and second positions are determined by comparing at least a portion of a first image captured at the first position by the capture device to at least a portion of a second image captured at the second position by the capture device.

3. The method of claim 2 wherein the first and second images are compared using stationary points in the first and second images.

4. The method of claim 2 wherein the first and second images are compared using stationary edges in first and second edge images corresponding to the first and second images.

5. The method of claim 2 wherein the first and second images are compared using object modeling in the first and second images.

6. The method of claim 1 wherein the first and second positions are determined using at least one of a magnetometer or an accelerometer at the capture device.

7. The method of claim 1, further comprising wherein applying the movement data to speaker indexing comprises using of an audio/video recording captured by the capture device.

8. The method of claim 7 wherein applying the movement data includes correcting for at least one of azimuthal movement or translational movement of the capture device that occurred during the capture of the audio/video recording.

9. The method of claim 7 wherein applying the movement data includes restarting the speaker indexing at the time in the audio/video recording when the capture device movement is detected.

10. The method of claim 9 wherein applying the movement data includes merging a first speaker indexing determined before the capture device movement with a second speaker indexing determined after the capture device movement, wherein a speaker in the first speaker indexing is matched to the same speaker in the second speaker indexing.

11. The method of claim 7 wherein the speaker indexing is used to display speaker segmentation in a meeting timeline of a client user interface, wherein the meeting timeline includes a timeline for each speaker identified in the audio/video recording.

12. The method of claim 11 wherein play speed for each speaker in the timeline is individually selectable.

13. A method, comprising:
determining a first position of a capture device from a first image of an audio/video recording made with the capture device;
determining a second position of the capture device from a second image of the audio/video recording after the capture device has been moved from the first position to the second position;
determining movement data associated with movement of the capture device from the first position to the second position;
comparing the first and second images using a table model of a table in the first and second images; and
outputting the movement data.

14. The method of claim 13 wherein the first and second positions are determined by comparing a first stationary point in the first image captured at the first position to a second stationary point, corresponding the first stationary point, in the second image captured at the second position.

15. The method of claim 13 wherein the first and second images are compared using stationary edges in first and second edge images corresponding to the first and second images.

16. The method of claim 13 wherein the capture device is positioned on the table.

17. A computer-readable medium, excluding a signal, having computer-executable instructions for performing speaker indexing, comprising:
determining a first position of a capture device;
determining a second position of the capture device after the capture device has been moved from the first position to the second position;
determining movement data associated with movement of the capture device from the first position to the second position; and
applying the movement data to speaker indexing.

18. The computer-readable medium of claim 17, wherein applying the movement data includes correcting for at least one of azimuthal movement or translational movement of the capture device that occurred during the capture of the audio/video recording.

19. The computer-readable medium of claim 17, wherein applying the movement data includes restarting the speaker indexing at the time in the audio/video recording when the capture device movement is detected.

20. The computer-readable medium of claim 17, wherein applying the movement data includes merging a first speaker indexing determined before the capture device movement with a second speaker indexing determined after the capture device movement, wherein a speaker in the first speaker indexing is matched to the same speaker in the second speaker indexing.

21. The computer-readable medium of claim 17, wherein the speaker indexing is used to display speaker segmentation in a meeting timeline of a client user interface, wherein the meeting timeline includes a timeline for each speaker identified in the audio/video recording.