Update x264 in contrib/build
Using multiple transcoding threads with x264 encoding gives http output problems.
Roughtly within an hour of a continuous run using dshow input and mmsh/asfh or http/ts output the stream becomes unavailable and debug on the encoder shows:
main warning: cannot select sockets
Similar problems occur using a network source as input (multicast udp/ts). Gradually more and more discontinuities are observed untill the output is also unavailable and the same network errors occur (network select error is related to input in this case?).
mpeg_audio debug: emulated startcode (no startcode on following frame)
ts warning: discontinuity received 0x2 instead of 0xb (pid=431)
ts warning: discontinuity received 0x7 instead of 0x0 (pid=431)
ts warning: discontinuity received 0xa instead of 0x4 (pid=431)
ts warning: discontinuity received 0x2 instead of 0x1 (pid=432)
mpeg_audio debug: emulated startcode (no startcode on following frame)
main warning: cannot select sockets
main warning: cannot select sockets
main error: network select error
main warning: cannot select sockets
If the stream was started from batchfile this Windows folder also becomes inaccessible with an error "Not enough quota is available to process this command" (untill vlc is forcibly closed).
There are no problems when using 1 transcode thread or udp/ts output and the problem does not seem CPU related since it also occurs at <10% CPU load (using very low transcoding resolution and bitrate).
Some extra debug lines/comment from Courmisch on a WSAENOBUFS problem?!
main warning: cannot select sockets (10055)
main error: network select error (10055)
select is only supposed to return an error when a signal is caught or when the program provides buggy parameters. if it returns when a session is saturated, how do we know which one ??? to me, it sounds like a Winsock bug, not much to be done about it. "If the system does run out of non-paged pool, there are two possibilities. In the best-case scenario, Winsock calls will fail with WSAENOBUFS. The worst-case scenario is the system crashes with a terminal error."
Problem doesn't seem to occur with same commandline but with just mp4v so can this perhaps be a threading x264 memory leak issue, either in x264 encoder itself or in the vlc implementation of x264?!
There is a confirmed handle leak in x264 encoder.c r272. Updating the contrib package to use r273 should solve the issue.
