Hi Pedro, On Tue, Jul 31, 2018 at 1:22 PM, Pedro Arthur <bygran...@gmail.com> wrote:
> 2018-07-28 14:31 GMT-03:00 Pedro Arthur <bygran...@gmail.com>: > > 2018-07-27 14:24 GMT-03:00 Rostislav Pehlivanov <atomnu...@gmail.com>: > >> On 27 July 2018 at 18:12, Rostislav Pehlivanov <atomnu...@gmail.com> > wrote: > >> > >>> > >>> And the coding style is just the tip, there are dozens of things I > >>> disagree with, such as the custom float to 8 bit conversions, when > filters > >>> already exist which take in floats (zscale). > >>> > >> > >> I should probably expand on what I mean by the custom float conversion: > >> make the filter accept a float pixel format, such as > AV_PIX_FMT_GBRPF32. We > >> have one, we use it in vf_tonemap and vf_zscale. Users will need to > specify > >> a filter to convert to float first, which will match what they have to > do > >> for vf_zscale and vf_tonemap. If you need to process YUV then add a > float > >> YUV format, but please, don't do custom conversions in filters. > > It seems there is a patch adding YUV float formats in the ml, I asked > > the student to make a patch removing the conversion and supporting > > only float formats when the yuv float format get in the tree. > Just to update on the matter, there are currently two patches on ml, > one which fixes the code style and one which removes a huge amount of > stored data from the sr filter. > We are working on removing the format conversion from sr filter, > adding the needed floating formats to swscale. Thanks for taking the time/effort to address some of our concerns. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
