Fix double-timescale in usdAbc plugin

[spiffmon]

Description of Issue

See description of problem in the alembic discussion group .

Currently we are both rescaling the individual timeSamples, and setting layer timeCodesPerSecond in a duplicated attempt to convert from Alembic seconds to a (presumed) target of 24 timeCodesPerSecond.

I propose we address this by only scaling the timeSamples, because this will produce a file that is directly useable via reference or payload, whereas timeCodesPerSecond in a referenced file is ignored, so consumers would need to manually apply the same scale as a layer offset on a reference (and payloads do not currently support layer offsets).

Also propose adding an SdfFileFormatArg to usdAbc so that one can specify the desired timeCodesPerSecond to use in the sample scaling.

Steps to Reproduce

System Information (OS, Hardware)

Package Versions

Build Flags

[jtran56]

Filed as internal issue #USD-4839.

[AlexSchwank]

Hi @spiffmon,

Any news on this one?

Thanks,
Alex

[spiffmon]

Hi @AlexSchwank . Sorry, this fell off my radar. If we're OK not adding any configurability for the sampling frequency to use for conversion (hardcoded to 24 timeCodesPerSecond), then I could probably squeeze this in, soon.

[AlexSchwank]

Thanks @spiffmon . I think a hardcoded 24 timeCodesPerSecond is a good first step. If we realize that a configurable value is needed we can improve it later on.