On 31/01/17 21:00, Aman Gupta wrote: > On Tue, Jan 31, 2017 at 12:26 PM, Mark Thompson <s...@jkqxz.net> wrote: > >> On 31/01/17 19:14, Aman Gupta wrote: >>> From: Aman Gupta <a...@tmm1.net> >>> >>> Copied directly from vf_scale.c. >>> >>> Implements the same expression logic, however not all the variables were >> copied over. >>> This patch was sufficient for my particular use-case >> `scale_vaapi=-2:min(ih\,720)`, >>> but perhaps it makes sense to add support for the remaining variables >>> and pull out shared code into a new vf_scale_common.c? >> >> I would prefer the code fragment not to be copied again, yes. >> >> (Implementing this and removing the duplication between scale, scale_npp, >> scale_qsv and scale_vaapi has been on my to-maybe-do-at-some-point list for >> quite a while, but I've never actually had a use-case for it to push me >> into actually doing it :) >> > > Ok, I'll see if I can refactor things to avoid duplication.
Great, thank you :) > You mentioned scale_qsv, and I see the git commit in the history that added > it. But vf_scale_qsv.c is no where to be found on master. Do you know what > happened to it? I'd like to implement the same logic there too if I'm > refactoring things.. Right, yes, it's not merged yet - it's present in the libav tree and branch here but skipped from ffmpeg master. Currently that merge is loosely blocked behind the ffmpeg.c filter setup being unsuitable for hardware transcode (the same issue that forces the 'format=vaapi|nv12,hwupload' hack for VAAPI transcode) - the patches were skipped at the time due to merging issues and it has not been revisited fully yet. Now, the filter does not actually depend on that because it can work standalone in lavfi, so I would be happy to just merge it without it being usable in ffmpeg.c so that this could continue. Alternatively, since all of the hardware filters were merged from libav, you could work there instead. (Or feel free to ignore that and just deal with the code you care about directly. If you only do some of them then hopefully I or someone else would be able to sort out the others at some point.) - Mark _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
