[FFmpeg-trac] #7855(avformat:reopened): Last subtitle in MP4 is displayed forever

[FFmpeg]

#7855: Last subtitle in MP4 is displayed forever
-------------------------------------+-------------------------------------
             Reporter:  fumoboy007   |                    Owner:
                 Type:  defect       |                   Status:  reopened
             Priority:  normal       |                Component:  avformat
              Version:  unspecified  |               Resolution:
             Keywords:  mp4,         |               Blocked By:
  mov_text                           |
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------
Changes (by mkver):

 * keywords:   => mp4, mov_text
 * resolution:  duplicate =>
 * status:  closed => reopened
 * component:  undetermined => avformat


Comment:

 1. My earlier claim was wrong. This is not a duplicate of #6341.
 2. In fact, #6341 was fixed some time ago.
 3. The differences between interm.mp4 from #6341 and this sample are as
 follows:\\
  a) interm.mp4 has an empty packet at timestamp 0 and empty packets to end
 both subtitle lines; so there are five packets and dts deltas are 3s, 10s,
 2s, 2s and 0. This means that the packet's dts values are 0s (the first
 sample always has dts 0 (before edit lists are applied), 3s, 13s, 15s,
 17s, which means that the actual subtitle lines timestamps are from 3s-13s
 and 15s-17s. (I don't know if the last dts delta entry is necessary or
 not.)\\
  b) The sample from this issue is different: It has two samples (for one
 line of subtitles) and two entries in the stts containing two dts deltas:
 5s and 3s, so that the dts of the first sample (the "empty" sample) is 0s
 and the time of the second sample (containing the actual subtitle) is 5s.
 And if there were another sample, then this sample would have a dts of 8s.
 But there isn't. Furthermore, the track as a whole has a duration of 8s. I
 am not sure whether this file is completely spec-compliant; I am leaning
 to yes.
 4. Even if this file isn't spec-compliant, one could nevertheless support
 it. In this case this ticket might become a "wish". But I'll leave it as
 defect for the time being.
 5. Modified versions of FFmpeg are even more unsupported than release
 versions. So you actually should not rebase your own commits on current
 git head, but just test current git head.\\
  The rationale for this policy is that it would waste developer's time to
 test something that might already have been fixed.
 6. The comment cehoyos wants you to suppress is surely "I’m surprised this
 bug made it through!". The claim you base this on is btw wrong as the
 sample from #6341 shows.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/7855#comment:5>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker