On Wed, 27 Sep 2017 16:31:37 +0100 Josh de Kock <j...@itanimul.li> wrote:
> On 27/09/2017 16:28, Carl Eugen Hoyos wrote: > > 2017-09-27 17:21 GMT+02:00 Josh de Kock <j...@itanimul.li>: > >> On 27/09/2017 16:17, Carl Eugen Hoyos wrote: > >>> 2017-09-27 17:15 GMT+02:00 wm4 <nfx...@googlemail.com>: > >>>> On Wed, 27 Sep 2017 17:08:06 +0200 > >>>> Carl Eugen Hoyos <ceffm...@gmail.com> wrote: > >>>> > >>>>> 2017-09-27 15:18 GMT+02:00 Josh de Kock <j...@itanimul.li>: > >>>>> > >>>>>> There is no point of having these output devices as all the > >>>>>> functionality is contained in the 'ffplay' tool. > >>>>> > >>>>> I use at least sdl and opengl regularly for tests that cannot > >>>>> be done with ffplay. > >>>> > >>>> How does it make sense to use those for testing > >>> > >>> FFplay only supports a limited set of pix_fmts, > >>> contrary to those devices. > >> > >> So if there is pix_fmt parity then I can remove OpenGL, and SDL2? > > > > No, but you can mark my argument as obsolete. > > I see no reason to bring parity to ffplay then. > > >> This should be simple enough. > > > > Sure? > > I was more under the assumption that this is simply impossible. > > (Until SDL3) > > Why would it be impossible? I don't see how the OpenGL, SDL2 device > could support more pixel formats than FFplay when they *all* use SDL2. The OpenGL one uses shaders, but for the others his argument is bogus, yes. _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel