Latest post Fri, Dec 18 2015 3:55 PM by OleksiiK. 4 replies.
Page 1 of 1 (5 items)
Sort Posts: Previous Next
  • Mon, Nov 30 2015 10:32 PM

    • Eric V
    • Not Ranked
    • Joined on Tue, Jun 23 2015
    • Posts 19
    • Points 215

    Encoder deadlock?

    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

  • Mon, Dec 7 2015 6:51 PM In reply to

    • Eric V
    • Not Ranked
    • Joined on Tue, Jun 23 2015
    • Posts 19
    • Points 215

    Re: Encoder deadlock?

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

    Eric

  • Thu, Dec 17 2015 1:05 PM In reply to

    • OleksiiK
    • Not Ranked
    • Joined on Mon, Dec 23 2013
    • Posts 25
    • Points 270
    • Avid Developer Moderator

    Re: Encoder deadlock?

    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?

  • Thu, Dec 17 2015 9:30 PM In reply to

    • Eric V
    • Not Ranked
    • Joined on Tue, Jun 23 2015
    • Posts 19
    • Points 215

    Re: Encoder deadlock?

    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

  • Fri, Dec 18 2015 3:55 PM In reply to

    • OleksiiK
    • Not Ranked
    • Joined on Mon, Dec 23 2013
    • Posts 25
    • Points 270
    • Avid Developer Moderator

    Re: Encoder deadlock?

    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.

Page 1 of 1 (5 items)

© Copyright 2011 Avid Technology, Inc.  Terms of Use |  Privacy Policy |  Site Map |  Find a Reseller