GOP SIZE on DM36x Codecs

Hi Sujit,

Can you please share encoder params and encoded stream?

Thanks,

Veeranna

Hi Veeranna,

folowing are the encoder parameters.

=========Encoder STATIC PARAMS=========
(pParams->videncParams).encodingPreset   =2
(pParams->videncParams).rateControlPreset   =5
(pParams->videncParams).maxHeight   =1080
(pParams->videncParams).maxWidth   =1920
(pParams->videncParams).maxFrameRate   =20000
(pParams->videncParams).maxBitRate   =10485760
(pParams->videncParams).inputChromaFormat   =9
(pParams->videncParams).reconChromaFormat   =9
(pParams->videncParams).dataEndianness   =1
(pParams->videncParams).maxInterFrameInterval=0
(pParams->videncParams).inputContentType=0
pParams->meAlgo   =0
pParams->profileIdc   =100
pParams->enableVUIparams   =0
pParams->levelIdc   =40
pParams->entropyMode   =0
pParams->transform8x8FlagIntraFrame   =1
pParams->transform8x8FlagInterFrame   =1
pParams->seqScalingFlag   =1
pParams->encQuality   =3
pParams->enableARM926Tcm   =0
pParams->outputDataMode   =1
pParams->sliceFormat   =1
pParams->enableDDRbuff   =0
pParams->sliceMode    =0

=========Encoder DYNAMIC PARAMS=========
(pDynParams->videncDynamicParams).inputHeight   =1080
(pDynParams->videncDynamicParams).inputWidth   =1920
pDynParams->maxBitrateCVBR   =10485760
pDynParams->LBRskipcontrol   =0
pDynParams->LBRmaxpicsize   =0
pDynParams->LBRminpicsize   =0
pDynParams->rcAlgo   =3
(pDynParams->videncDynamicParams).targetBitRate   =6990506
(pDynParams->videncDynamicParams).intraFrameInterval   =0
(pDynParams->videncDynamicParams).generateHeader   =0
(pDynParams->videncDynamicParams).captureWidth   =1920
(pDynParams->videncDynamicParams).targetFrameRate   =20000
(pDynParams->videncDynamicParams).refFrameRate   =20000
(pDynParams->videncDynamicParams).forceFrame   =-1
(pDynParams->videncDynamicParams).mbDataFlag   =0
(pDynParams->videncDynamicParams).interFrameInterval   =0
pDynParams->sliceSize   =0
pDynParams->airRate   =0
pDynParams->intraFrameQP   =28
pDynParams->interPFrameQP   =28
pDynParams->initQ   =28
pDynParams->rcQMax   =48
pDynParams->rcQMin   =18
pDynParams->rcQMaxI   =48
pDynParams->rcQMinI   =18
pDynParams->mvSADoutFlag   =0
pDynParams->enableROI   =0
pDynParams->metaDataGenerateConsume   =0
pDynParams->maxDelay   =2000
pDynParams->lfDisableIdc   =0
pDynParams->enablePicTimSEI   =0
pDynParams->enablePicTimSEI   =0
pDynParams->perceptualRC   =1
pDynParams->idrFrameInterval   =150
pDynParams->resetHDVICPeveryFrame   =2
pDynParams->aspectRatioY   =1
pDynParams->aspectRatioX   =1

=========OUTARGS PARAMS=========
m_pOutArgs->extendedError =0
m_pOutArgs->bytesGenerated =0
m_pOutArgs->encodedFrameType =-1
m_pOutArgs->inputFrameSkip =0
m_pOutArgs->outputID =1

I need a quicker response this. Hope you Understand.

-- Thanks

Sujit

Hi,

Params looks OK; please attach stream with issue.

Hi Veeranna,

attached the stream for 640x480 resolution. Its an avi recorded file, kindly use VLC Player to play it.

Hi Sujit,

I wanted to play in some analyzers and/or decode with JVT decoder. When I extract .264 from your avi I am getting some syntax error.

Can you try decode .264 using JVT at your end; and send the 264/avi without any error.

Once can you also try encQuality =2/0.

Thanks,

Veeranna

Veeranna,

also attached the yuv stream of the same for 640x480 h264 encoded stream.

Veeranna,

you can play the stream using VLC/QuickTime player. Its recorded in AVI formate so that you can play it to visualize the exact problem in any players.

Also i sent you another stream of the same in YUV format has been captured via file operation immidiate after encode has been done.

i checked with encquality =2 , High quality mode , but there is absolutely no difference.

Yes I have seen corruption in VLC and to analyze the issue we want open stream in analyzer(MB type, Mv etc). Your 2nd stream has many IDRs and it doesnt have any issue.

sujit mahapatro said:

i checked with encquality =2 , High quality mode , but there is absolutely no difference.

You mean you seen corruption or you didn't see.

i mean same corruption like you observed in the stream before.

Veeranna,

i have attached some encoded frames captured frame by frame. Hope this will help you to analyze.

Resolution is 640x480 and FPS = 20 , Bitrate - 10 MBps

Veeranna ,

Is there any findings.

Can you please share the encoded *.264 file before putting it into *.avi container.

We tried to get *.264 from the *.avi, but we got syntax errors. So if you can share *.264 file itself, we can look into the problem.

Rgds, Veeranna

_Veeranna,

_{I have already sent you the *.h264 file for some 500 frames in my last post. again attached for your reference.}

_{The files with extension *.yuv is actually *.h264 files has been captured immidiate after H264 encoder Process() call.}

Sujit,

If you are sending *.h264 for individual frames, we cant be able open in analyzers(as you know P frame and SPS/PPS dependency ).  Pls write encoded stream in one file for 200-300 frames.

Attached the *.264 filr for 400 frames , resolution 2048x1536, 20fps.

Kindly verify and let me know.

Also i request TI to verify the same with latest H264 encoder with GOP size 150 on their EVM.

Veeranna,

Just to add, you  might have observed in the avi stream this problem looks to be at the edges of images. So is there any codec parameter which looks into the image edges ?

Any further update Veeranna ?

Veeranna,

kindly let me know the updates. Have you tested with GOP size 150 on TI EVM at your side.

We need to come a conclusion quickly. If it is a problem from codec side and reproduced at your end also then we can fix some time with customer.

If this problem is happening only at our side then we need to figure out and resolve soon.

Hope TI understand our concern.

1565.Images.zipSujit,

I have decoded the stream you sent (2048x1536 ) by JVT; it decodes fine. Here attaching two images; one from elcard stream analyzer and other from decoded yuv.. At frame num 150 you can see diff behavior.

Our stream analyzer also doesn't show any corruption.

I guess its issue with decoder/player you are using.

Thanks,

Veeranna

Veeranna,

in the attchment the file name "decodedYUV" file looks to be fine but file name "elcardView " seems to be the problem.

So i am not able to figure out if decoder has problem then why "elcardView "  looks similar to the avi file i sent.

Do you mean elcard decoder also have problem ?

Please explain me clearly about the 2 images you have sent.

Hi,

decodedYUV image is YUV decoded from JVT decoder and elcardView image  is when we play stream in elcard player. So elcard has also an issue.

You can try to decode same stream with JVT decoder at your end, observe the decoded output.

Veeranna,

I don't have JVT decoder. I tested it on MainConcept decoder, Quicktime, VLC.

All have standard decoder's has the same problem.

Hi,

.264 you shared plays fine even in VLC(1.1.10 version) and JVT decoder is free,  Google it you will get complete package with source code. If binaries not available build it.

Veeranna,

VLC has the same problem.

Now i was testing same enviornment on DM365 with GOP 150, and i don't see any problem with our decoder and Mainconcept, VLC .

Do you think if decoder has problem DM365 it will work ?

I am very confused now what could be the reason. Please provide your input.

Hi,

I am not getting you. You mean you are not able to see the issue now?. Initially you sent me .avi which has issue when you play in VLC decoder. I also doubt your container format; when I extracted .264 from .avi I got the error. It should not be the case. So to conform this please play .264 then .avi.

currently are you playing .264 or *.avi ?

1. The files we shared and the problem we were checking was from DM368. and the avi container was just to record the data and to send TI, it has no relation with decoder.

2. Once you said Decoder has problem, i tried to test with GOP size 150 on DM365 and i found there is no problem.

So i was trying to clarify from you following ...

> If the decoder has problem then how does everything works fine on DM365 while i tested ?

> Why On DM365 same problem is not reproduced where as on DM368 it produces ?

The only difference between DM365 and DM368 is DM365 capture max resolution 1280x1024 and DM368 camera capture resolution is 2048x1536.

Even i tested for smaller resolutions on DM368 based camera but same problem persists.

sujit mahapatro said:

> If the decoder has problem then how does everything works fine on DM365 while i tested ?

Open the stream.264 you sent to me in Elcard and decode same stream using JVT decoder compare the picture around 150th frame. There you can see corruption in Elcard but not in JVT decoded YUV.

sujit mahapatro said:

Why On DM365 same problem is not reproduced where as on DM368 it produces ?

If you are seeing difference DM365 and DM368 then codec nothing to do here. Same codec software running in DM365 and DM368 so NO issue in codec software.

Have you verified input YUV you are feeding to encoder in case of DM368?

Veeranna,

I have checked with many standard decoders and every where same problem.

Only JVT reference decoder , i didn't find the problem which you have already mentioned.

from TI side please verify with different decoders. We can not say all standard decoders have problem.

Hi All,

this problem Has been resolved. Decoder side no issues.

Encoder dynamic parameter airRate i have configured for macroblok insertion in P frames based up on the resolution and frame rate.

pDynParams->airRate = (int)((((getHeight()*getWidth())/(16*16)))/(profile.framerate/1000));

And it works fine, i mean there is no visible difference in the video streams.

Thanks a lot To Veeranna for continuous support to resolve this issue.

Veeranna,

After setting airRate the video quality is ok for GOP=150 but i am finding some other problem.

The problem is the 1st video stream is taking more time for display.

Intially i am getting no frames for few millisecond and then it starts.

Can you suggest me what could be the reason ?

What other things i need to take care if setting airRate parameter.

My previous setting for airRate was 0.

With airRate 0 the streaming starts immidiately.

I need to understand the side effects of  airRate.

Why setting airRate to some value delays my 1st video frame for few ms.

Is there any other parameters i need to take care ?

Hi Sujit,

How you are sending bitstream to decoder? frame by frame or bunch of frames?. airRate parameter will not change anything in I frame. It forces desired number of MBs to I MBs randomly in P frames. With airRate and without airRate there should not be any change in I/IDR frames. And inP frame there might be some increase in bytes generated.

To my understand with airRate = 0 you are seeing corruption and with airRate !=0 you are not seeing is that right?

>> To my understand with airRate = 0 you are seeing corruption and with airRate !=0 you are not seeing is that right?

Yes you are right. Not for any values of airRate it works. airRate i have calculated as i mentioned ( widthxheight/16x16)/framerate.

>>How you are sending bitstream to decoder? frame by frame or bunch of frames?

Frame by Frame

Actually i tested manytimes , as soon as i make airRate = 0 , the 1st frame of video stream comes immidiately in with out any delay but with airRate value

it takes few ms to come.

can you let me know why airRate causing such problem ?

It should not cause any problem. Do you have any logs from decoder side? like whether it received bitstream properly or any other information. At decoder end please check it received 1st IDR and able to decode it. 

Decoder receives the 1st IDR after few ms only and once it receives its able to decode properly.

Can you check is that delay causing by encoder(by checking time across process call with and w/o air)?, air comes into picture only in P frames.

Veeranna,

The process call it self taking all the extra time with airRate changed value.

Following are the time taken by process call, with airRate =0 and with airRate= (w*h/16*16)/20  for resolution 2048x1536, 20 FPS, Continuous Mode for GOP=15 and GOP=100.

pDynParams->airRate = 0, GOP=15 i.e pDynParams->idrFrameInterval = 15

--------------------------------------------------

time taken for process frame -1 = 59 ms

 time taken for process frame -2 = 58 ms

time taken for process frame -3 = 57 ms

time taken for process frame -4 = 46 ms

time taken for process  frame -5 = 45 ms

 time taken for process frame -6 = 45 ms

time taken for process frame -7 = 45 ms

 time taken for process frame -8 = 47 ms

.............................

pDynParams->airRate = (w*h/16*16)/20  , GOP=100  i.e pDynParams->idrFrameInterval = 100

---------------------------------------------------------------------------

time taken for process frame -1 = 9396 ms

 time taken for process frame -2 = 6032 ms

time taken for process frame -3 = 5928 ms

time taken for process frame -4 = 6052 ms

time taken for process  frame -5 = 45 ms

 time taken for process frame -6 = 46 ms

time taken for process frame -7 = 46 ms

 time taken for process frame -8 = 50 ms

........................

Veeranna,

Can you check the Process call time taken and suggest me.

Hi Sujit,

Very first frame will take more cycles and airRate related calculation will happen. But I am not sure why 3-4 frames are taking more time at your end.

Veeranna,

Let me know how to resolve this issue ?

Because with this much delay we can not use our app. with up to 5sec GOP.

You need to check the same at your side in encoder, as process call itself taking the time from our side we can not do any thing.

We are waiting to resolve this issue at the earliest.

Sujit,

This is expected.  First frame process call will take more cycles as it has to some calculation related to airMBRate.

What about next 3 frames of the process call timing ?

Even for 1st Process call timing nowhere in TI documents mentioned about it.

For next 3 frames you are forcing frame as IDR or I frame. If you send Single at IDR at start you will not see more cycled consumed by process call.

In Datasheet  we mention average processing time by running over 1000 frames. Looks this info needed we will add this info in next releases.

Veeranna,

sorry i couldn't get you.

Do you mean to force Next 3 frames as IDR frame ?

Currently my 1st frame is IDR and next all frames are P frames.

No I dnt want you to force the frame as IDR or I. If you force you will see more cycle consumption by process call.

The stream you sent to us has starting 4 frames as I or IDR. Can you conform again only 1st Frame is IDR, remaining are P.

I have verified at our end, If you are forcing the frame as I or IDR then  we are seeing delay in process call. In normal case we are seeing only 1st frame takes more cycles.

Veeranna,

attached the stream with GOP=100 and airrate = (int)((((getHeight()*getWidth())/(16*16)))/(profile.framerate/1000));

Following is the time taken for the attached stream.

Process Call Timing Frame:1 = 8610

Process Call Timing Frame:2 = 6064

Process Call Timing Frame:3 = 6142

Process Call Timing Frame:4 = 6084

Process Call Timing Frame:5 = 45

Process Call Timing Frame:6 = 45 

Process Call Timing Frame:7 = 46

Process Call Timing Frame:8 = 51

........

Please check it.

HI

below are the numbers We are getting for 2048x1536

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 257396

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42347

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42266

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42283

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42504

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42310

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42359

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42450

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42318

CODEC_DEBUG_ENABLE: PROCESS LEVEL FRAME CYCLES = 42683

Can you run once on standalone testapp check the numbers?

You mean to test the same running my Camera on Stand Alone mode ?

Currently i am using NFS mode.

No. Run file based stand alone app provided with encoder release package.