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

[Nicolas Dufresne]

Le lundi 22 mars 2021 à 07:46 -0500, wanted002 a écrit :
> 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 ?

Not exactly, the default is to enable threads, SLICE for live pipeline, and
SLICE or FRAME (both) for non-live pipeline.

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

I assume you use Media Foundation, see "Slice encoding":

https://docs.microsoft.com/en-us/windows/win32/medfound/h-264-video-encoder

This is the default, it's will produce as many slices as you have CPU cores on
the encoder side by default (assuming I'm reading the doc right).

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

This is what is documented in FFMPEG API documentation, and was also observed. I
haven't looked at the internal details. But adding render delays, ensure for
live pipeline that the thread pool fills, otherwise the pool will always starve
and run single threaded. Let's hope this is not your situation. That could mean
that your time information is late, too high network latency, or miss-configure
latency somewhere.

> 
> 
> 
> --
> Sent from: http://gstreamer-devel.966125.n4.nabble.com/
> _______________________________________________
> gstreamer-devel mailing list
> gstreamer-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel