[FFmpeg-devel] mutlithreading in ffmpeg?

[Reimar Döffinger]

On 29 Mar 2011, at 04:29, Thomas Worth <dev at rarevision.com> wrote:
> On Sun, Mar 27, 2011 at 3:08 AM, Reimar Döffinger
> <Reimar.Doeffinger at gmx.de> wrote:
>> 
>> I am going to say it again: that in itself is not necessarily a bug.
>> The difference to single-thread does make it suspicious though, but nothing
>> more.
> 
> Of course it's suspicious -- it isn't producing expected results. And
> don't confuse "single thread" with simply setting codec context's
> thread count to 1. This does not work regardless of whether the thread
> count is 1 or > 1. It ONLY works with normal (non-mt) ffmpeg.

ffmpeg-mt has been merged into "normal" FFmpeg, thus I just can't make any sense of it.
You could try tracking down the specific commit that broke it.

> 
>> And the fact that here:
>>> seekpos:01001|pts:01001|decode2 return val:0319|got_pic_ptr:000|is keyframe:0
>>> seekpos:01001|pts:02002|decode2 return val:0318|got_pic_ptr:328|is keyframe:0
>> You are seeking to the same position twice and get a different result
>> means there's some state lingering. Whether that's your code's fault or
>> not is impossible to say with such an incomplete code-snippet.
> 
> The only reason this happens is because I am forcing a decode by
> ignoring *got_picture_ptr to expose the problem. This would not happen
> during normal operation. In fact, with the H.264 decoder I don't even
> have to check for got_picture_ptr, because everything returned from
> avcodec_decode_video2 is a valid frame. That is, except for ffmpeg-mt,
> where each frame after a keyframe is inexplicably ignored EVEN THOUGH
> it is reporting the number of bytes in the decode result!

Sorry, this makes no sense to me, I am saying that you do exactly the same seek twice and the result is different.
That is a _bug_ and means that somehow some state remains. What does this have to do with got_picture_ptr??
Or is there some critical code missing from the part you gave us.
The first step of debugging is understanding each and every such inconsistency, otherwise it's searching the needle in the haystack.

> And please understand that I'm not _asking_ anybody to do anything. I
> am just trying to solve this problem, and maybe someone is interesting
> in helping me. If you're not interested and would prefer to not "waste
> you time," then by all means, don't. But please, in the mean time
> don't tell me my arguments are invalid when you haven't even read them
> completely. That does not seem very productive, in my opinion.

I am trying to get you to understand that you don't provide any useful information, i.e. the information is not enough that I can be sure there is a bug, it certainly isn't enough for me to figure out where it might be!
Of course I could try to reimplement your program and test myself, but why should I do that when you already have that? It just feels like you're trying to make it difficult to help you on purpose! (I can't imagine that but it sure feels like it!)