[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