Qtopia Media Player Design--------------------------The Qtopia Media Player has some design complexity to itso this document aims to inform and help understand thecode.MultiThreaded-------------The first thing to understand is that it is multithreaded.The reason it is multithreaded is as follows:On PDAs like the Zaurus and iPAQ, the audio device has an audiobuffer of approximately 32k. This determines the maximum amountof audio data which can be queued at any one time. Commonlyaudio streams are 44kHz, 16bit stereo, which generates 44100*2*2number of bytes per second to send to the audio device. When youdo the maths (44100*2*2) / (32*1024) rounds up to 6, which isthe least number of times you must refill the audio buffer persecond. This is ideal conditions discounting how long it takesto decode the audio or do anything else. Ultimately what thismeans is that if it takes longer than 1/6th of a second todecode a video frame, then for a single threaded implementationyou will loose audio. Remember this is assuming nothing else isrunning and absolutely ideal conditions. In reality if theframerate drops below 10 frames per second and only forone single frame, you are dead. The audio misses filling theaudio buffer and there are completely unacceptable gaps inthe audio. When you consider that an mpeg could be streamed orbeing read off a CF card or microDrive in addition somebackground task could be running, it seems almost inevitablethat on a PDA that for one frame the rate could drop below10 frames per second. A multithreaded approach hasindependent scheduling for decoding the audio and video whichcompletely solves this problem since filling the audiobuffer (which is virtually a real-time task, but a slow one at1/6th of a second) is now never effected by the video decoding.It turns out that it also smooths out the playback ofvideo frames giving a slightly more even frame rate since the video frames are nolonger interspursed with audio decodingand buffering. The slower the CPU the more critical mutlithreadeddecoding becomes.  As you would expect, a faster CPU would decodeeverything fast enough that none of these issues are a problemso a single threaded implementation could work.Okay, so hopefully I've convinced you that multithreadeddecoding is required. If not, too bad, that's the way it is! :)One problem is that Qt is not very thread safe, specially withanything to do with painting. Additionally, for various reasonsthe Qt/Embedded library on the Zaurus does not support Qt threads,therefore pthreads are used instead.Because of the thread safety issues, the audio is decodedin the created thread without using Qt. There needs tobe a few mutexes to ensure safety in loopcontrol.The decoders also must be able to handle there own threadsafety. This can either be added in to the plugin wrapperor could be a builtin characteristic of the decoder. Forinstance in the ffmpeg plugin, mutexes surround loadingpackets for both the audio and video decoding but are notneeded around the actual decoding because both video decoding and audio decoding have their own contexts. Withthe libmpeg3 plugin, it handles loading mpeg packetsinternally, but also completely handles thread safetlyitself also. Audio or Video only decoders obviously don'thave to handle thread safetly.Model-Controller-View---------------------Moving on from the multithreaded nature of the player,lets look at the GUI side of things. The basic frameworkloosely follows a model-controller-view framework. It'sworth noteing that I didn't start out to design it thatway but it evolved to resemble this framework as I guessthat must be the best abstraction for a media player.It's not exactly a strict seperation, but it's close.The 'model' is encapsulated by the decoder plugins whichprovide an abstraction to the data. Also theMediaPlayerState class also maintains the current stateof decoding, options etc and holds the pointer to the decoder,so it is really the hub of access to the model. The 'controller'is in loopcontrol.cpp with the LoopControl class. It handlescontrolling the decoding. It does rate-control (ensuring theframe rate etc) and user control such as pause and so on.The 'view' is the VideoWidget and the AudioWidgetclasses which show the output and interact with theLoopControl class to allow the user to control the playback.If you think about the code in these terms it helps inunderstanding it better. There are other surrounding classesand widgets such as the playlist, file selection classesas well as the info / ID3 tag classes which are aboutselecting and controlling the media files.