On Wed, Dec 17, 2008 at 8:55 PM, Dan Dennedy <dan at dennedy.org> wrote: > On Wed, Dec 17, 2008 at 2:24 PM, Dan Dennedy <dan at dennedy.org> wrote: >> On Wed, Dec 17, 2008 at 11:12 AM, Jean-Michel Pour? <jm at poure.com> wrote: >>> On Wed, 2008-12-17 at 10:43 -0800, Dan Dennedy wrote: >>>> configure with --enable-pthreads and run ffplay with the -threads >>>> option followed by the number of worker threads to use. It will still >>>> keep a decoder control thread and separate reader/output threads, all >>>> of which are fairly light, so it is a good idea to use (#cores - 1) >>>> for the worker threads. >>> >>> Ah ... this skiploop is not documented. >> >> documented in the source :-). Actually, I knew of it because of 'ffplay -h' >> >>> ffplay -skiploop 48 -threads 2 avchd-test-1.mts works very well. >>> >>> By the way, FFmpeg developers suggested that we do not decode B frames >>> during viewing. I don't know is this can apply to Kdenlive. >> >> Yeah, I'm not sure, but I will experiment with it. I might be okay to >> skip B frames in preview (user might see repeated frames) and then >> process them during render. With ffplay you can use "-skipframe 16" to >> skip B frames. > > I learned that on my dual Athlon, these two options make it about > twice as fast! I also learned that despite this, it does not support > parallelized decoding even though (if I am not mistaken), it appears > most files I tested have 2 slices per frame (determined using "-debug > 1"). Nevertheless, this are some cheap, simple options.
Hmm, I have a H.264 1080p trailer downloaded from Apple's trailers site where multithreaded decoding does work with skiploop=48. I see it has 8 slices per frame. Ah... now I see (using -debug 1) that the AVCHD clip has 4 "packets," or whatever you want to call them (debug lines), per frame, but the slice always =1 whereas in the trailer slice = 1 to 8. -- +-DRD-+
