[Live-devel] Timing Issue on Processing of a Received Packet
Cihat Goktug Gurler
silencertr at gmail.com
Tue Apr 24 09:56:58 PDT 2007
Hi,
I'm now working on a multiview H264 server and client pair. The idea
is to receive different views of an object and than merge those images
in a way that it will result in 3D view of the object with special
displays such as lenticular sheet.
I'm not very familiar with the thread structure of VLC, therefore I
had the following question in mind. Shortly what happens if the thread
that receives the NALU is also used to process the image. Would the
delay cause packet loss? The details is as follows;
We have a class named as 'H264PlayerSink' which inherits 'MediaSink'
class. The number of instances from that class equals to the number of
streams we have, which is also equal to the number of views.
In order to generate correctly merged images we have to process the
frames that belong to same time instance. For this reason we have a
buffing mechanism to deal with delayed packets. This buffer passes the
NALU information from all views only if all of them arrived. It seems
that producing the *merged frame and putting it into FrameBuffer takes
around 30ms.
Finally the question. If this is done with the same thread that is
running on afterGettingFrame method of H264Playersink would that cause
packet loss? Since packets arrive with a faster rate.
I read that VLC is not multi-threaded.So I thought that if a time
consuming (around 30ms) duty is assigned at afterGettingFrame method
it may cause a problem.
What is your oppinion about that situation? Should I create a new
thread (pThread with mutexs) to deal with the merging issue? If I do
that afterGettingFrame will only take around 5 ms.
I hope the question does not need any clarification.
Best wishes
Goktug Gurler
Koc University / Turkey
PS: We are working on a PC with Intel Core2Duo 2600Mhz and OS is WinXP.
--
Cihat Göktuğ Gürler
ENG. 123 | phone 2653
Electric & Electronic Engineer,
Koc University, Turkey.
Email:
cgurler at ku.edu.tr
silencer at nebula.gen.tr
silencertr at gmail.com
More information about the live-devel
mailing list