ср, 23 окт. 2024 г., 18:23 Phyllis Smith <[email protected]>:
> may be we better to skip 7.1 completely? > > This is disturbing. Usually if something is not working in one version, it > is still carried to the next. > I crossposted my frustration with current situation (when ffmpeg team one-sidely breaks not just us but everyone downstream) earlier this day. Of course team of professional developers will change their part (breaking things) much faster and effortlessly than I ever can hope to repair them. Because ffmpeg apparently set to 2-3 release per year, with unknown amount of breakage each time ...I am not really eager to fix something twice. yuv range fix still not agreed upon, as far as I can, may be it will end up as rework and not just fix. I amnot sure if 7.1 makes much sense for us in itself? Of course breakage that come in 7.2/8.0 might be so big that I'll prefer to fix 7.1 instead. My main worry that even outside ff-scale filter and profile vs vprofile change something broke with some vaapi/qsv profiles, and it might be harder to track down. Right now 7.1 *builds* fine if you add renamed patch10 at least, but on runtime ..... we have all those errors Terje reported. > ... > Snip, Snip, Snip! > > Doesn't this correspond to what we previously also discussed for ffmpeg >>> 7.0.2? >>> >> >> ffmpeg as cli does its own option processing, as far as I understand. >> >> Using av_dict_* functions in c++ code was working with libav*/ffmpeg libs >> up to 7.0 >> but evidently not after.. >> >> I'll look into what ffmpeg cli does now, but if more changes in pipeline >> may be we better to skip 7.1 completely? >> >>
-- Cin mailing list [email protected] https://lists.cinelerra-gg.org/mailman/listinfo/cin
