Wiretap

Reply
Valued Contributor
alatteri
Posts: 88
Registered: ‎06-26-2003
Message 1 of 10 (267 Views)

Big problem with wiretap and audio delays.

267 Views, 9 Replies
01-31-2007 09:33 PM
Hey,
So take a clip with audio and cut it somewere. Now look at the audio delay reported by WT. Even worse then commit that cut clip and look at the delay.
IBM 6221 Flint 2007 SP1.
A.
Valued Contributor
alatteri
Posts: 88
Registered: ‎06-26-2003
Message 2 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-01-2007 09:02 AM in reply to: alatteri
Make sure to save to resulting clip between these steps.
Valued Contributor
alatteri
Posts: 88
Registered: ‎06-26-2003
Message 3 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-14-2007 02:36 AM in reply to: alatteri
This has been confirmed with clips coming from a variety of sources.
Using the tools provided in the API package.
Examine the audio delay settings of a given clip which the Slip value is 0 from within Flame.

milky-way:~ alatteri$ /Users/alatteri/Documents/Code/shrink.quicktime/wiretap/api/tools/Mac/OSX/wiretap_get_clip_format -h 192.168.1.55 -n /stonefs/Tether/audio_references/H_-1463798015_S_1171303214_U_26898/audiostream_H_279747890_S_1170425448_U_86522
Format dlaudio_float_le
Width 48048
Height 1
BitsPerPixel 32
Channels 1
BufferSize 262144
PixelRatio 1
FrameRate 48000
ScanFormat field1_odd
MetaDataTag IFFFS_XML
MetaDataStream 338363963


You can see here that it is reporting a audio offset of about 2 hours.
Now take that clip and gesturally drop it over a BLACK frame while in V12 mode. Analyze clip.

milky-way:~ alatteri$ /Users/alatteri/Documents/Code/shrink.quicktime/wiretap/api/tools/Mac/OSX/wiretap_get_clip_format -h 192.168.1.55 -n /stonefs/Tether/audio_references/H_-1463798015_S_1171430393_U_13233/audiostream_H_-1463798015_S_1171430391_U_429083
Format dlaudio_float_le
Width 48048
Height 1
BitsPerPixel 32
Channels 1
BufferSize 262144
PixelRatio 1
FrameRate 48000
ScanFormat field1_odd
MetaDataTag IFFFS_XML
MetaDataStream 0

Now it is reporting the proper audio offset of 0.

With this bug, it means my clients are unable to use shrink as a "1 step" stone to quicktime tool. They must now resort to an un-natural and all together disturbing work around. This severely limits the marketability of my product, and un-fortunately will cost me users.
Distinguished Contributor
dlabute
Posts: 103
Registered: ‎05-11-2004
Message 4 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-14-2007 06:12 PM in reply to: alatteri
We think this may be related to an existing bug. We're looking into it.

Dan
Valued Contributor
alatteri
Posts: 88
Registered: ‎06-26-2003
Message 5 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-20-2007 08:51 AM in reply to: alatteri
any update to this?
Contributor
grattor
Posts: 16
Registered: ‎12-05-2006
Message 6 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-20-2007 11:30 AM in reply to: alatteri
Hi Alan,

Sorry for the delays in getting to this, but I have answers on the AudioSampleOffset data you're getting.

AudioSampleOffset is a values expressed in number of samples, and the value is relative to timecode 00:00:00:00.

In the case of the clip you provided me with, which was a captured source, you have a video track starting at 01:57;29;08. The AudioSampleOffset therefore shows the 'start TC' of the audio stream expressed in audio samples: 338363963. The sample rate is 48kHz, so:

338363963 / 48000 = 7049.25 seconds
7049.25 / 3600 = 1.958215 hours
1.958215 = 1 hour, 57 minutes, 49 seconds, 15 frames.

Not exactly the same as your source TC because you have to adjust further for drop-frame timecode.

When you gesturally edited the capture clip on top of a black frame, you edited it into a timeline that had start TC 00:00:00:00 -- that's why the offset value worked out for you.

All that to say (I'm not trying to be smug here) that the AudioSampleOffset is returning correct values -- you just need to know how to interpret them.

Can you work with this? You see, we have one developer that I know of that has a Wiretap client that reads clips and pulls out the audio streams for audio finishing. They ignore the video TC data and use these sample values to reconstruct an audio timeline. So I can't really pull the rug out from under them.

Let me know what you think. I'm going to talk to some developers here to see if we can come up with something easier for you to work with.
Valued Contributor
alatteri
Posts: 88
Registered: ‎06-26-2003
Message 7 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-21-2007 07:33 AM in reply to: alatteri
I will ask told to my developer, but since i come from a Flame background where the slip value is relative to first frame of video, that is how i believe the values reported from wiretap should work also. I really dont see any sense in the way you describe it working now. Can you just have wiretap report slip values in both ways?
Contributor
grattor
Posts: 16
Registered: ‎12-05-2006
Message 8 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-21-2007 08:28 AM in reply to: alatteri
Well, it is true that you are suffering because of your Flame background. Unfortunately, audio has more strenuous editorial requirements and after many discussions with people in house and a WT developers working with audio interchange, the AudioSampleOffset is the way to go, for the following reasons.

1. The AudioSampleOffset can be though of as the start Source TC for the audio channel. Much like the start TC returned for the video track, it is an absolute value that can be used to recreate editorial context.

2. The reason why the value is returned in # of samples instead of start TC is that Smoke supports sub-frame audio editing. Were we to return TC, we'd have to arbitrarily clamp to a frame, forwards or backwards.

3. We could conveivably provide a relative offset value, positive or negative, but that would involve getting the start TC for the video track and then going through the same math to figure out where to lay down the audio.

Ultimately, an absolute audio sample offset relative to midnight provides all the information you need -- though the onus is on the developer to translate this into timecode and/or sub-frame positioning.

Having made this argument, I'm open to objections, especially from anyone else in the group who has an opinion.

Cheers,

rcg out
Contributor
grattor
Posts: 16
Registered: ‎12-05-2006
Message 9 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-21-2007 08:30 AM in reply to: alatteri
Posted twice by accident... Message was edited by: grattor
Valued Contributor
alatteri
Posts: 88
Registered: ‎06-26-2003
Message 10 of 10 (267 Views)

Re: Big problem with wiretap and audio delays.

02-21-2007 09:13 AM in reply to: alatteri
it would be so much easier if autodesk did this so every developer does not have to do it. Its tough enough getting stuff working as it is. Why duplicate work. Plus i still dont enderstand this philosophy behind the audio values, but oh well.

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
Are you familiar with the Autodesk Expert Elites? The Expert Elite program is made up of customers that help other customers by sharing knowledge and exemplifying an engaging style of collaboration. To learn more, please visit our Expert Elite website.

Need installation help?

Start with some of our most frequented solutions to get help installing your software.

Ask the Community