CUVIDMPEG2PICPARAMS frame_num/GOP/PoC/TSN

I’m trying to rearrange captioning and need the frame number / picture order count or really any way to figure out the order of the frames with the cuvidparser on the HandlePictureDecode callback that only exposes CUVIDPICPARAMS. H264 exposes PoC but MPEG2 doesn’t appear to. While a state machine for IPBBP → IBBP would work for perfect video, dropped/lost frames are problematic to detect.

I noticed that CUVIDMPEG2PICPARAMS has the following params:
int ForwardRefIdx; // Picture index of forward reference (P/B-frames)
int BackwardRefIdx; // Picture index of backward reference (B-frames)

I can’t make heads or tails of what these numbers mean while stepping through each frame. Can anyone shed any light on what exactly these parameters refer to? I basically need some way to identify what frame was passed to HandlePictureDecode. I even tried looking at pBitstreamData but it seems (?) the MPEG2 Picture Header is not included so I can’t parse for the TSN.

For instance:

TSN | FRAME TYPE | ForwardRefIdx | BackwardRefIdx
0 | I | -1 | -1
3 | P | 0 | -1
1 | B | 0 | 1
2 | B | 0 | 1
6 | P | 1| -1
4 | B | 1 | 4
5 | B | 1 | 4
9 | P | 4 | -1
7 | B | 4 | 7
8 | B | 4 | 7
12 | P | 7 | -1

Well, I’m guessing ForwardRef and BackwardRef are actually opposite of their names(?).

ForwardRefIdx seems to be what the frame references in the past while BackwardRefIdx seems to reference frames in the future, at least when thinking about a GOP in Display Order. While the indexes given are how the frames were discovered in the encoded bitstream.

Hi VelaK,

Answering your question about “ForwardRefIdx” and “BackwardRefIdx” they are index of forward and backward reference indexes of the frame being decoded(which is indicated by CUVIDPICPARAMS::CurrPicIdx). Can you elaborate what exactly you are trying to do or looking for? That will help us answer your questions better.

Thanks,
Ryan Park

Hi Ryan,

The gist of the problem was I basically needed the Temporal Sequence Number of the current frame so I could match it up with external content while decoding and encoding content. It doesn’t seem to expose that while H264 does expose the equivalent PoC field in the cuvidparser HandlePictureDecode callback.

I ended up solving my problem another way, but I still think it would be useful to expose in the future.