• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 98 subscribers
  • Views 355 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

dvrrdk 4.1 encoder link not releasing input frames when b frames enabled

abadobid
Intellectual 300 points

In our use case we need to dynamically enable/disable bframes, so we call Venc_setDynamicParam(.. VENC_BFRAME_RATE) to change the interFrameInterval as needed while the encoder channel is enabled.


After calling Venc_setDynamicParam a number of times (usually 3 when interFrameInterval==3), it looks like all the input frames are tied up in the encoder.

EncLink_h264EncoderFlush() is being called in encLink_h264.c when the interFrameInterval is changed, but it doesn't look like it is actually flushing the buffers from the encoder.

If I #undef ENC_LINK_ENABLE_APP_BUFFER_TRACKING_FOR_H264 in encLink_priv.h, then I no longer have the problem.

Index: dvr_rdk/mcfw/src_bios6/links_m3video/iva_enc/encLink_priv.h
===================================================================
--- dvr_rdk/mcfw/src_bios6/links_m3video/iva_enc/encLink_priv.h	(revision 474)
+++ dvr_rdk/mcfw/src_bios6/links_m3video/iva_enc/encLink_priv.h	(working copy)
@@ -198,7 +198,7 @@
/** @brief Internal - This macro should be enabled always to have input buffer tracking logic in application
   *  for H.264 B frame data flow. There is a random hang observed (HDVICP code corruption) with FLUSH.
   *  XDM_FLUSH following by process calls is required to unlock buffers which doesnt seem to work reliably. 
   *  App tracks input buffers to / from codec to avoid buffer locking & does not invoke FLUSH on parameter changes
   */
-#define ENC_LINK_ENABLE_APP_BUFFER_TRACKING_FOR_H264    
+//#define ENC_LINK_ENABLE_APP_BUFFER_TRACKING_FOR_H264
 
 /*
  *****************************************************************************

From the comments above the define, I imagine #undef this will cause other problems though.

  • 0
    Intellectual 300 points

    After running some more it looks like #undef ENC_LINK_ENABLE_APP_BUFFER_TRACKING_FOR_H264 isn't enough to fix the problem.  When I dynamically change the number of bframes, eventually all the input frames still end up being tied up in the encoder.

    So looking at the function EncLink_h264EncoderFlush() in encLink_h264.c, I see that if ENC_LINK_ENABLE_APP_BUFFER_TRACKING_FOR_H264 is defined, then it does not issue a XDM_FLUSH command to the encoder, but instead just calls Utils_encdecUnlockAllBuffers() via the ENC_H264_UNLOCK_ALL_BUFFERS macro.

    Utils_encdecUnlockAllBuffers() simply sets the locked buffer count to 0 (all buffers unlocked), but I don't see how these frames could make it back to the link.  It looks to me like any frames that were in the pChObj->buffersTrackInfo (locked up in encoder) are now simply lost.  They are never returned to the prev link.

    I'm not all that familiar with how the encoder link buffer management should work so maybe I'm missing something, but I don't see how this could work.