Wiretap (Read Only)
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Setting TC of new clip

7 REPLIES 7
Reply
Message 1 of 8
derrick
676 Views, 7 Replies

Setting TC of new clip

I'd like to set the starting timecode of a newly created clip. I tried setMetaData on the WireTapFormat I'm using to create the new clip. I created a little XML blob with the SrcTimecode set to something.

Although my time code appears in the Flame UI, when I try to access the clip again via WireTap I always get 00:00:00:00 for the SrcTimecode field of the clip's format's metadata. DropMode seems to work fine... I can set it to either DF or NDF and that comes out correctly both in the UI and on a subsequent WireTap access.

Is this a bug, or am I going about this the wrong way?
7 REPLIES 7
Message 2 of 8
Anonymous
in reply to: derrick

Sounds like a bug to me. Does the timecode show up if you restart the WT server?
Message 3 of 8
derrick
in reply to: derrick

No, it doesn't. It also seems to depend on the parameters of the clip, although I haven't quite figured out how. But I have some sets of parameters where the TC consistently shows up and some where it does not. I've gotten a little busy, but I'll try to make a small sample program sometime in the next few days.
Message 4 of 8
derrick
in reply to: derrick

Okay, I think I've tracked this down.

If I add an audio node as a child of the parent, then the bug gets triggered. I'm enclosing a modification to the createClip sample code that demonstrates the bug.

1. Set the WIRETAP_HOST and WIRETAP_NODE_ID variables.
2. Run the program with no arguments.
3. Use wiretap_get_clip_format on the new node; note the time code is properly set (the program defaults to 00:00:02:15)
4. Run the program with the -audio argument.
5. Use wiretap_get_clip_format on the new node; note the time code is returned as 00:00:00:00. However, if you look at the clip in the flame, the TC appears to be correct.
Message 5 of 8
nelsonr
in reply to: derrick

Hi there,

I had a look at your code. I think what's going on here is that once you add the audio the timecode resets to zero since you didn't specify an audio offset. Thus, the clip starts at zero since the audio starts at zero.

What you're missing is the metadata for the audio. You need to tell the audio to start at 2:15 as well. I was able to modify your code to get this to work.

You need to add the following line:
string audioMetaData = "6480000";

The audio sample offset is computed by the following:
135 seconds (ie 2:15) * 48000 Hz = 6480000

Then when you create the audio clip format, you need to add the metadata as in the line below:

WireTapAudioFormat audio_format( numSamples, 16, 1, 48000, WireTapClipFormat::FORMAT_DL_AUDIO_INT16_LE(), audioMetaData.c_str() );

Now when you do the wiretap_get_clip_format it should show the timecode as 2:15.

Hope this helps. Please let me know if you have problems.

Cheers.
Message 6 of 8
nelsonr
in reply to: derrick

Looks like the thread didn't like hardcoded XML in my message, so instead I'll just attach the code I modified.
Message 7 of 8
derrick
in reply to: derrick

Ah, okay... first, one small bug in your code... in the constructor for the WireTapAudioFormat, there needs to be one extra argument—right before the metadata string—of "IFFFS_XML".

This also turns out to be the reason my own code was failing... I had actually tried setting the audio offset, and nothing appeared to happen (see my other post on this topic). But I was doing it with
audio_format.setMetaData( );
It turns out that if I also do
audio_format.setMetaDataTag( "IFFFS_XML" );
then all is well.

So, even though this seems to work for the video clip, I take it that I should use format.setMetaDataTag("IFFFS_XML") on the video format as well, just to be safe?

Thanks for the help!
Message 8 of 8
nelsonr
in reply to: derrick

Oops my misktake! I guess I forgot to save properly. I made a copy of your code as to not modify the original, then copied the relevant changes back. I guess I copied it back a little too hastily as I ran into these same errors previously.

You are correct in what you say above. Still, I think you should be able to use setMetaData on the audio format as well. This sounds like a bug to me. I'll investigate a little further and log a bug if necessary.

Cheers, and thanks for the quick response.

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report