So I'm still looking into using bilinear instead of nearest. Most of the online discussions are in the context of computer graphics and using things like openGL shaders.
One solution I found and may try to implement is to add padding pixels around each face tile in the input frame. This should help in handling sampling near cube edges and corners. However, I'm not sure about the complexity of this or its effect on the performance. WDYT? Meanwhile this is a hacky/lazy way to use bilinear, but I can barely notice any improvements over using nearest by my bare eyes, are there any systematic way to evaluate the quality? https://github.com/HazemSamir/FFmpeg/commit/fcd82b9782b5f32072d9b0516b275fe3d4f4a163 On 3/12/18, Paul B Mahol <one...@gmail.com> wrote: > On 3/12/18, Hazem Ashmawy <hazem.s.ashm...@gmail.com> wrote: >> On 3/12/18, Paul B Mahol <one...@gmail.com> wrote: >>> On 3/12/18, Hazem Ashmawy <hazem.s.ashm...@gmail.com> wrote: >>>> Sorry about that! Here is github branch >>>> >>>> https://github.com/FFmpeg/FFmpeg/compare/master...HazemSamir:panorama_youtube >>> >>> Good, now can you look at how to use bilinear instead of nearest >>> interpolation >>> for cubemap to equirectangular conversion. >>> >>> Nearest is extremly ugly. >>> >> Sure, will look into that. Just to take that into my consideration, >> why didn't you use it at the first place? Were there any obstacles? > > It was non-trivial to do. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
