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

wanted002 wanted002 at
Mon Mar 22 12:46:10 UTC 2021

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;
      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
     * 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:

More information about the gstreamer-devel mailing list