DM8168 Capture_encode demo frame rate query

Simon Brown

Ok, I'm confused now. I'm running the EZSDK 5.02 capture encode OMX demo with an analogue 720p60 signal coming in on the IO card. I run it with parameters:

-o test.bin -m 720p -f 60 -b 10000000 -n 500

So at 500 frames limit, 60 frames per second, it should capture for about 8.3 seconds. My timing isn't very accurate, but it's capturing for more like 16 seconds, ie the frame rate is closer to 30 frames per second. Having said that, it also seems to have all the frames! I've checked the analogue signal on the scope, and it measures 60Hz frame rate.

Any clues? Is this to do with the DEI component? The frame counter is in the write to bitstream task on the output of the encoder, so is the encoder dropping frames? I don't think it is, but am confused where the frames are going to.

Cheers,

Simon

over 13 years ago

0 Archith John Bency over 13 years ago

TI__Intellectual 2910 points

Simon,

You are quite close to the answer. The issue is indeed with the VFPC DEI component. The default subsampling behavior of the DEI is such that it drops alternate output frames. This can be worked around in the capture-encode application by adding these lines of code inside the function in the capture_encode demo source:

OMX_ERRORTYPE IL_ClientSetDeiParams (IL_Client *pAppData)

{

OMX_CONFIG_SUBSAMPLING_FACTOR sSubSamplinginfo = {NULL};

OMX_INIT_PARAM(&sSubSamplinginfo);

sSubSamplinginfo.nSubSamplingFactor = 1;

eError = OMX_SetConfig ( pAppData->pDeiHandle, ( OMX_INDEXTYPE )

( OMX_TI_IndexConfigSubSamplingFactor ),

&sSubSamplinginfo );

}

This bug fix is to correct the default behaviour of VFPC DEI in the firmware. This should be available in the next SDK release. (SDK v5.0.3)

Archith

0 _Ralph_ over 13 years ago in reply to Archith John Bency

Guru 10685 points

Hi,

Can I chip in and say that after applying this change to the code, although it is a better situation that skipping every other frame, I find that the encoder is still skipping frames.

I have a 720p60 clip fed into the IODC that has _lots_ of graphical changes in. I would say that every encoded H264 frame would have to be an I-frame because of the large graphical transitions between frames. During the encoding, the HDMI output shows a smoothly playing clip as expected. I am encoded at 10Mbps and 60fps.

When I then play that encoded clip back (using the decode_display demo) slowly at 1 frame per second, it is obvious that quite a few frames are skipped, and some are repeated to make up for the skipped ones.

If I double the encode bit rate to 20Mbps the problem does not occur.

Does the encoder work by simply dropping and repeating encoded frames if it cannot keep up with being pushed to low encoding bit rates? This is my theory, I'd like to hear if it is true or not.

On this subject, where can I get a datasheet for the H264 encoder from?

Thanks,
Ralph

0 Simon Brown over 13 years ago in reply to _Ralph_

Intellectual 340 points

Hi Ralph,

I think I can answer you to some extent, though without any proof.

A while ago, I changed the capture_encode demo to output on the serial port the size of each H264 frame. The first time I ran it, I noticed that a whole bunch of frames were 37 bytes long (or similar). I then looked more closely at my command line and noticed that I had asked for 1Mbps, not 10Mbps. When I switched to 10Mbps it was fine. Admittedly, this was when I was still running the DEI with subsampling, so actually only doing 30fps. The 37byte frames were essentially saying no-changes (I think), not because there weren't any, but simply because it had run out of bandwidth. Having changed to 60fps I can still run at 10Mbps but my video isn't quite as tricky as yours, I suspect.

Good call about running it through the decode_display demo at 1 fps - I hadn't thought of that as a way of "single stepping" as it were.

And a datasheet for the H264 encoder would be nice - I'll second a request for that!

Cheers,

Simon

0 Deepak Poddar over 13 years ago in reply to Simon Brown

TI__Expert 4725 points

Hi Ralph

If codec is configured for low delay use case then Encoder will skip the frames to achieve the bit rate. However skipping of frame is seemless to the decoder/system, as that frame is encoded with every MB as skip MB.

Increasing the bit rate will lower down Or completely eliminate the frame skips.

Regards

Deepak Poddar

0 Simon Brown over 13 years ago in reply to Deepak Poddar

Intellectual 340 points

Hi Deepak,

Thanks for explaining. One question - you say "if codec is configured for low delay use case...." - where is this configured? Any ways of changing it?

Cheers,

Simon

0 _Ralph_ over 13 years ago in reply to Simon Brown

Guru 10685 points

Hi Simon and Deepak,

Thanks for your replies. Like Simon, I would like to know: where can I configure the "low delay use case"? I've just been through the OpenMAX IL document and also TI's OMX user guide without finding anything conclusive.

Thanks,
Ralph

0 _Ralph_ over 13 years ago in reply to _Ralph_

Guru 10685 points

Anyone know how to configure the "low delay use case"?

Processors

Processors forum

DM8168 Capture_encode demo frame rate query