Opened 11 months ago
Last modified 11 months ago
#10408 new defect
decoder sometimes reporting pts values in incorrect order
Reported by: | csab6597 | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avcodec |
Version: | 6.0 | Keywords: | |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Decoding video data through C api I found that in some situations the frames coming out of the avcodec_receive_frame()
function have their pts values not in the correct order, whilst the picture data itself seems to be in correct - that is display - order.
Check the video file provided. Have a look at the pts values by
ffprobe 02.mp4 -show_frames -select_streams 0
excerpt
... [FRAME] pts=478478 pkt_dts=480480 pict_type=P coded_picture_number=478 [/FRAME] [FRAME] pts=479479 pkt_dts=481481 pict_type=P coded_picture_number=479 [/FRAME] [FRAME] pts=481481 pkt_dts=482482 pict_type=B coded_picture_number=481 [/FRAME] [FRAME] pts=480480 pkt_dts=483483 pict_type=P coded_picture_number=480 [/FRAME] [FRAME] pts=482482 pkt_dts=484484 pict_type=P coded_picture_number=482 [/FRAME] ...
You find that the pts values are in proper order up to codec_picture_number=479
Probably because suddenly a B frame is coming up, the next frame in the list is reported to be 481, but when looking at the raw image data in the AVFrame
of that frame, it is indeed frame number 480 to be displayed. So the remedy for me right now is to swap the pts values between 480 and 481.
In the file provided this mixup will repeat again several times.
uploaded sample media through http://streams.videolan.org/upload/