[FFmpeg-trac] #11055(avcodec:reopened): OGOP (Open GOP) in certain conditions may cause missing frames of decoding

[FFmpeg]

#11055: OGOP (Open GOP) in certain conditions may cause missing frames of decoding
-------------------------------------+-------------------------------------
             Reporter:  markfilipak  |                    Owner:  (none)
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:  avcodec
              Version:  git-master   |               Resolution:
             Keywords:  everything   |               Blocked By:
  OGOP                               |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Comment (by pdr0):

 Replying to [comment:189 markfilipak]:
 > Replying to [comment:188 pdr0]:
 >
 > May I respond here?
 >
 > > As for the other issues, eg. the 1st frame in coded order specifies a
 frame_num of 227 and pic_order_count_lsb as 362 in this 99 frame sample...
 >
 > Oh, dear. Where can I see that, and how can I fix it? ...You see, I
 don't know how to parse M2TSes.


 The issues with POC, frame_num are for the AVC/h264 elementary bitstream,
 not for m2ts specifically. If you demux to elementary video stream, the
 problems remain - this is likely from improper cuts and handling

 You can use one of video stream analyzers such as the ones listed above,
 I'm sure there are several others, newer ones. I'm not up to date on all
 the tools .  I just know ffmpeg/ffprobe has long standing issues with IDR
 identification, and when you make bad cuts and joins, problems happen

 >
 > > another issue is the values are supposed to increase in decoding order
 according to the specs, but there are examples where they  decrease.
 >
 > Oh, dear, again. Decreasing DTS is obviously very bad. I thought I
 checked every DTS. Can you show me where in my composite listing DTS
 decreases (or just give me the DTS value).
 >


 frame_num specifies the decoding order and should never decrease. You need
 a parser which can examine slice headers. e.g. in stream decoding order
 frame 25 has a frame_num of 243, but frame 26 has a frame_num of 228 . I
 suspect this is from bad cuts/appending .

 I wouldn't waste too much time on this.  If you can demonstrate errors
 with a valid stream, then it should be investigated farther
-- 
Ticket URL: <https://trac.ffmpeg.org/ticket/11055#comment:191>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker