Signed-off-by: Rafaël Carré <funman@videolan.org>

avcodec_flush_buffers() may get or release frame buffers.
See also EndVideoDec().

With the previous commit, the vout wrapper's display pool is no longer
used ever if direct rendering is not in use. Removing it saves one
picture buffer.
Signed-off-by: Rafaël Carré <funman@videolan.org>

When the decoder output and the display video formats are different,
the picture copy comes for "free" during the conversion from the
earlier format to the latter one. So do not bother with copying the
picture before the conversion.

The straight copy is still required however in the case that the video
formats are identical but the display pool is inadequate (too few
pictures, slow memory bus...).
Signed-off-by: Rafaël Carré <funman@videolan.org>

todisplay cannot be NULL there since its two possible values are
checked already.
Signed-off-by: Rafaël Carré <funman@videolan.org>

This reverts commit d8100367.

It could be a problem if one had no contribs, but /lib/liblua.a was
present

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

_set_invalid_parameter_handler is now usable in recent versions of mingw-w64

Only use the first 34 or 42 bytes (streaminfo block)

Sample:
0109c7dd02be4e673824fe156bc4cb66  [UTW-THORA] Evangelion 3.33 You Can (Not) Redo [BD][1080p,x264,flac][F2060CF5] sample.mka

Signed-off-by: Rafaël Carré <funman@videolan.org>

This uses existing strings only

This reverts commit 75890fb5.

This caused infinite loops in aviobuf when muxing to mkv.
write_flag seems to mean "mux" versus "demux".
The real meaning might be lost on us for lack of a libavformat documentation translator.

Include unistd.h to fix the following error.

----
  CC       liblua_plugin_la-intf.lo
  intf.c: In function 'Start_LuaIntf':
  intf.c:372: error: implicit declaration of function 'close'
----
Signed-off-by: Rafaël Carré <funman@videolan.org>

According to xcb docs, we are responsible for freeing this memory.
Signed-off-by: Rafaël Carré <funman@videolan.org>

In libavcodec, thread-safe callback merely means callback that can run
on any thread. It does not imply that the codec should be re-entrant.
In other words, it boils down to not using thread-specific variables.

The VLC get_buffer callback is not reentrant currently, but it does not
care which thread it runs on.

Signed-off-by: Jean-Baptiste Kempf <jb@videolan.org>

75a167f5 really did not work.