[FFmpeg-devel] VP8 sliced threading
daniel.d.kang at gmail.com
Fri Jul 6 23:36:56 CEST 2012
On Fri, Jul 6, 2012 at 12:37 PM, Reimar Döffinger
<Reimar.Doeffinger at gmx.de>wrote:
> On Fri, Jul 06, 2012 at 03:14:17AM -0400, Daniel Kang wrote:
> > >
> > > Also how did you get performance numbers? For low horizontal resolution
> > >> I'd expect it to potentially get vastly slower on Windows when the
> > >> comes in, since the default minimum granularity of the sleep is 10ms,
> > >> should be longer than decoding a whole frame takes.
> > >>
> > >
> > > I only tested HD clips, on Linux and Windows. I will test a low-res
> > > once I can find a suitable one.
> > >
> > Sorry for the second email. Where did you find the information on
> > granularity on sleep?
> > that a value of 0 will "[cause] the thread to relinquish the
> > remainder of its time slice to any other thread that is ready to run." I
> > cannot find information on implementation details.
> I'm afraid it is not documented.
> Note I am not sure if things changed _after_ XP but my information
> should at least be correct for Windows XP.
My benchmarks were on Windows 7.
I don't have access to an XP box. Can I get ssh/remote desktop to one for
Also the pause instruction is meant for spinlock cases. You are using
> sleep in the same loop which will usually go into the kernel and in
> general this is not really a spinlock, so I don't think it is helping
> and I think it is not supposed to be used like this.
Do you think implementing this as a spinlock will help in this case?
I also think I read that using sched_yield this way is not portable and
> thus very much discouraged (it is implemented as a NOP often).
> The idea being that proper locking/signalling should be fast enough (and
> actually can be quite faster if sched_yield is actually a NOP).
On one Linux machine I tested on, using mutex locks and waits cause sliced
threading to dramatically slow down.
More information about the ffmpeg-devel