[vlc-devel] [vlc-commits] aout: do not use input resource for visualization
Thomas Guillem
thomas at gllm.fr
Tue Jan 22 15:04:23 CET 2019
On Mon, Jan 21, 2019, at 18:53, Rémi Denis-Courmont wrote:
> Le maanantaina 21. tammikuuta 2019, 13.50.58 EET Thomas Guillem a écrit :
> > On Mon, Jan 21, 2019, at 12:11, Rémi Denis-Courmont wrote:
> > > Hi,
> > >
> > > I don't see why filters should need to pass by decoders, or access the
> > > clock (which might not even exist - unpaced sout), as they are much
> > > better off with original timestamps.
> > >
> > >
> > > But more prosaically, I don't see the link with this patch, or even the
> > > whole patch series, which affects only visualisations, not audio filters.
> > OK, audio filters will generally only use original timestamps.
> > Visualization filters are audio filters, right ?
>
> That's oversimplifying. Filters do not have a request_vout while
> visualizations are not allowed to change the format or payload. It's just
> historical convenience to treat them in the same filter chain.
>
> > They will need to access
> > the main clock in order to synchronize with it. If the user change the
> > audio delay, the visualization filter need to know it.
> >
> > If I remember correctly, we discussed about it during last VDD. You first
> > disagreed with me, then when agreed that timestamps should not be touched
> > until output. The problematic point, that you mentioned, was how to
> > synchronize visualization filters.
>
> > This is what my patch was trying to solve.
>
> I don't see how the request_vout would have helped here given that most
> visualizations already did not use it, but use the vlc_gl_* API instead. It
It helped a lot since the request_vout went through the decoder, with a way to get the clock.
OK, this was a little hackish.
> does not make practical sense to standardize on the non-GL visualizations at
> this point. I might have liked it, but it is ostensibly never going to become
> the norm back again.
>
> And having said that, I do not have any good idea how to solve the problem of
> synchronizing OpenGL with audio. I am not familiar with OpenGL, and it was not
> my idea to use it for visualizations, so I feel neither competent nor
> responsible here.
Synchronize any vout or an OpenGL vout is the same for me. I just need a way to get a slave clock from the main one, that is held by the input, or I can get a slave from any other slave/master held by any decoder.
>
> --
> Реми Дёни-Курмон
> http://www.remlab.net/
>
>
>
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel
More information about the vlc-devel
mailing list