sample_embedding_folder2/0684296.txt

Ticket Name: RTOS/TDA2: Encode link latency variations

Query Text:
Part Number: TDA2 Tool/software: TI-RTOS Hello everyone! We have two issues regarding Encode link latencies. Issue 1: We have created two use cases with the excerpts given in the images attached below. Namely, in the case of the first image, we use one instance of Select link, that forms the output consisting of one queue comprising four channels. This output is fed into the Encode link instance, that performs H.264 encoding on all of the four input channels. We have set the following intra-frame interval (between two I-frames): pLinkDynPrm->intraFrameInterval    = 10; The Encode link feeds one instance of Null link. The latency measured by the "Print statistics" option (P key) outputs the value of ~36 ms for the Encode link. In the case of the second image, instead of using one instance of Null link for all of the 4 channels, we use 4 instances of Null link (one Null link per channel). Hence, the output from the Encode link (1 Q, 4 CHs) is firstly fed into a Select link that forms 4 Qs, each comprising 1 CH. The latency measured by the "Print statistics" option (P key) outputs the value of ~86 ms for the Encode link. Issue 2: In the case we set the intra-frame interval to the value 1 (every output frame is an I-frame): pLinkDynPrm->intraFrameInterval    = 1; the latency of the Encode link is ~18 ms when encoding one Q with 4 CHs. Hence, we can notice that the encoding latency is greater when generating P-frames. Is there any explanation of these two issues and is there any configuration that might be performed on the Encode link to decrease these latencies below 20 ms when generating P-frames? Best regards, Marko

Responses:
Hi Issue <1> I expect encode latency to be the same in both cases. BTW, what are you doing in Null link, just a termination or some File write etc.? If the output buffers are not fed back to encode link the latency numbers might shows high Please use single null link with 4ch. Issue <2> Yes, this is expected, encoding with P and B frames will take more processing cycles compared with I frame only encode. with P and B frames we can achieve lower bit-rates (higher compression) and hence more processing cycles regards, Shiju

Hi, Shiju! Thanks for your reply. We use multiple Null links to transmit four video streams to four individual devices. So, in our case, the Null link(s) perform outputs on the Ethernet. If I understand well, there is some kind of bufferbloat between the Encode link and Null links since the Null links are not able to output buffers to the Ethernet opportunely? If this is the case, it is possible to occur in our environment. Regarding the second issue, I have to note that we are not allowed to generate B frames, so we generate only I and P frames. Is there any solution to reduce this latency when generating frames of these two types only? Best regards, Marko

Hi Marko <1> yes, if the null links are not able to fee-up the output buffers of encoder link, you might see higher latency numbers. <2> Not powerful options, but you can try below encode option change pLinkChPrm->encodingPreset = SYSTEM_XDM_MED_SPEED_HIGH_QUALITY; to SYSTEM_XDM_HIGH_SPEED or SYSTEM_XDM_HIGH_SPEED_MED_QUALITY But please note that this will not give any big boost. regards, Shiju

Hi, Shiju, Thank you for your response. We will perform the observation of the free buffer get function results from the Encode link to get aware of free buffers availability during the execution. Also, we will set the proposed "encodingPreset" parameter flags and compare the statistical data with our current set-up. Best regards, Marko

Hi, Shiju! We have set the "encodingPreset" parameter SYSTEM_XDM_HIGH_SPEED and we have succeeded to speed up the encoding process, thus decreasing the latency from 88ms to 16ms. Best regards, Marko