Hello all,

We have a customer using Bluefish444 IngeSTore software and Avid Nexis shared storage. When writing to this storage using the AMT SDK in DNxHD MXF OPATOM format we are seeing the following results;

Target disk, CreateAmtFile() , CreateAmtTrack(ET_VIDEO) , CreateAmtTrack(ET_AUDIO) x 2

SCSI , 88ms , 46ms  ,111ms

3rd party network storage , 180ms ,  59ms , 114ms

NEXIS , 301ms , 1119ms , 4124ms

The bandwidth to this volume is fine, we can write uncompressed QuickTime without any issues.

Is this the expected result when writing to the AVID Shared storage or do we need to handle writing to this storage differently to direct attached or other network storage systems.

Tom Lithgow

Bluefish444 Product Manager

Hi Tom, some version numbers for AMT and NEXIS backend and server would be helpful but there was an issue in some older NEXIS client that resulted in long track creation times with AMT 2.x. This is dependent on the number of audio tracks but seems to be in line with the numbers you are showing above.

As a first step, you should retest with a version that has the fix; the first internal version that addressed this was 7.8.0.27923 - not sure about the release version. If your customer needs a reference for Avid CS, the internal issue number was SSENG-13789.

HTH

Andy

Hello Andy,

Thank you that is usefull information, we have passed this on and have been informed that they use Axid Nexis client Manager: 7.3.2.55.

They are looking into updating.

Thank you for the quick response to this enquiry.

Tom Lithgow

Hello Andy, 

We have an update from our customer site.

They updated the client to 7.10 and the results are much inproved, see below:

CreateAmtFile()       CreateAmtTrack(ET_VIDEO)        CreateAmtTrack(ET_AUDIO) x 2

298ms                       317ms                                               576ms                       

So thank you for this advice!

Unfortunatly when writting many files the latency increases, e.g. if we write with 8 channels of Audio  CreateAmtTrack(ET_AUDIO) x 8 = 2421ms 

This results in dropped frames for us as we have only been buffering xx time during a file capture.

If you have any further advice on this we are keen to hear, as it seems that the only work around for us is for a large ammount of buffering on the host client machine.

Again thank you for the upgrade advice, it is much improved.

Slightly off topic, does anyone know if it is possible with AMT to edit the start Timecode after the file and track has been written. (without creating a new file)

Thanks again,

Tom Lithgow
Bluefish444 Product Manager