Bug #1067

synchronization differences using "live" version and recorded version with bag-record

Added by J. Sanchez Riera over 11 years ago. Updated over 11 years ago.

Status:RejectedStart date:07/10/2012
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

In our speaker detector we detected some differences using "live" version with a video recorded and then replayed with bag-play.
Basically, when video is played with bag-play it seems audio is processed much before than the video. This doesn't happen with data coming directly from NAO.

It might be a problem with timestamps? Actually we should get the same results, right?

Here are 2 links as an example.

If more details are needed, ask and we will provide it.

Live Recording
https://transfert.inria.fr/fichiers/6c8ab14579163246531a0c1a8489e05a/live_1_direct.ogv

Using bag-play
https://transfert.inria.fr/fichiers/ef2d2fc218a000cb7ff705097c0dcd24/bag_1.ogv

History

#1 Updated by J. Wienke over 11 years ago

  • Description updated (diff)

We need more information on how the overall system is configured.

Can you please give us you bag-play command line and the command lines of the time-sync instances you are using.

#2 Updated by J. Sanchez Riera over 11 years ago

bag-play -S 522 ~/Data/tide/av_fusion/test1.tide 'spread://localhost:4803'

We use the script Y2PerceptionDemo4mic.sh in Year2Demo which uses

rsb_timesync --outscope "/vision/facetracks/sync" --primscope /vision/faces/left --supscope /vision/faces/right --strategy approxt --timestamp rsb::receive

and

rsb_timesync --outscope "/SynchAudio3D/" --primscope "/3DFacePoints/" --supscope "/nao/audition/itd/" --strategy timeframe --timeframe-timeframe 200000 --timeframe-buffer 0

Also upload the test1.tide into the webdav pub.

#3 Updated by J. Wienke over 11 years ago

  • Status changed from New to Rejected

Ok, then this is actually completely expected. The receive timestamps are always set in the receiving program, in this case the timesync, at the time an event is received from the network. You need to synchronize on the create timestamp. Anything else doesn't make sense as you are effectively not syncing then.

#4 Updated by J. Sanchez Riera over 11 years ago

aha, how you synchronize on the create timestamp? you mean we should remove rsb::receive on rsb_timesync?

#5 Updated by J. Wienke over 11 years ago

Yes, the default is actually create. So you can remove it or explicitly call rsb::create. Just have a look --help.

Also available in: Atom PDF