Opened 7 months ago

Last modified 7 months ago

#7855 reopened defect

Last subtitle in MP4 is displayed forever

Reported by: fumoboy007 Owned by:
Priority: normal Component: avformat
Version: git-master Keywords: mov mov_text
Cc: Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: no

Description

Summary of the bug:
Decoding the last tx3g subtitle in an MP4 produces an incorrect duration, causing the subtitle to stay on-screen until the end of the media.

How to reproduce:
Play the attached file in VLC. Also, run the following command and compare the outputted subtitle file with the original subtitle file (also attached).

$ ffmpeg -i Permanent\ Last\ Subtitle.mp4 -map 0:s:0 FFmpeg\ Output.srt
ffmpeg version 4.1 Copyright (c) 2000-2018 the FFmpeg developers
  built with Apple LLVM version 10.0.0 (clang-1000.11.45.5)
  configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1_1 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-lzma --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-librtmp --enable-libspeex --enable-videotoolbox
  libavutil      56. 22.100 / 56. 22.100
  libavcodec     58. 35.100 / 58. 35.100
  libavformat    58. 20.100 / 58. 20.100
  libavdevice    58.  5.100 / 58.  5.100
  libavfilter     7. 40.101 /  7. 40.101
  libavresample   4.  0.  0 /  4.  0.  0
  libswscale      5.  3.100 /  5.  3.100
  libswresample   3.  3.100 /  3.  3.100
  libpostproc    55.  3.100 / 55.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Permanent Last Subtitle.mp4':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp41mp42isom
    creation_time   : 2019-04-18T05:09:42.000000Z
  Duration: 00:01:05.04, start: 0.000000, bitrate: 431 kb/s
    Stream #0:0(deu): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m), 640x360, 289 kb/s, 23.97 fps, 23.98 tbr, 24k tbn, 48k tbc (default)
    Metadata:
      creation_time   : 2019-04-18T05:09:42.000000Z
      handler_name    : Core Media Video
      encoder         : AVC Coding
    Stream #0:1(deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 137 kb/s (default)
    Metadata:
      creation_time   : 2019-04-18T05:09:42.000000Z
      handler_name    : Core Media Audio
    Stream #0:2(eng): Subtitle: mov_text (tx3g / 0x67337874), 640x54, 0 kb/s (default)
    Metadata:
      rotate          : 0
      creation_time   : 2019-04-18T05:10:26.000000Z
Output #0, srt, to 'FFmpeg Output.srt':
  Metadata:
    major_brand     : mp42
    minor_version   : 1
    compatible_brands: mp41mp42isom
    encoder         : Lavf58.20.100
    Stream #0:0(eng): Subtitle: subrip (srt), 640x54 (default)
    Metadata:
      encoder         : Lavc58.35.100 srt
      creation_time   : 2019-04-18T05:10:26.000000Z
Stream mapping:
  Stream #0:2 -> #0:0 (mov_text (native) -> subrip (srt))
Press [q] to stop, [?] for help
size=       0kB time=00:00:45.25 bitrate=   0.0kbits/s speed=3.59e+04x    
video:0kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 79.069771%

Attachments (2)

Permanent Last Subtitle.mp4 (1.6 MB) - added by fumoboy007 7 months ago.
Subtitle.srt (42 bytes) - added by fumoboy007 7 months ago.

Download all attachments as: .zip

Change History (14)

Changed 7 months ago by fumoboy007

Changed 7 months ago by fumoboy007

comment:1 Changed 7 months ago by fumoboy007

This is reproducible with any MP4+tx3g file. I’m surprised this bug made it through!

comment:2 follow-up: Changed 7 months ago by cehoyos

  • Version changed from 4.1 to unspecified

Please test current FFmpeg git head to make this a valid ticket (there is no release support on this bug tracker) and please suppress your comments if you want a developer to look at your tickets.
Do not attach output files unless specifically asked to.

comment:3 Changed 7 months ago by mkver

  • Resolution set to duplicate
  • Status changed from new to closed

Duplicate of #6341.

comment:4 in reply to: ↑ 2 Changed 7 months ago by fumoboy007

Replying to cehoyos:

Please test current FFmpeg git head to make this a valid ticket (there is no release support on this bug tracker)

This policy does not make sense in this context where I have submitted a test file and command to reproduce the problem. I have my own commits on top FFmpeg; rebasing onto master and rebuilding takes a lot of time. I have given you exactly what you need to reproduce the problem; you can do so using the latest commit if you so desire.

and please suppress your comments if you want a developer to look at your tickets.

I don’t understand what you mean by “suppress your comments”.

Do not attach output files unless specifically asked to.

Please tell me you’re joking…

comment:5 follow-up: Changed 7 months ago by mkver

  • Component changed from undetermined to avformat
  • Keywords mp4 mov_text added
  • Resolution duplicate deleted
  • Status changed from closed to reopened
  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.

comment:6 Changed 7 months ago by mkver

  • Reproduced by developer set
  • Version changed from unspecified to git-master

comment:7 in reply to: ↑ 5 Changed 7 months ago by fumoboy007

Replying to mkver:

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.

I would like to help debug this, but I have no knowledge of the format. Is there somewhere I can freely download the MPEG-4 Timed Text specification (is that the right one?) or is there some document that summarizes the specification?

  1. 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.

Oh, I see git head is more than a thousand commits ahead of the releases. OK, I will spend the extra time to test on git head for future bug reports in case the issue is already fixed.

  1. 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.

Sorry for the false claim. My “surprised” comment was not meant to be accusatory; sorry if it came off that way. That being said, it would have been more productive to post a concrete rejection of the claim rather than a passive-aggressive response.

comment:8 Changed 7 months ago by mkver

The mp4 file format is described in ISO/IEC 14496-12 ("ISO base media file format"); timed text is described in ISO/IEC 14496-17 ("Streaming text format").

comment:9 follow-up: Changed 7 months ago by mkver

ISO/IEC 14496-17 is absolutely uninformative for this question:
"[T]o each text access unit a single time stamp applies. The time stamp assigned to a text access unit indicates the time at which the text access unit is to be presented on the display."

And the reason for this is that the carriage of timed text in mp4 is actually described in 14496-30, a document which doesn't seem to be available for free.

comment:10 in reply to: ↑ 9 Changed 7 months ago by fumoboy007

Replying to mkver:

ISO/IEC 14496-17 is absolutely uninformative for this question:
"[T]o each text access unit a single time stamp applies. The time stamp assigned to a text access unit indicates the time at which the text access unit is to be presented on the display."

And the reason for this is that the carriage of timed text in mp4 is actually described in 14496-30, a document which doesn't seem to be available for free.

Ah! Does this draft have enough information?

comment:11 Changed 7 months ago by fumoboy007

I submitted a patch that fixes this.

comment:12 Changed 7 months ago by cehoyos

  • Keywords mov added; mp4 removed
Note: See TracTickets for help on using tickets.