Gyan Doshi (12022-08-17): > It's not based on ffmpeg's 'internal representation'. All transform > attributes are stored as a composite in one mathematical object. > Evaluating the matrix values will need to look at all sources of > contribution. So gathering and presenting all these attributes in a single > option (+ docs) makes it clearer to the user at the cost of an initial > learning curve.
I concur a single option might be more convenient. Especially since our options system does not take into account the order of options: the interactions between multiple options would be rather hard to explain. OTOH, I do not like a dictionary-based approach, for the same reason: you have to explain the order of precedence of options, and how contradicting ones interact. Might I suggest to adopt the syntax of the transform attribute of SVG? Or a subset of it with a stricter syntax. https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/transform It requires writing a specific parser, but one that can be done with sscanf(): if (sscanf(cur, "translate(%d %d)%n", &dx, &dy, &off) >= 2 && off) { translate_current_matrix(&mat, dx, dy); cur += off; } Regards, -- Nicolas George -- “I dont see why” isnt an argument. Proposing better is.
signature.asc
Description: PGP signature
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
