Hi,

Under load we can reproduce what may be a deadlock in the DNx encoder. Note we have four client threads encoding frames in parallel. After having processed hundreds of frames, at some point the four calls to DNX_EncodeFrame will never return. Using gdb I inspected the various threads. This is on Linux on a HP Z820 using SDK v. 2.2.1.9. Here's the stack for the four client threads (same for all four):

#0 0x000000301ae0b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007fffefa56c42 in TF_WaitForAnyEvent(dummy_EventGroupObj_type*) () from .../libDNxHR.so
#2 0x00007fffefa58925 in ThreadForeman::ExecuteJob(ErrorMode_t, unsigned int) () from .../libDNxHR.so
#3 0x00007fffefa84daf in HDEncoder::doEncoding(unsigned char*, unsigned char*) () from .../libDNxHR.so
#4 0x00007fffefaa4f1a in DNXEncoder::encode_frame(void*, void*, unsigned int, unsigned int, unsigned int*) () from .../libDNxHR.so
#5 0x00007fffef637e52 in DNX_EncodeFrame () from .../libDNxHR.so

There are also fourteen DNx worker threads with the following stack (same for all):

#0 0x000000301ae0b5bc in pthread_cond_wait@@GLIBC_2.3.2 () from /lib64/libpthread.so.0
#1 0x00007fffefa56c42 in TF_WaitForAnyEvent(dummy_EventGroupObj_type*) () from .../libDNxHR.so
#2 0x00007fffefa5921f in ThreadProc(void*) () from .../libDNxHR.so
#3 0x00007fffefa574aa in thread_impl::ThreadProc(void*) () from .../libDNxHR.so
#4 0x000000301ae079d1 in start_thread () from /lib64/libpthread.so.0
#5 0x000000301a2e88fd in clone () from /lib64/libc.so.6

Note this is not specific to one image. When tried again the same image will encode fine but the process will hang again later while processing other frames.

Is this a known issue? How can I help resolving this? 

Thanks,

Eric

We have upgraded to DNx SDK 2.2.2.22 and the problem remains.

Eric

Hello Eric,

We couldn't reproduce the issue. Could you please desribe in details the workflow, that you are using. Is this case reproducible on Win\Mac? What kind of Linux are you using. How often the case reproduces (1 from from 1 000, 1 000 000)? What encoder settings are used?

Hi Oleksii,

I could not test this same scenario on Mac or Windows. We use Linux RHEL 6.2. It would happen after encdoing a few thousand frames, in HQX and 444, 10bit, with UHD frames (3840x2160).

Please note we were creating a fresh encoder before encoding each frame. This was certainly a factor. 

We have now changed our code to cache encoders and use DNX_ConfigureEncoder. This is much faster and the problem does not happen anymore.

Regards,

Eric

Just in case: if you don't change parameters there is no need to reconfigure a codec each time. Also it could be helpful to have several codec instances with unique settings and use appropriate one for each case.