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.

The dithering issue on DM368-MT5 IPNC

Hi all!
Did any other one purchase the Appro DM368-MT5 IPNC? I find a serious problem on this design.


If I confiured the IPNC as single 1080P 30fps H.264 stream output and the rate control type is CBR,then the problem is:
the video will dither slightly every 1-2 second.In drak or strong contrast lighting environment,the issue is more clear and serious.


if I change the rate control type to be VBR, then problem changed to be:
the dithering problem is relieved to some extent, but the video is not as smooth as the CBR type, the moving object sometimes is blocked for a very little time. and even worse, the screen sometimes is put into gray entirely and then recover to be normal.


I don't think the above issues is related to the PC. It has AMD Athlon X3 425 CPU and 2GB DDR3 1333MHz memory.

btw:

I also change the stream to be other resolution and the MPEG4 codec, the problem is still same to described as above.
My test version is Appro DM368-MT5 ver2.0.0 release.
I want to kown whether this problem is originated from DM368 chips or Appro software design or the DVSDK version?I have used the DM355 in a camera project,I didn't find this type of problem on DM355 before.
Can TI or Appro provide a quickly solution to this problem?
Thank you very much!

  • Hi,

     

    When you use CBR, there are frameskips to maintain bitrate, so you might see some issues when bitrate is low.

    Put 1080p@30 TO 8MBPS, then you not observe this issue.

    However, please send me the video prams you are using from Video page and Video Advacned page

     

    Regards,

     

    Raghu

     

  • 4857.config.rarHi,Raghu! Thank you for your kindly reply!
    I have configured my IPNC according to your advice.Unfortunately,I find that If I set the bitarate as 8Mbps for H.264 1080P 30fps CBR, the dithering issue relieved a lot, but it sometimes block the moving object for a very little time(same to the above VBR situation), that is to say, the 8Mbps video is not as smooth as 4Mbps'.

    pls check my video prams enclosed!

     

  • Hi Raghu!

    I noticed that my DM368-MT5 IPNC rate control type have only OFF,CBR and VBR. There is no CVBR control type in the selection and software design.

    Buf the CVBR type exists in other DM368 IPNC(the sony sensor IMX036) and DM355 IPNC. I want to konw why do you remove this type in the DM368-MT5 design.

    Is it the reason for the dithering and blocked?

    Thank you very much!

     

  • Hi,

     

    We have named CVBR as VBR as this algo was wrongly put in earlier versions.

     

    We are also redesigning CVBR algo and will be available in version 2.5 targetted end of nov

     

    Regards,

     

    Raghu

     

  • Hi Pavel,

    Try changing  dynamic parameters  of the h264 encoder as shown  below in the file alg_vidEnc.c:

    pObj->dynamicParams_h264.rcQMin=  1;

    pObj->dynamicParams_h264.rcQMax = 30 ;

     

    Check it if this woks for you.

    Also change in avServerUi.c:

                config->encodeConfig[i].cropWidth                              = ALIGN_ENCODE(1920);
                config->encodeConfig[i].cropHeight                             = ALIGN_ENCODE(1080);

     

     

    Regards,

    Mahendra  Kumar

     

     

     

     

     

     

     

  • sorry it should be :

     

    pObj->dynamicParams_h264.rcQMinI=  1;

    pObj->dynamicParams_h264.rcQMaxI = 30 ;

     not

     

    pObj->dynamicParams_h264.rcQMin=  1;

    pObj->dynamicParams_h264.rcQMax = 30 ;

     

     

     

    i.e. change the rate control setting  of the I frame , to avoid this problem.

     

     

     

    Regards,

    Mahendra

  •  Hi Mahendra!

    I have modified the rcQMaxI and rcQMinI parameter as you advised and test it detaily.

    Following is my test result:

    If I set a larger rcQMaxI(bewteen 40 and 51) parameter,the entire image will dither apparently about every 1-2s. The larger of rcQMaxI, the more apprent of the dithering.

    If I set a smaller rcQMaxI(bewteen 30 and 40) parameter,the moving object will be blocked for a very litter time(but the feeling is very apparent).

    so I want to konw what is the exact reason for the block and dithering?

    I want to control the timestamp of h.264 packet by myself,that means i don't need any timestamp info in the h.264 encode packet, and I will add timestamp on the packet by myself.is it possible?how should i do?

    Anyway, Thank you very much for your kindly reply!


  • Hi pavel,

    I am not able to see any blocking here with the above  settings. Probably the brightness and contrast settings of the scene here varies from you.

    To be sure can you put some debug information  , if the timestamp between the two frames is more than 30ms.

    I am also testing here.  I do not see any frames being missed here.

     

    Regards,

    Mahendra kumar

     

     

     

     

  • Hi Pavel,

           You are right. I could see blocking of the encoding , if I set rcQMaxI=30 in constant bitrate mode. Particularly when the bitrate is very low. 

    I think in constant bit rate mode , if the encoded frame is not fitting with in a particular size, then that frame is skipped. This is bad for us.  Anyway in variable bit rate mode this problem is solved.

     


     


     


  • Hi All,

    I'm not sure what "dithering" means exactly. But, it seems that I faced the similar issue.

     

    In CBR, Image quality might be degraded or some frames might be dropped to meet the target bitrate when it is quite low.

    But, it seems that image quality for I-frame is quite differ from one for P-frame when the target bitrate is low. (It was a steady scene. There was no action or something to increase bitrate.)

    i.e. Image quality is good for I-frame but, it is getting worse for P-frames. And then, it becomes good again for the next I-frame. This repeats every second.

     

     

    I used a default values for Q-related parameters.

    If I narrow down Q-ranges, there is no difference between I-frame and P-frame.

    But, framedrop is observed. There was no frame drop with default Q-ranges.

     

    I benchmarked the other IP Camera for the same target bitrate.

    It showed a consistent image quality for I-frame and P-frame.

     

    For CBR with low target bitrate, how can i get a consistent image quality over I-frame and P-frame minimizing frame drops?

    FYI, I used DM368 and H.264 version is 02.00.00.10.

     

    Best Regards,

    Jinkyu Park