Am 22.08.22 um 14:30 schrieb Nicolas George:
Thilo Borgman (12022-08-20):
My two cents about it that the a=b:c=d syntax from AVDict is at least
known and used in filters already.
The function style a(b,c,d) thing from SVG would be completely new.
Instead of the AVDict overhead, it adds a simplistic parser overhead.
Also, maybe I'm just unaware, these style of options appears not to be
often used in the command line world.
These are good points. On the other hand:
- The "a=b:c=d" syntax needs documentation and is misleading with regard
the order and interaction of suboptions.
Yes needs documentation. I don't see a misleading point in terms of the syntax,
just in the mathematical sense - which gets resolved by documenting it.
Syntax-wise, it aligns more to the dont-care order of options to filters (where
this syntax is taken from). The only two exceptions are -vf / -filter_complex
where the order is relevant. All other options to filters are not respecting
order, AFAICT and this would be a new exception to respect the order of a=b:c=d
options.
- The SVG syntax is more powerful, it allows to compose several
transforms.
Then we'd have to do two things, add a completely new syntax (which comes with
new overhead) and a new scheme of math and order-respecting composition of the
final matrix, which can then be many many simple transformations (which in our
use case will rarely be needed). Where instead we would reuse known syntax and
could get away with the relatively simple decomposition into three sequentially
applied filters.
However, I can see that our optimal solution should actually involve a new
filter that applies pixel disposition by a 3x3 matrix (which we don't have yet,
do we?) and an order respecting syntax (of either kind, though even more
overhead with SVG syntax) so that we can skip matrix decomposition and apply
just one (hopefully efficient) filter for any transformation that comes via
input or cmd line. That would be much more work to ask for IMHO and I'm not a
total fan for that just fixing #8329, #6370.
I don't want to override your opinion just because others argued to be happy
with a (technically better) version of the proposed. Give me more reason and/or
a matrix transform filter and my internal barrier (and real-world limitations)
to go that full length in one step might drop. Until then I'll work on v3 which
has to be done either way.
Thanks!
-Thilo
_______________________________________________
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".
