What does null available_range mean?

[jminor]

In the OTIO documentation, here, it says that a Clip or MediaReference available_range may be null when the available range of media is not known. However, it doesn't explain how that actually works in practice. Specifically how does such a clip align if it has (or doesn't have) embedded timecode in the media file? Related to this, what happens when embedded timecode differs from the available_range value in a MediaReference.

We have a real world case of this in the DPEL ALab Trailer OTIO asset.

Here are specifics from @darbyjohnston (thanks!)

The ALab .otio file has audio references that do not specify an "available_range":

"media_references": {
    "DEFAULT_MEDIA": {
        "OTIO_SCHEMA": "ExternalReference.1",
        "metadata": {},
        "name": "",
        "available_range": null,
        "available_image_bounds": null,
        "target_url": "ALab_WAVs/mk020_sfx.wav"
    }
}

and clips with source_range starting at 0:

{
    "OTIO_SCHEMA": "Clip.2",
    ...
    "name": "mk020_sfx",
    "source_range": {
        "OTIO_SCHEMA": "TimeRange.1",
        "duration": {
            "OTIO_SCHEMA": "RationalTime.1",
            "rate": 24.0,
            "value": 2483.0
        },
        "start_time": {
            "OTIO_SCHEMA": "RationalTime.1",
            "rate": 24.0,
            "value": 0.0
        }
    },
    ...
}

However the referenced .wav files have start times specified in samples, for example here is the output from ffprobe:

Input #0, wav, from 'ALab_WAVs/mk020_sfx.wav':
  Metadata:
    comment         : vFRAMERATE=24.000
                    : vSPEED=24.000
                    : vNOTE=mk020_sfx.wav
    encoded_by      : Media Composer 21.12.1.55644
    originator_reference: 000000000000002a66f0b88799059884
    date            : 2022-10-31
    creation_time   : 23:03:19
    time_reference  : 172800000

172800000 / 48000 = 3600 seconds for a start time of 01:00:00:00.

So the specific issue here is that we need to clearly document how this case is handled, and possibly update the ALab example asset to conform to that.

[douglascomet]

This topic would also be applicable to still images used within a timeline, right? The only issue I've seen with a null available_range was with the SVG adapter which requires an available_range so a diagram can be generated. I've gotten around this by copying the source_range to the available_range via a hook.

[reinecke]

Question from TSC meeting: Should we engage with the DPEL WG to talk about how we signal version updates on sample assets once we have a correction for this?

[darbyjohnston]

Following up from today's meeting I downloaded the latest versions of the assets from the DPEL website and compared the .otio files in the .zip file ("ALab_mk020_final_edit.h264.otio") and .otioz file. The only differences were the paths to the media files which is normal (e.g., "ALab_h264_MOVs/mk020_0010.mov" vs. "media/mk020_0010.mov").

On a side note I think we should add the version number to the .zip and .otioz file names so we don't confuse multiple versions. Maybe the current ones are implicitly v.1.0.0 but the next release could be named something like "alab_mk020_final_edit.h264.v.2.0.0.otioz".

[jminor]

Great. Can you check to see what ffprobe says about the start time metadata in the WAV files?

@reinecke what was the other tool you mentioned that shows start time metadata?

[apetrynet]

I believe it was mediainfo. I think it should be available in most linux package repos.

[darbyjohnston]

I checked the WAV files with ffprobe and they all match, with "time_reference" = 172800000. So I guess the new version of Resolve is ignoring embedded times if the available_range is null.

[jminor]

@markreidvfx let us know what you find in the Avid project. I'm curious to know if the 1 hour offset is in there.

I see lots of Origin=0 and StartTime=0 in the AAF via aafdump.py.

         <aaf2.mobs.MasterMob "mk020_sfx" urn:smpte:umid:060a2b34.01010101.01010f00.13000000.060e2b34.7f7f2a80.63586fdf.b362ce8b at 0x105514630>
           AppCode <aafInt32 TypeDefInt> 10
           Slots <kAAFTypeID_MobSlotStrongReferenceVector TypeDefVarArray>
             <aaf2.mobslots.TimelineMobSlot 1 at 0x1054dcae0>
               Origin <aafPositionType TypeDefRename> 0
               EditRate <Rational TypeDefRecord> 24
               Segment <kAAFTypeID_SegmentStrongReference TypeDefStrongRef>
                 StartTime <aafPositionType TypeDefRename> 0
                 SourceMobSlotID <aafUInt32 TypeDefInt> 1
                 SourceID <MobIDType TypeDefRecord> urn:smpte:umid:060a2b34.01010105.01010f10.13000000.01c3370d.98459605.6b97f493.9ff4a1bd
                 Length <aafLengthType TypeDefRename> 2483
                 DataDefinition <DataDefinitionWeakReference TypeDefWeakRef> <aaf2.dictionary.DataDef Sound 01030202-0200-0000-060e-2b3404010101 at 0x1053d5310>
               Segment <kAAFTypeID_SegmentStrongReference TypeDefStrongRef> <aaf2.components.SourceClip SourceClip at 0x105090e00>
               PhysicalTrackNumber <aafUInt32 TypeDefInt> 1
               SlotID <aafUInt32 TypeDefInt> 1
             <aaf2.mobslots.TimelineMobSlot 2 at 0x1053d6360>
               Origin <aafPositionType TypeDefRename> 0
               EditRate <Rational TypeDefRecord> 24
               Segment <kAAFTypeID_SegmentStrongReference TypeDefStrongRef>
                 StartTime <aafPositionType TypeDefRename> 0
                 SourceMobSlotID <aafUInt32 TypeDefInt> 1
                 SourceID <MobIDType TypeDefRecord> urn:smpte:umid:060a2b34.01010105.01010f10.13000000.01c33718.98459605.43b8f493.9ff4a1bd
                 Length <aafLengthType TypeDefRename> 2483
                 DataDefinition <DataDefinitionWeakReference TypeDefWeakRef> <aaf2.dictionary.DataDef Sound 01030202-0200-0000-060e-2b3404010101 at 0x1053d5310>
               Segment <kAAFTypeID_SegmentStrongReference TypeDefStrongRef> <aaf2.components.SourceClip SourceClip at 0x1054f5c20>
               PhysicalTrackNumber <aafUInt32 TypeDefInt> 2
               SlotID <aafUInt32 TypeDefInt> 2
           LastModified <TimeStamp TypeDefRecord> 2022-10-25 23:23:11
           CreationTime <TimeStamp TypeDefRecord> 2022-10-25 23:23:11
           Name <aafString TypeDefString> mk020_sfx
           MobID <MobIDType TypeDefRecord> urn:smpte:umid:060a2b34.01010101.01010f00.13000000.060e2b34.7f7f2a80.63586fdf.b362ce8b

[markreidvfx]

The AAF has a start timecode 01:00:00:00 on the audio clips

The avid project has a start timecode 01:00:00:00 too. I think this is a error with the otio-aaf-adapter not being able to determine what the start timecode is.

Oddly the avid MXF audio files are showing a start timecode of 00:58:58:14 with ffprobe and mediainfo, not sure why yet. I see it with my mxfdump.py tool too. A Start 84926 frames.

If I load the MXF files with the media tool in avid in fresh 24 project I get the same start timecode of 00:58:58:14 for the audio files too.

Maybe the start timecode was manually edited in the avid bin, that might explain this. I don't think this has anything to do with our issue here. If I recall correctly, @jminor you said you exported the .wav and .mov files using Media Composer, so they should have the corrected timecode values in them as evident from the wav files.

[jminor]

While discussing this elsewhere, we made this diagram to help explain how an application should handle source_range, available_range, and embedded timecode in media.

[ssteinbach]

@jminor "invalid clip" really means "operations that require time are invalid" - you can still fetch metadata, references, serialize/deserialize etc. from this clip even if you cannot compute the temporal information.