[vlc-devel] A/V capture

[Rémi Denis-Courmont]

Le mercredi 18 mai 2011 11:12:18 Jean-Paul Saman, vous avez écrit :
> On Tue, May 17, 2011 at 8:58 PM, Laurent Aimar <fenrir at elivagar.org> wrote:
> >  I think it could be made better by simply changing the way input slaves
> > are synchronized (when possible, otherwise the old way should be used).
> > The way es_out SET_PCR is handled might need some changes (like creating
> > a es_out per input slave), but I am not sure.
> 
> input-slave is very limited and starts showing issues when building
> encoders using capture cards. This use-case is usually combined with systems
> that are just powerful enough to capture audio and video with nothing to
> spare. Any inefficiency will thus show up and running the input slave on
> the video capture thread is one of them.

How do you verify those hasty claims? If said systems have nothing to spare, 
how adding one thread should make things worse before it makes them better, 
especially if those systems have a single CPU core. And if you need/want to, 
VLC already supports threaded access_demux (RTP and XCB screen capture do 
that).

I believe the main inefficiency in video capture comes from the two memory 
copies in VLC, much more so than the input slave. There is one copy in the 
V4L2 access, and another one in the rawvideo codec.
Only one memory copy is really needed (or even none in some cases).

And then, synching audio and video is a hard problem in theory. And in 
practice, there may be bugs in how VLC timestamps ALSA, V4L2, etc and/or 
annoying limitations in those capture interfaces. I don't see how adding a 
thread would magically solve those issues.

-- 
Rémi Denis-Courmont
http://www.remlab.info/
http://fi.linkedin.com/in/remidenis