On Fri, Dec 9, 2022 at 1:45 PM Niklas Haas <ffm...@haasn.xyz> wrote: > Oh, you are right. So that presents an alternative to 4 - rather than an > encoder flag, we can tie the auto-conversion in fftools to be tied to > the strict_std_compliance check. > > I will try implementing this approach, it may be the best compromise in > that it presents a clear upgrade path that doesn't break the common > case. > > That said, there still is an encoder that has this problem: "amv". > Currently, this only advertises YUVJ, but after YUVJ removal, it would > be treated equivalently to mjpeg when `strict_std_compliance` is enabled. > > But given that this is a less common format, I think, such a regression > would not be as big a concern. (And we can still special-case it in > fftools, if we want to) >
As a user of the API, I do not think hacking fftools is the way to go. I vote option 3, filter negotiation also takes color_range (etc) info into account, and auto-inserts a scale where needed. But that is only half the solution, and actually not the important part. If i have a frame source and another sink that both have declared pixel formats, i can easily check whether conversion needs to happen at all, and if so, just set up an empty filter chain and have it auto-insert the required scale filter (super!). Now i would have to also be able to: 1. have settings in the filter context (i guess) for color_range, etc, and corresponding syntax for the args argument of avfilter_graph_create_filter() and/or corresponding options to set, so that filter input and output sides can be provided with correct info 2. query my sink for what it actually provides (a bunch more functions ala av_buffersink_get_format() are needed to get color_range, etc) I probably don't oversee the problem, so may be missing more that needs to be done, or be off the mark here. I also agree with Henrik that a way to query encoders for what they support besides formats is critical, and that this should ideally be context-senstive (so you can set certain options, and then query what remains of supported pix_fmts, color_range, etc). All the best, Dee _______________________________________________ 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".