The problem comes from the fact that into xine_probe_fast_memcpy() there is
a call to xprintf, which excutes some actions to this->log_lock. But the
"log_lock" field is still uninitialized. Under Windows, the xine_init()
always crashes because that type is implemented as a structure, so the lock
receives a NULL pointer and the execution is halted. The attached patch
proposes to move the mutex objects to the top of xine_init() function.

--HG--
extra : transplant_source : %07%1D%7F%F0%97%7D%06%3E%9F%2Ar%03%1DQ%14%F3%D1%EF%1D%93

With Pthreads for Win32/Win64 I cannot compare two pthread_t items because
they are implemented as structures. This patch fixes the comparison by
using pthread_equal() function.

--HG--
extra : transplant_source : %9D%98%CE%83%5E%BD%A9u%11%C7%3BmP%28%EBH%D0%B6I%DF

Changeset 8ffe18290ba5 fixed bug 1784272 (opening raw filenames with #
character, like "show #1.mpg") but at the cost of killing # separator in raw
filenames completely. Although this might be a valid requirement in a new devel
branch, imho, such change in stable branch should be considered a regression.

The original idea of passing partial MRL for the input plugins to try doesn't
work because plugin will generate error messages for every failed attempt to
open the file (like "show " above), even thought the complete MRL is valid
and will be played.

So, since raw filenames are an exception for the MRL scheme anyway, we
try stat'ing the partial filenames to determine what user means with the #.

Retrieving frame size and format is a legal operation even for
otherwise not supported frame formats like XXMC.

xine_get_current_frame() relies on the caller to provide a sufficiently
sized buffer. To calculate the required size of the buffer, one has to
call xine_get_current_frame() to retrieve the necessary parameters. But
as the image can change between two successive calls one has to pause
the stream for consistency.
To improve the situation, xine_get_current_frame_s() has been introduced
which requires to specify the buffer size when an image is going to be
retrieved. Furthermore, it will return the required/used buffer size.
In that way, it can prevent copying data into a too small buffer and
therefore can be considered safe.
For convenience, xine_get_current_frame_alloc() is provided which takes
care to allocate a sufficiently sized buffer. This function avoids
pausing the stream as the image will be returned in a single call.

This is to avoid having to rebuild external plugins for each new release.

--HG--
extra : transplant_source : %C2%3EF%0B%EF%16%40K%FD.%EB9%E07%CB%97GhU%98

(Cset 1a0447486a13 broke things differently.)