[Ffmpeg-devel] Using avcodec threaded help request

Scott Harper orcein
Tue Mar 27 22:25:28 CEST 2007


>> If someone could offer a description of pthreads' usage or show me to
>> a working example I would be very appreciative! ^_^
>>
>
> Hi.
>
> I'm still tangled in threads in my own app, but my first advice is  
> to run
> your app through valgrind (or valkyire). During my tests I became  
> almost
> fully positive that there are no deadlocks in libavcodec itself, if  
> it used
> correctly, and the problems occur in the application itself.
>
> Also search the mailing lists for my (or others) emails regarding the
> libavcodec functions that should be locked by mutexes.

Thanks for your response!  As it turns out, the problem was because I  
copied the ffplay.c packet queue code, which when reading frames  
checks to make sure that the packet queues aren't too big (ie full)  
before allowing the continued reading of more packets.  What was  
happening was that one video would run full on video frames and empty  
on audio frames, and a second video would do the opposite, creating a  
deadlock in both reading and writing frames of either.

The solution I came up with was to simply change around the check from:

if( mAudioQ.nb_packets > MAX_AUDIOQ_SIZE ||
	mVideoQ.nb_packets > MAX_VIDEOQ_SIZE ) {...}

to

if( mAudioQ.nb_packets > MAX_AUDIOQ_SIZE &&
	mVideoQ.nb_packets > MAX_VIDEOQ_SIZE ) {...}

(the logical OR to a logical AND).  This DOES open up my program to  
end up with a great excess of frames of one or the other, but I'm  
somewhat at a loss for how to control how many packets are stored  
while avoiding my previous deadlock.  I'm working on the assumption  
that if a video file has both audio and video data that they will all  
have to be used eventually, and watching my memory reveals this to be  
accurate while running.

Are there any other suggestions on how to make this work without the  
potential/theoretical overflow?

-- Scott




More information about the ffmpeg-devel mailing list