[FFmpeg-devel] VP8 sliced threading

Daniel Kang 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
> sleep
> > >> comes in, since the default minimum granularity of the sleep is 10ms,
> which
> > >> should be longer than decoding a whole frame takes.
> > >>
> > >
> > > I only tested HD clips, on Linux and Windows. I will test a low-res
> clip
> > > once I can find a suitable one.
> > >
> >
> > Sorry for the second email. Where did you find the information on
> > granularity on sleep?
> >
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms686298(v=vs.85).aspxstates
> > 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 mailing list