We are using IPNC 3.5.0 on a DM8127. Back in March of this year, I posted a question (http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/252361.aspx) about B-frames and was told that they are not supported, apparently because the existing buffer handling cannot deal with the out-of-order frame generation that B-frames involve. However, the documentation on the H.264 encoder itself (ti_tools/codecs-dm814x/REL.500.V.H264AVC.E.IVAHD.02.00.04.01/500.V.H264AVC.E.IVAHD.02.00/IVAHD_001/Docs/H264_Encoder_HDVICP2_UserGuide.pdf) explicitly says that B-frames are supported. And indeed, if I set encPrm.chCreateParams[i].defaultDynamicParams.interFrameInterval to 2, I get an H.264 stream that contains B-frames.
However, there are a few mysteries: In the first GOP of the stream, the first B-frame is missing. That is, the first GOP begins I, P, B, P instead of I, B, P, B, P, and is of size 15 instead of 16. The structure of the subsequent GOPs is correct. Also, the size of the encoded stream is more than twice as big as the same file encoded at the same bitrate without B-frames. And, if I use ffmpeg to convert the encoded streams back to YUV and compare them to the original YUV file to determine the peak signal to noise ratio (PSNR), the PSNR of the stream that included B-frames is significantly worse (by about 5.5 dB) than that of the stream encoded without B-frames. Finally, if I set the interframeInterval to 3, the call to System_linkCreate() for the encoder hangs.
Are B-frames still considered unsupported? If so, can anyone provide advice on how I could overcome the problems noted above? Thanks.