On 4/7/2019 4:22 PM, Marton Balint wrote: > > > On Sun, 7 Apr 2019, James Almer wrote: > >> On 4/7/2019 3:47 PM, Marton Balint wrote: >>> framethread.c is put into libavutil, but is has to be included >>> directly to >>> avoid creating avpriv functions. >> >> If the reason behind this factorization is sharing the code between >> modules across several libraries and the function signatures are >> unlikely to change, then using avpriv_ functions is justified. >> The structs will be internal to libavutil, so the only thing tied to the >> ABI will be the avpriv symbols. >> >> Including the entire c file will result in unnecessary binary bloat once >> this code is used for example in libavfilter. > > Yeah, I agree. I just did not want to make it avpriv until we have at > least a second component using it, because I cannot forsee if the API > will be sufficent or not.
Fair enough, guess it should be ok like this until it's needed elsewhere, to avoid having to potentially live with useless symbols until a major bump if they ultimately need to be changed. Although i have to say it's kinda weird having a source file in the libavutil folder that's not compiled into said library. Wait to see if someone else comments. > > Regards, > Marton > _______________________________________________ > 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". _______________________________________________ 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".
