DVSDK 4.02 + Codecs

Hi Samer,

You can download the latest encoder and decoder from the link

http://software-dl.ti.com/dsps/dsps_public_sw/codecs/DM36x/index_FDS.html

Upgrade should be simple copy paste.

What kind of artifacts are you observing? Is it in the encoder output or the decoder output?

Hi Adithya,

Thanks for your reply, so DVSDK4.02 does not have the latest codecs?.

The artifacts observed are smudges and/or color changes, like if i move in front of the camera there is like a smudge on the movement area but it corrects itself after a while. This keeps happening only on movement.

I am not sure it is on the encoder or the decoder but I can tell you this I did a test Encoder -> Computer streaming and there were no artifacts.So im guessing it is the decoder.

Best Regards,

Sam

Hi,

Please find the attached video displaying the artifacts... I have updated the codecs and my problem still presists

7713.MOV00389.MPG

Best Regards,

Sam

Hi,

This gets more bizzare if i dont add "input-src" on my pipeline as composite which it is the output is shown below. No artifacts are shown but the colors are green and red as you can see.... I dont have a clue now what is wrong any help would be appreciated.

3107.MOV00391.MPG

Best Regards,

Sam

Hi Samer,

Is the issue fixed?

Somehow the post got missed.I apologize for the delay..

Hi Adithya,

This problem still presists and I have not got a definative answer as yet. For the time I have just moved to using mpeg4 since that works fine. It would be really helpful if I could be advised to whether it is my problem or something is wrong with the codecs. I also tried to downgrade the codecs the problem still presisted.

Best Regards,

Sam

Hi Sam,

Can you please share your all parameters of encoder and decoder? Are you seeing this issue after upgrading to DVSDK4.x ? And can you please check is output bitstream of encoder is fine?

please have a look at following post it  may helpful

http://e2e.ti.com/support/embedded/f/356/p/117162/417071.aspx#417071

Thanks,

Veeranna

Hi Veeranna,

My DVSDK is 4.x. I would not be much intrested to check the encoder as encoder streaming - > PC  -> decode on VLC or any other client works well. There are no smudges or artifacts which eliminates it as a potential problem.

The problem arises with Encoder Streaming -> Board Decode which does not work well and presents the artifacts. Im not sure what parameters are you after as this is all being done in TI GStreamer (I have checked everything there and it all seems fine).  Im not sure if you support gstreamer but since it was a possible decoder problem I thought I would post here. Any help would be appreciated.

Best Regards,

Sam

Hi Sam,

Its Decoder DPB issue, please share decoder create time( members of struct IH264VDEC_Params or IVIDDEC2_Params )and dynamic parameters(IH264VDEC_DynamicParams or IVIDDEC2_DynamicParams) . And what value you are setting for "frame_closedloop_flag"?. If you are setting to '0', please set it to '1' and try. Please also tell me how you are initializing DPB buffers required by decoder? Please have look at testapp  provided with decoder package and post mentioned earlier

Thanks,

Veeranna

Hi Veeranna,

Please find the link to the files which is the only file I can find in the gstreamer codec plugin for the TI's Build. I dont see this setting closed_loop_flag anywhere nor can I see the DPB buffers which you have mentioned.....please let me know if this is what you are looking for....

https://gstreamer.ti.com/gf/project/gstreamer_ti/scmsvn/?action=browse&path=%2Fbranches%2FBRANCH_DDOMPE%2Fgstreamer_ti%2Fti_build%2Fticodecplugin%2Fsrc%2F

files are: ti_encoders.c

Best Regards,

Sam.

Hi Sam,

You are using base parameter mode,  decoder mode will be universal and display delay parameter will be 16. I am not sure you are allocating DPB of size 16. To decode bitstream encoded by TI's Dm36x encoder ClosedLoop  decoder mode is enough, its has lesser memory footprint.

You need to use extended parameter mode and extended param will have closed_loop_flag flag, set it to 1. From gsttividdec2.c file please check what value you are setting for dmaidec->params and dmaidec->dynParams structure parameters. Please see the code under macro "EXTENDED_PARAMS_ARGS" in "TestAppDecoder_ih264_arm926.c" present at  \packages\ti\sdo\codecs\h264dec\apps\client\test\src directory to know more info on extended parameters. Please check User Guide also.

Thanks,

Veeranna

Hi Veeranna,

Thanks for your reply and the help. Im still struggling to figure out where I should add the params->frame_closedloop=1 as this is supported by gst-ti project. I have tried grepping my sources to see where the parameter might be being set and I cannot find it..... it is only found in the dvsdk codecs -> ih264dec.h and nowhere else.

Ive looked at the example you have mentioned but the same problem I dont know where to add this in the gstreamer.....

On a side note i think you might be right on the problem being for the closed loop because when I run a pipeline from the board I get a few messages saying "cannot decode frame" for a while and then it plays the stream. After then with few intervals I get the same messages "unable to decode frame "

Best Regards,

Sam

I can now confirm this is a problem with the frame_closed_loop and setting that to 1 has solved the issue for me... this followed by correct IDR frame generation tweaking from the h264 decoder. This change has been done by DDOMPE himself to support the frame_closed_loop as an extended argument.

Thanks Veranna again for pointing in the right direction.

Best Regards,

Sam

Hi Sam,

Its nice to know your issue is solved. 

For your information, its not issue with frame_closed_loop, Its issue with application which not allocating enough reference buffers. There is one more param called displayDelay and stream behavior will control reference buffer requirement. DM36x decoder has two 2 modes: Universal mode( frame_closed_loop = 0)it can decode all h264 streams.It may need reference buffers up to 16 depending on streams. 2nd mode is ClosedLoopMode( frame_closed_loop = 1) this decoder mode will decode streams only generated by TI DM36x encoder.TI's DM36x encoder uses 2 reference buffers, so allocating 2 reference in decoder will be enough to decode these streams.

Above information will be useful when you use DM36x decoder ( Universal mode frame_closed_loop = 0) to decode streams other than TI DM36x.

Hi Veranna,

So does this mean dispDelay corresponds to the number of reference buffers being allocated? If that is true then what is a good value to set this at for Universal Decoder to work?. Also if true then how do these values vary with the reference buffers being allocated?. I ask since this has also been implemented and i can set this value at runtime.

Best Regards,

Sam

Hi Sam,

Please refer below link to know about displayDelay and buffer requirement by decoder.

http://focus.ti.com/general/docs/lit/getliterature.tsp?literatureNumber=sprab88&fileType=pdf

To decode TI encoder stream try to set displayDelay = 0 and use Universal Decoder mode, it will work. Universal mode and closedLoop mode have performance difference. CloosedLoop mode is faster it can decode 1080p@30fps with limitation of it can only decode TI's DM36x encoder' streams. You can see datasheet for performance numbers.

If you are using decoder in cloosed loop system (ENCODE[TI's DM36x] - DECODE), better you use ClosedLoop decoder.

Hi Veeranna,

I have tested the decoder with dispdelay=0 and closedLoop=0. I was able to decode the stream but with the smudging artifact problem which had persisted earlier. However it works fine for the closedLoop. My system at the moment is actually closed loop so it would be fine. This would be interesting to solve for the future though.

 

Best Regards,

 

Sam