Quote:
Originally Posted by taemun
That would be the one that had 3MB in RAM and ~750MB in pagefile at the end 
Not to tell you your job or anything, but shouldn't that instance be able to be closed after the first pass is complete? (ie after all the scene cuts have been found) |
That would certainly make the most sense, wouldn't it?
The only real reason I didn't do that is that I had abstracted away the avs2yuv process so far that it hid all the parts that I could have closed. Rather than attempting to do that, I decided instead to try and get rid of the splitter altogether. After much hacking away, I finally decided to do a ground-up rewrite to the entire program, which turned into x264farm-sp (which doesn't have a splitter). The 2-pass x264farm has since fallen by the wayside.
Quote:
|
On another note, why is it that the x264 builds used by x264farm have to be made in MSVC? (ie not from x264.nl)
|
That is due to an annoying bug that x264 will open the stdin handle in text mode, meaning that it will interpret ASCII character 0x1A as an EOF marker and stop encoding. (it also turns 0x0D0A into 0x0D) MSVC builds don't have this issue, though, as there are a few MSVC-specific lines in x264 to switch to binary.
This is only a problem in controller-based mode, though. You may use anything you want if you ensure that the computer is using agent-based encoding.
(Note that it's not really a bug in x264; I think stdin and stdout are usually opened in text-mode in Windows. It's just a bit odd that x264 expects binary data to pass through them...)
It
should be an easy fix for making it work in cygwin/msys, but I really don't know enough C to say for sure.
Quote:
And: what is the newest MSVC build. The one posted a couple pages back by SpAwN_gUy called x264.819.msvc2005.modified.exe, seems to crash quite a bit (I think its when x264 has too low of a bitrate, and normally it would throw an error ... but instead, this build just crashes and then Windows sits and waits for user input - ie to close the "this program has crashed" dialog).
Cheers,
t
|
I'm not really sure what the most current version of MSVC x264 is. I gave up making my own builds a long time ago, since x264 is really only tested against GCC, and some of the changes would break MSVC for long periods of time. Not knowing a lot of C, I was clueless to fix it in these cases. Since then, I have had no need for controller-based encoding (on Windows boxes), so I haven't kept up with the progress. I'll have to defer to SpAwN_gUy to answer that question.
If you can get agent-based encoding up and running, then you can bypass this restriction. That would probably be the best course of action right now. (if the CoreAVC fix made agent-based encoding work, then you can use anything you want)