Re: XviD-devel Digest, Vol 64, Issue 11

Thanks Brad,

I just realised that decoder has a handle, therefore, making instances of
how many decoder I want will do just fine.


2008/5/24 <[email protected]>:

> Send XviD-devel mailing list submissions to
>        [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        http://list.xvid.org/mailman/listinfo/xvid-devel
> or, via email, send a message with subject or body 'help' to
>        [email protected]
>
> You can reach the person managing the list at
>        [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of XviD-devel digest..."
>
>
> Today's Topics:
>
>   1. Re: Multi-instance of decoder (Brad Cagle)
>   2. Re: XviD-devel Digest, Vol 64, Issue 10 (RG Nur Rahmat)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 23 May 2008 08:30:26 -0500
> From: "Brad Cagle" <[email protected]>
> Subject: Re: [XviD-devel] Multi-instance of decoder
> To: [email protected]
> Message-ID:
>        <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> A thread per instance would be the way to go. I have used Xvid in many
> multi-threaded
> projects, and It has never been a problem. Also if you are using multi-core
> CPU's your
> project will be utilising the CPU more efficiently.
>
> On Fri, May 23, 2008 at 2:53 AM, RG Nur Rahmat <[email protected]>
> wrote:
>
> > Hello Guys,
> >
> > I am trying to use XviD decoder in 4 instances in which they are running
> > parallel, so far, all I know if these decoder functions are called
> > sequentially, I will not have problem in displaying the encoded video.
> > However, in the network, we can not determine when data packet will
> arrive
> > so that my decoder function will crash due to parallel usage.
> >
> > My question is, how to go about this problem? Will multi-threading solve
> > the
> > problem, considering I'll be suing the same decoder core?
> >
> > Thank you for your replies.
> >
> > Regards,
> > RG Nur Rahmat
> > _______________________________________________
> > XviD-devel mailing list
> > [email protected]
> > http://list.xvid.org/mailman/listinfo/xvid-devel
> >
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 23 May 2008 21:42:56 +0800
> From: "RG Nur Rahmat" <[email protected]>
> Subject: Re: [XviD-devel] XviD-devel Digest, Vol 64, Issue 10
> To: [email protected]
> Message-ID:
>        <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hello Guys,
>
> I have tried to stream from 2 different computers, and I can see 2 streamed
> video from remote cameras, however, the images from these are interlapped
> in
> each respective display (GUI), I think I should flush the decoder every
> time
> it has decoded 1 frame, since I am using only the same xvid_decore for
> these
> two incoming encoded images.
>
> Please enlight me.
>
> Regards,
> RG Nur Rahmat
>
>
> > Message: 3
> > Date: Fri, 23 May 2008 15:53:45 +0800
> > From: "RG Nur Rahmat" <[email protected]>
> > Subject: [XviD-devel] Multi-instance of decoder
> > To: [email protected]
> > Message-ID:
> >        <[email protected]>
> > Content-Type: text/plain; charset=ISO-8859-1
> >
> > Hello Guys,
> >
> > I am trying to use XviD decoder in 4 instances in which they are running
> > parallel, so far, all I know if these decoder functions are called
> > sequentially, I will not have problem in displaying the encoded video.
> > However, in the network, we can not determine when data packet will
> arrive
> > so that my decoder function will crash due to parallel usage.
> >
> > My question is, how to go about this problem? Will multi-threading solve
> > the
> > problem, considering I'll be suing the same decoder core?
> >
> > Thank you for your replies.
> >
> > Regards,
> > RG Nur Rahmat
>
>
> ------------------------------
>
> _______________________________________________
> XviD-devel mailing list
> [email protected]
> http://list.xvid.org/mailman/listinfo/xvid-devel
>
>
> End of XviD-devel Digest, Vol 64, Issue 11
> ******************************************
>