[vlc-devel] [vlc-commits] aout: do not use input resource for visualization

[Thomas Guillem]

OK, finally, it's way more simpler and less hackish with the current codebase.
 
I made my visualization filters working back with the new clock.

See the last 4 commits of this WIP branch: https://code.videolan.org/jbk/vlc/commits/clock-core/18

Do you agree with such modification if aout filters ?


On Tue, Jan 22, 2019, at 15:04, Thomas Guillem wrote:
> 
> 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
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> https://mailman.videolan.org/listinfo/vlc-devel