Just to rephrase the difference between choices #3 and #4: #3 means to make an entirely new data representation (say, some kind of struct with various fields) and have to somehow make TypeDesc, ParamValueList, and potentially lots of apps, deal with it.
#4 means to encode the timecode as an existing data type (a string, or a uint[2]) -- for which ParamValueList and apps that don't care about timecodes can continue to operate as they always have -- but have the 'vecsemantics' field (or use the 'reserved' field) in TypeDesc encode that it's supposed to be interpreted as a timecode. Minimally intrusive. But before enshrining "these bytes are an SMPTE timecode" in the TypeDesc, I'd want us to be really, really sure we agreed on what the encoding is and that we won't discover later that we need to change it. On Oct 10, 2013, at 10:18 AM, Larry Gritz wrote: > 3. Make an entirely new type, > 4. We could transform the 'reserved' field in TypeDesc to some kind of > "special meaning" code -- or just make another tag for the existing > 'vecsemantics' byte -- and let "this is an SMPTE timecode" be one of those > values. -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
