Our code (derived from the jetson-ffmpeg project) is using NvVideoDecoder class. What we’re seeing is that at some point the order in which v4l2_buffer are dequeued is different from that of them being queued.
I’m seeing the order of buffers DQed being FIFO for awhile, and then it changes.
Consider this log:
problem2.txt (393.7 KB)
In line 160, rather than receiving back the buffer 7, it is buffer 9. Buffer 7 then isn’t seen until line 194. Buffer 8 isn’t seen until line 644.
I don’t think client-side code has anything to do with it, as all the Qing/DQing occurs in context of a single thread. Any ideas what could it be? This is TX2/Jetpack 4.6.
The encoded h264 stream may not be encoded in display order so you may feel like misorder happens. Actually decoder has decoded the stream and put frames in display order. So you can get frames in capture plane in correct order.
FYI, the sample h264 stream is encoded not in display order. You may add index to each buffer at output plane and capture plane to check it.
I understand that B-frames happen; however this particular bitstream doesn’t have those - only I- and P-frames. Everything is in display order.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.