It is a bit safer.

Close #3439

The XCB/XVideo (for a long time) and the XCB/X11 (since the commit
before the previous one) video output plugins will fail safe in case
the embedding window has an alpha channel. In VLC 1.0, the Xlib plugins
needed this hack as the Xlib error handler would terminate VLC.

If compositing is in use, VLC will now use GLX. This will require
software chroma conversion from YUV to RGB. Also, unless the GLX output
is explicitly selected, VLC will flash twice before it starts rendering.
First, it tries (and fail) to use XVideo, then plain X11. To fix this
cosmetic problem, we would need to keep the window across plugins.

I assume this change is needed to fix #3581, but I have not tested, so
it may or may not be sufficient.

Neither of them support YUV. But GLX is much more likely to work than
FB, and also fails in a safer way.

VLC does not currently handle color masks for ARGB chromas, so this can
not work yet. Instead, fail safe to the GLX output.

It fixes #3522.

Close #3520

Close #3513

Signed-off-by: Christophe Mutricy <xtophe@videolan.org>

Sends NULL-pict to encode when it's closing time, then encoder knows to
flush buffers and check that it has outputted all the frames.

Contains changes to x264/avcodec-module to implement that on encoder-side.
Add quick check on omxil/dirac/theora for that, so they don't crash.
And add likely-macro to x264/avcodec in check of NULL

If someone more familiar with dirac/theora/omxil encoder-modules could
check if they have buffers that need to be outputted, would be nice.

Fixes some tickets, but I failed to find any of those in trac.

Multiple cores are pretty common nowdays, so shouldn't be big issue. Maybe
better would be implement cpu-core counter, like in x264, but at the moment
only avcodec-module doesn't seem to handle i_threads=0 as automatic.