[Kdenlive-devel] AVCHD/h264 decoding benchmarking

[Dan Dennedy]

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-+