On Fri, Aug 24, 2012 at 10:02 AM, Roger Pack wrote:
>> Could it be that x264 or FFmpeg is improperly using the pthread
>> library and that is what is actually causing this issue?
>
> This is possible, as I saw this recently
> http://ffmpeg-users.933282.n4.nabble.com/Performance-issue-question-mayb
> Could it be that x264 or FFmpeg is improperly using the pthread
> library and that is what is actually causing this issue?
This is possible, as I saw this recently
http://ffmpeg-users.933282.n4.nabble.com/Performance-issue-question-maybe-my-misunderstanding-td4652757.html
which makes me wonder i
Could it be that x264 or FFmpeg is improperly using the pthread
library and that is what is actually causing this issue?
If so, I can dig into the code of both and see how they use pthread.
Also, I'm not sure if this issue presents itself in just x264 (not
x264 in FFmpeg), but would it help if I
> This is often useful for profiling:
>
> http://www.codersnotes.com/sleepy/
I haven't gotten it to work with gcc 4.7.1 + dwarf stuff, but maybe
others will have better luck, or can point me in the right direction?
-r
--
This is often useful for profiling:
http://www.codersnotes.com/sleepy/
On Tue, Aug 14, 2012 at 2:26 AM, Kyle Schwarz wrote:
> On 8/13/2012 8:31 PM, NightStrike wrote:
>> On Wed, Aug 8, 2012 at 2:49 PM, Kyle wrote:
>>> It's *very* slow. If you compare the speed to that of a older FFmpeg,
>>> the
On 8/13/2012 8:31 PM, NightStrike wrote:
> On Wed, Aug 8, 2012 at 2:49 PM, Kyle wrote:
>> It's *very* slow. If you compare the speed to that of a older FFmpeg,
>> the debug build is practically unusable.
>
> I'm coming into this very late, and I probably can't be of much help,
> but just a thought
On Wed, Aug 8, 2012 at 2:49 PM, Kyle wrote:
> It's *very* slow. If you compare the speed to that of a older FFmpeg,
> the debug build is practically unusable.
I'm coming into this very late, and I probably can't be of much help,
but just a thought. Have you tried profiling ffmpeg to see where it
On Mon, Aug 13, 2012 at 11:18 AM, Kyle Schwarz wrote:
> On 8/8/2012 8:49 PM, Kyle wrote:
>> On 8/7/2012 3:06 AM, Kai Tietz wrote:
>>> 2012/8/7 Kyle Schwarz :
On 8/6/2012 4:58 PM, Kai Tietz wrote:
> I have attached a modified version of winpthread (uncomress it and
> rename it back to
On 8/8/2012 8:49 PM, Kyle wrote:
> On 8/7/2012 3:06 AM, Kai Tietz wrote:
>> 2012/8/7 Kyle Schwarz :
>>> On 8/6/2012 4:58 PM, Kai Tietz wrote:
I have attached a modified version of winpthread (uncomress it and
rename it back to .dll). It would be great if you could test this
variant
On 8/7/2012 3:06 AM, Kai Tietz wrote:
> 2012/8/7 Kyle Schwarz :
>> On 8/6/2012 4:58 PM, Kai Tietz wrote:
>>> I have attached a modified version of winpthread (uncomress it and
>>> rename it back to .dll). It would be great if you could test this
>>> variant on your box, too.
>>
>> Thanks a lot for
> No, you don't need to recompile. Is the application really stucked,
> or is it just very slow? Have you tested that it response on '?' key
> stroke? As for me the encoding works - slowly - but it works.
Ok I tried the latest .dll, same thing here (still shows pauses):
Basically, you should s
2012/8/7 Kyle Schwarz :
> Hi Kai,
>
> On 8/6/2012 4:58 PM, Kai Tietz wrote:
>> I have attached a modified version of winpthread (uncomress it and
>> rename it back to .dll). It would be great if you could test this
>> variant on your box, too.
>
> Thanks a lot for the modified libwinpthread-1.dll,
Hi Kai,
On 8/6/2012 4:58 PM, Kai Tietz wrote:
> I have attached a modified version of winpthread (uncomress it and
> rename it back to .dll). It would be great if you could test this
> variant on your box, too.
Thanks a lot for the modified libwinpthread-1.dll, and the continued help.
I copied
On 8/6/2012 3:56 PM, Kai Tietz wrote:
> 2012/8/6 Kyle :
>> On 8/6/2012 1:59 PM, Kai Tietz wrote:
>>> 2012/8/6 Kyle :
On 8/4/2012 3:38 AM, Kai Tietz wrote:
> 2012/8/4 Kyle Schwarz :
>> On 7/27/2012 5:37 PM, Kai Tietz wrote:
I have tried it, thanks for the patch!
>>
2012/8/6 Kyle :
> On 8/6/2012 1:59 PM, Kai Tietz wrote:
>> 2012/8/6 Kyle :
>>> On 8/4/2012 3:38 AM, Kai Tietz wrote:
2012/8/4 Kyle Schwarz :
> On 7/27/2012 5:37 PM, Kai Tietz wrote:
>>> I have tried it, thanks for the patch!
>>>
>>> Unfortunately it appears that (ffmpeg + libx2
On 8/6/2012 1:59 PM, Kai Tietz wrote:
> 2012/8/6 Kyle :
>> On 8/4/2012 3:38 AM, Kai Tietz wrote:
>>> 2012/8/4 Kyle Schwarz :
On 7/27/2012 5:37 PM, Kai Tietz wrote:
>> I have tried it, thanks for the patch!
>>
>> Unfortunately it appears that (ffmpeg + libx264 using it at least)
>>>
2012/8/6 Kyle :
> On 8/6/2012 2:45 PM, Kai Tietz wrote:
>> Another question I have. Which ff-tool is blocking for you? I tried
>> ffplay, which didn't dead-locked on my Windows-box (i7 Windows 7
>> 64-bit). Could you provide me with example film/stream, so that I am
>> able to reproduce your dea
On 8/6/2012 2:45 PM, Kai Tietz wrote:
> Another question I have. Which ff-tool is blocking for you? I tried
> ffplay, which didn't dead-locked on my Windows-box (i7 Windows 7
> 64-bit). Could you provide me with example film/stream, so that I am
> able to reproduce your dead-lock?
Using ffmpeg.
Another question I have. Which ff-tool is blocking for you? I tried
ffplay, which didn't dead-locked on my Windows-box (i7 Windows 7
64-bit). Could you provide me with example film/stream, so that I am
able to reproduce your dead-lock?
Thanks in advance,
Kai
---
2012/8/6 Kyle :
> On 8/4/2012 3:38 AM, Kai Tietz wrote:
>> 2012/8/4 Kyle Schwarz :
>>> On 7/27/2012 5:37 PM, Kai Tietz wrote:
> I have tried it, thanks for the patch!
>
> Unfortunately it appears that (ffmpeg + libx264 using it at least)
> appears to deadlock (?) after a few seconds
On 8/4/2012 3:38 AM, Kai Tietz wrote:
> 2012/8/4 Kyle Schwarz :
>> On 7/27/2012 5:37 PM, Kai Tietz wrote:
I have tried it, thanks for the patch!
Unfortunately it appears that (ffmpeg + libx264 using it at least)
appears to deadlock (?) after a few seconds.
Here's an ex
2012/8/4 Kyle Schwarz :
> On 7/27/2012 5:37 PM, Kai Tietz wrote:
>> > I have tried it, thanks for the patch!
>>>
>>> Unfortunately it appears that (ffmpeg + libx264 using it at least)
>>> appears to deadlock (?) after a few seconds.
>>>
>>> Here's an example trace:
>>>
>>> Thanks for your help in t
On 7/27/2012 5:37 PM, Kai Tietz wrote:
> > I have tried it, thanks for the patch!
>>
>> Unfortunately it appears that (ffmpeg + libx264 using it at least)
>> appears to deadlock (?) after a few seconds.
>>
>> Here's an example trace:
>>
>> Thanks for your help in this!
>> -roger-
>
> Hmm, it seems
Hi Roger,
2012/7/27 Roger Pack :
>> So, I made spinlocks "fair" by revision 5274. This means that no
>> threads get *lost* on scheduling, if lock is requested.
>>
>> Please give this version a try.
>
> I have tried it, thanks for the patch!
>
> Unfortunately it appears that (ffmpeg + libx264 usin
2012/7/27 K. Frank :
> Hi Kai!
>
> On Fri, Jul 27, 2012 at 4:09 PM, Kai Tietz wrote:
>> So, I made spinlocks "fair" by revision 5274. This means that no
>> threads get *lost* on scheduling, if lock is requested.
>
> This is purely a matter of multi-threading curiosity on my part.
>
> How much add
> So, I made spinlocks "fair" by revision 5274. This means that no
> threads get *lost* on scheduling, if lock is requested.
>
> Please give this version a try.
I have tried it, thanks for the patch!
Unfortunately it appears that (ffmpeg + libx264 using it at least)
appears to deadlock (?) after
Hi Kai!
On Fri, Jul 27, 2012 at 4:09 PM, Kai Tietz wrote:
> So, I made spinlocks "fair" by revision 5274. This means that no
> threads get *lost* on scheduling, if lock is requested.
This is purely a matter of multi-threading curiosity on my part.
How much additional cost (if any) do you think
So, I made spinlocks "fair" by revision 5274. This means that no
threads get *lost* on scheduling, if lock is requested.
Please give this version a try.
Thanks in advance,
Kai
--
Live Security Virtual Conference
Exclusi
2012/7/26 Roger Pack
> > Hmm, by looking at this I see that the issue might be a
> > raise-condition about spin-locking. Means too much threads try to get
> > spinlock-lock repeatively. So that one (or more) waiting threads
> > simply don't get a chance to get the lock. I saw that pthread-win3
> Hmm, by looking at this I see that the issue might be a
> raise-condition about spin-locking. Means too much threads try to get
> spinlock-lock repeatively. So that one (or more) waiting threads
> simply don't get a chance to get the lock. I saw that pthread-win32
> uses here for spin-locking
Thanks for the patch, I will take a look.
Hmm, by looking at this I see that the issue might be a
raise-condition about spin-locking. Means too much threads try to get
spinlock-lock repeatively. So that one (or more) waiting threads
simply don't get a chance to get the lock. I saw that pthread-
>>> Well, the issue seems to be that a mutex, which is already up to be
>>> destroyed, is still waited to return. I allowed for this that a mutex
>>> can be destroyed even if another thread waits for lock for it. You
>>> may want to test revision 5250.
>>
>> Thank you I will try it.
>
> Had you
Hello Roger,
2012/7/24 Roger Pack :
>> Well, the issue seems to be that a mutex, which is already up to be
>> destroyed, is still waited to return. I allowed for this that a mutex
>> can be destroyed even if another thread waits for lock for it. You
>> may want to test revision 5250.
>
> Thank
> Well, the issue seems to be that a mutex, which is already up to be
> destroyed, is still waited to return. I allowed for this that a mutex
> can be destroyed even if another thread waits for lock for it. You
> may want to test revision 5250.
Thank you I will try it.
>Which edition MinGW64 G
Hi, Kai
于 2012/7/23 4:14, Kai Tietz 写道:
> Hello Roger,
>
> 2012/7/22 Roger Pack :
>> Greetings fellow program(mers).
>>
>> A "situation" occurred the other day where, using (cross compiled)
>> ffmpeg+libx264 with mingw-w64, "--enable-pthreads" and the mingw-w64
>> pthread library, some oddness wou
Hello Roger,
2012/7/22 Roger Pack :
> Greetings fellow program(mers).
>
> A "situation" occurred the other day where, using (cross compiled)
> ffmpeg+libx264 with mingw-w64, "--enable-pthreads" and the mingw-w64
> pthread library, some oddness would result, like the app would "hang"
> eating up 10
于 2012/7/22 13:12, Roger Pack 写道:
> Greetings fellow program(mers).
>
> A "situation" occurred the other day where, using (cross compiled)
> ffmpeg+libx264 with mingw-w64, "--enable-pthreads" and the mingw-w64
> pthread library, some oddness would result, like the app would "hang"
> eating up 100%
Greetings fellow program(mers).
A "situation" occurred the other day where, using (cross compiled)
ffmpeg+libx264 with mingw-w64, "--enable-pthreads" and the mingw-w64
pthread library, some oddness would result, like the app would "hang"
eating up 100% cpu, seemingly doing nothing useful. I was t
38 matches
Mail list logo
