1

I learned how to transcode MKV video to MP4 with HEVC (x265) video encoding to make the files smaller in a way that makes it all compatible with iOS. But while the process is great — and the compression is great with low file size — when I try to merge subtitles into one specific video, the resulting MP4 video I get a pile of errors out of FFmpeg like this:

[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3152805999 / timestamp: 3154741000 is out of range for mov/mp4 format

I am using macOS Mojave (10.15.2) with FFmpeg 4.2.1 installed via Homebrew, but the problem persists even if I download the nightly build (ffmpeg-4.2.1-macos64-static, 20191215-9fe0790) and use that binary instead of the Homebrew installed version.

The issue is I have this one video I have successfully converted to an MP4 with x264 video and AAC audio in the past and have been able to merge SRT subtitles as well into the resulting file without issue. But when I create an MP4 using HEVC (x265) video today from the same exact source, the SRT subtitle merge fails with those “pts has no value” and “is out of range for mov/mp4 format” errors.

This is the command I use to create the HEVC (x265) MP4 video from an MKV source:

ffmpeg -i input.mkv \
       -map_metadata -1 \
       -vf scale=-1:720 \
       -c:v libx265 -crf 20 -c:a aac -b:a 128k \
       -threads 4 \
       -tag:v hvc1 -sn \
       -map 0:0 -map 0:1 output_hevc.mp4 \
       ;

And this is the command have used successfully in the past to merge SRT subtitles into an existing MP4 without re-encoding:

ffmpeg -i output_hevc.mp4 \
       -i input.srt \
       -c:v copy -c:a copy \
       -c:s mov_text -metadata:s:s:0 language=eng \
       output_final.mp4 \
       ;

I think the issue might be that for about 50% of the video there are no subtitles; only in the second 50% of the video are subtitles needed.

The video in question is about 2 hours long. And for the first 50 or so minutes, there is no need for English subtitles. But around 50 minutes in, that is when the subtitles kick in.

So the subtitles in the SRT begin like this:

1
00:52:33,123 --> 00:52:50,123
It was a dark and stormy night…

But when I run the above FFmpeg command, the output is something like this; times a bit fudged for example’s puropose:

Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
  Stream #1:0 -> #0:2 (subrip (srt) -> mov_text (native))
Press [q] to stop, [?] for help
frame=25560 fps=0.0 q=-1.0 size=  304640kB time=00:52:00.00 bitrate= 791.7kbits/frame=50730 fps=50726 q=-1.0 size=  681984kB time=time=00:52:00.00 bitrate=1772.4kbit[mp4 @ 0x7facb9002000] Application provided duration: 3152137000 / timestamp: 3152137000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3152805999 / timestamp: 3154741000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3153246998 / timestamp: 3156809000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3154051997 / timestamp: 3159013000 is out of range for mov/mp4 format
[mp4 @ 0x7facb9002000] pts has no value
[mp4 @ 0x7facb9002000] Application provided duration: 3155556996 / timestamp: 3163817000 is out of range for mov/mp4 format

And tons of similar messages until, et voila! The merge ends, no subtitles are viewable and there is that.

This is driving me nuts! I mean if I use the same command, but specify a seeking time that begins at around the point where subtitles come in I actually see the subtitles on the 50% of the video that needs them:

ffmpeg -I output_hevc.mp4 \
       -i input.srt \
       -c:v copy -c:a copy \
       -c:s mov_text -metadata:s:s:0 language=eng \
       -ss 3120 \
       output_final.mp4 \
       ;

But I need more than 50% of the video, of course. Heck, I even just tried this command; I can get the subtitles to merge with the MP4 if I set the seeking to any value equal or greater than 1005 seconds:

ffmpeg -i output_hevc.mp4 \
       -i input.srt \
       -c:v copy -c:a copy \
       -c:s mov_text -metadata:s:s:0 language=eng \
       -ss 1005 \
       output_final.mp4 \
       ;

But what is so magical about 16.75 minutes (1005 seconds) in the context of this?

Why can I get the subtitles to be merged if I only select the times the subtitles appear in the second 50% of the video but not if I run the command to merge the full video?

FWIW, if I run a similar command to create an MKV of the video, all is fine!

ffmpeg -i output_hevc.mp4 \
       -i input.srt \
       -c:v copy -c:a copy -c:s copy \
       output.mkv \
       ;

Just somehow this merging with mov_text makes the process fail it seems.

And if I add a bogus subtitle at the beginning of the file like this:

0
00:00:00,000 --> 00:16:75,000
Foo!

1
00:52:33,123 --> 00:52:50,123
It was a dark and stormy night…

Everything works as desired! Except for having the word “Foo!” showing up for 50% of the video. Obviously not ideal.

Is there any way around this? Is this an FFmpeg bug or perhaps an issue with HEVC (x265) video with subtitles being merged?

2

Seems like adding a bogus subtitle at the beginning of the SRT file that spans from the beginning of the video to about where the subtitles begin fixed this issue.

This solution is clearly a “hack” but it works.

Riding off of my idea to add a bogus subtitle at the beginning of the SRT file, I realized that SRT subtitles — according to the SRT specs — allow for HTML tags. Knowing that I added the following bogus subtitle and it all works!

0
00:00:00,000 --> 00:16:75,000
<b></b>

1
00:52:33,123 --> 00:52:50,123
It was a dark and stormy night…

That’s it! Just adding an empty bold tag allows it all to work and for the subtitles to be merged…


But — as stated at the outset — this is clearly a hack and I am open to hearing more from others who know more about FFmpeg. I can only assume none of this issue reflects desired behavior and there must be a more elegant way to deal with cases like this. Or is this a bug (not a feature) and should be reported?

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.