-
Notifications
You must be signed in to change notification settings - Fork 743
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Deadlock on ffmpeg+x264 for windows encode with tune=zerolatency #480
Labels
Comments
Simply because it didn't use to build with that option. If they've fixed
it, sure, that's fine. Please send a pull request and let's see if there
are any build issues remaining.
|
Thank you for your quick response, saudet. I'm really sorry, I'm not used to github and don't understand to send a pull request.
|
You'll need to send a pull request to be able to test it.
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello guys,
I'm using a javacpp-1.3 and ffmpeg+x264 for Windows x64 and facing deadlock problem.
I'd like to encode in real-time, so set a
-tune zerolatency
that is a x264 option.Option setting source code below:
Actually I don't know about x264 in defails, but this option apparently enables x264 to encode a frame in thread parallel.
Encoding frame and extracting avpkt source code below:
After encoding for a while, the encoding loop is stopped in
avcodec_send_frame()
.Without x264 zerolatency option, that problem doesn't occur.
I doubted this problem would be a bug on official ffmpeg+x264 at first, but I didn't face the same problem by using below command.
I tried some cases and found, official ffmpeg+x264 is using a win32 thread, on the other hand ffmpeg+x264 in javacpp is built with
./configure --disable-win32thread
so it's using a pthread by default.I guess my problem will be resolved if ffmpeg+x264 in javacpp is built without
--disable-win32thread
.I have two questions.
Thank you.
The text was updated successfully, but these errors were encountered: