Don't kown how to make avdec_h264 working under multi-threads modes, seems not working with max-threads

[wanted002]

Many thanks! I really appereciate your time and advices.
I still have some beginner questions to figure out, so beg for your guidance
more :)

Q1 :  About "thread_type" and  "thread_count" in source code: 
I read the function 
"gst_ffmpegviddec_set_format at gst-libav-1.16.2/ext/libav/gstavviddec.c"  and
found these code:

    '''
    if (is_live)
      ffmpegdec->context->thread_type = FF_THREAD_SLICE;
    else
      ffmpegdec->context->thread_type = FF_THREAD_SLICE | FF_THREAD_FRAME;
    '''

So the default "thread_type" parameter is FF_THREAD_SLICE , means
multithreading base on slice for version 1.16.2?
And is the parameter "ffmpegdec->context->thread_count" indicate how many
thread for decoding will be spawned ?

Q2 : Why the decoding job still runs only on one  cpu core ?
    I use the "top -H -p xxxx" command,  xxxx is the pid of my
gst-launch-1.0 programm running the pipeline . But I saw decoding job is
loaded on the 1st decoding thread, the other three are idle.(My cpu got 4
cores, so I set avdec_h264 with "max-threads=4").   But I tested this on
ubuntu20.10 with gst-1.18.0, all decoding jobs were loaded on each cpu core
with parameter "thread-type=Frame". 
    By the way, the encoding side is a windows10 laptop, and I guess maybe
windows-os encoded h.264 stream with slice=1. But I'm ashamed that I 'don't
known how to prove it....  Any advices,please?

Q3 : Why 1 frame latency is introduced if the multithreading base on Frame/1
? 
I read the function 
"gst_ffmpegviddec_set_format at gst-libav-1.18.0/ext/libav/gstavviddec.c" , and
see the comment:
    /* When thread type is FF_THREAD_FRAME, extra latency is introduced
equal
     * to one frame per thread. We thus need to calculate the thread count
ourselves */

    Thank you very much for your guidance. Best wishes.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/