Does SDK provide method to calc PTS and DTS for every encoded frame?

[Jetsen_W_]

I'm using the SDK for h.264 encoding and muxing. when i read the example of "msdk_ffmpeg_integration", i found that the sdk handles PTS as follow:

mfxStatus FFMPEGWriter::WriteNextFrame(mfxBitstream *pMfxBitstream, bool isPrint) 

{

++m_nProcessedFramesNum;

AVPacket pkt;
av_init_packet(&pkt);

AVCodecContext *c = m_pVideoStream->codec;

m_pVideoStream->pts.val = m_nProcessedFramesNum;

pkt.pts = av_rescale_q(m_pVideoStream->pts.val, c->time_base, m_pVideoStream->time_base);

....

}

It just simply use the ProcessedFramesNum to calc PTS,but i think it's not the best(or correct) method.

As I know, h.264 has I、P、B frame, and the PTS will not be continuous,so how can I get the correct PTS and DTS?

[Petter_L_Intel]

Hi,

Intel Media SDK does not do much with regards to handing timestamps. Essentially, all the Media SDK components are transparent to timestamps, it is up to the application layer to manage this function.

However, if you check out the Media SDK tutorial (http://software.intel.com/en-us/articles/media-sdk-tutorial-tutorial-samples-index) sample which is showcasing ffmpeg transcode you will find a simple example on how to deal with PTS and DTS in application layer. Also note that recent Media SDK API release also introduced a new feature that allows encoder to calculate DTS from the input PTS.

The sample you refer to is from an older article where timestamp management was large simplified/ignored.

Regards,
Petter 

[Jetsen_W_]

Petter Larsson (Intel) wrote:

Hi,

Intel Media SDK does not do much with regards to handing timestamps. Essentially, all the Media SDK components are transparent to timestamps, it is up to the application layer to manage this function.

However, if you check out the Media SDK tutorial (http://software.intel.com/en-us/articles/media-sdk-tutorial-tutorial-samples-index) sample which is showcasing ffmpeg transcode you will find a simple example on how to deal with PTS and DTS in application layer. Also note that recent Media SDK API release also introduced a new feature that allows encoder to calculate DTS from the input PTS.

The sample you refer to is from an older article where timestamp management was large simplified/ignored.

Regards,
Petter 

Dear Petter

Thanks for reply.

I've downloaded the Media SDK Samples, and I'll test new method in the article.

BTW, is there some docs about  new feature for calculating DTS you mentioned?

Thanks.

[Petter_L_Intel]

You can find the documentation about DTS (DecodeTimeStamp) calculation in the Media SDK reference manual.

[Jetsen_W_]

Petter Larsson (Intel) wrote:

You can find the documentation about DTS (DecodeTimeStamp) calculation in the Media SDK reference manual.

thank u.

[Jetsen_W_]

Hi, Petter
I deal with PTS and DTS as you said by using follow codes:
mfxStatus CMux::WriteNextFrame(mfxBitstream *pMfxBitstream, bool isPrint)
{
MSDK_CHECK_ERROR(m_bInited, false, MFX_ERR_NOT_INITIALIZED);
MSDK_CHECK_POINTER(pMfxBitstream, MFX_ERR_NULL_PTR);

printf("PTS=[%d], DTS=[%d]\n", pMfxBitstream->TimeStamp, pMfxBitstream->DecodeTimeStamp);

...
}
and I get the result:
PTS=[0], DTS=[-7200]
PTS=[14400], DTS=[-3600]
PTS=[7200], DTS=[0]
PTS=[3600], DTS=[3600]
PTS=[10800], DTS=[7200]
PTS=[28800], DTS=[10800]
PTS=[21600], DTS=[14400]
PTS=[18000], DTS=[18000]
PTS=[25200], DTS=[21600]
PTS=[43200], DTS=[25200]
PTS=[36000], DTS=[28800]
...

this result seems to be right, but strange thing is that the first DTS(and second DTS) has a negative value,is that something wrong? Maybe I made a mistake?

Best Regards

[celli4]

Degang,

The decode timestamp [DTS] indicates when the frame must be decoded, and the presentation time [PTS] indicates when the frame must be displayed.

To display a frame at time zero, you better have decoded it before time zero, or at time zero. So, I believe the negative DTS numbers are fine.

if you notice, the DTS are increasing consisently at 3600 cycles per frame (1/25th sec @ 90khz), so it is saying decode the frames in order, but the PTS is jumping around, this is because the encoder reordered the frames for referencing and efficiency reasons.

Cameron

[Jetsen_W_]

camkego wrote:

Degang,

The decode timestamp [DTS] indicates when the frame must be decoded, and the presentation time [PTS] indicates when the frame must be displayed.

To display a frame at time zero, you better have decoded it before time zero, or at time zero. So, I believe the negative DTS numbers are fine.

if you notice, the DTS are increasing consisently at 3600 cycles per frame (1/25th sec @ 90khz), so it is saying decode the frames in order, but the PTS is jumping around, this is because the encoder reordered the frames for referencing and efficiency reasons.

Cameron

Thank you for explanation, I understand.the DTS and PTS.