EbH265EncSendPicture is hanging

[rexvl]

EbH265EncSendPicture is hanging when I encode the frames from encode loop without the delay on linux. I have to add usleep call between EbH265EncSendPicture calls to avoid the issue. Please see the attached source. Look like EbH265EncSendPicture is hanging on sem_wait.

I also found that EbH265EncSendPicture is hanging when I disabled pkt reading loop at all after ~230 frame. Is it expected behavior or EbH265EncSendPicture should return EB_ErrorMax status or something else?

main.cpp.gz

[tianjunwork]

Hi @rexvl, there was a simple app(similar to what you are doing) which removed later. https://github.com/OpenVisualCloud/SVT-HEVC/pull/174. Do you mind take a look first before we come back from thanksgiving holiday?

[rexvl]

Hi @tianjunwork, of course, thanks, happy thanksgiving!

[rexvl]

Few addings.

EbH265EncSendPicture works without hanging if I run the app as root.

Tried to set config.switchThreadsToRtPriority = 0 but EbH265EncSendPicture still hanging if the app run without root privilegies.

[Austin-Hu]

Hi @rexvl ,

At first, I couldn't reproduce the issue with your main.cpp, running on my Ubuntu 18.04.1 with Xeon 8280 CPU, no matter SwitchThreadsToRtPriority was 1 (by default) or 0 which I hard coded in the SVT-HEVC library. As for the SVT API usage, please refer to the reference App, the ffmpeg plug-in or the gstreamer plug-in.

As for your 2nd finding related to "disabled pkt reading", I believe you didn't call EbH265ReleaseOutBuffer() in the loop, either. Because here is the procedure if EbH265ReleaseOutBuffer() isn't called: 1. There wouldn't be any object returend to the empty queue of the "Output Stream Buffer" System Resource, where the objects (~230 as you observed) will be exhausted; 2. The InitialRateControl kernel couldn't get any available (empty) buffer object from the "Output Stream Buffer" System Resource, and it will keep waiting for the object with EbGetEmptyObject(); 3. The latter Packetization kernel will hang (by EbGetFullObject()) as well, and will not send RC_PACKETIZATION_FEEDBACK_RESULT to RateControl kernel; 4. The RateControl kernel will not return any object to the empty queue of the "Input Buffer" System Resource any more; 5. Eventually as you observed, EbH265EncSendPicture() couldn't get any buffer object from the "Input Buffer" System Resource, and keeps waiting there.

So based on the current SVT architecture and design, any application using SVT API must invoke EbH265GetPacket() and EbH265ReleaseOutBuffer() for each cycle encoding, even though it doesn't intend to.

Thanks!

[rexvl]

Hi @Austin-Hu,

the first issue is 100% reproduced on Ubuntu 19.04 running on Intel(R) Core(TM) i5-6600K.

Also the issue is reproduced on Fedora 27 running on virtual machine on VMWare.

The stack trace of the executing process at hanging might be helpful:

1 futex_abstimed_wait_cancelable futex-internal.h 205 0x7fedd46fc086 2 do_futex_wait sem_waitcommon.c 111 0x7fedd46fc086 3 __new_sem_wait_slow sem_waitcommon.c 181 0x7fedd46fc178 4 EbBlockOnSemaphore 0x7fedd43cd299 5 EbGetEmptyObject 0x7fedd43ccf73 6 EbH265EncSendPicture 0x7fedd4391dc2 7 main main.cpp 78 0x56238b3fe5a9

[Austin-Hu]

Hi @rexvl ,

Could you supply your reproducing steps? Because we couldn't reproduce the issue for long time with the configuration and steps below:

• Configuration: -- Ubuntu 18.04.1 + Xeon 8280 CPU, Ubuntu 18.04.1 + i7-8809 -- Windows 10 + i5-7300, Windows 10 + xeon 6140
• Steps (in Ubuntu):
  1. gcc main.cpp -I /usr/local/include/svt-hevc/ -lSvtHevcEnc -lpthread -o main
  2. ./main

Thanks!

[rexvl]

Hi @Austin-Hu

I saw no significant difference with my command. I do the following:

export LIBRARY_PATH=/home/test/SVT-HEVC/Bin/Release && gcc main.cpp -I /home/test/SVT-HEVC/Source/API -lSvtHevcEnc -lpthread -lstdc++ -o main

./main

EbH265EncSendPicture hangs after about 1-2 minutes.

I also reproduced the issue on Ubuntu 18.04.1 running on VMWare.

[Austin-Hu]

BTW, I'm using the latest commit of master branch. You're also using the latest one, correct? @rexvl

[rexvl]

Yes, I'm using the latest rev from master too.

[Austin-Hu]

Yes, I'm using the latest rev from master too.

Hi @rexvl , sorry that we're busy with other issues recently, and will look at this issue later. And could you create an account so that we can remotely debug it, as we couldn't reproduce the issue in our side. Thanks!

[rexvl]

Hi @Austin-Hu, sory for the delay. Will grant the remote access when you needed. Please skype me to @rexvl25 when you will be ready for debug.

[Holly0521]

Hi @Austin-Hu,

the first issue is 100% reproduced on Ubuntu 19.04 running on Intel(R) Core(TM) i5-6600K.

Also the issue is reproduced on Fedora 27 running on virtual machine on VMWare.

The stack trace of the executing process at hanging might be helpful:

1 futex_abstimed_wait_cancelable futex-internal.h 205 0x7fedd46fc086 2 do_futex_wait sem_waitcommon.c 111 0x7fedd46fc086 3 __new_sem_wait_slow sem_waitcommon.c 181 0x7fedd46fc178 4 EbBlockOnSemaphore 0x7fedd43cd299 5 EbGetEmptyObject 0x7fedd43ccf73 6 EbH265EncSendPicture 0x7fedd4391dc2 7 main main.cpp 78 0x56238b3fe5a9

I used to have the same problem and I used the engine is ffmpeg.

[Austin-Hu]

Hi @rexvl & @Holly0521 , sorry for the late replying. Could you check whether PR #475 + #508 could help address this issue? Thanks!